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
Community driven efforts have many intrinsic aspects that are good for the project and its users. By drawing upon a wide variety of experience and perspectives these projects can have non-linear and innovative outcomes. Mindshare happens largely due to “word-of-mouth” from people successfully using the project for real work which means the project works well for target use cases. Distributed “ownership” of many contributors strengthens the project’s longevity.
The drawback of community driven projects are also intrinsic to their nature. These projects are often under-resourced and updates can lag significantly. A lack of funding can also mean that the most knowledgeable people may not have time to contribute as they have to seek support doing other things besides working on the software. With a large group of decision makers and loose governance, decisions can also be slower. Integrations with heavily used commercial products may not exist. Responses to user feedback can be slow, sporadic, or not clearly managed.
A summary of these comparisons between CBOSS and CDOSS projects is given in the following table:
It is advisable to keep these strengths and weaknesses in mind when selecting open source software for your organization. In addition to advising clients about the factors to consider when selecting open source software, Quansight can often help mitigate the weaknesses inherent in both types of projects.
For community-driven projects, our consulting services can fill the gaps of commercial support with support, training, staffing and program evaluations. Through Quansight Labs we can help address feature development and bug fixes.
For company-backed projects, we often consult with the project leaders and can help them engage with the wider open-source community for staffing, talent replacement, and community standards integration. This allows them to gain many benefits of community involvement while retaining control of the direction of the project.
This post summarizes an article written by Travis Oliphant and published on LinkedIn. Read the full article here.