Matt Aslett continued his series on Open Core yesterday, and pointed to my post on the subject. He says, and I agree, that we can’t expect companies to call themselves Open Core as a means of differentiating from Open Source if we use pejorative phrases like “crippleware” to refer to Open Core projects.
But that ship has long since sailed. No company has every described themselves as “an Open Core company” to anyone except VCs, as shorthand for their business model. In the software business, Open Core has no-one defending it, and it has no brand value. In fact, in free software circles, Open Core has been a pejorative phrase almost since it was coined – fauxpen source, popularised by Tarus Balog, cites Open Core as a synonym, and pretty much every mention of it which I have found has not been by a vendor referring to themselves, but by an analyst or commentator referring to a class of business models.
In one sense, that’s what is amusing about this – the valuable brand, Open Source, is the one everyone uses, and vendors who sell Open Core products find themselves in the unenviable position of having to defend calling themselves “an Open Source company” to what they doubtless consider zealots, but there is no other brand they can use which gives the same marketing benefits while providing sufficient differentiation with Open Source.
I don’t consider the OSI or other people decrying this use of the Open Source brand as zealots, they are simply protecting their brand against dilution.
Matt argues that Open Core products don’t deliberately cripple their free software offering (at least, the good ones don’t), they merely “sell value-added features that are designed to be of value to paying customers”. I would argue that is simply a restatement. Regardless, I accept that there are some features which a proportion of the user base will be prepared to pay for, and which most of the rest of the user base won’t care about. If you can ensure that the proportion of your user base which cares about the feature but is not prepared to pay for it is small, then you have the potential for license revenues without damaging your reputation too much.
As you increase the number of features which users need to pay for, however, you will find that the number of people who care about at least one commercial feature who are not prepared to pay for it will become significant. You only have to look at the SugarForge (a nice initiative in community enablement, by the way) to see that the lack of reporting and sales forecasting in SugarCRM’s community edition is something which a lot of people are interested in – the most active & popular community projects are related to those features. Does the decision to omit those features from the core product represent hobbling? Does the presence of modules that implement those features in the Forge show the victory of the Open Source way? Both, perhaps?
SugarCRM is far from the worst Open Core vendor in this space, so I don’t want it to come across as though I’m picking on them. OpenBravo also does a good job of enabling its community to fend for itself. Others don’t fare so well, and in private will admit that their community edition is “not suitable for production environments”. While this may just be a sales tactic to get people to pay for support, the message that this sends to potential customers is “Open Source might be OK to test out & play around with, but when you want to get serious you’d better pony up or you might have trouble”. Not exactly inspiring confidence in the Open Source way there…