Libero is eLife's  platform to help publishers do more with everything they publish. The platform has evolved since development began in 2015 from an enabler of innovation for eLife's own journal, to a more reusable and modern platform for publishing, and now as a community-driven platform for publishing and presentation of scholarly content.
The developments in community engagement resulted in the need for a well documented and agreed governance model. 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).
eLife will also pursue the concepts of trademark licensing for the name Libero so that an ecosystem of service providers can grow around the software and the project can gain some level of sustainability from trademark-licensing fees. Anyone is permitted to use the software as the MIT licence permits, and use the documentation as the CC-BY license permits.
This document also outlines processes for dispute resolution, upholding the code of conduct and details of how the community meets.
On the spectrum of governance models for open source projects you have Benevolent Dictatorship on one side and Meritocratic on the other. The former is simpler but places responsibility of administration on the project lead since all decisions pass through one place. However, in contrast, a meritocracy is more complex and decision-making can be slower due to the number of voices involved.
The community opted to keep the governance as simple as possible and hope to sustain the project lead role by assigning it to eLife as an organisation, meaning that any eLife employee deemed fit to participate can do so and the decisions and community building efforts are not left to a single person – a common criticism of this model.
The community have also left open the future possibility of transferring ownership to a non-profit foundation should the community grow to a sufficient size or if eLife can no longer sustain the role of project lead.
eLife is a non-profit organisation inspired by research funders and led by scientists. Their mission is to help scientists accelerate discovery by operating a platform for research communication that encourages and recognises the most responsible behaviours in science. They are a registered 501(c)3 non-profit and well-funded by HHMI, Wellcome, the Max Planck Society and the Knut and Alice Wallenberg Foundation. Their leadership team is known for openness in technology, science and publishing. This makes eLife a good fit to lead this project.
The community should be able to hold the project lead to account and influence their stewardship of the project. To address this need, it was decided that a Steering Committee should be formed from organisations who wish to make a commitment or contribution to Libero. The contributions might take a number of forms, including, but not limited to, the addition of code to core or extension components, input into the roadmap for Libero, and becoming users or service providers.
Any organisation or individual can be a member of the steering committee and new members are added by consensus of the existing committee. Specific individuals representing organisations should be in a senior position and have access to technology or publishing knowledge in their organisation.
The specific responsibilities of the steering committee can be summarised as:
- Ensuring that the community-driven development process is fair and transparent for all participants
- Evangelising the open source project to possible users, funders and new community members
- Ensuring adequate participation by staff within each member organization in special interest groups
- Supporting the project leadership in communicating the benefits and obligations of membership to the community
The Steering Committee should convene at least twice per year.
Current membership is detailed on the Steering Committee page.
Each member of the Steering Committee completes a Memorandum of Understanding (MOU) with the Project Lead. This is also available to other community members who wish to publicly show their support for the project.
The MOU details the commitment from both sides to the community and the production of a viable system for Libero. It ensures that the values of the organisations, the project lead and the community are aligned. It also helps to outline the reasons why organisations are committed so that others can see the diverse set of goals that the community shares.
Having commitment from an organisation using an MOU adds to the sustainability of the community and the software, and allows us to make longer term plans with more certainty.
A template of the MOU used is available here.
A Special Interest Group (SIG) is comprised of members from multiple organisations, with a common purpose of advancing the Libero project with respect to a specific topic. Their goal is to provide focused forums for getting work done, making topic related decisions, onboarding new contributors and advising the Project Lead or Steering Committee.
Areas covered by SIGs may be vertically focused on particular components or functions, cross-cutting/horizontal, spanning many/all functional areas of the project, or in support of the project itself. Given the small size of the initial community there are two SIGs; one for technology and code-related concerns, and one for product and design-related concerns. We expect these to grow and diverge as new topics arise and the community grows.
SIGs must have at least one lead at any given time, and ideally, members from all core contributor organisations. SIG leads are intended to be organisers and facilitators, responsible for the operation of the SIG and for communication and coordination with the other SIGs, the Steering Committee, the Project Lead and the broader community.
SIGs should be kept small, relative to the size of the community, and remain focused to allow decisions and discussions to happen quickly. They should meet regularly and when issues arise, make key discussion points or outcomes public through the Libero Community Slack or a request for comment (RFC), an architectural decision record (ADR) or a design decision log.
An alternative to a SIG is a Working Group which is a time limited, topic specific group that should have similar leadership and reporting responsibilities of a SIG. There are currently no Working Groups in the Libero community.
Focuses on topics related to the codebase, architecture, testing, continuous integration, deployment and related tools or services.
Focuses on the product roadmap and direction of Libero in terms of a platform for the various use cases. This includes the user experience design, user interface design, new and existing features, prioritisation and movement of components between the different classifications.
Proposing a SIG
New SIGs can be proposed at any time by community members and should be done so informally on the Libero Community Slack or as the output from a meeting of an existing SIG or the Steering Committee.
Given the adoption of the benevolent dictatorship model of governance for the project it is beneficial for the project lead to hold the copyright of all code contributions to all core and selected extension components. This means that eLife can make decisions about the whole codebase without having to contact all contributors, speeding up the process of change.
For contributing organisations or individuals it also means the ownership is clear from the outset and their ownership responsibility is reduced yet they retain attribution rights.
For the community, the CLA also provides protections against patent infringement as any contributors grant a worldwide, royalty-free, non-exclusive, perpetual and irrevocable patent license to the project lead.
There are two CLAs available, one for employees of an entity, to be completed once by a representative of that entity for all contributors, and one for individuals. The CLAs were generated using http://contributoragreements.org provided by Free Software Foundation Europe and have been left unmodified so they can be easily regenerated as legislation evolves.
Further details about making a contribution can be found in the contributing guide on the community Github repository.
The community have opted for the MIT License as it is approved by the OSI and FSF, is popular and well known and is one of the most permissive FOSS licenses.
Other considerations were copyleft style licenses, including the AGPL license that adds copyleft protection even for service providers. We decided that eliciting contributions was better served by good community practices and evangelism rather than licensing restrictions and a copyleft license was therefore not selected.
"Core components" are those that will likely be used by a very high proportion of the community, "extensions" are where more than one community member could reuse them and "compatible components" are those that are more specific to a single organisation.
The content creator and eLife will decide how a component should be classified and components are likely to move from compatible, through extension to core as reuse increases and the platform evolves. The Product SIG will advise on classification and movement between classes for components.
Examples of each class might include:
- Core - content store, schema for article title or abstract, patterns for article title or abstract
- Extension - IIIF image server, schema for plain language summary, about pages
- Compatible - adaptor to send content to a publisher’s proprietary systems
eLife is pursuing a trademark for the use of Libero with respect to downloadable software and service provision for the general functions of the software.
The protection this affords will allow the community to have more control over the use of the name in relation to publishing to ensure the use aligns with the community’s values. It also helps prevent bad actors from promoting an association with the community and its members.
While eLife encourages community members to promote their use of Libero with no restrictions, they also offer the option to licence the trademark to organisations that wish to leverage the name with their usage. This might be of interest to organisations that wish to build their reputation in the publishing industry or to provide services using Libero, for example. A process for applying to use the trademark will be decided and made available here when it is ready.
As suggested by OSS Watch:
The benevolent dictatorship model does not need a formal conflict resolution process, since the project lead’s word is final. If the community chooses to question the wisdom of the actions of a committer, the project lead can review their decisions by checking the email archives, and either uphold or reverse them.
For Libero the decision review would also extend to Slack messages, comments, issues and pull requests on Github or records of conversations stored on Google Drive.
The Libero Community wants everyone to have a positive experience by being welcoming and respectful, so expects members to abide by the Contributor Covenant. As exemplified by other large open source communities we value our community tremendously and we'd like to keep cultivating a friendly and collaborative environment for our contributors and users. Here is an excerpt:
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
Details of the code of conduct and methods for reporting instances of abusive, harassing, or otherwise unacceptable behavior can be found on the code of conduct page.
The community aims to meet multiple times per year, whether in person or via open video call. Details are provided on the Libero Community repository. Core community members often meet at or around regular conferences or other meetings (for example, Coko Meetings, FORCE Conferences, SSP Conference and OASPA Conferences)Upcoming
- No upcoming events
- Libero Community Sprint August 2018
- Libero Community Prototype Demonstration June 2018
- Libero Community Meeting March 2018