On Open Source Sustainability #
It's been 10 years since I wrote Money and Open Source. In the past decade,
- Several startups have been founded to "solve" the problem of open source sustainability. (None have succeeded.)
- Several open source projects have gone the route of raising venture capital (including mine), to mixed results.
- Most individual OSS devs are still giving their labor away for free to commercial entities, but the commercial entities have started to experiment with not doing that.
tl;dr - The current situation isn’t optimal
It still isn't.
What follows is an extremely abbreviated summary of what I've learned in the last 10 years on this subject, why nothing has changed, and what I think needs to change in order to make OSS a "good job".
What Is Success? #
When discussing a problem, it is always best to clarify what success would look like. The term "sustainability" gets thrown around a lot in this conversation, but I don't often see tangible definitions of what that would mean.
It's no mystery why this is. Carefully defining "sustainability" would make it much more challenging to declare progress towards victory, which is essential to securing investment. Note: I did not say "declaring victory" - the goal of any extended project like this requires setting yourself up to say "We've made so much progress! We're so close! With your help we'll finally be able to..." and so on.
But as one who does and cares deeply about open source creation and sharing, I am interested in actual success, not just a never ending failure that benefits me personally.
Success would mean that open source is sustainable. That means, for the people who create and maintain the open source commons, the "producers" in this ecosystem:
- There are compelling personal reasons for them to continue providing this labor and putting the value produced by that labor into the open source commons.
- They are capable of dedicating their time and attention towards this labor. That is, there are no compelling financial, legal, emotional, or social reasons preventing them from spending their time in this way.
- The benefits of performing open source labor must be consistent enough to factor into rational lifestyle choices.
In practical terms, that means that the time and attention spent on open source development, for a sufficiently skilled and motivated developer, must provide a level of income at least roughly commensurate to what they can attain at a full time job working in technology.
Developers are humans. Humans eat. Humans have children and parents to care for, hobbies to pursue, and bills to pay.
In order for open source to be "sustainable", it must be feasible for a well-established prolific open source developer working full time on valuable open source projects to make around $200,000 per year from their efforts.
At the very least, I would expect that the developers in the top 1% or so of open source producers would be able to make a full time job of it. Until that happens, open source is not sustainable.
I usually shy away from discussing things like this in moral terms, because I find practical considerations are much clearer and less open to ambiguity. But, on strictly moral grounds, I would submit that if "open source" fundamentally cannot be made sustainable, then we should stop doing it, for the simple reason that harming and exploiting ourselves and others is a bad thing to do.
Why All OSS Sustainability Attempts Have Failed #
Since I did write that article 10 years ago, and because I've done a lot of open source stuff and remain prolific on GitHub, I'm regularly approached by startup founders pursuing new OSS Sustainability ideas. I always agree to take these calls.
They fall into three general categories, all of which are doomed to failure:
- Make giving and receiving donations really easy, and people will donate.
- Replace existing open source commons with a paid alternative that devs will adopt and enterprises will use.
- Invent an entirely new economy to replace capitalism.
None of these are capable of achieving the success defined above, because none of them are really trying to achieve it. I have not seen evidence that a single open source developer is capable of achieving a full "salary replacement" income from any of these efforts.
Marketing vs Passing The Same Dollar Around In Circles #
The problem with donations is that there are 2 general ways that they can be solicited: to corporations or to developers.
Soliciting companies for donations to open source is not feasible, because for-profit companies are not charities, they are interested in their own profits. (It's what they're literally for.) Without a positive ROI, they usually won't (and, arguably, shouldn't) do it.
So, the motivation tends to be marketing, either for their products, or to build credibility in the development community, appear as good actors, etc. A smart company will thus donate the minimum necessary to achieve the maximum positive return on that investment.
They are not motivated by the potential demise of open source (if it dies for us, it dies for everyone, so we're no worse off) or of any particular project (if needed, we can fork and pay a dev to maintain it, but if not needed, don't).
There are some exceptions, but not many. It's worth noting that, at least in Sentry's case, one of the people behind this generousity appears to be Chad Whitacre, the founder of GitTip who I mentioned in that essay back in 2013. Good on Chad, he definitely has been at this for a while.
I may be overly cynical, and it's inspiring to see that level of commitment to a worthwhile charitable cause. But I remain skeptical that "exceptionally charitable individuals" is a scalable solution, no matter how inspiring they may be.
Soliciting donations from individuals participating in open source communities is an easier sell, since they tend to appreciate the need to support others like themselves, but the futility of such an approach should be obvious. If we all donate $20 to our favorite developers, and they donate the majority of what they get to other developers, it's one big love fest, but everyone starves (except the payment processors).
Replacing Open Source Commons #
The idea is: instead of publishing your code to npm, rubygems, cargo, et al, you publish it to some other system, which consumers have to pay to access.
This isn't going to happen.
When it comes to open source communities, inertia and gravity are the most powerful forces in the universe.
When there is a vacuum, an entrant into a field can fill the niche and attract users and attention. But even when that happens, things don't often get "completely replaced". The "node killer" finds a new niche next to node, which keeps on doing its thing.
Open source distribution channels, in particular, are exceptionally sticky due to the interconnected nature of dependency graphs. People want to publish their code where the users are; users want to use the system where the libraries are published.
The chicken/egg problem with this strategy makes it completely infeasible.
Software Supply Chain Security #
https://www.softwaremaxims.com/blog/not-a-supplier