The ‘open’ in open source is about more than sharing code. It’s about sharing how your project is funded, how you make decisions, and who’s on your core team.
From operating systems to CSS frameworks, open source gives creators the ability to accelerate development, learn from communities of experts, and incorporate thoroughly-reviewed code. At its heart, open source concerns freedoms relating to code, but an open source project is a complex system that happens to focus on code.
In my last article, we started to explore how we might move past the typical focus on the open source license and instead develop a social model that captures additional complexity. As a recap, we established that the technical model of open source describes what you can and cannot do with it, typically by way of the project’s license, whereas the social model describes how open source interacts (or doesn’t) with the larger ecosystem and the people within it. That initial article addressed capturing the purpose of a project based on its specific goals within the open source ecosystem.
In this second piece, we will continue to develop the social model of open source by exploring the benefits of operational transparency, and outlining some key characteristics that maintainers should aim to make publicly available.
The benefits of operational transparency
A key benefit to open source is that anyone can examine the code they incorporate, but how the project operates is just as important to a project’s success as the functionality itself.
With open source making up an estimated 90% of today’s modern technology, it’s increasingly critical to make operational information readily available to the public, so that you can empower contributors and users to evaluate projects based on the criteria important to them.
The operational characteristics of an open source project are often thought of as fundamentals to the teams behind them, and yet they’re rarely communicated well beyond the maintainers.
This is a lost opportunity, as open source projects that clearly, concisely, and consistently articulate how they operate give contributors and users the social frameworks that they need to work well within the project.
Here are some high-priority details that projects should aim to make publicly available:
1. The decision-making model
A vital part of running an open source project is deciding how to run the project. While ‘governance’ is an ever-expanding term, its primary concern is around how decisions get made and who gets to make them. (The Open Source Way has a fantastic, comprehensive guidebook around open source governance.) Whether a project is managed by a benevolent dictator for life (BDFL) or is foundation-backed, clearly communicating the model in use benefits potential contributors and the project alike.
An example is Node.js which openly shares that it follows a consensus-seeking decision-making model.
2. The project’s affiliations
As more companies start to create open source as part of their strategic initiatives, it can instill a healthy amount of skepticism in potential adopters. When a project is run by a corporation, decisions about the future of the project can (but not necessarily) become opaque to the end-user. That said, a corporate-sponsored project may also have the ability to focus on security, developer experience, and usability in a way that independent projects cannot, as they can leverage the time, talent, and treasure of the company.
By identifying the affiliation of a project, whether it be a company, government, non-profit, or individual, you allow consumers to make informed decisions based on their own strategy and values.
An example is TypeScript’s open affiliation with Microsoft.
3. The funding sources
While open source is free (as in puppy) to consume, it is most definitely not free to create. From bandwidth and infrastructure to time, costs can add up. For people looking to build products by integrating with open source software, the price of switching components can be high as interoperability between projects is rare.
Exposing how the project supports itself provides a two-fold benefit: 1) people deciding on a technology can evaluate if the project fits their risk profile, and 2) current integrators can clearly see when a project becomes at risk of running out of capital.
Plus, financial transparency is right in line with open source values.
An example is Homebrew which has been openly funded by GitHub sponsors, OpenCollective, and Patreon.
4. The maintainers and the core team
As incidents such as log4j and Heartbleed have shown us, open source software that provides key functionality for many services and applications is often maintained by only a handful of people. Additionally, information about the people maintaining projects may be difficult to find, forcing users to trawl the project’s metadata through mailing lists, commit history, etc… in order to determine the size of the core team. The effectiveness of a team may be dependent on the number of members, but there are many other variables that influence how well a team manages its processes.
Publishing an up-to-date list of core team members, even without any information beyond usernames, can signal when a piece of software is in danger of becoming under-maintained or effectively unmaintained. In turn, this opens up an opportunity for users to step up and offer to take a more active role within a crucial dependency.
An example is Font-Awesome which publicly shares its team list.
Transparency helps everyone
Openness is about more than just code; it is also about how we make decisions, how we support ourselves, how we prioritize issues, and how we delegate responsibilities.
Of course, the operational details that a project considers important may vary, and maintainers will choose to highlight those that are most relevant to them. A project in its beginning phase might not yet have a formalized governance model or funding, while a more established project may have a variety of defined roles and responsibilities.
But wherever possible, increasing transparency around how work gets done sets clear expectations for contributors, raises the visibility of when a project is in need of support, and reduces the amount of effort that falls on the maintainers’ collective shoulders.
Keep an eye out for my next article where we’ll explore how to incorporate dynamics and conventions around communication into our social model of open source.
