Se­lec­tive edit­ing dis­torts ideas. For in­stance, many know Stew­art Brand’s fa­mous ob­ser­va­tion that “in­for­ma­tion wants to be free.” This phrase, stand­ing alone, is of­ten cited in sup­port of the ar­gu­ment that con­straints on dig­i­tal in­for­ma­tion are fu­tile or immoral.

But few have heard its rarely cited sec­ond half, which states the op­po­site premise: “in­for­ma­tion wants to be ex­pen­sive.” When read in con­text, it’s ap­par­ent Brand meant to de­scribe two forces in ten­sion. With se­lec­tive edit­ing, how­ever, the mean­ing changes.

Se­lec­tive edit­ing has also dis­torted the mean­ing of open source. As the open-source world has grown, it has at­tracted more par­tic­i­pants, from in­di­vid­ual pro­gram­mers to large cor­po­ra­tions. That is ex­pected. Not all of these par­tic­i­pants agree on what open source means. That is also ex­pected. Some in­flu­en­tial par­tic­i­pants have tried to di­lute the idea of open source, dumb­ing it down from a method­ol­ogy into a short­cut. That is also expected.

But even if ex­pected, it’s still worth­while to re­sist this di­lu­tion. Why? In the long term, it’s bad for open source. Not nec­es­sar­ily be­cause of ethics or moral­ity—just be­cause of prac­ti­cal­ity and sus­tain­abil­ity. Be­cause if open source is di­luted by de­clin­ing ex­pec­ta­tions, those of us who en­joy its ben­e­fits will ul­ti­mately lose out. Also, those who con­tribute to projects that are “open source” in name only will have good en­ergy wasted on du­bi­ous ends. So we all have an in­ter­est in de­fend­ing open source from dilution.

In that spirit, here are seven qual­i­ties that I con­sider es­sen­tial to the iden­tity of open source, con­trasted with the di­luted forms they com­monly as­sume. The point of this ex­er­cise is not to of­fer The One An­swer about what “open source” means, nor to sug­gest that oth­ers are Do­ing It Wrong. How could I? Open source is in­her­ently het­ero­ge­neous, like every­thing that hap­pens in the agora.

Still, the fact that we can talk about open source at all means that it must have some ir­re­ducible fea­tures. For ex­am­ple, rea­son­able peo­ple can dis­agree about what con­sti­tutes art. But is any­one go­ing to dis­pute that the Mona Lisa is a work of art? Like­wise, though it doesn’t make sense to speak of open source mono­lith­i­cally, nei­ther does it make sense to as­sert that it’s a purely sub­jec­tive con­cept. Open source must mean some­thing, oth­er­wise it means nothing.

This is what it means to me.

Es­sen­tial qual­ity #1
Di­lu­tion: Open source arises from a spirit of free­dom and co­op­er­a­tion.
Re­al­ity: Open source arises from a spirit of cap­i­tal­ist competition.

Open source, as a soft­ware-de­vel­op­ment process, al­lows com­pet­ing prod­ucts to emerge with­out the cap­i­tal and la­bor de­mands of tra­di­tional pro­pri­etary soft­ware de­vel­op­ment. Most of the suc­cess­ful open-source projects are in­tended as sub­sti­tutes for suc­cess­ful pro­pri­etary soft­ware prod­ucts. This is no co­in­ci­dence. The de­mand for the propi­etary prod­ucts is what also cre­ates the de­mand for the open-source alternatives.

More­over, the suc­cess of an open-source project de­pends on how well it com­petes with the pro­pri­etary al­ter­na­tive. Time is money. Open-source soft­ware that doesn’t get the job done is ul­ti­mately no bar­gain. While some will choose open-source soft­ware purely as a po­lit­i­cal state­ment, most soft­ware cus­tomers eval­u­ate their op­tions in the usual terms—cost vs. benefit.

Es­sen­tial qual­ity #2
Di­lu­tion: Open-source de­vel­op­ers work for free.
Re­al­ity: Open-source de­vel­op­ers are paid.

No­body works on open-source projects for free. Per­haps a small group of de­vel­op­ers con­tributes to open-source projects for en­ter­tain­ment value in­stead of, say, build­ing ships in bot­tles. They’re in the mi­nor­ity. Most open-source work is ac­com­plished by pro­fes­sional de­vel­op­ers be­ing paid pro­fes­sional rates.

This is nec­es­sar­ily true for two reasons.

1. Soft­ware de­vel­op­ers are not al­tru­ists. They are ra­tio­nal par­tic­i­pants in the la­bor mar­ket, and well-paid ones at that. They have no in­cen­tive to de­vote them­selves to open-source de­vel­op­ment at poverty wages when there’s plenty of com­pa­nies who would pay them to do the same work.

2. As al­ready men­tioned, open-source soft­ware can’t suc­ceed if it doesn’t com­pete with propi­etary al­ter­na­tives. And it can’t com­pete with pro­pri­etary soft­ware un­less it can at­tract soft­ware de­vel­op­ers of com­pa­ra­ble qual­ity. And the only way to at­tract those de­vel­op­ers is to pay them mar­ket rates. In the sense that there is no free lunch, there is no free software.

Es­sen­tial qual­ity #3
Di­lu­tion: Open source makes things free.
Re­al­ity: Open source re­de­fines what is valuable.

Open-source de­vel­op­ers don’t work for free, but there’s a sym­met­ric propo­si­tion that goes along with that: open-source projects re­turn equiv­a­lent value to who­ever is pay­ing for that de­vel­op­ment time—usu­ally the de­vel­oper’s employer.

If you be­lieve that tech­nol­ogy com­pa­nies be­have ra­tio­nally, this must be true. A com­pany will put its cap­i­tal into the most valu­able ac­tiv­i­ties it can find. If a com­pany is fund­ing open source, the com­pany must ex­pect a re­turn on the in­vest­ment that’s bet­ter than other options.

Open-source soft­ware ad­vo­cates some­times im­pre­cisely de­scribe it as “free as in beer” or “free as in speech.” When I worked at Red Hat a long time ago, an en­gi­neer friend de­scribed it more ac­cu­rately as “free as in pup­pies.” No, you don’t pay for open-source soft­ware. But nei­ther do you get the ex­tras that are stan­dard with pro­pri­etary soft­ware: ease of in­stal­la­tion, sup­port, doc­u­men­ta­tion, and so on. You make up the dif­fer­ence with your time. Or you can pay some­one else for these ser­vices. The net ef­fect is that the mar­ket for soft­ware-re­lated ser­vices is shifted out­side the soft­ware it­self, in­stead of be­ing in­cor­po­rated into the li­cense price. But that mar­ket is merely shifted—not destroyed.

Es­sen­tial qual­ity #4
Di­lu­tion: Open source has no bar­ri­ers to par­tic­i­pa­tion.
Re­al­ity: Open source re­lies on meritocracies.

Open source couldn’t func­tion with­out mer­i­to­cratic fil­ter­ing. This prin­ci­ple fol­lows nat­u­rally from the idea that open source is a method of cre­at­ing com­pet­i­tive prod­ucts. To get high-qual­ity re­sults, open-source projects have to in­sist on high-qual­ity con­tri­bu­tions, and re­ject the rest. Open-source projects are typ­i­cally open to all in the sense that any­one can pro­pose changes to the code. But those changes can al­ways be re­jected or rolled back.

The idea of open source is mis­used when ap­plied to projects that have no mer­i­to­cratic fil­ter­ing and are open to con­tri­bu­tions from any­one. Those projects are bet­ter de­scribed as “file shar­ing.” What dis­tin­guishes the open-source method is its re­liance on a de­vel­oper com­mu­nity to find the best ideas. This nec­es­sar­ily means that most ideas are rejected.

Es­sen­tial qual­ity #5
Di­lu­tion: Open source is de­mo­c­ra­tic.
Re­al­ity: Open source re­lies on benev­o­lent dictators.

Open-source projects are led by de­vel­op­ers who are some­times known as “benev­o­lent dic­ta­tors.” Usu­ally, these are the peo­ple who started the project and are ac­knowl­edged to hold the vi­sion of the project’s future.

They aren’t elected, but on the other hand, they are al­lowed to stay in power only by con­sent of all the other par­tic­i­pants. It’s open source—any­one could take the code and start a new project with it (a.k.a. “fork­ing”).

This rarely hap­pens. Ul­ti­mately, par­tic­i­pants in an open-source project get more out of keep­ing the project in­tact un­der one benev­o­lent dic­ta­tor than frag­ment­ing it into mul­ti­ple projects. (Once again, the in­flu­ence of ra­tio­nal in­cen­tives.) Like­wise, the dic­ta­tor has an in­cen­tive to re­main benev­o­lent, since the project could al­ways dis­ap­pear from be­neath them.

Es­sen­tial qual­ity #6
Di­lu­tion: An open-source project can have one de­vel­oper.
Re­al­ity: An open-source project re­quires mul­ti­ple developers.

This re­quire­ment fol­lows nat­u­rally from the idea that open source is a mer­i­toc­racy. No mer­i­to­cratic fil­ter­ing can hap­pen if all the con­tri­bu­tions come from one per­son. In­di­vid­u­als will some­times pub­lish their per­sonal soft­ware projects and an­nounce “hey, this is now open source.” That doesn’t make it open source, any more than buy­ing a case of beer and a bag of potato chips makes a party. You still need guests. Like­wise, to cre­ate mer­i­to­cratic pres­sure, open-source projects need mul­ti­ple de­vel­op­ers (to cre­ate a com­pe­ti­tion of ideas) and a benev­o­lent dic­ta­tor (to choose among those ideas). With­out this pres­sure, it’s file shar­ing, not open source.

Es­sen­tial qual­ity #7
Di­lu­tion: A soft­ware project can be open-sourced at any time.
Re­al­ity: Open source is part of the project’s DNA or it’s not.

As open source has be­come more suc­cess­ful, more pro­pri­etary soft­ware projects have been “con­verted” to open source. This is akin to graft­ing wings onto a ele­phant in hopes that it will fly.

Open source is a way of mak­ing soft­ware (and other things). It em­bod­ies cer­tain val­ues and ex­cludes oth­ers. It’s not in­trin­si­cally bet­ter than pro­pri­etary de­vel­op­ment. Nor is it ap­pro­pri­ate for every project. But the de­ci­sion to make a project open source is only mean­ing­ful early in the project. That way, the lead­er­ship, the de­vel­oper com­mu­nity, and the code can evolve around those principles.

A pro­pri­etary project starts with fun­da­men­tally dif­fer­ent prin­ci­ples, and grows around those prin­ci­ples. It can’t be­come an open-source project later on, any more than an ele­phant can be­come an ea­gle. Nev­er­the­less, those who con­vert pro­pri­etary projects to open source of­ten sug­gest that it’s the best of both worlds: a way of shar­ing the ben­e­fits of pro­pri­etary de­vel­op­ment with an open-source community.

Nearly al­ways, it’s the worst of both worlds: open-sourc­ing just be­comes a cyn­i­cal way of ex­port­ing the prob­lems of a pro­pri­etary project. Un­for­tu­nately, this is the more com­mon sce­nario, be­cause pro­pri­etary projects that are suc­cess­ful have noth­ing to gain from be­ing open-sourced. De­vel­op­ers aren’t adopt­ing your pro­pri­etary tech­nol­ogy? Re­duce the price to zero and re­brand it as open source. Your pro­pri­etary soft­ware is full of deep, mys­te­ri­ous bugs? Make it open source, and maybe some­one else will fix them. Your tech­nol­ogy is about to go ob­so­lete be­cause you were slow to up­date it? Maybe open-sourc­ing it will ex­tend its life. Com­pa­nies fling their soft­ware over the open-source fence when they have noth­ing left to lose.

But the tech­nique has never paid off. The open-source projects that are suc­cess­ful signed onto the method­ol­ogy early and stuck with it. Com­mit­ment alone is not suf­fi­cient for open-source suc­cess, but it is necessary.

Most of my ex­pla­na­tions above have been couched in the lan­guage of soft­ware de­vel­op­ment. But the mes­sage goes be­yond soft­ware. Though open source came from the soft­ware world, and may re­main par­tic­u­larly suited to that kind of project, there’s no rea­son it can’t be plau­si­bly adapted to other kinds. It’s al­ready happening.

The crit­i­cal is­sue is how thor­oughly and thought­fully the open-source model is ap­plied. As open source spreads out­ward from its tra­di­tional roots, it will face higher risk of di­lu­tion. Again, I’m not ar­gu­ing for a canon­i­cal de­f­i­n­i­tion of open source. Per­haps the best we can hope for is that those who want to call their project open source will ed­u­cate them­selves about the char­ac­ter­is­tics of suc­cess­ful open-source projects. If you don’t like my sum­mary of es­sen­tial qual­i­ties, then learn enough about open source to come up with your own. And don’t do it out of a sense of oblig­a­tion or home­work—do it out of your own self-in­ter­est. How can it hurt to un­der­stand what makes other open-source projects suc­cess­ful? Hav­ing made that as­sess­ment, if you want to mod­ify the key prin­ci­ples for your own project, go ahead. I won’t complain.

But do me a fa­vor: don’t call it open source.

I still largely agree with these es­sen­tial qual­i­ties. Since I wrote the piece, how­ever, I’ve re­leased soft­ware for pub­lish­ing web-based books, called Pollen, that I de­scribe as open source.

Does my project live up to my seven es­sen­tial qual­i­ties? Right now, some more than oth­ers. In par­tic­u­lar, though Pollen has users who are not me, it still only has one de­vel­oper, who is me.

But oth­ers have started to build tools and code li­braries that work with Pollen. So even though I’m the only de­vel­oper of the core Pollen code, the world’s tini­est ecosys­tem has formed around it. As that ecosys­tem grows, I hope that even­tu­ally the core Pollen code will be a rel­a­tively small part—and I will be a rel­a­tively small con­trib­u­tor. And this is the im­por­tant part of es­sen­tial qual­ity #6—that the project both cre­ates op­por­tu­ni­ties for par­tic­i­pa­tion and in­duces that participation.

Still, I sup­pose I’ve soft­ened on the view that these seven es­sen­tial qual­i­ties should be part of an open-source project right away. In prac­tice, suc­cess­ful open-source projects of­ten take a long time to reach ma­tu­rity. I don’t ex­pect Pollen to be different.

As the benev­o­lent dic­ta­tor of my own open-source project, I use these seven es­sen­tial qual­i­ties as guide­posts. No, Pollen doesn’t yet meet all of them. But I would like it to. And it’s mov­ing in the right di­rec­tion. Be­ing open source won’t be a suf­fi­cient con­di­tion for Pollen’s suc­cess. But it will be a nec­es­sary condition.

—Matthew But­t­er­ick
Jan­u­ary 2012 & No­vem­ber 2015