Who Governs Open Source Software?

Updated: Apr 6

Why you should care how the projects you depend upon are managed.

As a company that specializes in providing support and services to users of open source software, we are often asked to advise our clients on their selection of which software to use. One important factor in this decision is not obvious: how the candidate software projects are managed. Not all software projects are structured and managed in the same way and the differences could be important to the users.

There are many potential differences in the way open source software projects are managed and maintained. At Quansight, we believe an important dimension of open-source project maturity is who governs the project. There are two main categories of project governance, or who ultimately controls project direction. There are projects where the ultimate decision in project direction lies with a particular company. We call this kind of project Company-Backed Open Source Software [CBOSS]. Alternatively, there are those projects that are governed by a broader community of contributors (independent of which company they work with). We call these projects Community-Driven Open Source Software [CDOSS].

Categorizing projects as CBOSS or CDOSS can be nuanced as some projects can shift from one model to the other over time. It is also not always completely obvious how governance decisions are made, and therefore many contributors to a project may not actually know what kind of project it is. Both models exist and are valuable and important to the open source economy. But, there are strengths and weaknesses of each model that should be considered when there is a choice between the two. The differences are described and compared below.

CBOSS and CDOSS Definitions

CBOSS projects are those where the governance of the project is controlled by a particular company or organization. Governance is determined by a role someone has at an organization and not as the individual. The organization typically provides the majority of the contributions or funding. Typically external contributions are welcomed but ultimately the company controls what gets committed to the code-base. Contributors are usually encouraged and may even be allowed to join a governance team. However, the final decisions are made by a person in that “role” at the governing company. Current examples of CBOSS projects are TensorFLow, PyTorch, TuriCreate, Java, and Swift. Strictly speaking a hobby project or an early-stage project with one decision maker and an unclear way a community is involved in project progress is also technically CBOSS where the “organization” is the one person. We categorize a project as CDOSS if the project has maintainers from at least 2 organizations with other evidence of wider community participation, or at least 3 independent organizations if most of the contributions are coming from people in those organizations. Current examples of CDOSS projects are Python, NumPy, SciPy, Dask, Pandas, Scikit-Learn, conda-forge, and Jupyter.

Both types of projects have the traditional benefits of open source software. Both can be supported from community contributions and can get help from the broader community as well as be built on freely without licensing fees. The strengths of flexible and agile development mean that both types of projects can rapidly fix problems. However there are additional strengths and weaknesses associated with each project type as well.

CBOSS Strengths and Weaknesses

Having a company backing a project can provide many benefits. Companies often pay non-developers to create documentation, user guides, web pages, etc. meaning higher quality support materials. Companies often have better project management tools resulting in faster progress. Projects may be more sustainable because core developers can be replaced if they leave a project. Developers are often more experienced and hired specifically for their skills resulting in higher quality code and architecture. On the other hand, depending on a single backer can have downsides. If the company changes its overall strategy the importance of the project and support can go away. These and other important conversations often take place within the company and are not always transparent to external parties. “Developers-for-hire” may lack passion for the project which can result in lower quality code. If the person with the governing “role” leaves the company, the character and future of the project can be at risk as new leadership inside the company steps up. And finally, evolving community standards may not be included in a CBOSS project driven with a narrow set of goals.

CDOSS Strengths and Weaknesses