Open source is everywhere. The “bazaar” proved to be too hard to die and too good to be ignored. It is even used by or even injected inside some of the “cathedrals’” most valuable codes. But, still there is this mind barrier that divides geeks from IT managers. Still, after almost twenty years from its inception, IT managers are reluctant enough to fully go to open source, they prefer a cloud app, even if they openly advocate for its benefits.
What it’s so different between geeks left and IT managers right hemisphere? Is it really the fear of lack of support (a.k.a: the inability to blame someone when things go sideways)? No it’s not. Open source projects’ support is accurate and on time and free most of the times.
Is it the fear that the code is produced by unknown code hobbyists around the globe? No it’s not. After all you cannot claim that you know a single developer from proprietary projects, unless you own the project and the project is your first “hello world”! So what is it that prevents Enterprises globally adopt open source massively?
It is the same thing that made open source popular. It’s the constant evolution of functionality. Imagine for a moment that you’re an IT manager responsible for the enterprise’s smooth IT operation. Remember, this is a highly responsible job with your neck constantly on the line. Supposing that you found some open source projects that claim to cover most of your operational needs and you have the green light from the top management to evaluate and select in a given time frame.
And here comes the chaos! What to evaluate? You have the recent release, the last “stable” release, the last “community approved/stable” release, the promising new release with added functionality (the one missing functionality that you desperately want) around the corner etc. Don’t even dare to propose to evaluate everything! Do that for just three “heavy duty” projects and you’re done! And even if you manage to conclude that you only focused on the last stable release. What and how you evaluate that!?
Let’s change chapter here and we’ll come back later. I know that I may sound a bit harsh but I always thought that the majority of academics (excluding my PhD professor for obvious reasons) are like these lost artists that they do art only for their own satisfaction ignoring and neglecting audience’s preferences and aesthetics. For an IT manager is at least unacceptable to live in an era where the number of scientific papers trying to shed light into open source evaluation is only equivalent to developing countries’ population, and still lack the right decision making tools.
Having said that, in the end of the day you need to make a decision and unless you have time to spent in reading IEEE double-columned papers (personally I don’t) you have to make a leap of faith. You have to rely on other’s judgment. Huge amount of data is there for you to explore. Information, like number of downloads or number of reported/fixed bugs can be extracted through the statistics services offered by OSS repositories (i.e. Sourceforge) or more accurately through automatically extracting data from the project’s web pages and especially the source code control system, in the form of CVS.
Normally, and you don’t have to be a rocket scientist to understand this, the number of downloads is strongly positively correlated to a set of qualities like (functionality, usability, maintainability,productivity etc.) while number of bugs is strongly negatively correlated to qualities like (security, portability extendability, etc.)
And because at some point you’ll need assistance in persuading your top management that you know what you’re doing, now is the right time to explore these papers and find millions of super-duper studies that link bugs with everything and number of downloads with oson layer!
Got the picture? First, rely on numbers’ reality and then use academics’ sci-fi stuff for reasoning, if you need any! Good open source hunting.