tag:blogger.com,1999:blog-5985995329553099015.post321786317824289319..comments2007-07-01T05:34:39.108-04:00Comments on Opening The Social Web For Business: Open Source Business Models: Definition of "Suppor...Shaun Connollyhttp://www.blogger.com/profile/05536033402074599031noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-5985995329553099015.post-68461863108636911382007-07-01T05:34:00.000-04:002007-07-01T05:34:00.000-04:00It's only peripheral to the discussion, but perhap...It's only peripheral to the discussion, but perhaps a better term for "technical support" or "pure support" is <I>usage support</I>.<BR/><BR/>It's essentially support that doesn't make changes to the product.RdRhttp://www.blogger.com/profile/00554446763223614458noreply@blogger.comtag:blogger.com,1999:blog-5985995329553099015.post-30821771400378665662007-06-23T09:04:00.000-04:002007-06-23T09:04:00.000-04:00It is possible to make brands that sell, logos tha...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 ;-). <BR/><BR/>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 ;-))? <BR/><BR/>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? <BR/><BR/>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). <BR/><BR/>My two cents.<BR/><BR/>/Przemekeracehttp://www.blogger.com/profile/11255782866493475403noreply@blogger.comtag:blogger.com,1999:blog-5985995329553099015.post-70998644470511216542007-06-22T12:07:00.000-04:002007-06-22T12:07:00.000-04:00Stormy, the use of the word "own" is one of the tr...Stormy, the use of the word "own" is one of the traditional comebacks re: the Professional Open Source model.<BR/><BR/>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.<BR/><BR/>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. <BR/><BR/>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. <BR/><BR/>This is why we, at JBoss, have taken the approach of hiring the key committers for the important emerging/innovative projects. <BR/><BR/>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.Shaun Connollyhttp://www.blogger.com/profile/05780468461984002256noreply@blogger.comtag:blogger.com,1999:blog-5985995329553099015.post-75306427684557582552007-06-22T11:11:00.000-04:002007-06-22T11:11:00.000-04:00Actually, it's not about create and support vs pur...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.<BR/><BR/>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. <BR/><BR/>Stormy<BR/><BR/>(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.)stormyhttp://www.blogger.com/profile/06839380843084474991noreply@blogger.comtag:blogger.com,1999:blog-5985995329553099015.post-23798065844425310502007-06-22T04:36:00.000-04:002007-06-22T04:36:00.000-04:00Stormy has a vested interest in pure support, but ...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.<BR/><BR/>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.-http://www.blogger.com/profile/07579837791109488979noreply@blogger.com