Putting a Price Tag on Open Source
I’ve previously written about common reasons that developing open source software is not funded. That post focused mostly on the individual circumstances and choices of open source maintainers and projects. In contrast, this post attempts to apply a more systemic lens to the same question. My conclusion is that by using some of the tools of antitrust economics we find a structural explanation for why so many open source maintainers fail to capture value from their projects (in the form of their work being unfunded).
It is worth saying at the outset that open source software is not monolithic, and treating it as such is a mistake. In innumerable ways, CPython is not like Android which is not like zlib which is not like the Python Cryptographic Authority which is not like the Linux kernel. Some of these projects have effectively no funding, others are almost entirely developed by people paid to work on the project. Some could be rewritten in a few weeks, others are the work of many lifetimes. While we often talk about open source software in general terms, I think it’s clear that in many key respects (particularly when we’re talking about open source and money) these projects are not alike. As such, this post is primarily about open source projects which are principally maintained by volunteers.
A year ago, a colleague opined to me that he thought the question of how much open source software was worth was incoherent: Under capitalism (understood broadly) one of the features of a market is that it provides price discovery – the process of buyers and sellers figuring out what the other will sell or buy for. For voluntary transactions, things are worth the intersection of what someone will sell for and what someone will buy for. Most open source software is transacted for $0 (sometimes people pay slightly more, and sometimes people spend non-zero amounts to obtain adjacent services like consulting from a maintainer). Does this mean that most open source software is worth $0? There’s something viscerally offensive about this question. Whether you’re an open source maintainer or consumer, you find open source software valuable!
However, for most purposes we’re not particularly interested in how much open source software is worth, we’re interested in the adjacent, but distinct, question of how much value it creates. There’s been some attempts to study this question, but the answers those studies provide don’t appear reliable (the best paper I’m aware of on this subject attributes 90% of open-source value creation to software written in Go). Regardless, most people believe the amount of value created by open source software is substantial. Which is cool, creating value is fun, and is in many way validating of the quality and importance of the open source software we create.
However, I believe many people make the mistake of taking the answer to “how much value is created” and treating it as the answer to “how much could I charge for this open source software if it were commercial software”. But those aren’t the same question, and they don’t have the same answer. It is extremely obvious to any observer that many open source maintainers capture very little (if any) of the value created by their open source projects. When I say “capture value” I’m referring to users paying or donating to the maintainers of a library for its development (I’ll be using this vocabulary throughout this post). In fairness, some maintainers aren’t even trying to capture value, they’re just giving a thing away.
I believe that the most significant factor that is ignored in looking at open source value capture is competition. In markets, competition is the engine that drives price reductions and quality improvements. In any market, if you make a useful thing and are very profitable, you will induce other people to enter the market, compete with you, and try to capture some of that market share (and profits) for themselves. Competition is the force that makes this redound to the benefit of consumers: competition drives value capture from producers to consumers, generating consumer surplus. In a (theoretical) maximally competitive market, we expect prices to fall to the marginal cost of production, and for all value to be captured by consumers. As a consumer, I’m a fan. Despite the centrality of the concept of competition to economics, I’ve never seen it discussed in the context of open source funding.
Economics has tools for measuring how competitive (or in the alternative, consolidated) a market is, such as the Herfindahl–Hirschman Index (HHI). But before you can measure how competitive a market is, you need to identify what the market is. Market definition, however, is not an simple subject. In all of the modern antitrust litigation I’m aware of, it is a fiercely contested question: who exactly do the defendants compete with? Plaintiffs generally argue for smaller markets, while defendants argue for broader markets (smaller markets make it easier a plaintiff to show the defendant has monopoly power, and the inverse for larger markets). At base, market definition is about cross-elasticity of demand. Cross-elasticity of demand basically asks: If you change the price (or quality) of a good, what do people switch to or from? Alas, figuring out the cross-elasticity of demand between different products is easier said then done, as a result of which antitrust economics has also come up with tools to attempt to figure it out.
So how much competition is there in open source? That’s not a coherent question. A better question would be: for any given open source project, what market does it participate in, and how competitive is that market? I’m not going to attempt to resolve that rigorously (if for no other reason than there are thousands of open source projects, each with their own market definition analysis), but we can do some thought experiments. One of the tools economists use to define markets is SSNIPT, or “small but significant and non-transitory increase in price or other worsening of terms”, which asks: could a company profitably impose a persistent small price increase (5-10%), or would they lose customers to a competitor? If you can successfully raise prices in this way, it suggests that you have monopoly power.
There’s lots of quantitative ways economics look at this question, but for this post we’re just going to do a thought experiment. What would happen if a popular open source project got worse? Not catastrophically worse, but a bit worse and it stayed that way. Would people switch to other competitors? Clearly the answer to this question depends on the nature of the project. Changing programming languages is much different than swapping out a CSV parsing library. But I think one uncomfortable observation is: many popular open source projects could get worse, and stay that way for a long time, without it really impacting how much people use them.
While there are some types of projects for which there are many choices (e.g., programming languages, databases, or web frameworks) there are plenty of others for which there are hardly any choices. There are not very many PNG libraries for Python, TLS libraries for Ruby, or regular expression libraries for Rust. In fact, there seems to be an inverse correlation between the number of head-to-head competitors a project has and how painful it is to switch. A small library used to implement one piece of functionality in an application might be easy to switch to a competitor (but there aren’t many choices available!), while there are numerous programming languages available and switching an existing project is quite involved. This is all complicated by the fact that there’s a difference between making technical choices for a greenfield project and for an existing project: when you chose the programming language (or web framework, or anything else) for a new project, you can compare them on the merits of how well you expect them to work for your use case, but after you’ve selected a set of core tools, you face non-trivial switching costs. In addition, this presents the possibility that for greenfield projects, libraries for different languages may compete (e.g., a Go CSV parser competes with a Ruby CSV parser), because a user might select a programming language based on the availability of an exceptional library for their needs, but for existing projects these libraries do not compete (because switching libraries would require switching programming languages at high cost).
In part, the lack of competition for many open source libraries is likely because its relatively common in open source ecosystems for people to push for there to be a “single right answer”, and to favor collaboration over competition. When a new library appears, its often treated as a replacement for a predecessor, not something that will compete with another library for the “market”.
Returning to the question of what happens when an open source project gets worse, the idea that a project could get worse for a protracted period of time without losing market share would suggest that (some) open source projects face little competition. This suggests they should be able to capture significant value (because, as someone with monopoly power, they can profitably raise prices), but in practice this is a dynamic we almost never see. Instead, what we do see from time to time is that a new competitor will emerge, in the form of a fork! Whether its LibreSSL and OpenSSL, libav and ffmpeg, or ValKey and Redis, at some point a fork may emerge. Indeed, the example of ValKey/Redis is illustrative, as that fork occurs explicitly in the context of the Redis owner attempting to capture greater value.
Perhaps it’s the case that while many open source projects face little competition, nevertheless “competition is just a click of the fork button away”.1 This isn’t a dynamic that occurs in commercial markets, for obvious reasons. But it does provide an explanation for what we see: open source projects frequently have no or few head to head competitors, but can’t capture value because the cost of a new entrant in the form of a fork is effectively zero, constraining their ability to profitably raise prices. This dynamic may also explain why convincing people to fund open source maintenance is hard: its always possible to add more funding later and fork a project if it becomes unmaintained – there’s no risk of an open source project “going out of business” in a way that’s impossible to resuscitate.
Why should we, open source maintainers and users, care about this? I think its critical to understand whether things happen for structural reasons or idiosyncratic ones. These thought experiments (if you find them at all persuasive) suggest there are structural reasons that open source maintainers capture so little value from their projects, and why companies that contribute so often treat them as donations and not like vendors. And of course, the risk of a fork comes not just from companies, but also individual open source contributors. If an open source project attempts to capture too much value (taking away from consumer surplus!) there will inevitably be open source “scabs”, willing to fork the project and maintain it with less value captured by maintainers.
Before I close, I want to consider two additional perspectives on the question of why open source maintainers capture so little value. The first can be found in Avery Pennarun’s The Gift of It’s Your Problem Now. He writes, “The best part of free software is it sometimes produces stuff you never would have been willing to pay to develop (Linux), and sometimes at quality levels too high to be rational for the market to provide (sqlite).” Simply put, lots of open source projects put an emphasis on attributes (such as quality, or ergonomics) that are well in excess of what anyone would rationally pay for. When open source is consumed at no cost, a consumer doesn’t mind getting something better than they need (why would they, there’s no extra cost!), but if a maintainer tries to capture value (raising the price above $0) a consumer would be happier simply using a worse good for free.
Second, I believe there’s a very strong reason to believe that a significant portion of the value that’s created by open source is precisely because it costs $0. That is to say, any attempt to charge more than $0 would inextricably cause less value creation. And the reason for the discontinuity at $0 is because it eliminates significant sources of dead weight loss. If you charged $0.01 for your open source software, that’s remarkably close to charging $0 in economic terms. However, charging $0.01 requires you to have payments infrastructure, to figure out what the unit of software you’re selling is (when does a customer need to spend $0.02 to get two copies of your software?), your customers will require you to register as a supplier in their system. All of these are costs to incurring any non-$0 transaction, and they make $0.01 seem remarkably like $1000. While maintainers for decades have insisted that software is free as in speech, not free as in beer, I think it’s quite clear that being free as in beer is exceptionally important to the amount of value that open source software creates.
Having written all this, and conducted all these thought experiments, I’m led to the conclusion that open source maintainers capture very little of the value they produce for real, structural, reasons. One of the consequences in a situation like this is that it creates consumer surplus, and also expands output (i.e., more people use the software because it’s free). In a normal commercial market, both of these things are generally good (competition is a force that ensures consumers, rather than producers, capture value). A major asterisk, is whether or not that output expansion (and consumer surplus) are sustainable. Of course, many people’s critique of the failure to pay maintainers for open source software is that it renders open source un-sustainable, and thus they’d say that if sustainability remains an open question, then this whole piece is just begging the question. Unfortunately for them, a) this was fun to think about and write, b) “how much short- or medium-term consumer surplus should we give up to obtain sustainable output” is a very awkward question! It’s also quite clear, I think, that there are many open source projects with long track records of sustainability, even in the absence of any funding.
Hopefully, you found all this as interesting to think about as I did. Perhaps you had some different empirical observations than I did on some of the key thought experiments. Please tell me about them! It’s also my hope that perhaps someone will be able to invert this blog post, and find some ways to use this all as a blueprint for maintainers to capture value, without destroying consumer surplus, or perhaps as a way to rigorously identify open source projects that have actual sustainability risks from their lack of funding. Finally, I’d love it if people would attempt to quantify the cross-elasticity of demand for different types of open source projects.
-
With apologies to Google and their attorneys, who love saying “competition is just a click away” with respect to their monopoly on general search services. ↩︎