Open Source Software is Unsustainable
Date: 2023-12-08 | create | tech | business |
Open Source Software has enabled the age of technological advancement. It gives anyone access to high quality software tools for almost any usecase which in turn allows even small players to compete alongside large incumbents. In many ways, this is what's allowed the software industry at large to continue innovating for so long.
Aside: An alternative reality is one in which software wasn't open. In this reality it's likely that several large incumbents would build monopolies and buy up not just their competitors but also the underlying technologies they depend on. In this reality competition would be dead before they even began. As is natural, innovation would stagnate for if there's no incentive to evolve then the costly process wouldn't occur. This is bad for normal people like you and me as the incentives switch from providing value to end users to preventing others from providing better value.
So in large part we should be celebrating Open Source Software. It is indeed an incredible achievement that essentially everyone in the world is benefitting from. And yet if we look just a little closer we find that one of the key components of OSS - those that actually create and maintain these packages - is incredibly, horrifyingly underserved.
This unfairness to OSS maintainers leads to a vicious lose-lose cycle of extraction from what conceptually should be a win-win virtuous cycle for all. This vicious lose-lose cycle leads to high rates of creator attrition, leading to large rates of high-demand abandonware, and ultimately large inefficiencies in the entire software ecosystem.
In this post we're going to be diving into the world of Open Source Software and examining this question:
Q: Why is Open Source Software unsustainable in its current form and how can we fix it?
Open Source Software is inherently unsustainable because the currently implemented incentive structure between creators and users are not aligned. Users can extract infinite value from OSS while creators often get nothing. This leads to otherwise successful projects becoming abandonware, wasting resources on both the User and Creator front.
The current cycle of OSS:
- Creators build something of value
- Users leverage that value
- Users demand more
- But Creators don't get value in return
This leads to short-term outcomes:
- Creators burn out (because they expend more effort than they get in value)
- Package gets abandoned even though lots of User demand
and long-term outcomes:
- Users either spend a lot more effort to fork and maintain their abandonware or switch to the next package
- Creators less likely to want to build / maintain new OSS
This is a vicious lose-lose cycle. The more people play the more likely it is that a User / Creator gets burned by abandonware despite high demand and decides not to play again.
In this post we're going to explore the state of the OSS ecosystem, some perspectives on what makes it unsustainable, and some potential paths to sustainability.
The State of Open Source
There's that saying that we stand on the shoulders of giants - essentially meaning that everything we are able to achieve today is largely due to our ability to leverage all the achievements of those that came before. Proving this is obvious - my life would be substantially worse if I didn't have ready access to water, electricity, and the internet - all of which are only possible due to the achievements of those that came before. We might call these dependencies we rely on every day - Load Bearing Dependencies (similar to Load-Bearing Internet People).
Image source: XKCD - Dependency
The software industry is largely the same. There are many Load Bearing Dependencies that the majority of software projects / companies use to run. Many of these dependencies have been built and maintained by a single random person who likes to tinker on weekends - for years. Millions of developers use their work for free via package managers in order to build their own projects / companies.
Yet very few of these Load Bearing Dependencies and their weekend tinkering creators ever see monetary rewards for their work. Much less rewards enough to pay for the time they put in. They're largely thought of as volunteers, if they're thought of at all.
And therein lies the problem. We have a single point of failure in our system and there's very little incentive for that single point of failure to not fail. In fact the extra load from people using that tiny package often increases the incentive to fail in the form of extra work for little reward - an influx of new requests, hours building / maintaining the software and its build pipelines, keeping up with PRs / requests / roadmaps, etc.
In software, one of the driving principles we strive for is reliability. This is because if our system isn't reliably doing what it's supposed to then it's not a very useful system and nothing else really matters. Single points of failure are a common factor for reliability issues so we try to build redundancies / fallback mechanisms to deal with them when they inevitably fail - and they will inevitably fail.
And yet, here we are building our entire systems on top of multiple single points of failure with no fallback mechanisms and indeed an increased incentive to fail as it gets more popular! Can you imagine a sustainable system in which the more useful it becomes the worse it works?
If this was a business - it would never open. If this was software, we'd rearchitect so it could scale.
Why People build Open Source
I think it's clear why Users use open source - they get free access to high quality software. But I think we need to spend a bit more time understanding why the Creators build open source in order to come up with solutions that work for both sides.
I recently stumbled on a post that does a great job explaining open source sustainability from an OSS maintainer's perspective.
Image source: Thomas Stringer
In this post the author explains why people build software as a function of their passion and monetary reward:
time = passion + money
I think a more generalized function is probably something like this:
- Motivation leads to effort:
motivation -> effort
- Motivation is a function of interest and reward
motivation = interest + reward
I think this is a pretty accurate generalization of why people do things. People often don't do things only for money / reward nor do they do things only out of interest. There is typically some balance between these value sources that allows an activity to persist sustainably long-term.
It's also critical to point out that as demand grows in OSS, typically Creator interest wanes. Now in the short-term after a spike of popularity this interest probably increases but as this demand leads to more and more requests outside of the Creator's inherent interest, it will wane.
This is similar to what I felt when I left Software Engineering to become a founder - I had more freedom and more potential for reward but because the work required many things outside of what I was actually interested in doing (like marketing / sales / fundraising) my interest dropped dramatically.
A Path to Sustainability
So how do we fix this? Well it doesn't seem we've found a paradigm that's widely worked yet so it's hard to say for sure. But I do think we can pull from what works in other industries / implementations and see if that works here.
In general, for an ecosystem to be sustainable it needs to provide a virtuous cycle. In business we call this a flywheel. Every turn of the cycle leads to a win-win for all players. This means that the more we play the more the cycle spins out value and the more we want to play again.
If we don't have this virtuous cycle then often we have a vicious cycle or no cycle at all. If any part of our cycle loses the more we play then that part will not want to play and thus our cycle stops.
From our previous explorations of OSS and its Creators, it's clear that the biggest factor breaking our cycle is the reward component. There are lots of Creators with interest who start building packages but the reward component is missing which leads to abandonware despite high demand.
So the question really becomes how can we reward OSS Creators sustainably?
The easiest thing to implement would be donations. As people use software they could donate to the Creators and thus Reward its maintenance that way. But we've tried this for years in the industry and it typically just doesn't work outside of the most popular packages (which in turn often don't give to their own dependencies). Not enough people donate and those that do are often just random devs giving $10s while the big cos making bank off this free software give nothing. This leads to the Creators not receiving enough reward to continue.
The next easiest thing we could do is end OSS. At the end of the day what we're trying to accomplish is a fair exchange of value between User <> Creator. Like it or not we've actually come up with a pretty efficient way of doing that - Capitalism. It's truly the most meritocratic exchange of value with Supply <> Demand controls built-in. In this way we ensure Creators always get the reward equal to the value the Users get from it (assuming perfect pricing). But we also see how this one doesn't really work as a whole because it leads to the anti-competitive practices we explored earlier so likely leads to a net negative for the industry.
Which leads us to the middle ground - taxes. We've essentially explored the potential ways to solve this via strict Capitalism - we give directly (relying on the altruism of a minority of whales) or we force value exchange (creating a value obstacle and potentially opening the door for non-competitive monopolies). Now we look at how governments typically solve for this balance between the pulls of individual freedom and good of the masses and find governance and taxes.
Funding OSS via Taxes
In many ways OSS is like a public service. If we think of our software project as a town / city then the OSS packages we use might be a part of the infrastructure it runs on. Maybe it's the blueprints for the streets, the electricity lines, or the water pipes and sewers. If we didn't have these blueprints made available to us then building our software town would be prohibitively expensive because we'd have to do all of that ourselves. In the same way, public services are expensive to build and maintain so a town must charge taxes if it wants to remain functioning.
Good taxes are typically value-based. If you use a public service a lot and / or get a lot of value out of it then you pay more to support that thing. This is mostly a fair trade off and allows those that get the most value to support that thing more - creating a virtuous cycle. Examples might be tolls on highways or income-based taxes.
Image Source: Thomas Stringer
In the OSS Compensation post we mentioned earlier, the author suggests a compensation model like this:
compensation = developers + money
This makes it so that companies contribute some level of compensation consisting of either devpower ior money.
On the surface I think this makes sense:
- Companies must give back value (as they're the ones making value off of this)
- Can give devs or money - depending on their needs, the resources available to them
- Allows individuals to still play with open source for free
The problems are:
- No requirement for cos to give
- Devpower does not scale linearly - too many cooks in the kitchen / mythical man month
So again I think we end up in a weird place where only a few cos are giving (and thus not a big enough pot to reward Creators) and it's very possible that we end up with more unfocused devpower than is actually useful.
IMO: The best software teams are < 6 people who are tightly focused on a given goal. This is much more effective than a team of 100+ who are not focused.
Instead I think a more sustainable model is for every project to be run more like a non-profit company. Their product is the project and the mission is to make x easier via their project and the only reason the company exists is to support this project.
This allows the OSS project to have a little more stability and separation from volunteers, allowing it to build an actual team for the project. This allows a core team to form which can build expertise and vision through focused experience / effort with the project and the problems it tries to solve. Companies should still be allowed to provide devpower but I think the OSS project should be more discerning / in control of who actually joins the core team.
Now this model still has problems in terms of overhead - wrt usage, funding, and organizational overhead. I think we're going to need some form of central project hub that deals with this overhead for projects so they can mostly focus on what they're good at / interested in - the project.
Some examples of overhead across projects:
- What companies use this a lot and probably should be paying?
- How do we distribute funds (and deal w taxes)?
- How do we incentivize funding?
By centralizing a lot of this overhead in the hub, it seems like we could get a nice tradeoff between sustainability for projects without too much extra cost.
Some examples of orgs kind of doing this:
- Open Source Collective - A non-profit that handles funds for a cut of the donations
- GitHub Sponsorships - Companies can sign on to support a project and in turn get a bit of exposure
But I don't think they're quite there yet.
These are just some thoughts from a random guy on the internet. I am not an active OSS maintainer nor do I actively contribute to any OSS projects. But I have seen many packages with a lot of promise / usage die simply because the incentive structure didn't work.
If no one uses it / gets value from it, fine. But if we have both Supply and Demand for a given project, then we have the opportunity for a win-win for everyone. Missing out on this - largely because we weren't intentional - is an unearned loss.
I believe strongly that every action is a vote - for who you want to become and the world you want to live in. If you want something to keep going, you've got to support it. Support the open source projects you depend on.
If you liked this post, you might also like: