Why can’t we just charge for open source infrastructure?
This question comes up often. Those in the startup world, energized by the problem and wanting to help make it better, suggest finding something to charge for to make open source infrastructure more sustainable.
My answer: Why would we WANT to charge for it?
There’s a good reason why some of this stuff is free, and it starts with a trip back to the late 1990s, at the end of the first dot com boom.
Ask any venture capitalist or startup founder why we had a second tech boom, and the answer invariably includes: “Because startups got cheaper to build.”
Ask them why startups got cheaper to build, and they’ll probably tell you about Heroku and AWS. They might mention APIs.
But all that stuff happened from 2005–2010.
Something else had to happen first, and that was the birth of the open source LAMP stack in 1998: Linux (operating system), Apache (server), MySQL (database) and PHP (language). This software bundle allowed anyone to create software applications for a tenth of the cost.
I’ll let VC Mark Suster explain what happened next:
When I built my first company starting in 1999 it cost $2.5 million in infrastructure just to get started and another $2.5 million in team costs to code, launch, manage, market & sell our software.
The first major change in our industry was imperceptible to us as an industry. It was driven by the introduction of open-source software, most notably what was called the LAMP stack.
Open source became a movement — a mentality. Suddenly infrastructure software was nearly free. We paid 10% of the normal costs for the software and that money was for software support. A 90% disruption in cost spawns innovation — believe me.
By not charging for open source infrastructure, we protect the right of anybody with an Internet connection to teach themselves how to code and build. This is good for startups, and for you.
Those people then create things like Facebook, Google, Uber, AirBnB — or, you know, maybe just Goat Attack and glitter bombs.
(By the way, we tried charging for software in the 1980s and 1990s: think Microsoft or Adobe. Remember having to pay $200 to get the latest Windows upgrade? Yeah, nobody liked that.)
Open source infrastructure, like programming languages or libraries, can be thought of as a system of information. Stewart Brand famously said, “Information wants to be free”, despite the fact that it is actually expensive, “because it’s so valuable”. That’s why content is so hard to charge for, and why in the early 20th century, Andrew Carnegie personally financed over half the public libraries in the United States.
One special feature of Andrew Carnegie’s libraries was that people were able to browse books by themselves (called an “open stack” policy). We take this for granted today, but in the early 1900s, people had to request a specific book from a librarian, who would then bring it to you.
Carnegie wanted to empower people to discover information for themselves (and reduce operating costs). Thanks to the precedent set by Carnegie, most libraries switched to an “open stack” policy.
In my last post, I said that we couldn’t charge for Python any more than we could charge for English. The difference between English and Python is that one requires dedicated maintenance and upkeep so that it doesn’t break. It has millions of dollars, and even lives, riding on it.
(Note: Your next question might be, “What about building a consulting business around the project?” Asking someone to do this is like asking a teacher to moonlight as a bartender so they can afford to teach kids. And yes, this is how many open source contributors — and teachers — pay their bills. But consulting detracts from the important work, which is developing the project itself. OpenSSL is a perfect example of a project that monetized through consulting, and we got Heartbleed as a result.)
I’m currently exploring better ways to support open source infrastructure. If you want to stay involved, you can sign up here to get updates when I post something new, or follow me on Twitter.
