But few have heard its rarely cited second half,
Selective editing has also distorted the meaning of open source. As the open-source world has grown, it has attracted more participants, from individual programmers to large corporations. That is expected. Not all of these participants agree on what open source means. That is also expected. Some influential participants have tried to dilute the idea of open source, dumbing it down from a methodology into a shortcut. That is also expected.
Still, the fact that we can talk about open source at all means that it must have some irreducible features. For example, reasonable people can disagree about what constitutes art. But is anyone going to dispute that the Mona Lisa is a work of art? Likewise, though it doesn’t make sense to speak of open source monolithically, neither does it make sense to assert that it’s a purely subjective concept. Open source must mean something, otherwise it means nothing.
This is what it means to me.
Essential quality #1
Dilution: Open source arises from a spirit of freedom and cooperation.
Reality: Open source arises from a spirit of capitalist competition.
Open source, as a software-development process, allows competing products to emerge without the capital and labor demands of traditional proprietary software development. Most of the successful open-source projects are intended as substitutes for successful proprietary software products. This is no coincidence. The demand for the propietary products is what also creates the demand for the open-source alternatives.
Moreover, the success of an open-source project depends on how well it competes with the proprietary alternative. Time is money. Open-source software that doesn’t get the job done is ultimately no bargain. While some will choose open-source software purely as a political statement, most software customers evaluate their options in the usual terms—cost vs. benefit.
Essential quality #2
Dilution: Open-source developers work for free.
Reality: Open-source developers are paid.
Nobody works on open-source projects for free. Perhaps a small group of developers contributes to open-source projects for entertainment value instead of, say, building ships in bottles. They’re in the minority. Most open-source work is accomplished by professional developers being paid professional rates.
This is necessarily true for two reasons.
Software developers are not altruists. They are rational participants in the labor market, and well-paid ones at that. They have no incentive to devote themselves to open-source development at poverty wages when there’s plenty of companies who would pay them to do the same work.
As already mentioned, open-source software can’t succeed if it doesn’t compete with propietary alternatives. And it can’t compete with proprietary software unless it can attract software developers of comparable quality. And the only way to attract those developers is to pay them market rates. In the sense that there is no free lunch, there is no free software.
Essential quality #3
Dilution: Open source makes things free.
Reality: Open source redefines what is valuable.
Open-source developers don’t work for free, but there’s a symmetric proposition that goes along with that: open-source projects return equivalent value to whoever is paying for that development time—usually the developer’s employer.
If you believe that technology companies behave rationally, this must be true. A company will put its capital into the most valuable activities it can find. If a company is funding open source, the company must expect a return on the investment that’s better than other options.
Essential quality #4
Dilution: Open source has no barriers to participation.
Reality: Open source relies on meritocracies.
Open source couldn’t function without meritocratic filtering. This principle follows naturally from the idea that open source is a method of creating competitive products. To get high-quality results, open-source projects have to insist on high-quality contributions, and reject the rest. Open-source projects are typically open to all in the sense that anyone can propose changes to the code. But those changes can always be rejected or rolled back.
Essential quality #5
Dilution: Open source is democratic.
Reality: Open source relies on benevolent dictators.
This rarely happens. Ultimately, participants in an open-source project get more out of keeping the project intact under one benevolent dictator than fragmenting it into multiple projects. (Once again, the influence of rational incentives.) Likewise, the dictator has an incentive to remain benevolent, since the project could always disappear from beneath them.
Essential quality #6
Dilution: An open-source project can have one developer.
Reality: An open-source project requires multiple developers.
Essential quality #7
Dilution: A software project can be open-sourced at any time.
Reality: Open source is part of the project’s DNA or it’s not.
Open source is a way of making software (and other things). It embodies certain values and excludes others. It’s not intrinsically better than proprietary development. Nor is it appropriate for every project. But the decision to make a project open source is only meaningful early in the project. That way, the leadership, the developer community, and the code can evolve around those principles.
A proprietary project starts with fundamentally different principles, and grows around those principles. It can’t become an open-source project later on, any more than an elephant can become an eagle. Nevertheless, those who convert proprietary projects to open source often suggest that it’s the best of both worlds: a way of sharing the benefits of proprietary development with an open-source community.
Nearly always, it’s the worst of both worlds: open-sourcing just becomes a cynical way of exporting the problems of a proprietary project. Unfortunately, this is the more common scenario, because proprietary projects that are successful have nothing to gain from being open-sourced. Developers aren’t adopting your proprietary technology? Reduce the price to zero and rebrand it as open source. Your proprietary software is full of deep, mysterious bugs? Make it open source, and maybe someone else will fix them. Your technology is about to go obsolete because you were slow to update it? Maybe open-sourcing it will extend its life. Companies fling their software over the open-source fence when they have nothing left to lose.
But the technique has never paid off. The open-source projects that are successful signed onto the methodology early and stuck with it. Commitment alone is not sufficient for open-source success, but it is necessary.
Most of my explanations above have been couched in the language of software development. But the message goes beyond software. Though open source came from the software world, and may remain particularly suited to that kind of project, there’s no reason it can’t be plausibly adapted to other kinds. It’s already happening.
The critical issue is how thoroughly and thoughtfully the open-source model is applied. As open source spreads outward from its traditional roots, it will face higher risk of dilution. Again, I’m not arguing for a canonical definition of open source. Perhaps the best we can hope for is that those who want to call their project open source will educate themselves about the characteristics of successful open-source projects. If you don’t like my summary of essential qualities, then learn enough about open source to come up with your own. And don’t do it out of a sense of obligation or homework—do it out of your own self-interest. How can it hurt to understand what makes other open-source projects successful? Having made that assessment, if you want to modify the key principles for your own project, go ahead. I won’t complain.
But do me a favor: don’t call it open source.
I still largely agree with these essential qualities. Since I wrote the piece, however, I’ve released software for publishing web-based books, called Pollen, that I describe as open source.
Does my project live up to my seven essential qualities? Right now, some more than others. In particular, though Pollen has users who are not me, it still only has one developer, who is me.
But others have started to build tools and code libraries that work with Pollen. So even though I’m the only developer of the core Pollen code, the world’s tiniest ecosystem has formed around it. As that ecosystem grows, I hope that eventually the core Pollen code will be a relatively small part—and I will be a relatively small contributor. And this is the important part of essential quality #6—that the project both creates opportunities for participation and induces that participation.
Still, I suppose I’ve softened on the view that these seven essential qualities should be part of an open-source project right away. In practice, successful open-source projects often take a long time to reach maturity. I don’t expect Pollen to be different.
As the benevolent dictator of my own open-source project, I use these seven essential qualities as guideposts. No, Pollen doesn’t yet meet all of them. But I would like it to. And it’s moving in the right direction. Being open source won’t be a sufficient condition for Pollen’s success. But it will be a necessary condition.
January 2012 & November 2015