Despite starting as a “cancerous” and purportedly “anti-American” blight on the software world, open source has come to be as American (and capitalist) as apple pie. Everyone uses it, big companies like Facebook bake it into their standard development practices and practically no one questions its value anymore.

Which is interesting, because it’s by no means clear that your software needs to be open source. Before you assign your code to The Community, here are some considerations that should factor into your decision.

First, Some Myths

Whether you’re new to open source or and have been around for years, you will have heard about The Community. You’ve been warned not to make The Community angry. You’ve been advised that The Community is huge and will shower code on you if you open source your code. You have heard The Community described as a loose affiliation of pizza-eating hackers who code for love.

In other words, you’ve been fed a lot of nonsense.

First of all, there is no Open Source Community, as John Mark Walker insisted years ago. Open source is, instead, a community of communities. The nature of open-source communities differ markedly from one to the next.

Yes, there are common traits of successful open-source communities, but even if you follow them a certain amount of good fortune is required, just like in proprietary software (e.g., getting market timing right). Also, don’t expect your project to work if you assume that “if I open source it, developers will come.”

Why? Because all open-source projects get the vast majority of code contributions from a small group of dedicated developers, and the gargantuan majority of open-source projects never attract more than the founding developers and are discarded within the first year.

(By the way, “dedicated” is a nice way of describing developers who are paid to contribute. This is as true of “community” projects like Linux as it is for “commercial” projects like Alfresco. Few people can afford to work full-time for free.)

Finally, you’ve no doubt heard of The Community’s best efforts to tear itself apart with fights between GPL and Apache advocates. (I’ve argued for both GPL and Apache at different phases of my career.) The license wars are over: Apache won. Actually, if the GitHub generation is indicative of trends, and I think it is, then actually “no license at all” licensing has won.

Why Not To Open Source

Open source isn’t the panacea some proponents would have you think

Despite an increasingly blasé attitude toward licensing on the part of many developers, open sourcing your project will almost certainly involve significant costs.

For one thing, if you’re opening your code, it’s going to require extra work to ensure that it won’t embarrass you. The other day, I was talking to a MongoDB engineer who used to work for big, brand-name proprietary software companies. The biggest difference between proprietary code and open-source code, he told me, is quality.

In his experience, proprietary software tends to be written for business-mandated deadlines. The important thing is to ship the code, even if it’s not great. In open source, by contrast, his experience suggests code doesn’t get released until it’s ready, even if business tries to impose release dates.

While neither characterization is perfect, the principle is correct: when your code is on display, you’re going to make sure it’s of higher quality than if it’s hidden behind license restrictions.

That may be great for the ultimate users of open-source software, but it means that open sourcing code isn’t simply a matter of picking a license, releasing the code and popping a bottle of champagne as you wait for The Community to start beavering away. If you choose to open source your software, you also choose to spend a lot more time getting it in shape—that is, making sure it’s modular and well-documented so that contributors can easily get involved, as Matt Harrison highlights.

Even when you go through this trouble, do you really want help? Noah Kantrowitz just took Chef Inc. to task for being open source in name only:

We have ChefInc putting in a massive amount of time and money along with a few individuals, then a small handful of companies and even fewer individuals contributing through one project or another, and then the long tail of pure consumers.

In such a world, does open source code matter? I’d still argue that the answer is yes. But let’s be clear: This approach means you’re adopting a more difficult business model.

Open sourcing your code usually cuts your business off from easy revenue streams. Dropbox can open source its Go libraries because its business doesn’t depend on selling these libraries. But if you sell a CRM system, open sourcing that system will significantly impact your ability to make money from it.

No wonder Marc Andreessen got so much retweet love when he quipped:

"The best minds of my generation are thinking about how to make people buy support contracts for free software." –Anonymous — Marc Andreessen (@pmarca) June 16, 2014

For those of you who’ve tried it, that statement rings of both mirth and misery.

Even if you fit more into the Dropbox model and want to open source code to attract The Community to help you build it out, the cruel reality is that most projects, most of the time, are on their own.

So What Good Is Open Source?

With this in mind, why would you ever open source your code?

Well, if you write infrastructure software (operating systems, databases, etc.), you don’t have a choice. As Cloudera co-founder Mike Olson declares:

[T]here’s been a stunning and irreversible trend in enterprise infrastructure. If you’re operating a data center, you’re almost certainly using an open source operating system, database, middleware and other plumbing. No dominant platform-level software infrastructure has emerged in the last ten years in closed-source, proprietary form.

If you want your project to be noticed, more likely than not it’s going to need to be open source. Whether you like it or not, “open” is the primary currency that developers understand.

While some have succeeded in getting around this requirement with “cheap and easy to adopt” (e.g., Amazon Web Services), or with “cheap and immediately available,” as Tim O’Reilly discusses, using an open source license tends to be an easy shortcut.

It also offers all sorts of other benefits, from free advertising to technical recruitment to frictionless code sharing and more. When I asked a few members of various open source development communities, it became clear that open sourcing one’s code also affords personal freedom, per Tony Yarusso:

@mjasay Convincing employer to let me put an OSS license on work product means I can use those scripts personally and at future jobs. — Tony Yarusso (@TonyYarusso) July 3, 2014

And personal satisfaction, per Paul Ramsey:

@mjasay "Someone else might find this useful, and then think I'm cool." #amended — Paul Ramsey (@pwramsey) July 3, 2014

Beyond such personal reasons, it’s also true that open code can be a great way to disrupt incumbent vendors if you’re an upstart looking for ways to prove yourself against established vendors.

Besides, open source is fun. I’ve worked at open source companies for nearly 15 years, and have witnessed firsthand the camaraderie and collaboration that open code fosters. Oh, and plenty of flamewars—but The Community has gotten better about that.

No, open source isn’t the perfect option for everyone. But in my experience, “open” should be the default for all software and all companies. You may find the same.

Images courtesy of Shutterstock