Interesting thread on InfoQ regarding open source business models:
http://www.infoq.com/news/2007/06/open-source-models
Rod Johnson and Stormy Peters are engaging in the debate of which model is better: "Create & Support" vs. "Pure Support". This topic has gone round and round in the past, and I think the heart of the debate lies in the definition of "Support".
The "Pure Support" model should actually be called "Technical Assistance" since it focuses on helping people get over technical issues, find workarounds, etc.
Technical assistance is important, but what happens when the issue requires a bug fix...or a refactoring of some of the code? Then what?
The code can be changed...but who manages that change? And if that code is part of a complicated stack of open source technologies...who is managing all the patches and branches of all those changes?
Also...who ensures that change is committed upstream so that future releases of the technology benefit from the change? If the changes are not committed upstream...then who will maintain that fork for the X-years lifecycle that enterprise customers demand?
Let's be real. While enterprise customers need technical assistance, they also need patches and updates to the versions of the software they have deployed today...and they want the peace of mind that comes with knowing that their fix today will still be there in future versions if/when they upgrade.
So, this explains why we at JBoss hire the key technical leaders from the projects that comprise our middleware portfolio. THIS is Professional Open Source.
Professional Open Source is not just Technical Assistance.
Thursday, June 21, 2007
Subscribe to:
Post Comments (Atom)
5 comments:
Stormy has a vested interest in pure support, but they have been trying to recruit members of popular projects on a pay-per-incident basis. Unfortunately, NDA and tax-complexities make that less appealing than youd think.
At the same time, buying control of an OSS project doesnt scale to all the many projects out there -you need to identify which ones are critical, and which ones you can keep at arms length. Even there, its good to be on drinking terms with the developers, as if you need a point release of some tool to match your timescale, or some patch taken up, a good relationship helps. Its why a redhat, eclipse or apache email address often generates a better response than some corporate email account that the OSS world has no respect for.
Actually, it's not about create and support vs pure support. It's about what type of relationship you need to have with the community in order to use and support an open source product.
One argument is that you have to "own" an open source software project before you can do anything useful with it. You have to "own" it, i.e. have all the developers on payroll, before you can support it or ensure that bugs get fixed. I think that the open source model gives you a lot more freedom than that! I don't have to have any of the Apache httpd committers on payroll in order to submit a bug fix to the httpd project! If I submit a good bug fix, I'm sure they'll take it. Better yet, I know if I submit a bug, they'll fix it - it's a good project with a good team working on it. What OpenLogic has done is realize that we don't have to hire all the committers in the world. We can work with them to ensure that our customers get the support they need. In cases where the community helps us, we pay them. On a contract basis instead of on our payroll. We compensate them for their work. It fits into the open source model. Saying that you can't use and support an open source product unless you have the committers on your payroll is extremely insulting to the open source community and the great, high quality projects they've created. It's also a step back to proprietary models.
Stormy
(FYI, OpenLogic does more than support. My marketing folks would like you all to know that we have a software product with a knowledge base that helps companies discover, install, track, and govern open source and open source policies. Among other things - check out our website for more info - http://openlogic.com.)
Stormy, the use of the word "own" is one of the traditional comebacks re: the Professional Open Source model.
Red Hat does not "own" Linux for example...it has full time employees who work in the Linux community. We work with the community on making sure we provide all the elements of "support" our customers demand.
Everybody uses Apache HTTPD as their example of how the community is responsive to fixes. It is a poster child example because it is mature and established for many years.
The reality is that there are 1000's of other projects out there that are still proving themselves; and it is less certain if they will last over the long term.
This is why we, at JBoss, have taken the approach of hiring the key committers for the important emerging/innovative projects.
To Said's point, we do not hire all of the committers either. But we do hire enough to ensure future vibrancy of our key projects, rather than leaving it to chance.
It is possible to make brands that sell, logos that are visible, create a value that shareholders are going to be happy with. What happens when you put logo on open source? You get open source with logo ;-).
The real open source applications are the product of the selfregulatory ecosystem. It is the ecology that makes thigs roll. What happens when you try to introduce some improvements to the things that are selfregulatory? (consider rabbits in Australia ;-))?
The fact is that in the end it all comes down to skilled people that know how to do things, how to provide the end users/businesses with the functionality they need. Now, is it better to have 1 person that knows everything about the given OSS project and since it might have to provide support as well, is spending majority of its time answering questions and fixing bugs, or to have a couple people (not necessarly full time employees) that know the project through the experience and are able to get out of it what they need and in addition to share their knowledge with someone that is ready to pay for it?
The discussion has orignated when talking about Spring project. It's popularity does not come from the fact that Interface21 had a great support. It comes from the fact that it was a good framework, that developers were simply allowed to download and use (vs required to pay for), that it has been distributed via Internet (at zero cost of course).
My two cents.
/Przemek
It's only peripheral to the discussion, but perhaps a better term for "technical support" or "pure support" is usage support.
It's essentially support that doesn't make changes to the product.
Post a Comment