Economics of Open Source
Hat tip to Paul Ramsey for the link to this blog post by Stephen O’Grady, “The Economics of Open Source: Why the Billion Dollar Barrier is Irrelevant.”
O’Grady argues that despite protests from those who haven’t seen the billion-dollar-value FOSS company of their dreams, open source business is doing great.
The question, remember, isn’t whether businesses and developers are consuming and producing open source software. They are, in droves. Nor are there questions as to whether or not the software can be sold successfully on a commercial basis: it is, every day. The only remaining questions really regarding the economics of open source are whether they can duplicate the margins of their proprietary predecessors, and frankly I think most customers hope they don’t.
This brings up an understated point about the economics of open source: that the proprietary software production model is a monopolistic model and hence bad for technology consumers. The high margins of proprietary software companies are due in part to monopolistic rents. The non-competitiveness of the proprietary software market leads to bloated, inefficiently created, and poorly supported software.
Another, related economic issue is the challenge of open source business, which O’Grady sums up like so:
Part of the challenge for open source software vendors, of course, is the fundamental difference between open source software and proprietary alternatives, not to mention other tangible goods: the primary asset to be sold is (generally) freely available.
I think this is a poor characterization of the problem. The problem is not that the asset to be sold is freely available. That would assume that software is the asset to be sold. But if an asset is “anything … capable of being owned or controlled to produce value and that is held to have positive economic value,” then free software can’t be the asset.
So what has to be primary asset for open source software vendors? The time of software experts who can do development or support.
At this point the analysis gets confused, because there are two issues at stake. Would-be open source billionaire entrepreneurs become disappointed that consulting and support around open source doesn’t scale as well as their proprietary software forebears. But this reaction is accentuated by another, independent problem: the free-rider problem around developer and support services.
Open source software vendors are in the business of shedding off public goods in the form of (improvements to) freely available software. This is why make sense for an open source vendor like OpenGeo to consider itself a social enterprise: it “does good” merely by operating.
But it also means that these services are going to be under-valued in the market because it is so difficult to capture the consumer demand for a software improvement as revenue.
How much does each user of a free software project value this new feature? Ok, sum that. That’s how much the open source vendor should be able to raise, in principle, for developing that feature–if there is only one potential supplier.
Proprietary software companies are able to capture this demand for the software improvements through the mechanism of selling the software itself. Free software developers won’t be able to raise as much–because they compete with each other as suppliers (which is good for society!)–but there is still a much bigger market there than is currently tapped into.
The kind of advance that will fuel open source business moving forward is mechanisms that allow for the capturing of this latent consumer demand.
The most literal case of this “crowdsourced microfunding,” a model that is greeted with mockery whenever I talk about it to people with industry experience, but which has recently had a preliminary success story: Diaspora’s skyrocketing funding via Kickstarter. Kickstarter, as opposed to other collaborative funding sites that have come and gone like Fundable.org, looks like it has some additional incentive structures built in that eliminate some of the Nash equilibria in the collaborative funding game in which not enough actors participate. (New York Times coverage and mass resentment towards Big Brother don’t hurt either.)
But there are other models for solving this problem as well. For GeoNode, the World Bank’s CAPRA initiative is seeking out partners to build a global community of funders to be in partnership with the developer community.
If this model works and is replicable, the potential impact on the software business world could be immense. Strategic cooperation between major funders would allow them to efficiently channel funding towards development while regulating against free-riders among themselves. The result would be a highly efficient market for software development–more efficient than either the proprietary software market or the free-rider-ridden free software market.
These speculations are consistent with O’Grady’s analysis: none of this leads to a billion-dollar corporation. But it does lead to a thriving economy of smaller scale consultancies, valued fairly according to their expertise, generating a torrent of free software available for all. Isn’t that the best outcome of all?