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.

[jsoltero]

Great post, Matt. As you know from our numerous conversations in the past, this is the reason why Hyperic's business model is set up the way it is. Most companies have the benefit of being able to spend a lot of time "reaping" and worrying less about "sowing". (See my previous ran^H^H^Hcomments about downloads vs. dollars). For us, the task of driving both almost simultaneously has been one of our biggest challenges, and one which we've made many adjustments to throughout the years. In every case, the adjustment included giving more into the community based product as we continue to deliver value around the core.

The way we've done it is by developing a short, simple ethos for deciding which things are included as part of our subscription:

- Reliability
- Intelligence
- Scale

Now, it doesnt mean that our open source product isnt reliable, scalable, or intelligent. Far from it (check with the thousands of companies that use HQ Open Source in production). Instead, it means we know where to put the value that allows us to continue to build excellent, GPL-based software and live to tell the tale. These elements also incorporate some non-feature parts of our subscription. For example, our support offering helps with reliability and scale, and our ability to provide commercial indemnification means you can reliably count on a company to protect your use of the software.

I know this recipe doesnt work for every company. That said, I believe that if you indeed subscribe to the 'reap then sow' argument you're providing here. The best way to do it is to be transparent about how you make your choices.

Again, great post.
-javier

[Savio.Rodrigues]

Matt, you had me until:

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

Few companies behind a single-vendor controlled OSS project would risk losing control of their code. SpringSource is about the only example I can think of that went the APL route in recent history....and the book is not yet closed on that story.

BSD-style licenses really only make sense for projects with multiple vendors who each have a stake in the project's direction.

Also, it's good to see that your aversion to proprietary is beginning to wear off, if even a little ;-)

Don't worry, I'll convince you yet that proprietary is going to be the savior of the OSS business model. And when this happens, don't worry, I won't dig up all those posts about burning boats or how OSS vendors care about customers while proprietary vendors don't. We're all here to serve customers and make some $$$. :-)

Savio

[tristanbob]

Neat ideas, Matt. I think you are right that this model could be used successfully to build a community, and then sustain the community by making money and strengthening the core. All parties benefit, which is similar to the invisible hand of capitalism.

Am I getting the impression that you like the Apache licence more then GPL?