Brian Prentice

For those of you not familiar with commercial open source software – which I will now refer to as COSS (hey, I’m an analyst, it’s my job to create acronyms) – it is essentially a business model loosely tied to the concept of “freemium.” On one hand a vendor provides a free, open source offering (and by that I mean that it’s covered under a license agreement recognized by OSI) which is usually supported by the community. On the other hand there is a “value-add” solution which is not free, is directly supported by the software vendor and is a proprietary-licensed offering.

First things first. COSS doesn’t mean you get some hybrid software that’s half open source and half proprietary (a dessert topping and a floor wax). You pick – you’re either using the open source version or the proprietary version. And if you’re picking the latter than you might as well remove the words “open source” from the term commercial open source software. You’re basically just acquiring good old fashion software in the good old fashion way.

So, from the users’ perspective nothing really changes. The innovation in commercial open source software is largely on the vendor side of the equation. COSS is a way for a software vendor to leverage the positive aspects of open source – particularly community development – as a way to build a business and defray some of the engineering and sales & marketing costs. Not that there’s anything wrong with that!

But, as a user, if you decide to go down the free open source route – especially as a long term decision – you need to be crystal clear on how the vendor is “value adding” their proprietary version. If you don’t, you could be in for a surprise.

The most common way of value adding commercial open source is via the product. In this approach, the vendor not only separates the open source and proprietary versions of the product by providing direct support but also by adding more features to the proprietary version. The proprietary version is therefore a functional superset of the open source solution (this is a topic I’ve explored in more detail in “Commercial Open Source Software: Is All That Glitters Usually Sold” – Gartner subscription required)

Product differentiated COSS has a specific weakness. If the vendor is the primary, or sole, committing organization (in other words there’s not much of a community outside the vendor) then unless you’re either happy with the product as is, or plan on doing all the needed product modifications yourselves, then you are highly dependent on the vendor for product improvements.

The problem comes from the fact that over time the vendor has a financial incentive to see a growing functional gulf emerge between the open source and proprietary versions. After all, they make their money only when you move to the proprietary version. If those couple of extra features you need require an “upgrade”…well so much the better. And that incentive is fuelled when the vendor has a group of venture capitalists hounding them for revenue.

This problem is simply solved. COSS vendors should create a fully transparent charter of development that describes the criteria they will use in determining whether new capabilities go into the open source project or when they’re allocated to the proprietary version. Additionally, it should describe the conditions under which features in the proprietary version will migrate their way into the open source project. That charter of development should be open for audit. With such a charter there may still be a yawning gap between the two versions of the software but at least you’ll know exactly what you’re getting into.

Unfortunately, development charters like this are rare – really rare. Most COSS vendors I have spoken to assure me that they have criteria and they’re committed to assuring a good open source version is available. But there’s no documentation nor full transparency so it basically boils down to “trust me.”

If you’re a trusting type of person, working for a trusting type of organization then no problemo!

By the way, not all COSS is product differentiated. Some COSS providers differentiate themselves based on their service levels (things like indemnification, certifying stacks, consolidating release intervals, etc.) – what I like to call “Community Gap Coverage.” That approach I consider to be much cleaner than differentiating by product.