X

The community made me proprietary

Why good open-source companies turn to proprietary value to make a living.

Matt Asay Contributing Writer
Matt Asay is a veteran technology columnist who has written for CNET, ReadWrite, and other tech media. Asay has also held a variety of executive roles with leading mobile and big data software companies.
Matt Asay
3 min read

I've been following the brouhaha that emerged from The 451 Group's recent report on open-source (non-)business models. It has been suggested that the findings demonstrate that there is no money in pure-play open source, and that every open-source company inherently depends upon proprietary software (or service) to make money.

Agreed. Even Red Hat depends upon providing value through Red Hat Network and RHEL that can't be had elsewhere.

What is perhaps not clear from the ruckus is why proprietary rears its ugly head within otherwise open-source companies. Here are several reasons, the last of which is perhaps the most surprising, but also potentially the most important:

  1. Vendor Sloth. It's easier to look backward to old models as open-source companies navigate the future. The problem with this approach is that it means open-source companies end up much less disruptive than they otherwise could be. This is why I like Mark Shuttleworth's insistence on coloring outside the lines with Ubuntu, just as Google did before him in search, seeking alternative ways to monetize his technology. The rejoinder? He can afford to, while many of us need to feed families today.
  2. Customer Sloth. Most would-be buyers don't intend to free-ride on a community, giving back neither code, nor cash, nor testing, nor publicity; but if given the option to use code for free or pay for it, they'll take it for free. In many cases, it's because creating a business justification for paying is too hard. ("Because we really love this community and want it to survive" turns out to be a lame justification to the CIO and CFO.) Proprietary bits in otherwise open-source software give a clear reason for payment and, hence, supporting the community (as it in turn fuels further open-source development).
  3. Community. Yes, that's what I said. The shrill cries of a vocal minority in the open-source community make it painful to be a pure-play open-source company. In fact, the harder you try to hew to open-source purity, the louder they whine about perceived infractions. It therefore becomes much easier to differentiate one's paid-for offering ("Enterprise") from one's free offering ("Community") by completely separating out proprietary bits, allowing the company to invest fully in its community offering while also investing in its (separate) Enterprise bits. This ends the debate about "ours," turning it into a "mine" and "yours" discussion, which oddly enough is much less fractious than the divvying up communal property.

This last one rankles me the most, but since I've been on both sides of it I guess I deserve to be rankled. Ultimately, the open source that most of us use every day is fueled by cash, whether directly or indirectly. Apache, Linux, Zimbra, etc.: cash makes it go, and big (and small) companies are shoveling that cash in.

Some companies like Google have found highly efficient ways to get cash out of open source. Other companies are expert at writing great open-source software, but still need to find better models for drawing cash out. The sooner these two groups meet in the middle, the better.

I personally believe that a phased approach to open source works best. In an Web-enabled world, companies that try to monetize every transaction will fail, because there are far too many other companies and communities happy to give away the same service or application for free. The secret, then, is in finding ways to give away huge piles of value and monetize just enough of it to make a viable, strong business. Google exemplifies this, as does Red Hat. So long as vendors seek to serve customers first, this principle is easy to follow.