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:

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.