Fitting the optimal level of openness to your business strategy

As open source has gone mainstream, it has become clear that "open source" is a much bigger tent than Richard Stallman, founder of the free-software movement, or the Open Source Initiative, maintainers of the Open Source Definition, envisioned.

Open source is being applied to a wide array of industries--from software to automotive--and it has started to assume different forms to fit the very different needs of insurgents and incumbents, customers and vendors, nonprofits and for-profits, at different phases of development.

One way to view the continuum of disparate needs, and the licensing strategies that adhere to them, is with this simple grid:

The Open Source Continuum

(Credit: Matt Asay)

Generally, openness favors new entrants to a market while proprietary ("standards," source code, APIs, etc.) favors incumbents. It's therefore not surprising that JBoss open-sourced its application server, not BEA (now Oracle).

Incumbents, however, are increasingly turning to open complements to spruce up the attractiveness of their proprietary cores. Hence, we see Microsoft encouraging open-source add-ons for its CRM and SharePoint products, even while keeping the cores firmly proprietary. The same is true of IBM, which has been exceptionally astute at encouraging and creating open complements (Eclipse, Linux, Apache, etc.) to its closed cores (Hardware, WebSphere, etc.).

At the same time, we've watched self-described open-source companies begin to add to their open cores with closed complements to provide more predictable (and more easily justified) sales. SugarCRM led the market with this model, but since then it has been followed by virtually every open-source software company that does greater than $10 million in sales.

Sales motivates both incumbents and insurgents to keep some aspect of their software closed, but this must be balanced against the desire to attract users and, eventually, developers. Generally speaking, openness attracts adoption far more efficiently than proprietary: the fewer the restrictions on download, use, and potential derivative works, the greater the likelihood that users will flock to it.

Many, however, assume that "community" is the Great Panacea in the Sky, the one thing that will make a company (or project) great. For those who continue to cling to this myth, Michael Dehaan has written an excellent rebuttal. Don't trust Michael's logic? Linus Torvalds reminded me in an e-mail recently of the likelihood of getting contributions from users:

Most users are "free-loaders". There are relatively very few people who actually give back in source code _or_ in bug reports, so anybody who argues against free-loading in open source is a moron.

Or as Marc Fleury suggested to me recently, "when you think about it for two seconds, the notion that the best software engineers in the world would start working for you for free is a little naive."

This isn't to suggest that you shouldn't try to amass a massive external development community, but simply that you should temper your expectations to the phase and nature of your organization, as Fleury noted in our recent interview.

Very few open-source projects command significant external communities (and research indicates that even the big-name projects rely on a small core of committed (read: paid) developers to drive the project), largely because external developers can generally only afford to contribute to projects that align with their self-interest, which often translates to "those projects that pay the bills."

On average, the less money a project requires to keep the lights on, the more likely it will trend to the upper-right corner of the box above and, assuming the project is any good, the more likely it will be able to attract outside developers, paid (by their employers to write such contributions) and unpaid.

This may not be you. Such a strategy may absolutely be the right thing for Mozilla or Eclipse, but may be absolutely the wrong strategy for Microsoft, Red Hat, MindTouch, or you.

I personally believe that it's critical to keep the core open because this a) reduces lock-in, b) encourages add-on development (assuming the core is modular and well-documented), c) drives adoption, and d) leaves room for monetizing the periphery of a project. But your mileage may vary.

In sum, though I used to articulate One True Way to Do Open Source, I was wrong. It's a big tent. It makes no sense to try to stipulate, as I once did, this company is open source and that company is not. There is simply how different people and organizations use open source, with varying levels of effectiveness.

Your thoughts?

Follow me on Twitter @mjasay.

[JosefAssad]

I don't think you need to attract a horde of world class developers willing to work for free, and I don't think that the way things play out at RedHat is how they'll necessarily play out elsewhere. It's valuable experience but isn't quite the law of gravity. :)

Of course the way we follow principles is a big tent so long as we acknowledge the principles and the ways we adhere to and deviate from them.

I can't help but think that needing to strip the openness out of either the core or non-core extensions to improve business results might have something to do with the inherent revenue potential of open source just as well as it might with chosen business models.

And maybe it's structural. The IT market has been fed a diet of huge vendors for decades and expects scale; open source doesn't lend itself to generation of companies on that scale. Maybe that is the challenge; not the scale and associated business targets for the company delivering open source, but rather the actual structure of how software is perceived, bought.

[Matt Asay]

Very valid point: I've long thought the software business is a bit of an anomaly (make a mint by printing copies for free, selling them for much). But does the industry want to persist that way? Open source, SaaS, and other new models suggest that the industry is resetting to lower priced, subscription models. Time will tell.

[imacat_tw]

I believe the legend of your grid (The Open Source Continuum) is wrong. The y-axis should be "openness of complement", while the x-axis should be "openness of core".

[ITRebel]

Very cogent overview of current and future industry trends that does seem to capture the essence of what is going on. I found myself in agreement with most of it.

[PerryIsmangil]

As you have surmised above, a pure free software company will never "grow" into a company size, by metric of revenues, into the millions of dollars. There is just not enough value out of these digital bits, without creating an artificial scarcity by having secret code.

So my suggestion to would be open source software companies or even current ones considering freeing their software: don't do it, if you want to make millions of dollars.

[iquaid]

Apparently Matt misunderstood Michael Dehaan thoroughly, as Michael explains here:

http://michaeldehaan.net/2009/05/24/earth-to-matt/

I thought that was a mistake on Matt's part, too, since Michael is one of the most astute community-oriented programmers I know.

[mpdehaan]

Indeed, Matt is quoting me *quite* out of context. I think he skimmed it.

Matt, are you giving Bill Gates a guest column next?