|
OpenSourceSustainabilityPlan
Plan for open source and sustainability aspects of project
(TODO: discuss this with OSS-watch, especially the section Summary thoughts on sustainability) IntroductionThis page documents a plan for creating an open source project that is sustainable as such beyond the initial funding period. It draws upon advice from OSS-Watch, particularly the page at http://wiki.oss-watch.ac.uk/StartYourProject. Identify communityThis project has arisen from previous work that aims to facilitate the publication of research data on the web, so that it can be reviewed, and re-used in the generation of new insights, and to avoid the costs of unnecessary repeated experimentation. This has involved a combination of biological researchers, classical arts researchers, and semantic web experts. User community: initially, small research teams, particularly in life-sciences and classical arts; later, almost anyone who uses a computer to gather, organize and disseminate data. Developer community: initially, me and maybe some close colleagues; later, semantic web developers, academic software developers, and hopefully more. Source code licenceThe MIT licence has been chosen as it is simple and permissive. I believe sustainability for this project is maximized by lowering the barriers to adoption or adaptation, even if that means some users may "free-ride". Experience suggests that most will not. Documentation licenceDocumentation is released under the Creative Commons Attribution licence (http://creativecommons.org/licenses/by/2.0/uk/) - this is chosen as being similar in spirit to the MIT licence for code. Collaborative decision makingThe project welcomes contributions from anyone who has an interest in its goals, and explicitly aims to encourage participation. This decision making (or "governance") model aims to indicate to potential contributors the ways in which they may engage with the project. See: In the style of the examples at http://wiki.oss-watch.ac.uk/ExamplesOfOpenSourceGovernanceModels
Community toolsTools for communicationsIntended tools for communication are:
The mailing list is open for anyone to view, but posts from non-members will be held for moderation. (If spam proves to be a problem, membership may be required for posting messages.) Membership is subject to moderation. The aim is to be as open as possible while minimizing the impact of spam messages. Other tools to be considered in future:
(TODO: Description of a Project (DOAP) record) Version managementSubversion provided through a Google code project. Issue trackingIssue tracking provided buy Google code. Project managementThe key style here is lightweight. Which is not to say non-existent. My experience is that 10-15% project time spent on planning is well-spent in ensuring that the remainder of the time is used effectively. The intended style of development management is based on agile methods, though not using a specific agile methodology. Initially, the Google Code wiki will be used to collect information about the project roadmap, user stories, task breakdown and sprint plans. Later, we hope that Shuffl itself will be able to provide some of the development management tooling, in a fashion similar to Mingle. The management processes and tool usage will be subject to continuous review and re-evaluation. Getting the job done trumps consistency. See Agile ecosystem below. Contributor licence agreementSee: (TODO: I'm hoping for a form of agreement to be provided by OSS-watch, following a "distributed ownership model") Subversion repository organizationTop-level branch and tag directories, with sub-projects having separate subdirectories under trunk. (This facilitates relative file references between sub-projects, which in turn facilitate building or using the software in different environments.) Within a single Google code project, this organization is pretty much dictated in any case. Release managementSee: (TODO: outline release management process) Agile ecosystem(TODO: find IBRG notes) Sustainability optionsSee:
The clear message from the second link above is that the project will need some level of continuing input (if not income) to survive. Possible sources of future inputs include:
The conduct of Shuffl is intended to be fully open from the outset. All technical, managerial and operational decisions will be recorded here, alongside the open source code and documentation. This should help to ensure that well-motivated newcomers can learn enough about the project to make useful contributions. Infrastructure CostsUsing Google-hosted services means the project infrastructure's existence is not subject to the vagaries of research project funding. The persistent fabric of the project will be able to survive funding gaps, as long as Google continues to provide these services for free (and they do appear to have some commercial motivation to do so). Support costsThe costs of responding to users' and developers' questions. Being able to do this will always require some degree of resource input. Provide an environment that allows a community to support themselves - the Google infrastructure helps here. Support costs for the product produced by the projects initial phase may be reduced by ensuring adequate documentation and support materials are created while the project is funded. Support costs for the project itself (the ongoing community of users and developers) may be reduced is a suitably modular software architecture is adopted; i.e. requested changes to the system can be implemented through add-in modules rather than changes to the core system. jQuery's established plug-in framework might be something that can help here. The storage back-end should be abstracted, so it can be replaced at will by something that plays well in an intended deployment environment. Collaboration and consensus costsThese costs may be the hardest to defray: formal control of a project's direction and integrity needs a committed team or individual, who usually need to have an income from somewhere to support their activity. If the overhead of governance is low, then a single volunteer may be able to hold down the job, but this would not be a scalable solution. If the project is wildly successful, then it maybe can come under the wing of one of the established organizations (Apache, etc.) and use their governance structures. If the project has some commercial appeal, then maybe a company would be prepared to provide cover for this function, possibly in return for access to a skilled individual. Development costsAll the factors affecting support costs and governance costs apply, but there are some aspects of development costs that can be mitigated though the technical approach to the product:
The bottom line here would appear to be: try to avoid making expensive and constraining commitments in the software's technical design. (Maybe easier said than done, but worth trying for.) Summary thoughts on sustainability(TODO: replace this with something more positive, when I know what. OSS-Watch, can you help here?) OSS-watch says that many OS projects fail because they don't plan for success, but I'm finding it hard to understand what success might look like and what form it would take, so cannot see how to really plan for it. The only party of this analysis that feels at all satisfactory is the infrastructure sustainability. In the face of all other uncertainties, Google's continuing infrastructure support feels rock-solid. I can see that the project may be sustainable if it succeeds in just a small way, with low-overhead governance, a self-supporting community and ad-hoc ongoing development. I can also see how a project would be sustainable through attracting substantial support from further research grants or commercial interests if it is wildly successful. But the transition from small-scale to large-scale success is hard to plot, and I fail to see how to plan for it other than to understand the needs and make a conscious attempt to be flexible and opportunistic. Going though the exercise of preparing this plan, the one thing that I can see doing from the outset is being more conscious of the need to make it as easy as possible for users and developers to join in, though small as well as large contributions, and that this is something that pervades all other aspects of the project, right down to technical design issues. Collected links
|
Sign in to add a comment
Graham, the document referred to in your summary thoughts section has been published by OSS Watch, in the final version it says:
"It is therefore important to ask ourselves why projects fail to reach sustainability. In some cases this is because the project fails to achieve what it set out to achieve. In these cases one would expect the project to be allowed to disappear. However, in a distressingly large number of cases the project does reach its initial objectives, yet still fails. This is especially true in funded development work in the HE and FE sector. This kind of failure is usually caused by a failure to plan for success. That is, there is no early plan as to how the project will sustain itself when the initial seed funding runs dry, and consequently no resources are assigned to reaching sustainability. "
The link is now http://www.oss-watch.ac.uk/resources/sustainableopensource.xml
Graham, in that doc it says " TODO; link for meritocracy governance model - OSS-Watch help please?. " the link you want is http://wiki.oss-watch.ac.uk/MeritocraticGovernanceModel
A general introduction to the importance of governance models is at http://wiki.oss-watch.ac.uk/GovernanceModel.
Ross, thanks. I've updated and added links to the body. I'd still like to talk about the shape of "summary thoughts" - I really would like it to be more positive, if knowingly incomplete/open-ended