Kevin Burton’s New Feedblog wants help finding good open source software for IT monitoring. Although Mr. Burton needs an IT monitoring solution, almost anybody making a software choice faces the same challenge.
Not so long ago, when a business decided to solve a problem with software, the calculus was simpler: make or buy. Software products came from software vendors, who competed with each other, and with internal development teams to get business.
It’s different now. Pick a problem that can be solved by software, and you’ll find multiple open source offerings. Certainly, the lean and the mean look to the open source world first. But corporate behemoths are down with it too: acceptance of OSS by the man is old news. And when even the UK government buys in, open source is mainstream.
The “you get what you pay for” adage doesn’t necessarily apply to open source. Many software companies, including Hyperic, provide robust and rich open source versions, in addition to enterprise editions that customers pay for. We do pack extra, high-value features into our enterprise version, but we have plenty of users that manage smaller infrastructures quite successfully with the OSS version.
But, back to Mr. Burton’s plea for help. He asks what open source monitoring solution he should use instead of Nagios. Clearly, he should consider Hyperic HQ. But, perhaps the broader issue is, how do you choose the right open source product, whether you’re looking for IT monitoring or an application to identify weed species in crop systems in the Indo-Gangetic Plains”? (Not a made up example.)
Cursory research (using a proprietary search engine) indicates there’s a lot more chat about why to choose open source software than how to choose it. One of the few on how to shop around is this ZDNet article; it focuses on how to choose a CMS, but the recommendations apply to any software choice. The author suggests checking out freely available information for clues about the software publisher’s process, quality, and community.
Here are eight additional ideas to include in your software evaluation checklist:
- Do you have to build the product to be able to use it? I’d rather this were an option than a requirement, and (personal opinion) the fact that I have to build it myself seems to indicate that ease of implementation and use is not a high priority to the publisher.
- Is information about the product as free and available as the software itself? Is there documentation? Or is the information you need on page 200 of 10,000 pages returned by your search query? If there is documentation, is it current? It should correspond to the current version of the software. Is it documentation free? If it’s not, how do you like paying for information that is required to make the product work?
- Can you find a statement that unambiguously describes the product’s functionality? It’s funny how long it can take to figure out that the behavior or feature you’re trying to use isn’t actually supported.
- Is there a clear definition of what the product is “best” for? Can you figure out what type of environment it was designed for, what its limits are, in terms of scalability, security, or other criteria?
- Can you locate information about the implementation process, like how much configuration is required, and what’s involved? For instance, to configure a behavior, do you use a web UI, edit a property file, or modify the source code?
- How big, active, and satisfied is the community. User forums tell you a lot. Do questions get answered? Do many responses suggest “reading the code”? (Danger Will Robinson.) Are there actual contributions – new features, plugins, extensions, etc. – from community members?
- Will you get the support that you need? Obviously, this depends on your appetite for self-support and the impact of unsolved problems on your mission. If you don’t have a high tolerance for unsolved bugs or unanswered questions, is there somewhere to go for support, even if you have to pay for it?
- Is there a growth path? Assuming the software has some hard limits, in terms of scalability, security, or functionality, what will you do when you hit them? Is there a fuller-function offering you can migrate to easily?;-)
Bottom line, Mr. Burton should have no trouble finding a good OSS monitoring solution. Perhaps he’ll use take this advice and make the right choice. :-)