eLife launched its first open source application, Lens, in 2013, followed by the first version of Libero, then called Continuum, in 2016. There was an expectation that holding a launch event and opening the code would attract users and contributors without additional effort. It soon became apparent that growing a community does require a specific effort and so fostering engagement with the Libero community is something we have been working on for the last two years.
Listening to the community is also very important, so it was serendipitous that the idea of holding a Libero Community Sprint came from a conversation with Paul Mollahan, Libero community member and Services Director at innovative digital consultancy, Digirati. We thought it would be beneficial for everyone who intends to work on Libero to simply “reserve a couple of weeks in the summer so we can all work on Libero at the same time”. Borrowing ideas from the eLife Innovation Sprint and post-conference sprints such as those held at DrupalCon, we set out with a number of high-level goals:
- Bring the community together
- Foster engagement
- Give people a sense of ownership
- Reduce friction for future contributions
- Broaden the diversity of ideas
- Get some community agreement
- ...and write some code!
eLife hosted the first two days as a workshop in its offices in Cambridge, UK. Attendees from Digirati, the Coko Foundation, Hindawi, eLife and the Royal Society of Chemistry flew in from places as geographically distributed as Canada, Greece and Scotland. For the first two days we expected to see “mostly coding”, “plenty of whiteboarding” and “a bit of discussion” with some potential, tangible goals including some well-named and well-structured repositories on Github, a build, test and deployment pipeline and a journal website with an article heading.
We left the agenda of the two-day workshop to the attendees, suggesting discussion topics on the day using Open Space Technology. This technique meant there would still be natural gaps for people to pair program and have informal discussions, while giving some structure to proceedings. Topics were diverse and covered items relating to all types of people present: software developers, infrastructure engineers, technologists, product managers, user experience designers and publishers.
This resulted in more discussion than we had expected, which was generally thought to be a positive thing, because it gave us the opportunity to solve problems as a community and reach agreement on areas we’d been discussing for a while.
Architecture and code
Sessions on infrastructure at the beginning ensured everyone agreed and understood the way we should deploy our applications, and a session on architecture mapped out where the various components and interactions of the system were. This was especially important as we’re working on the evolution of an existing architecture, with some parts being retained and others having to be changed in order to work for a broader use case.
The two-day workshop was followed by remote collaboration for the remainder of the two-week Sprint, with participants returning to their usual places of work while maintaining a full-time commitment to the project until the end of the Sprint. During that time we saw commits to the code made by four organisations, in twelve repositories, including one on coding standards. All of this development used the same methods of working that we would like all contributors to use, so practicing them in a short, intense period helped us resolve bottlenecks and take input from everyone.
Product and roadmap
eLife’s Product Manager for Libero, Maël Plaine, had been speaking to different groups of people in the preceding weeks but had some more detailed, face-to-face input into the roadmap by three publishers and two technology companies during the Sprint. This helped confirm the direction of Libero’s minimum viable product while ensuring varied views on future development.
An interesting conversation sparked around the classification of the various components we’d defined in the architecture discussions. Some components would be very important to all users of Libero, and some less so, with others being specific to a single organisation. The discussion resulted in the classification of core, extension and compatible components, helping us define ownership and accountability better when thinking about how the community and code is governed.
Governance
One of the more fruitful sessions was on governance, which led to more focused discussions around contributor license agreements and related documentation. Having early consensus on how the project should be governed was important – it increased engagement from contributors because they had a clear understanding of how they could use and contribute to Libero.
We discussed licensing and the ability to use the platform for commercial gain, both now and in the future, and ensuring that the platform always remains as free, open source software. To ease administration and decision making in the community we discussed the possibility of assigning ownership to a single organisation. We explored the involvement of a foundation for this, either a new one or an existing one such as the Apache Foundation or the Apereo Foundation, but decided that eLife was well placed to act as project lead. With further exploration of existing open source governance models we decided that a ’benevolent dictatorship’ model would suit the community, because eLife was able to commit the time and people whereas other contributors could not make as large or as full-time a commitment, but were keen for development to progress unimpeded.
To ensure that others have a way to influence eLife (as project lead) we decided to support the benevolent dictatorship model with the formation of a steering group for core contributors/organisations who are transparent about their involvement through the signing of a Memorandum of Understanding with us. We continued our discussion into the realms of code ownership and copyright too, eventually proposing and investigating the use of a Contributor License Agreement (CLA), which we’re likely to adopt. The CLA can be used to ensure the license is kept open and gives contributors the right to attribution, which allayed the concerns that initiated the discussion.
The conversations were really focused and clear, which resulted in a governance document that we’ll release shortly on the Libero website. I’ve included an excerpt below to highlight one of the key outcomes of all the (non-coding) effort at the Sprint:
“Following a discussion at the inaugural Libero Sprint in Cambridge, UK, August 2018 it was decided to opt for a Benevolent Dictatorship model of open source software governance where eLife are the project lead. This will be supported by a Memorandum of Understanding between organisations involved in core contributions, a contributor license agreement (CLA) and a steering committee, which in turn is supported by Special Interest Groups.
"The community (anyone interested in using, discussing, influencing or contributing to Libero) believes this gives the best balance between freedom, responsibility and accountability for eLife, with the ability of others to influence the future direction of the platform.
"The components of the system will be separated into Core components (all supported and the copyright owned by eLife), Extension components (supported and the copyright owned by eLife, where appropriate) and Libero-compatible components (supported and the copyright owned by the creator).
"The software will be licenced under the permissive MIT license. Contributors will use the CLA to assign copyright of their contributions to core components or appropriate extension components over to eLife and in return retain attribution in the distributed source code. Copyright of documentation will also be assigned in a similar way and made available under a Creative Commons Attribution License (CC BY 4.0).”
Conclusion
The particular sprint format we used worked well for our community and stage of development. We were surprised that there was much more discussion needed than we’d originally anticipated, but contributors were pleased with the outcomes of those discussions. Getting an agreed way to name, deploy and interact with the software has meant that the momentum built up during the Sprint has been maintained. The same can be said for the product roadmap too, which continues to be clarified and broken into actionable tasks. This has helped inform and accelerate the ongoing development and user experience design work for Libero. The outputs from the governance sessions were perhaps the most surprising outcome, which has recently been vindicated in discussions with funders at a recent JROST meeting, and with people involved with the Apereo Foundation, who suggest that having a clear governance and licensing structure in place early helps open source communities to succeed.
We welcome comments, questions and feedback. Please annotate publicly on the article or contact us at innovation [at] elifesciences [dot] org.
Do you have an idea or innovation to share? Send a short outline for a Labs blogpost to innovation [at] elifesciences [dot] org.
For the latest in innovation, eLife Labs and new open source tools, sign up for our technology and innovation newsletter. You can also follow @eLifeInnovation on Twitter.
