The open-source add-on economy

Dana Blankenhorn suggests that add-ons make good business sense for Acquia and other open-source vendors, and he's dead-on. Zimbra climbed to $20 million in just two years on the back of a successful add-on strategy to its open-source Microsoft Exchange killer. SugarCRM is doing well with such a strategy, too.

It's not, however, simply a way to make money. It's also a way to better define and feed community.

Seem counterintuitive? Perhaps it is for those companies like Red Hat, Acquia, and others that are built to harvest preexisting open-source communities (Linux and Drupal, respectively). But for companies like Zimbra, MySQL, etc., an add-on strategy enables a vendor to focus wholly on delivering a quality open-source project while simultaneously creating a robust, scalable business.

SugarCRM's John Roberts has been saying this for years, and Marten Mickos of MySQL (now Sun) has been suggesting this strategy for the past year as MySQL looked for ways to strengthen its revenue while keeping its community strong. The two need not be conflicting strategies.

In fact, they're complementary. It's actually quite difficult to distribute a 100 percent open-source product and monetize it at the same time. Support doesn't scale. Determining how to make a "community" release compelling while also selling an "enterprise" release without selling "just support" is tricky.

It's actually much cleaner to tell the market, "Listen, 95 percent of the product is open source and we add commercial extensions or proprietary services for a segment of our community. Most of you won't need these. For those who do, here's how to pay for them." So long as the principle by which features are reserved for the enterprise release is clear and transparent, it enables the company to feed and foster its unpaid community base without reservation, which in turn creates a stronger community.

It's a tightrope, as Funambol's Fabrizio Capobianco will tell you. But it's perhaps an easier, cleaner one to walk than a completely open-source model, at least where the aspiration is to become a public company.

Don't get me wrong: I continue to believe that open source is the best way to build new businesses and new markets. It's just that I'm starting to feel that I've been wrong to suggest that all software must emphatically be 100 percent open source, all the time, in every situation. If adding a hint of proprietary software to a solution is done in such a way to encourage a purchase but not compel long-term lock-in, I'm no longer convinced that this is wrong. If it puts food on the table without putting anyone out, where is the harm?

All of which is my way of coming to grips with hybrid business models that I've long disdained. Savio is right: all models are hybrid at some level. Red Hat doesn't give away its binary distribution of RHEL. JBoss had the proprietary JBoss Operations Network. MySQL has never been a charity: it has deployed a dual-license model and charged for support and other services. And so on.

Does this mean that open-source businesses are really no different from proprietary software businesses? Yes and no. Yes, in that they involve some element of "proprietary" that gives the buyer a clear reason to purchase.

But no, in that the intent and scope of proprietary lock-in is dramatically reduced with open source, even in models that employ some proprietary "frosting" to their otherwise open-source components. Red Hat's "lock-in" is the continued value of its supported and the proprietary service it embeds into RHEL, JBoss, etc. through certification, bug fixes, etc. that make its binaries more valuable than simply downloading alternative versions of the software from the web.

With Red Hat, the company is always one click away from CentOS, and a few clicks away from SUSE. With MySQL, even with a proprietary Workbench there's no real lock-in to prevent a customer from jumping to Oracle. And so on.

Open source offers real differentiation. But it also, to make money and hence feed more open-source developers, also may build add-ons, as Dana suggests. This isn't a bad thing, I'm increasingly convinced. It's a way to make many more good things.