Why respondents rate "the features you need" as highly appealing seems quite obvious. In fact, the question seemed so obvious to us in planning the survey we considered not even asking it. Upon further reflection we decided to include it because we thought Open Source aficionados might find the need for features relatively less important as access to source can facilitate the addition of those features that might be missing. But this was not the case. Respondents clearly suggest that having the right features is the number 1 thing they demand in Open Source software.
What's the implication for vendors of Open Source software? You better be competitive on the feature front. This reflects our experience over the past five years. We've consistently moved up the food chain as we've proven our core features do the basics at least as well as the proprietary offerings. Corporate customers may cut you a little slack because you're Open Source, but not much. And the more mission critical the use the less they can afford to give you the benefit of the doubt.
Question 2: How attractive is the availability of quality commercial support? Mean Answer: 5.94.
The attractiveness of commercial support as demonstrated by respondents' answers to this question is also confirmed by our experience selling an Open Source CRM. You're not seriously considered for larger engagements if there's any doubt in your ability to be around for the long haul to support the code. Serious users do not consider support and maintenance a luxury. They're a necessity. In our case, we've written roughly 800,000 lines of code in the past 5 years. Moreover, our code functions intimately with several hundred thousand lines of 3rd party code. Few IT managers want to manage this complexity on their own. They have too many other dragons to slay.
Question 3: How attractive is the right to use the code for internal purposes however you want? Mean Answer: 5.47.
As a general rule respondents valued the unencumbered use of software for internal purposes quite high. However, the average (mean) doesn't tell the whole story. A number of respondents cared deeply about this right, others cared to a considerable degree, and many cared only moderately. Moreover, we couldn't find much of a rhyme or reason as to why they responded as they did given their comments. Except in one type of case. In those instances where respondents were involved in efforts to extend Centric CRM (our software) in some fundamental or important way, they invariably responded with a "6" or "7". Which makes sense. Control is paramount in these instances.
Question 4: How attractive is the right to define the terms of the license for the improvements you might make Mean Answer: 5.28.
Many of the respondents in our survey were from organizations not in the business of selling IT products and services. Considering this, the relative attractiveness of control in how improvements are licensed surprised us. It seems somewhat counter-intuitive to value a right so much if your core business makes the need for it mostly moot. After a bit of chin pulling on this we concluded that perhaps there's a simple and very American dynamic (given all of the respondents were US citizens) at play here.
A cultural bias in the US is "I can do with my property what I want". The software version of this goes something like "If I create some really cool code it's my right to determine how it's to be licensed." As a rule this is a pretty sound position. And we believe this sentiment is reflected in the responses to this question. But we'd ask: How does this sentiment jibe with the GPL? The answer is it doesn't. If you want the right to license what you've built and in your own unique way - as "free as in speech" - don't extend it from GPL code. Other OSI licenses like BSD and LGPL can work fine, but not the GPL. As the preamble to the GPL says, "to protect your rights we need to make restrictions". One of those is that modifications must themselves be GPL'd. We point this out not to bad mouth the GPL. In fact, we believe it's a revolutionary (and needed) tool and ideal for certain situations and classes of software. Rather, we point this out because many blindly, and with little regard to what customers and/or partners want, try to make it fit all situations. It doesn't and it can't. We find it great at the lower levels of the stack. We find it counter-productive in many other domains.
- "Survey, Page 1/3"
- "Survey, Page 2/3"
- "Survey, Page 3/3"
