5 Mistakes Open Source Software Companies Make, and How to Avoid Them

What does it take for open source software companies — and their partners — to thrive? Fifteen years ago, that would have been a tough question to answer. But now, with so many companies already having gone open source, it's easy to look back and identify what makes open source work, and which mistakes open source companies should avoid.

By open source software companies, we mean ones that engage the open source ecosystem in some way. They don't need to make all of their products open source. They don't have to be developing open source code. They just need to work within the open source channel in one way or another.

When you look at the history of those businesses, some trends come to light. Here's what hasn't worked well for open source companies.

Expecting Other People to Write Your Code

When Mozilla launched in 1998 by open-sourcing the Netscape Navigator browser code, it was a big deal. Mozilla was the first major organization that shifted from a closed source to an open source model because it thought the latter would work better for business.

But Mozilla quickly learned that simply open sourcing Netscape didn't mean an army of volunteers would materialize to help build its product. Instead, Mozilla development lagged at first. One of the chief Mozilla leaders, Jamie Zawinski, jumped ship within a year (actually, a year and a day) of the launch.

Things eventually worked out, of course. The browser that became Mozilla Firefox went on to evolve into one of the most successful open source projects — but not until after Mozilla learned the hard way that it is easy to make code open source, but hard to get third parties to start contributing to it.

Cherry-Picking Which Products to Open-Source

Some open source companies have placed themselves in awkward positions by choosing to open-source some products but not others. Canonical, for instance, has become a huge presence in the GNU/Linux world through its open source Ubuntu platform. But it has irked some users by keeping other code closed.

In some ways, that makes business sense. But it also sends mixed signals to the community, and undercuts enthusiasm. It's better to err on the side of making code open unless there's a really good reason not to.

Neglecting Documentation

If you're a programmer, you probably enjoy writing code much more than documentation. But software is not very useful if the designers provide no instructions for actually using it.

This challenge plagued the first and arguably most important free-software project, GNU. (I know: GNU was not a company, but the example still applies.) By 1988 the GNU developers had produced an impressive body of code. But little of its was documented. GNU tried to shore up this problem by appealing for donations so that it could "hire somebody to write documentation!!!" as a GNU newsletter put it at the time. But it wasn't until Dick Karpinski, a professor at the University of California at San Francisco, announced a 1,000 dollar cash prize for writing GNU documentation that people started doing it.

GNU learned the hard way that documentation isn't something you can tack on after your code is written. You should have a plan from the start for making sure documentation develops as rapidly as your code.

Adopting a Simplistic Business Model

Ask people how open source companies make money, and the response will usually involve selling support service related to code that is given away for free. But if you look closer, that's not actually the crux of the business model at the most successful open source companies.

Take Red Hat (RHT). Yes, Red Hat sells support services for many of its products. But as the company's founder and former CEO Bob Young put it in an essay titled "Giving It Away: How Red Hat Software Stumbled Across a New Economic Model and Helped Improve an Industry" (published in the 1999 volume Open Sources, edited by Chris DiBona, Sam Ockman and Mark Stone), Red Hat thrived because it focused on building a brand name, not tacking support services onto open source products.

Young compared Red Hat to the commodities industry. Making money with Linux was like selling ketchup, he wrote. On its own, ketchup is cheap and can be made at home. But Heinz makes millions of dollars selling ketchup because it has built a brand people trust. People could make ketchup in their own kitchen sinks, just as admins could build their own GNU/Linux distributions. But they don't. People buy ketchup from Heinz because of the Heinz brand. They purchase Red Hat Enterprise Linux subscriptions because of the Red Hat brand.

The takeaway is that success involves more than just offering some kind of support service and hoping people purchase it. You need to give customers a compelling reason to seek commercial support in the first place, and, once they do, to decide to use your offering.

Reinventing the Wheel

One of the major arguments in favor of making code open source is that it saves developers from having to reinvent the wheel. Instead of writing a new program that does the same thing as one already in existence, you can borrow someone else's code, and put your own energy into creating additional, original features.

But that hasn't stopped many open source companies and projects from creating redundant code. For example, there are at least a dozen orchestration platforms currently available for Docker containers — Swarm, Kubernetes, Mesos and lots of others. They are not identical. But they all do the same general thing. That makes it hard for any one orchestrator project, or the company behind it, to gain an edge.

The lesson here is that open source organizations thrive when they avoid building redundant solutions. Otherwise, it's hard to make a splash.

Have other ideas on what makes open source work best? Feel free to share.