Governance in Open Source Software Projects

Below is the text of an article I wrote for a LYRASIS member newsletter in which I talk about the nature of governance in open source software projects. I’m reposting it here for the DLTJ readership.

One of the more fascinating aspects of open source software is the role that its creators and users play in its evolution. (For more on the community nature of open source software, see a previous article, The Challenges and Rewards of Open Source) With proprietary systems, the creators and users are separate groups, and the control over the relationship is bound up in proprietary rights and contracts. (This doesn’t diminish the role of robust user groups for proprietary software; rather it is a reflection of where the ultimate control lies – with the creators of the software.) With open source software, the creators and users are commonly the same or closely overlapping. How do creators and users work with each other? This is a question of governance.

There are several models of governance of open source software projects. One can point to the benevolent dictator model of the Linux operating system. In this model, Linus Torvalds has complete control over what makes it into the Linux package and what does not. Over the years Linus has come to rely on others that specialize in various areas of the operating system, but ultimately he is the one that decides what happens. (Recently Linux made a decision to number a release of the Linux operating system as 3.0. In the release candidate announcement, he said: “But let's face it - what's the point of being in charge if you can't pick the bike shed color without holding a referendum on it? So I'm just going all alpha-male, and just renumbering it. You'll like it.”)

A model used in libraries and closely related fields is the “community source” model. Popularized through the work of the Kuali Foundation (the umbrella organization for the Kuali Open Library Environment -- or OLE -- project), community source is characterized by institutions agreeing to pool their resources for software development in exchange for exclusive rights to influence the design and implementation of the software during initial stages of development. Although access to the code itself is limited at the start, there is a commitment by the early participants to pursue an open source license and code release after the initial effort.

A third model is characterized by its open and democratic nature. Open source projects in the Apache Foundation follow a rigorous protocol of merit-based leadership. A participant shows his or her interests and abilities by offering new code and documentation to a project, and other members of the project acknowledge that effort by voting for the participant to have greater responsibility in decision-making for the project. Sometimes called a meritocracy, this model of governance is also called a “do-ocracy” – power resides with those who ‘do.’ (See “How the Apache Software Foundation Works”.)

Regardless of how a community organizes itself and makes decisions, another important aspect of governance is the ownership of contributions from the community. Like all creative areas, the creators of code, documentation, and support materials hold copyright to their creations as soon as they are fixed to a tangible medium. In the case where someone is paid to make those creations, the employer holds copyright; this is the case with proprietary companies. With open source software – much of which is created with volunteer efforts – the ownership of the software can be much murkier. Here, there are two primary models:

1. Creators assign rights to an entity that publishes the compiled works of all contributors with an open source license; and
2. Creators all agree to release their contributions with the same open source

The former usually requires some form of signed “contributor license agreement” (CLA), for example, the Apache Foundation’s agreement. The latter is usually an assumed or unspoken agreement within the community. Don’t confuse a CLA with the open source license itself. The CLA addresses rights at the input of contributions to a project; it is certainly the case where software can be released under an open source license without the requirement of a CLA from contributors. Although each ownership model is equally valid, the requirement of a contributor license agreement is usually a sign of a robust, formal and mature community.

Perhaps one of the most difficult things for a new open source project to set up is its governance model. With the focus – and the excitement – on coding, releasing, bug-fixing and documenting, creating a set of rules through which a community governs itself is the last thing active developers and users want to spend time and effort on. How does the community make decisions? How will the community permit others to add their contributions and ensure contributions are available to all? In my experience, governance rules tend to grow organically and the reasons for why things are done a certain way are lost to the mists of time and mailing list archives. Yet when considering whether an open source project is right for your library, evaluating how your efforts will be received and valued by the open source community you are joining should be a key factor in your decision. And to make that determination, start by looking for how the community governs itself.