Open source network management buzz comparison 2009

I did a comparison of the buzz for the leading open source network management tools in 2008 so I thought it would be interesting to do the same comparison for 2009 and see what’s changed.

As I did last year, I’ve compared the number of searches for the project name using Google Trends. As always, this post is not intended to be indicative of the usefulness of a particular tool to your requirements.

Open Source Network Management System Trends

Firstly a comparison of the major players in open source network management: Zenoss, Hyperic, Nagios, MRTG and OpenNMS. The most striking thing about the graph to me is the decline in searches for Nagios. From the middle of 2009 things have been declining quite steeply. MRTG has been declining though it just looks like a continuation of the decline evident for the last few years.

Open Source Network Management System Trend 2009

A Comparison of the Nagios Ecosystem

Whilst the above graph showed a reduction in the relative number of searches for Nagios, perhaps the Nagios ecosystem graph can explain it. Icinga, a Nagios fork, was created during 2009 and may be responsible for at least some of the decline. Icinga appears on the graph during late April and has a steady presence throughout the rest of 2009 save for a small period during the Christmas break.

A Comparison of the Nagios Ecosystem 2009

Open vs Closed Network Management Systems

Given that 2009 was a year of recession in many countries, perhaps it won’t surprise too many to see so many of  both the commercial open source and proprietary tools trending downwards. I suspect that 2009 was a tough year for winkling money out of IT budgets.

Open vs Closed Network Management Systems 2009


All in all an interesting year. Apart from the Icinga/Nagios episode it seems odd that none of the tools has made  significant progress during 2009. If open source tools were to make a move against their proprietary cousins you would assume it would be 2009 given the economic background. Budgets have been tight, so why haven’t open source tools made progress in these recessionary times?

Planet Network Management Highlights – Week 39

Highlights from Planet Network Management + Planet Sys Admin for Week 39 2009.

Open source network management activity comparison

The recent controversy over the ICINGA Nagios fork brought into focus the relative activity of the various network management projects.

One of the main complaints aimed at Nagios was the slow speed of development. The following graphs, taken from the open source directory ohloh, show the number of commiters and the number of commits over the last three years for Nagios, OpenNMS and Wireshark. I can’t vouch for how accurate the stats are but I think they do provide some insight into the development processes of the respective projects.

I’ve used OpenNMS, Wireshark and Nagios as the basis for the comparison because all three are mature, successful open source network management projects of similar age. Wireshark and OpenNMS dwarf Nagios both in the number of contributors and the number of commits. Commits themselves can be misleading, a commit into the source repository doesn’t indicate what the commit contained, whether it was a simple bug fix to a single file  or a very large new feature requiring hundreds of changes. There is no reason to think that Nagios commits are inherently larger than Wireshark or OpenNMS commits.

Looking at the graphs, perhaps there was a problem with the structure of the Nagios project.

Nagios responds to the ICINGA fork

Matt Asay over at The Open Road commented recently that forks are a sign of strength in open source. I’m sure he’s right, but they are not necessarily a sign of strength for the project being forked. The one positive thing is that it makes the community sit up and review the root cause of the fork.

As Andreas Ericsson says in his post The future of Nagios, recent events have demonstrated weaknesses in the structure of the Nagios project, specifically that Ethan Galstad is the only commiter of fixes and enhancements to Nagios. A single commiter is fine until the commiter doesn’t have sufficient time to work on the project as might be required to keep up with community submitted fixes and enhancements. Understandably, individual contributors are going to get frustrated that their patches and enhancements are not being incorporated into the project.

If nothing more comes of the ICINGA fork than a review of the Nagios structure, then the fork will have been worthwhile.

Nagios begets ICINGA

Nagios is probably the best known open source network management tool. Ethan Galstad created NetSaint, the tool that eventually became Nagios, many years ago at the very dawn of using open source tools in network management.

Things are not going well. A number of people from the Nagios community, including a couple from the Nagios Community Advisory Board have decided to create a fork of Nagios under the ICINGA project. The reason? The founders of the ICINGA project charge Nagios with stifling the development of the project.

It will be interesting to see how much traction ICINGA attains. Forks often fail to gain the necessary momentum to be successful.

Centreon – Nagios remixed

One of the problems with Nagios is that initial set up & configuration can be intimidating to the new user. There are a number of methods for easing the initial installation problems, but you are still left with an intimidating configuration process.

One option is to use Centreon, a (relatively) new front end for Nagios with a more accessible web front end for configuration. Centreon is fully open source and is supported by Merethis, a French company, who also sponsor development of the project.

Centreon is similar in concept to Groundwork Open Source though far narrower in scope.

A perspective on open source network monitoring tools…

…by Grig Gheorghiu over on the Agile Testing blog: The sad state of open source monitoring tools.

“I wish there was a standard nomenclature for this stuff, as well as a standard way for these tools to inter-operate. As it is, you have to learn each tool and train your brain to ignore all the weirdness that it encounters.”

One of the problems with I.T. is the absence of a standard terminology. It would make things a lot easier if everybody used a standard set of terminology. Kinda hard to see how this can be imposed though. I guess over time a standard terminology will just evolve after the industry has matured a little more.