
This is the fifth blog post in a series about open source project governance, so while this one can be read on its own, you might still consider pausing and reading about why governance is important, defining governance, pathways to leadership, and creating intentional culture.
People sometimes think of open source project ownership as something a bit nebulous with projects owned by an undefined “community” of people; however, this is rarely the case from a legal standpoint. While there are a few exceptions, open source projects usually have an individual, company, or foundation controlling the trademarks, project infrastructure, and other assets. This overall ownership structure often impacts how the project is governed on a day to day basis and how the project is perceived by others.
For projects owned by individuals, there are often concerns about succession planning and the impact on the project if something happened to that individual (see obligatory xkcd dependency comic about the one maintainer in Nebraska). This can result in concerns about the sustainability and risks associated with using projects owned by single individuals.
For company owned open source projects, if the project is truly open, the governance processes should specify how people can move into leadership positions with the assumption that you’ll eventually have maintainers from outside of your company. On the flip side, if you have no intention of allowing people from outside of your company to move into leadership positions or make decisions, then you should be clear about that and keep the project as owned by your company. While it’s not ideal, I have a lot more respect for companies who are honest about how others can participate than ones that claim to be open while still making all of the big decisions behind the closed doors of their company.
On the other hand, we have foundations for open source projects, which tend to be non-profit organizations that are focused on providing the resources and organizational structures that projects need to get funding and legal support for their work. In many cases, projects end up in foundations because an individual or company decided to move the project into a foundation.
It’s also important to think about when your project might be ready to contribute to a neutral foundation. If your project is very immature, foundations are unlikely to be interested in your project, whereas a project with many users and good traction that just needs help moving to the next level would be much more likely to be accepted and successful under a foundation. For companies contributing projects, you’ll have a stronger case for moving it into a foundation if you have some contributors, and ideally at least one maintainer, from outside of your company. Contributors tend to be suspicious of company owned open source projects, especially ones requiring a Contributor License Agreement, given the recent rug pulls and relicensing behaviors from some companies over the past few years, so contributing a project to a foundation might make it easier to build a community around that project.
The challenge with contributing open source projects to foundations is that as individuals and companies, you also give some of your control to the foundation. Typically, the project’s trademarks, repositories, websites, and other assets would be transferred to the foundation. Existing maintainers and leaders will usually keep their positions. However, neutral foundations (e.g., Apache, Eclipse, CNCF, Linux Foundation) often make sure that the governance is set up in a way that makes it easy for anyone to participate and eventually move into leadership positions, so as the contributing company or individual, you should expect for some leadership positions to transition to other people over the longer term. While this does mean giving up some control over the project, putting a project under a neutral foundation gives others more confidence that they can contribute as equals.
You’ll still need to do the hard work of getting more contributors and building the community – you won’t automatically get this from the foundation. Most foundations have so many projects that putting a new project into a foundation may not get as much attention as you expect, and the foundation’s attention will be spread across all of those projects. The biggest misconception about putting a project under a foundation is that you’ll get immediate traction with more contributors and more adopters, but this still requires hard work from the people already participating in the project, so it’s important to set your expectations appropriately.
One important note is that contributing a project to a foundation is almost always an ongoing commitment, not an exit strategy, so the contributing organization will likely be expected to provide staff and other support over both the short and long term. It’s also a permanent decision, and you aren’t likely to be able to take the project back after you’ve put it into a foundation, so it’s worth taking some extra time and doing some research to decide whether you should continue to own the project or whether it would be better to put it into a foundation.
Resources:
- Power Dynamics, Rug Pulls, and Other Corporate Impacts on OSS Sustainability
- New Power Dynamics in Open Source: Rug Pulls, Relicensing, and Forks
- Collaborative Leadership: Transparency and Governance Beyond Company Affiliation
- Good Governance Practices for Healthy Open Source Projects (video)
- The Open Source Way Guidebook section on governance.
- CHAOSS Practitioner Guide: Getting Started with Organizational Participation
- CHAOSS Practitioner Guide: Getting Started with Contributor Sustainability
Photo by Hannah Busing on Unsplash