- EB cs-exim.xml
- ET cs-moodle.xml
- GH cs-sakai.xml
- RW cs-aplaws.xml
- RG cs-cocoon.xml
- SW cs-texgen.xml
- SL cs-eduapss.xml
New doc to be created by extracting salient points relating to sustainability from 7 existing case studies. RG to provide support. EB
- to assign case studies to team members, who will highlight relevant info
before brainstorm early May.
SvdW to have draft ready for ET by end May.
- Philip Hazel wrote Exim in 1995 and by the time was approaching retirement in 2007 there was still no governance model in place that would ensure that Exim survived his departure. He said that when he started writing the software in those early days "I assumed that it would be 'finished' after a year or two", this naivety has had serious implications for a piece of software that has seen huge uptake.
* Exim is far from a volunteer effort, its author's almost full-time contribution was sanctioned by his employer, the University of Cambridge, over many years.
1. APLAWS was a solution developed to meet a specific public service need (The Electronic Service Delivery initiative to make councils do more stuff online) and had substantial public funding. The work of selecting open standards and defining taxonomies for kinds of service delivered by councils was a major part of the work, was undertaken collaboratively and arguably has been more sustainable than the software itself, which seems dormant in the last 12 months. This might point to a lesson about openly developed requirements being an important component of the benefits that flow from a project.
2. Following on from 1 - your software project may be a success by dying where the real aim is to leverage institutional change ie the sustainable output is not the code but the improvement in organisation and documentation brought about as a requirement for the code.
3. APLAWS built on established code. It's basic but we should re-iterate that using established code gives access to both pre-built functionality and pre-built communities.
4. APLAWS expressed a desire to incorporate newer external standard implementations of functionality that they had had to develop themselves in the first instance. Perhaps we should say that this is something that is likely to happen especially in innovative projects, and that staying sustainable can mean bringing in more standard implementations of functionality when/if they appear.
* Governance/project structure: Moodle is run as a benevolent dictatorship, under a franchise-like partnership model. Companies around the world provide commercial support in the form of royalties, annual fees and unpaid work, thus playing an important role in helping to fund paid developers and further the development of Moodle initiatives.
* Universality: the Moodle development community strives to improve the capability of the tool so that it satisfies educational requirements around the world.
* Planning for the future: at every stage, Moodle has had an eye on the future direction of the project and set goals accordingly. At the time of writing, the project was investigating the feasibility of establishing a foundation.
* Flexibility: '... if something exciting or interesting suddenly appears out of nowhere, and we can integrate it, then we do ... Likewise, a planned feature may not get completed or may be left out from the actual release if it was completed badly.'
* OS licences support open innovation and novel services
In this case the innovation takes advantage of the ability to redistribute to open up a market and potential revenue. The value add is in the aggregation into a readily accessible (in both senses) format and the small amount of new code to make selection and access easier (the menu system and the primitive 'app store').
"EduApps is possible precisely because of the licensing conditions of the software it bundles: as most of the programs are open source licensed, anyone has the explicit freedom to redistribute and duplicate without restriction. This removes a barrier commonly found with proprietary software, where the licence restricts such uses.
EduApps is not typical of software development projects, where code is the primary manufactured artifact. Rather, it provides a service to collect, package and distribute programs and so makes them easier to access and evaluate. This is somewhat akin to a Linux distribution."
* Encouraging a diverse community will improve sustainability, but requires expand project horizons and strong leadership
Sustainability may be improved by looking beyond the project boundaries and encouraging others with closely related interests to collaborate. This may require some restructuring of code and/or processes to encourage others.
"During the consultation, we identified a significant interest in the possibility of creating an open development community of groups interested in developing similar sticks. OSS Watch believes the most sustainable community structure consists of a core open development project that supports other independent projects, including EduApps itself. This would manage the core technology such as the menu system and maintain a central pool of portable programs, along with public mechanisms for addition, review and QA. By enabling a diverse community of interested projects, this structure will allow the sharing of the core project, which is then not limited to the requirements and resources of any single project. As a result, the sustainability of all the projects is improved."
* The Sakai Educational Partner's Program was designed as an annual membership costing US$10,000, with a three-year commitment. Members received no special rights to the software over and above those of the general community via the open licence. They did, however, receive access to some SEPP workgroups and discussion lists, and a waiver of conference registration fees to send as many attendees as desired to Sakai Conferences. SEPP funds were used for community development, documentation writing, conferences, and member support for general Sakai information. SEPP membership did not initially give access to many of the workgroups that the investors used to co-ordinate the project.
* There will always be healthy reflections and questions around how Sakai might have done better or worse if it had used a more traditional open source model in the beginning. For those who lived through the tornado of the start-up period and the challenges presented by having only six partners, it is difficult to imagine that more voices with differing levels of investment would have made those times easier. It is possible, however, that the opportunities and challenges would have simply been different—not better or worse. Sakai's purposeful, but gradual, opening up throughout its two years of grant funding enabled a very smooth transition to a broader community with the Sakai Foundation. A different development model might have yielded a greater community of contributors and adopters earlier on, but it is not clear what could have been accomplished in just two years to yield enterprise-class software.
* Advertising expertise
"Notably, valuable research grants and partnerships have come from companies that may only have become aware that Nottingham possessed the expertise they sought thanks to their experience of TexGen. The TexGen development team is convinced that this sponsorship would not have occurred had TexGen not been freely and publicly available, as those companies would have been less likely to have begun using the software."
* Wider applicability of the software beyond its original use
"It allowed the group's work to spread beyond its normal field and be used in different areas."
"Prof. Long, Associate Dean for Research at the Faculty of Engineering at Nottingham University, states: "At our panel interview [for renewal of the grant], the panel members (senior academics and industry representatives) were extremely impressed by our approach [to disseminating TexGen], and in particular the very wide user base and range of applications that this had generated.""