This essay discusses what's wrong with open source right now (opens new window), a controversial idea I have to fix it, and how we must adapt our cultural expectations if we're serious about open systems.

It's critical we find a solution to the open source sustainability problem, because otherwise secretly-proprietary structures like the BSL (opens new window) or the SaaS-ification of everything (opens new window) will continue to encroach on us.

I'm convinced our current problems stem from what I'll call the "old school open source social contract", and its knee-jerk resistance to maintainers demanding reasonable financial support for their work (opens new window).

My argument will follow these points:

• Our existing open source social contract disapproves of maintainers asking for anything other than contributions.
• But most projects can't get by on just contributions, so many either languish or just don't happen.
• So it's in our collective best interest to change our social expectations slightly so more open systems can be sustainably created.

Old-school engineers and the Clique of The Supported.

Our current open source norms and social contract developed mostly on accident during the late 80s, 90s, and 00s, and in a very specific social environment. It seems obvious it arose among technically skilled people whose peers were also technically skilled.

Here's my attempt to sum up this social contract, with some of the assumptions spoken out loud:

• You're a software engineer, with a day job at a tech company (likely a software startup, likely VC funded). That company is trying to sell some product which is excludable (opens new window) and therefore easy to charge money for.
• On the road to building this product you're going to build a bunch of software. Big swaths of that software aren't in any way central to your business model, and you have no means/intention of monetizing it. (opens new window)
• Therefore you ought to make all that software open source. It doesn't hurt you at all, and in fact could benefit you greatly (opens new window) (could generate leads to promising talent, improves your reputation in the industry, allows you to slyly shape the structure of the industry, solicits helpful contributions from other engineers at other companies who also want to use it).
• All this software should be completely permissively licensed. Don't create any kind of friction for other people to adopt or contribute to this software. (opens new window) You aren't going to make money from this software, and it would be a drop in the bucket anyway compared to your product revenues. So just be generous and everyone will be generous to you in exchange!

For the community this social contract arose in, it works perfectly! A commons (opens new window) isn't just a "free-for-all" (despite the attempts of openly fascist cranks to strawman it as such (opens new window)), but rather is defined by social expectations of mutual obligation (opens new window). Among technically skilled peers who are all employed by well-resourced tech companies, an expectation of mutual contribution to open source perfectly matches the requirements for a healthy commons.

But not all open systems can or should be built by engineers employed by well-resourced tech companies.

You can't eat contributions.

For any project not somehow supported by some well-resourced entity, a mutual obligation of contributions doesn't help very much. For such projects a large influx of users/contributors is more likely a burden than a blessing.

Nadia Asparouhova's excellent book "Working in Public" (opens new window) and earlier report "Roads and Bridges" (opens new window) make it clear the majority of impactful and ambitious projects are mostly maintained by a small number of people. Very few are able to remain healthy merely by accepting contributions, since accepting contributions just requires a different kind of difficult work in the form of mentorship and review. Without some source of stable support, whether from a company or even an academic tenure or public institution, it's absurdly difficult to create ambitious and impactful open systems.

It's extremely frustrating when engineers whose open source careers have been supported by well-paying jobs guffaw over sustainability concerns.

Our current social contract only supports the creation of "incidental" systems, ones that happen to be supportable within some other model. Tons of possibly valuable open systems will never fit that description, such as those with independent maintainers or those seeking to primarily benefit less-technical users who can't reasonably be expected to provide useful contributions.

Not all open systems can be "made into a product" without compromising either the values of the maintainers or the very benefits of the open system itself.

And existing open source models aren't good enough. They all either profoundly distract from the actually valuable maintenance work (opens new window) or create perverse incentives (opens new window), or just don't work (opens new window).

And this problem is bigger than just software! We also lack support systems for all other kinds of information goods that can be created once and beneficially distributed to anyone, such as legal documents (opens new window), blueprints and designs of all kinds (opens new window), and anything else you can imagine.

If we want more open systems, we need different norms.

We have to figure out what our real values are.

Are we willing to tolerate only a narrow band of people in a narrow band of support situations being the ones who build and maintain all the open systems? Will we actually assert that anyone who can't make technical contributions can't meaningfully participate in our commons?

Or do we want to allow truly open systems to pop up wherever people have the creativity and determination to make them happen?

It's helpful to ask: why do we care about open systems? Is openness valuable just because then "all bugs are shallow" (opens new window), or because distributed peer review is effective? (opens new window)

I claim three essential properties fully explain why open systems matter:

• Anti-Rivalry. (opens new window) Distinct from rival goods (opens new window) (which get less valuable the more people use them), and even merely non-rival goods, anti-rival goods become more valuable the more people use them. A closed system can never fully leverage the power of anti-rivalry, since many beneficial participants will be shut out.
• Consumer Surplus. (opens new window) Whenever I trade something for something else, it's because I value the thing I'm getting more than the thing I'm giving. The difference between those values is my surplus, and in an open system most of the value created is surplus! The reason we instinctively dislike rapacious companies is that they attempt to take away more and more surplus without giving any more in return.
• Adversarial Interoperability. (opens new window) This property is the one that protects users from someday being "rug-pulled" or "captured" in a monopolistic walled garden. The BSL (opens new window) clearly violates this property, and most SaaS business models (opens new window) do as well.

Because of these properties, open systems are likely the most powerful tool we have to create societal progress and shared prosperity.

As we figure out how to solve our problem the above three properties should be kept in mind.

Alright sounds fine, any specific ideas?

Yes, I have a few specific ideas that seem promising enough to experiment with. But after thinking up one of them in particular, threshold conditional licensing, I myself experienced intense resistance and discomfort to the idea. I suppose I too am an old-school engineer despite my age.

So for months I've been wrestling with this idea and my resistance to it, and now I'm quite comfortable with it and other adjacent possibilities. It seems clear to me threshold conditional licensing could be used in such a way that we get essentially all the benefits of anti-rivalry and consumer surplus and adversarial interoperability, all while still creating sufficient incentives for financial support that maintainers can get "enough" to thrive.

Despite my new comfort with these ideas, I'm pretty certain my fellow engineers will have the exact same knee-jerk reaction I had, which is why I wanted to share my thoughts. In order for ideas like threshold conditional licensing or similar to work, we as a culture have to be okay with maintainers using a structure that demands their collective users provide them some amount of money.

If we want to build many more kinds of open systems, not just programming languages and databases, but truly open social platforms that can actually compete with the toxic trap of the walled gardens (opens new window), or journalism institutions that don't have incentives to sensationalize everything, we have to be flexible and creative, and willing to scrutinize our long-held assumptions.

I'm going to write a follow-up essay with a more up-to-date exploration of my ideas for supporting open systems. In the meantime feel free to share any new ideas you think sound promising, or to weigh in regarding mine.

We're all in this together!