A time to reap, a time to sow: A phased approach for open-source businesses

During my morning reading, I happened upon this verse from Ecclesiastes:

To every thing there is a season, and a time to every purpose under the heaven...a time to plant, and a time to pluck up that which is planted.

It made me think of the ongoing debate around open-source business models (illustrated well in a recent post by Savio and perhaps more so in the comments section to that post), kicked up by MySQL's recent decision to offer closed extensions to its core (100 percent open source) database, but one that has been simmering for a long time. MySQL is essentially saying, "We've spent a decade planting. We'd like to reap a little of what we've sown now."

MySQL is doing this right. It has focused on adoption first, and has committed to keeping the source of that adoption open source. But in its next phase, perhaps it demonstrates an ideal open source-based business model. Or rather, a phased approach to growing an open-source business...?

The model looks hybrid in the end, but it takes a long time getting there:

1. Open source your product. Make it exceptional code, and 100 percent open. Focus on building a development community, but assume that really what you can expect is a vibrant user community (since very few projects attract outside, unpaid development);


2. Sell support and other services around this free software. No real attempt should be made to monetize the software directly (at this phase);


3. Offer a commercial version of the open-source software (Optional). By this I don't mean one that is proprietary or has closed extensions, but rather a stable binary of the free-flowing project. Think RHEL or Alfresco Enterprise. The difference in the code is largely one of certification and testing.


4. Add closed extensions to the core, still 100 percent open source project. Customers get full access to the source code to view and modify it. The user community loses nothing, but the company adds a compelling reason to pay it money for those shops that otherwise won't or can't. This is best achieved through a modular architecture that enables outside plug-ins without decrementing the value of the core.

It's a phased approach, one that makes a lot of sense to me but which I doubt many of us have really thought about. It has simply happened naturally as we've sought to find ways to write more open-source software while still getting paid (and yes, I'm talking about "paid" in the sense that makes venture backers happy).

I'm not suggesting that this is The One True Way to make money with open source. But I am suggesting that it seems to make sense as a project trajectory. Done right, it preserves the value of the community while also preserving the value of the company.

In fact, it could actually augment value for the community, and not because of the stock open-source company suggestion that proprietary extensions pay for greater development in the core open-source project. This is true, but I think there's a better reason to tolerate proprietary extensions:

It may well enable the company to offer its core open-source project under the most liberal of licensing terms.

Look at the commercial open-source projects out there, and you'll notice a range of efforts to embrace open source without embracing one's competitors: Badgeware and the GPL are the top-two defense mechanisms open-source companies deploy.

With the ability to monetize the periphery of a project, it might well leave companies free to provide their core product under Apache-style licensing to truly maximize adoption. This would, of course, mean that competitors could also leverage the core, but who cares, so long as one can still make enough money to grow and fund continued development?

I invite comments as I've only briefly thought this through. I might be missing something. I've never been a fan of proprietary software and remain distrustful of it now. I just wonder if it can be inoculated to allow open-source companies to write more open source, and under more permissive licensing terms, while keeping customers free from lock-in and in control of their IT destiny.

It may also be the only way that single-vendor communities can truly break out of being a single-vendor community into creating community property.