Thriving countries are built on a system of public infrastructure — from rule of law to transportation to healthcare to education. When governments underprovide these, citizens’ quality of life suffers.
As open source communities grow, they are dependent on maintainers to provide bugfixes, features, and architectural changes. When maintainers underprovide these, the technology often falls behind the times and community members’ careers, and quality of life, suffer.
How do we make sure public goods are adequately provided?
The structure (national/regional/local), functions, size, and funding sources of governments are informed by decades if not centuries of political philosophy & practice.
In contrast, the structure, functions, size, and funding sources of open-source maintainer groups are a largely unsolved questions and, in many cases, the main barrier to successful software projects.
One increasingly prominent answer is for founding organizations — companies founded by key contributors of an open-source project — to play a crucial role. In many ways, it’s a role resembling a government!
Founding organizations have a responsibility to their projects and communities: to keep them thriving and on the cutting edge. We believe that to fulfill that responsibility, founding orgs must be able to create a successful business model and then make proportional investments in open source as they grow.
And when founding organizations aren’t able to build strong businesses, or then fail to invest adequately, and the project starts falling behind the times, the community should hold founding orgs accountable.
A question that’s frequently discussed in the web development community is how to make open-source maintainable. Some examples:
Open source is key infrastructure: for comparison, imagine if the lead mechanic on the Brooklyn Bridge had to work on it in his spare time, or hustle for contracts!
Inconsistent or sparse funding isn’t just bad for project maintainers. It’s also bad for the project community, because inconsistent funding means inconsistent maintenance. Over time, this is costly to the community as bugs pile up or feature gaps grow, causing user frustration and necessitating workarounds and occasional replacement by the next “new thing”.
As Devon Zuegel at GitHub put it: “[Open source] is everywhere, yet it lacks financial and personnel resources. Developers and companies benefit from a vibrant OSS ecosystem, but they lack proportionate incentive to contribute time and money to creating and maintaining projects.”
One of the lessons we’ve learned from recent economic growth is that for most people, their economic future is tied to their country of residence. The level of economic development and well-being in one’s country of residence strongly influences one’s baseline standard of living, as well as the ups and downs.
This is also true for developers when choosing a development community—developers with expertise in communities with healthy, growing usage have better economic prospects than developers with expertise in less well-maintained, shrinking communities. For example, a React developer in 2016 generally had more career prospects than a Perl developer.
This means that creating sustainable open-source communities isn’t simply a problem for community maintainers, it’s a problem for everyone.
When a project is created outside an established company, a growingly popular way of sustaining it is to form a commercial organization around it, raise venture capital, hire maintainers, and create hosted services to pay the bills.
We’ll term these “founding organizations”—companies founded by the creator or key contributors of an open-source project to support the project. A growing number of projects are now sustained in this way. We believe this is exciting for software developers the world over, because better software benefits everyone!
Of course, with great power comes great responsibility. Founding organizations are usually viewed as project stewards and as such have special responsibilities to the community that go beyond ordinary corporate responsibilities or even customer-centricity.
We believe founding organizations have a responsibility to provide public goods and infrastructure to their communities to contribute to the community’s health and long-term success.
As Dries Buytaert, the founder of Drupal and Acquia put it:
In economics, the concepts of public goods [is] decades old…for example, everyone can benefit from fishing grounds, whether they contribute to their maintenance or not. Simply put, public goods have open access.
Open Source projects are public goods: everyone can use Open Source software and someone using an Open Source project doesn’t prevent someone else from using it.
Some public goods in open source include:
- A well-maintained PR and issue backlog, and roadmap
- Comprehensive, understandable documentation
- Ongoing maintenance work required to keep code modern
- Features that benefit underrepresented groups of users
- Ensuring plugin compatibility and interoperability
If we were to make an analogy of open-source to something more physical, for example transportation infrastructure, it’s easy to see the parallel for each one to common government-provided public goods.
|Open Source Public Good||Analogy in Transportation Infrastructure|
|Comprehensive, understandable documentation||Accurate official maps|
|A well-maintained PR, issue backlog & roadmap||Official communication around planned roadwork|
|Ongoing maintenance work||Ongoing maintenance work|
|Features that benefit underrepresented users||Graded sidewalks, curb cuts, crosswalks with audio cues|
|Plugin compatibility and interoperability||Uniform traffic standards & rules of road|
Governments aren’t the only organizations providing public goods; in most developed countries there’s a well-developed nonprofit sector that helps promote the arts, education, and other social services.
But governments are often responsible for crucial pieces of infrastructure (such as transportation!)—especially ones requiring large capital expenditures.
This is a crucial distinction because often large expenditures—new major versions, centralized, coordinated releases—are required for open-source projects over time to keep them modern and prevent them from falling behind.
This is the most important public good founding organizations and other governing bodies provide: technological parity with up-and-coming tools; staying on the cutting edge.
Other technologies can fall behind. In the website world, both WordPress and Drupal lack core support for version control and modern frontend tooling. In the infrastructure world, Docker exists and is widely used; however, as a project it has been more or less subsumed by Kubernetes, and today most development happens on Kubernetes rather than the container runtime.
We believe founding organizations’ responsibility to the community extends to a sort of social contract to keep the technology up to date:
- When a technology stays at the cutting edge, the founding organization has fulfilled its social contract.
- Conversely, when a technology begins to fall behind the times, fails to invest in important public goods or keep up with changing development standards, the community should hold the founding organization largely responsible.
Keeping an open-source tool on the cutting edge doesn’t typically require technological breakthroughs. More often, it requires steady, methodological, persistent engineering work—and lots of it.
Much of this work, especially in systems with plugin architectures, can come from the community. Both Drupal and Magento, among others, have done excellent work crediting community contributors and commercial entities for work they’ve done or sponsored.
But there are almost always key changes — fundamental re-architectures, foundational stability and scalability work — that should be done by a centralized entity. This requires sufficient economic investment from founding organizations to hire enough talented engineers, engineering managers, and product managers to move the work forward.
To invest the requisite amount, a founding organization must be both able and willing. Put another way, a founding organization:
- must have sufficient resources to invest, which means being commercially successful, both in absolute terms and relative to the size of the community
- And then choose to make that investment
To analyze the level of investment a founding organization makes, we must ask two questions.
The first question is: is the company effective in creating a sustainable business around the community?
Founding organizations have a responsibility to build strong businesses in order to sustain continued investment into the community.
Community members often ask quite reasonable questions about founding’ organizations plans when they announce venture funding or commercial products. Sometimes these are paired with fear the project will sell out, or that the community will be left behind. We would reframe that: in order to invest adequately in the project and the community, founding organizations must develop sustainable and successful businesses.
What a sustainable business looks like will depend on the space; the right metric here will be different for a database than a deployment tool than middleware. We’ll give some insight into how we see this for our world: the web.
On the web, one metric for a company’s ability to generate revenue, given a certain level of adoptions is called “monetization intensity”—a company’s revenue divided by the proportion of the web running on the open source framework, measured in percentage points.
Closed-source vendors like Shopify, Bigcommerce, Wix, and Squarespace typically make $500M or more in annual revenue and up for each percentage point of the web they occupy.
To be competitive in this world, “founding organization” website company needs to be making something in the ballpark of that — based on data we share a bit later, at least $100M in revenue per percentage point of the web.
The second question is: is the company investing product & engineering resources to open source?
Founding organizations employ a number of different types of contributors helping open-source, from engineers actually writing the code and committing it, to engineering managers, product managers and other roles helping support the work, to marketing and community staff helping organize events and support the community.
In crafting a metric, it’s important to select for observability. We believe the right metric to measure founding organization investment is open-source headcount proportion: the number of FTE equivalent engineers dedicated to open-source projects as a percentage of overall employees.
For example, if a founding organization employs 100 people, and has ten full-time engineers writing open source code, and ten engineers writing open-source code half-time, its open-source headcount proportion would be 15% = (10 + 0.5 * 10) / 100.
What’s a good baseline for how much a founding organization should invest in open source? We feel a good comparable here is governments, who almost always spend 15-20+% of GDP on public goods.
After a number of conversations with other founding organizations who have helped sustain their communities and keep them relevant in changing technological times, the general tenor was sufficient investment was at least 10% of headcount.
We wrote this piece, among other reasons, to share our deep commitment to open source technology and to the community. We feel that we have a responsibility to keep Gatsby an incredibly healthy and vibrant ecosystem.
What that means to us:
- Open-source staffing level. We have 25 people in our roughly 55-person organization — over 45% by headcount — writing open-source code and documentation. We’ll continue to report this figure periodically over time.
- Continued development. In the last few months, we’ve shipped themes, MDX 1.0, better offline support, better site performance for large sites, schema snapshotting, UI improvements to documentation, structured logging, asset prefixing, and a long list of other features and research initiatives.
- Commercialization. We’re building a sustainable revenue base via the recently launched Gatsby Cloud with features like Preview and Builds.
We’re committed to making Gatsby the next way to build on the web. We believe Gatsby is great for the community, thousands of whom are using Gatsby to earn a living and for the web in general. Security, performance, accessibility, and modern tooling should be the default in front-end development, not afterthoughts.
Our goal is to help create a better web—for everyone.