« European Open Source VC economy? | Main | Steve Jobs on death »
June 14, 2005
What does your customer think of "productized" Open Source?
Whenever I read the term "productized Open Source" - I cringe. I realize what companies like SpikeSource are trying to express by using the term, but my experience has been that customers often expect the Open Source project to be a product without you even actually saying so.
What do I mean by that. Well, plenty of times we've been on-site with a customer and implementing a solution based on an Open Source project. The customer has requirements that sometimes don't match what the Open Source project can currently do. And more often than not we've been addressed as if we were the "product vendor" and asked why on earth the Open Source solution can't do XYZ and when do we think we'll (!) fix it.
Of course it is our business model to offer services around Open Source projects and one of those services is bridging the gap into the Open Source community and helping the customer get a bug fixed or patch applied. But only the community itself is capable of say adding additional functionality - to the project. We, as the company providing the serivices can't just magically roll out a new version for the customer containing the feature she happens to need.
The customer has to understand that Open Source solutions are not products in the same sense as say a boxed-solution from a traditional vendor is. Once they start using the Open Source solution they themselves become part of the community and in a sense are actually to some extent their own vendor.
So my feeling is that suggesting you offer "productized" Open Source may really conjur up the wrong impression - unless of course you actually can influence the project roadmap to that extent - as say companies like JBoss or MySQL can.
Posted by Matthew at June 14, 2005 06:34 PM
Comments
I guess you do what other product companies do when the customer wants specialized features.
you maintain a fork/patchset on the opensource project for your customers with the features that the rest of the community don't want. and it becomes your product that you sell and maintain and offer help with (and maintain for them) and you get paid to do it.
Telling your customer that your 'helping' them put the patch through is a crock.. your company is offering solutions to them, not acting as a liason between them and the open source world. It is in your interest that the patch goes mainstream more than theirs
Posted by: Ian Holsman at June 15, 2005 12:34 AM
you know, its an interesting issue for all the supported-OSS vendors. Redhat, IBM and the other linux distoes have all got the effective right to put changes into the core of linux, but that doesn't apply to other things up the food chain. Out in the java projects, I would view a patch submit from anyone like that just like any other: apply it if is good, ignore it if it is bad.
I think if you are going to be a supported-OSS stack vendor, you are going to need all your fingers in the whole of the stack, otherwise your customers are going to be let down at some point. This can be done by forking your own version of the code (the way jboss did with Axis), but once that happens, the original project refuses to support the fork. Once you fork, only the forked user base is the support community for that fork.
Posted by: Steve Loughran at June 15, 2005 12:09 PM