Wed 30 Mar 2016

Ongoing maintenance of FOSS projects

Tom Clark Public Seen by 357

Tom Clark Wed 30 Mar 2016

The document as drafted really only addresses the process to release software as open source. Perhaps that is it's intended scope. But the full lifecycle of an open source project includes ongoing maintenance of the project, including tracking issues, accepting contributions of code and other assistance, and communicating with the larger community that may coalesce around the project. It's important to advise organisations that plan to release software as open source to consider and plan for these issues.


Open Data NZ Wed 30 Mar 2016

A good point Tom. The focus has been on initial release, but I can clearly see that there is a need to plan for the full life cycle. I guess the question is do we incorporate that in this initial work, or do we flag it as a phase 2 project?


Brent Wood Thu 31 Mar 2016

If you want phase 1 to be relevant to phase 2, you need to deliberately do this. Short term solutions that don't think about tomorrow can cause more problem than they solve, requiring a baby AND bathwater fix for phase 2.

If NZGOAL-SE is intended at some time to take the long term success of a software project released as open source as one of its goals (I suggest it should), then it should factor this in from day 1.

In the GPL discussion I raised some issues about the requirements for ongoing success - releasing a software project which promptly goes belly up is a waste of everyone's time (& not just open source - Lotus 123 or Wordperfect anyone?)

Also - NZGOAL & the Declaration generally are about maximising value through reuse- any software project should be planned for the long haul if reuse is the goal. Software or data.


Tom Clark Thu 31 Mar 2016

When planning and performing the initial release, some thought must be given to the longer term plans for maintenance, updates, and community involvement. This document must at least bring up the topic.

As far as the question about how to run an ongoing FOSS project goes, that's a huge and complex topic. It probably warrants a document of it's own. For some organisations, it may be true that all they can manage to post their project code to GitHub and leave it there. They may not have the resources to manage a full fledged ongoing open source project. I think that that is ok, provided that the organisation is honest about the situation (honest with itself and with outside parties) from the beginning.


Dave Lane Thu 31 Mar 2016

One extremely valuable outcome of this process would be for Gov't procurement and grant funding to recognise the need for maintenance/refactoring/infrastructure budget for the lifetime of the system in addition to any initial bulk outlay/funding.
At present, we're squandering many many resources and data sets created, for example, by our scientific community, because funding does not extend to them keep their results or other systems (e.g websites) running online indefinitely. It's a real mismatch.


Cam Findlay Sun 3 Apr 2016

FOSS community management and social aspects of shared maintenance could be better served in it's own set of guidance or borrowing from something like the online engagement guidance released on webtoolkit last year that makes mention of open source (reuse in action :smiley:)

See https://webtoolkit.govt.nz/guidance/online-engagement/

If we stick with just the licensing aspect of NZGOAL, I think what might be interesting to include is how to correctly accept contributions into Govt released projects and the licensing complexities around this. This addresses the shared maintenance aspects to some degree and leaves open for expansion in later revisions.

If a member of the public contributes some code to an existing nz govt code repository (though a Pull Request or some other peer review process), where does the copyright reside? Further, at what point is the code considered "licensed" from the member of the public to the original code repository maintainer? I believe copyright assignment in the NZ Copyright Act needs to be explicitly in "writing" (interpretation of that could be interesting in a digital world). So some sort of cross-licensing is going to be the primary mechanism here. Someone correct me if I'm wrong.

Having a way for contributions to be legally accepted and sub-licensed correctly to grow the works that is 1) not overly complicated and; 2) covers the legal aspects, would be worth addressing in the NZGOAL-SE.

I'd hope this would encourage contribution back to canonical code repositories and build communities around projects rather than further fragmentation and duplication (forking). :nz:


Dave Lane Thu 7 Apr 2016

I think there has to be an element of responsibility for FOSS projects which refers back to the original service provider/vendor or someone else who has responsibility for the code base... I think there should either be a) an ongoing modest funding stream to ensure the service provider continues supporting the development of the project, b) an expectation that doing so is a "cost of business", or c) that projects gets handed over to an independent (funded) entity for maintenance after the initial procurement terms have been satisfied... I don't think copyright assignment is a good idea in a general case, as I think it inhibits contribution (mostly because it adds complexity).


Cam Findlay Fri 8 Apr 2016

@davelane on your last point here... agree, assignment is a pain.

This raises, how can FOSS code repos effectively communicate to contributors how the project can accept (legally) code contributions. From experience, I've often used a "contributing" file in my codebase that lets contributors know that by me accepting their code they are effectively licensing it to me and then I'm sub-licensing it back under the original license type of the projects canonical repo. I think this bit is unclear in the policy as it stands and think this is in scope due to the licensing aspect of it (the point of NZGOAL is licensing guidance after all).

This is because NZ Copyright Act has a first owner clause and no mechanism to waive copyright (also the reason we might not be able to utilise CC0 under the current legislation, that is a whole other discussion! :smiley: ).

On the point about project maintenance, funding to maintain is one way, building a user community to share the maintenance is another :star:


Danyl Strype Wed 20 Apr 2016

This is actually another advantage of using GPL or AGPL (EDIT: I've moved my off-topic rant on GPL moved to the relevant thread.


Cam Findlay started a proposal Wed 20 Apr 2016

Maintenance of open source projects should be detailed in additional guidance notes. Closed Fri 22 Apr 2016

Agreement here means that: you think that NZGOAL-SE should consider referencing a set of guidance notes around long term open source project maintenance, while keeping the detailed guidance itself outside of the policy itself. Guidance notes can more easily be updated to keep up with the times where as policy takes time to adjust and is best to contain the principles that lead towards good decision making.

Agree - 6
Abstain - 6
Disagree - 6
Block - 6
6 people have voted (15%)

Edward Abraham
Wed 20 Apr 2016


Cam Findlay
Thu 21 Apr 2016


Rob Elshire
Thu 21 Apr 2016


T. Charles Yun
Thu 21 Apr 2016


Danyl Strype
Thu 21 Apr 2016

As I said in comment, maintaining an open source project is a book-length topic, but perhaps a few general principles of good stewardship could be included, particularly as they relate to license choice.


Richard Liddicoat
Thu 21 Apr 2016


Edward Abraham Wed 20 Apr 2016

While a licence is relatively straight forward, the communities around a project are likely to be as diverse as the projects. I wouldnt want people to think that releasing code as open source requires them to run a community project. In many cases, it may simply be that the agency wants the code open sourced so the cant be held to ransom, without any expectation of it turning into an active project.


Danyl Strype Thu 21 Apr 2016

In response to the original topic, making open source projects work long term is more art than science, and a number of books have been written on the topic, including Producing Open Source Software by Karl Fogel, which you can download gratis from the website. There's no way this topic could be covered in any depth in NZ GOAL, but perhaps we could distil a few principles from sources like Fogel's book, to guide the way publicly-funded open source projects might be run?

My short list would be (not in order of importance):
* public-facing version repository: accessible to any potential contributor without any requirement to use proprietary software (we've covered this elsewhere)
* develop in public ("release early, release often"): no software project is every "finished" or "tidy", at least not for long, and part of the benefit of open source practice is avoiding developers duplicating each others' work, so it helps to see the code as it evolves. I've noticed that solo developers are particularly nervous about this, fearing their code will torn apart by scornful trolls, and sadly this can happen, which leads on to...
* have community standards with teeth: pre-defining procedures for decision-making, conflict resolution, and standards of behaviour is key. The model Code of Conduct put together by the Discourse project is a good template. A culture of friendly, welcoming, constructive, communication doesn't just happen, it needs to be envisioned and modelled by project leaders (both formal and informal), and violators put in the stocks and pelted with tomatoes (they knew that would happen, as it was laid out as the sanction for their action in the CofC). Which leads on to...
* community-driven (democratic? consensus?) decision-making: GIT helps with this because a fork can become the main project if the original maintainers are not responsive to the developer community, but this is not a surefire guarantee, as we've seen with the recent ragequit of a core BitCoin developer.
* consider the ongoing costs (in $ and time) of maintaining the project's toolset; repository, homepage, email lists etc and have a business model in mind. Even if that model is depending on grants, donations, or crowdfunding, if you know in advance that's likely to be the case, you can plan to keep your project infrastructure light.


Cameron Shorter Fri 22 Apr 2016

Further: Guidance should be given to agencies as how to assess the level of open source engagement that should be invested in. Ie How much time/effort should a project contribute toward Open Source, and how should you justify the business case to put toward this investment. The answer will be different depending on the importance of the open source technologies to business goals. Investment is a sliding scale, covering: "report bugs", "provide patches", "release code", "participate in community", "lead community", "sponsor core development", "build community - through marketing, release management, answer external developer questions".


Danyl Strype Sun 24 Apr 2016

I have a document on my wiki written some time ago, which describes some of the considerations for releasing code in a bit more details. It now includes the decision tree for choosing a license I drafted for another thread.