Open Path

A Vision for Software Commons

Heartbleed, Log4shell, and now XZ. The time has come to take definitive concrete action to resolve the Open Source sustainability crisis. This post puts forward a plan for a new entity called Software Commons that combines real funding with real accountability, without losing the hacker spirit that is the heart and soul of Open Source. It builds on posts I’ve been publishing for the past couple months (with the caveat that my thinking was a bit muddled until earlier this week).

We have a huge opportunity. Honestly, it’s so big I’m kind of scared to put it out there, because a lot of things will have to come together for this to become a reality. Perhaps the breathtaking sophistication of the XZ attack and our sheer dumb luck in catching it will prove a shock sufficient to get this ball rolling. We shall see. Certainly maintainer burnout was at the heart of the XZ story, just as it is at the heart of my understanding of the sustainability crisis:

Open Source has created an economic value vacuum. Our society depends utterly on the common pool resource of Open Source software, and this commons is severely underprovisioned. How do we know? The real indicator of the Open Source sustainability crisis as I define it is maintainer burnout.

My initial sketch for Software Commons was an institution that “brings together producers and consumers of FOSS under one roof, alongside platform partners, to negotiate an enduring solution to the Open Source sustainability crisis.” Let’s fill in the picture more. This is gonna be terrifying or thrilling, I don’t know which yet.

What We Need, What We Can’t Give Up

In designing Software Commons, there are two new realities we need to create, and one we can’t give up. The two things we need are:

• Funding. Security crises are the most painful symptom highlighting our chronic underprovisioning of maintainer attention. The answer is to pay people to pay attention.

• Accountability. We need assurances that all companies are doing their part to fund Open Source, and that the money is being used to actually improve the ecosystem.

The thing we can’t give up is the hacker spirit. If the only real option to make a living in Open Source is to take a job at a megacorp, we will have lost. For companies, Open Source is about cost savings and brand equity. That’s fine. For humans, Open Source is about autonomy, creativity, and free-spirited collaboration within a welcoming community. It’s wonderful when companies employ maintainers, and we need to sustain a significant indie maintainer contingent in the Open Source community. We need to fix the XKCD pic with many more small blocks, not one big one.

So how do we unlock funding and provide accountability without ruining what’s special about Open Source?

Three Funding Levers

We have basically three levers available to pull to unlock real funding for Open Source: ROI, taxation, and FOMO.

ROI, in my book, covers a whole huge swath of approaches, from Tidelift to the bounty model to sponsorware to tried-and-true consulting businesses. I think of these as using capitalist market economics to subsidize Open Source development. It gets gray, but I put security-focused efforts such as OpenSSF and security fellowships in this bucket as well, because the essence of the ROI lever is convincing companies to pay for a future result. This is what our companies have evolved to do best, so it can be difficult to think beyond this approach. I’m not saying ROI-based solutions are bad. I agree with Jacob: let’s celebrate every time a maintainer gets paid. I’m saying the Software Commons opportunity is even bigger.

Taxation is what Sovereign Tech Fund, FOSSEPS and other Euro-centric Digital Commons efforts are hooking into. I love to see it. More power to ‘em. This might be what we have to resort to in America as well, but there’s an option we could try first.

FOMO is the new, unproven option. You could also call it social proof or corporate social validation. Companies are herd animals. Look how quickly every company in the industry became an AI company. Eighteen months ago, we were still talking about the metaverse. At the individual level, quirks of our psychology can be used to influence behavior—for good or ill. How can we work with the grain of “corporate psychology” (if you will) to overcome the tragedy of the Open Source commons?

FOMO is the tack I’ve taken with FOSS Funders, collecting logos of companies that care enough to participate in Open Source funding and talk about it, in order to inspire others. After six months, we’re at 17 companies. That’s not very many. Maybe we’ll hit a tipping point, but to be honest it feels like building a ladder to the moon.

Can we build a FOMO rocket? If so, we first need to properly frame our situation.

The Restaurant Analogy

Open Source is like a restaurant, not a grocery store. At a grocery store (or pretty much any other store), you pay first, then you get the thing. At a restaurant, you get the thing first, and then you are expected to pay. Yes, it’s possible to dine and dash. But we don’t. When we are presented with a tab for a meal we have already consumed, we pay the tab.

Now picture a meal with a large group of friends. Inevitably, someone forgot their wallet—or “forgot” “their” “wallet.” The rest of the group has to pick up their share. Sometimes, one person gets stuck with the whole tab.

Our companies are sitting around the table. Open Source is the meal we consume year after year. The opportunity with Software Commons is to split the check.

Splitting the Check With a Fair Share

The problem is that we need a check to split. We need a tab, a hook, some entrypoint that provides these properties:

1. a way to meter consumption of Open Source software;
2. a way to weight distribution to maintainers; and
3. a way to actually collect the money, an invoice.

I believe the answer, if we don’t want to have to resort to taxation, is for one or more large developer tools companies to step up and add a line-item to their invoices, for an opt-out “Software Commons Open Source Fair Share.” 😳

Now, I work for a developer tools company. Maybe Sentry will be the one to pull this off, maybe not. Other strong candidates would be cloud providers (AWS, GCP, Azure) or code hosting platforms (GitHub, GitLab, Bitbucket), maybe even project management products (Atlassian, GitHub, Linear). Maybe it’s one company, maybe it’s a consortium, in which case we would need to reconcile customers between them to account properly for Fair Share payments.

A Proof of Concept Invoice

Let’s imagine some large developer tools company called DevTools, Inc. that has per seat pricing of $320 per year plus some usage based pricing. Let’s put the Fair Share at a nice even $128 per user per year.

Okay, ready? Here’s what a customer’s bill might look like:

For this example I’ve taken it that user seats are enough of a proxy for Open Source consumption that we don’t need to include usage-based pricing in the equation. But notice that the number of units for Fair Share is 920 instead of 1000 for the main product. This is because Fair Share is based on previous year’s consumption, so we would look at previous year’s seats. The 1000 is for the customer’s future usage of DevTools’ own product. Restaurant vs. grocery store.

Now, that dollar amount, $128, is pulled out of thin air. Some napkin math I did a few years back puts the amount at more like $2,000 per user per year—a lot to plop onto an invoice unannounced. How would we get where we need to be?

Finding Level Over a Decade

One critical success factor for Fair Share would be almost universal participation. It’s essentially a voluntary tax—and let’s be clear, taxation might in fact be the only long-term answer. If we think we are headed there and want to try something else first that might lessen or obviate the need for a tax (and create something really new and interesting in the world), then here’s how I think we could do it:

1. Start with a really, really small amount. Let’s say $8 per user per year, something just barely above a rounding error. The goal is to make it as easy as possible for as many companies as possible to say “yes,” so we see at least 95% participation across all customers of whichever dev tool companies participate. Really, 99% participation should be the goal at this stage.

2. Ratchet up year by year. Go from $8 to $16 to $32 to $64 to $128 to $256 to $512 to $1024 to $2048. What’s that? Nine years. Maybe we start at $4, and a decade from now we’re up into hypothetical real money.

3. Monitor participation metrics. We would need to balance transparency with privacy for the dev tools company, who won’t share their total user seats. We should have some public metrics, though, probably total annual dollar volume, percentage participating at all, and percentage participating above, at, and below the set Fair Share amount.

4. Level out in response to reality. This is important: we will need to learn over time how knowledge of participation metrics affects participation. It feels to me a bit like setting the fed rate, a delicate game with a lot riding on it. If participation dips below 80%, does that trigger a collapse? Will we be lucky to see 50% participation even at $4/user/year? We can make some educated guesses, but ultimately there’s no way to fully predict what will happen. We would have to try it and adapt.

5. Communicate constantly. We should have announcements from the stage at every Open Source conference with town halls to field questions and feedback. It should feel like this is a thing the whole industry is doing together and nobody is a sucker for participating—you’re a pariah if you don’t!

6. Account for other contributions. Fair Share should be only one part of what companies contribute to Open Source. Some already contribute financially. Two other major components are employee time spent on Open Source projects, and gifts-in-kind (Fastly donating PyPI bandwidth is the best example). We need a robust reporting framework to factor in these contributions to the overall picture.

7. Frame the aggregates in terms of GDP. The best way to think about the value of Open Source is in terms of the productivity boost it gives to the rest of the economy. Today the value of Open Source is anchored at zero. We need to shift that to “1% of GDP” or whatever. However, it is very important that we let this figure emerge from the interaction of companies voluntarily participating in Fair Share, rather than trying to determine the value a priori. In other words, this would be a 10-year experiment to truly answer the question, “What is Open Source worth?”

Accountability Through Foundations

Where would the money go? It would go to Open Source foundations, weighted in part by the aggregate language breakdown across the developer tools company’s customer base. Sentry is like half JavaScript projects, for example. Another part would go to foundations that support the operating systems, databases, and developer tools that don’t show up in a language breakdown.

Each foundation would be responsible for their ecosystem. As budgets grow year over year, we would expect them to take more and more responsibility:

• Foundations would be able to take on new responsibility for security. Right now we depend on products like Socket, Snyk, and Dependabot to bolt security onto mostly unregulated package repositories. With real funding, we would be able to expect real accountability from foundations for their own package repositories, proactively finding and removing malicious packages such as XZ 5.6.x. This tees up nicely with European negotations over the Cyber Resilience Act, and EO 14028 in the U.S.

• Foundations would also be able to make real strides in diversity. The uncompensated nature of much current Open Source maintenance work exacerbates existing inequalities of opportunity. Ecosystem foundations can partner with Outreachy and other specialists to recruit and mentor participants from diverse backgrounds.

• Just as companies will want to have their Open Source contributions beyond the Fair Share accounted for, we should also ask foundations to transparently report their budget allocations in high-level categories such as R&D, registry maintenance, events, marketing, outreach, and general administration. Shared norms can emerge over time. What is the acceptable ratio of spending on events to spending on engineering? Let’s find out.

The Heart of Open Source

I’m gonna come out and say it: the bulk of foundation funds should go to individual people who created value by writing Open Source software. This is the heart of Open Source: people freely sharing their code with other people in the community—and yes, companies—who are free to read, run, modify, and redistribute it for any purpose.

In order to preserve this essential element of Open Source, foundations should utilize mechanisms such as Open Collective expenses and Liberapay teams to give individuals real economic autonomy. Jobs are fine. Grants are fine. But individual contributors are like the restaurant staff who did the actual work of preparing, serving, and cleaning up the meal we just enjoyed. Asking maintainers to pitch grants for future projects in order to access funds has it the wrong way around. They already did the work.

Forward-thinking foundations will find ways to distribute the economic benefits of Fair Share in keeping with the Open Source spirit of collaborative autonomy. This is how we will ultimately reach Open Source sustainability:

Open Source sustainability is when any smart, motivated person can produce widely adopted Open Source software and get paid fairly without jumping through hoops.

Challenges Aplenty

Getting money into Open Source is a huge challenge. ROI has not gotten us where we need to be. Just maybe we can build a FOMO rocket—if some developer tools company steps up as the booster stage. If not FOMO, there’s always taxation, which will be even more work to pull off, though if it is our only option, even in the United States, we’ll likely have to try it.

Getting money to the right people is another huge challenge. It will take years for foundations to scale up to handle the responsibility. But scale they must, in order to meet the increasing demands of government and business for security-hardened Open Source ecosystems.

The hardest challenge will be ensuring that the flickering heart and soul of Open Source does not dwindle further as pressure mounts. It can never truly die, of course, as long as two people exist who freely share their code with each other. But the ideal future—mine, anyway—is a thriving indie Open Source contingent, stewarded by foundations, coexisting alongside the corporations and governments of our civilization.

That is the opportunity I see for Software Commons.

---

Share the vision? Contribute on GitHub.