Sometimes the open core functionality ceiling gets lower

First of all a little bit of background will make the post a little bit more understandable to non I.T. folks.

A bit of background

Zenoss is a network management software vendor with an open source core product, called Zenoss Core, and a closed source product called Zenoss Enterprise.

Zenoss is written in the Python programming language and uses the Zope web application framework.

Relstorage is a Zope add-on for saving data to a relational database. Relstorage allows Zenoss to use a relational database as its storage backend, with all of the scaling out benefits that entails.

A relational database does not need to run on the same server as Zope, you can run it on a completely different server. In fact, you can run the relational database on a cluster of machines giving substantial scalability benefits. With Zope’s native database format, running it on a different machine isn’t possible.

Zope’s native database format limits how scalable Zope can be, which in turn limits how scalable Zenoss can be.

A bit more background

Way back in 2010 myself and others suggested that an open core strategy would lead to some difficult decisions about which features go into the open source product and the closed enterprise product.

I suggested that a feature ceiling could be reached in the open source product and offered some modest proof that it existed.

The ceiling fell in… a bit

Phew, now we’ve got the introductions over, what the heck has all of the above got to do with open core software and lowering the functionality ceiling?

The following is part of a conversation on the dev IRC channel run by Zenoss.


“… A decision was made some time ago to move from standard zopedb to relstorage to improve performance.  Recently, a decision was made to remove the relstorage code from Zenoss Core.”

Bill Karpovitch Co-founder and CEO of Zenoss Inc.

“a mistake we made in the process was that product management had it slated for an enterprise feature but we began development in the core trunk.  for better or worse, our decision was to pull it back. we are continuing to look this as part of the plan forward.”

“all good points.  to be clear, the Core/Enterprise feature decisions are challenging and involve tough trade offs.”

As Bill Karpovitch says above, the relstorage feature wasn’t intended to go into Core, it was supposed to be an Enterprise only feature.

Unfortunately, it kind of snuck into Core accidentally and was removed. This upset the Zenoss community quite a lot as they believed that it would effectively create a fork between the Core and Enterprise products. A fork would make creating add-ons more difficult because potentially Core and Enterprise would need to be tested seperately. Supporting both would also be more difficult due to the core of the Enterprise product being different from Zenoss Core.

The relstorage feature was released in Zenoss Enterprise version 4.1.


BTW this post is in no way an attack on Zenoss, or their very fine business. Kudos to them for having this kind of discussion in public. The above is just a concrete example of the friction that is inevitable when you have an open source product and a closed source product.

The friction isn’t confined to open core companies either, closed source companies have exactly the same friction when they have tiered products too.

There is a happy ending, relstorage was eventually added to Zenoss Core version 4.2.

Musings upon the open core functionality ceiling

One of the things you’d expect from an active open source project is that the code base is likely to grow as more and more features are added.

In An exploration of open core licensing in network management I mentioned that one possible side effect of open core software is the creation of a functionality ceiling.

A functionality ceiling is a level of functionality beyond which the community edition product manager is unwilling to implement because of the fear that the enterprise product will be less attractive to potential customers.

That got me thinking, if a functionality ceiling does exist, how can I demonstrate it?

The graphs below are taken from the Ohloh open source project directory. The rather useful thing about Ohloh is, in addition to cataloguing open source projects, it also performs  extensive code analysis.

The two graphs below are taken from the Hyperic code analysis and the Zenoss code analysis pages on Ohloh.

Hyperic Code Analysis Graph
Hyperic Code Analysis Graph
Zenoss Code Analysis Graph
Zenoss Code Analysis Graph

Both of the graphs clearly show a plateau in the quantity of code committed to the respective community edition code repositories. There may be a number of explanations for the plateau, perhaps heavy re-factoring work clears the space required by new features. Though, realistically I doubt that re-factoring would be capable of continually reducing the size of the code base in order to make way for new code.

The plateau look suspiciously like evidence that open core software, at least in the network management world, tends towards a functional ceiling.

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?

A real world example of the problems with open core software

A real world example of what Tarus Balog from OpenNMS has been banging on about recently with his critique of open core or fauxpen source.

A product manager who has an open product and a closed product plainly has a decision to make over which features go into which product. Give too much away and the value add of the closed enterprise product is insufficient to warrant the licence fees. Put too many features into the enterprise product and the open source offering becomes useless.

Have Hyperic‘s & Zenoss‘s feature selections leaned too far towards their closed enterprise versions? Alemic Boiling would seem to think so…

Tivoli vs open source network management buzz 2008

As suggested by Jane Curry in her comment on the Open source network management buzz comparison 2008 post I’ve compared Tivoli related keywords and selected open source projects. Tivoli covers a lot of ground so comparing it on its own doesn’t really tell you very much.

Tivoli vs Open Source Network Management Systems
Tivoli vs Open Source Network Management Systems

Both Tivoli Monitoring and NetView have been pretty consistent throughout 2008 unlike OpenView which fell substantially. It is odd that Tivoli Monitoring fell off a cliff in December. Presumably, that is just a really heavy seasonal decline rather than anything more fundamental. Maybe Tivoli people get very generous Christmas breaks. 😉

Open source network management buzz comparison 2008

As it’s the start of a new year I thought it would be an ideal time to look back over the year just gone. I have used Google Trends to compare the number of searches during 2008 of various open source and proprietary network management tools.

Whilst search volume is an interesting metric for network management tools, it is not intended to be in any way indicative of the usefulness of a particular tool. If you want to choose a tool, start from your own requirements first and select a tool from that.

Open Source Network Management System Trends

First up is a comparison of the major open source network management systems. Nagios, as one of the oldest open source projects in network management,  still has a huge community of users and, in spite of a number of very good competitors, appears to be holding its own.

MRTG during 2008 does show signs of continued decline. Hardly surprising given that a number of very capable competitors exist that are much easier to install and configure.

Zenoss, Hyperic and OpenNMS are all doing well, retaining substantial levels of searches with Zenoss retaining its early lead.

Open Source Network Management System Trend 2008
Open Source Network Management System Trend 2008

A Comparison of the Nagios Ecosystem

Nagios is a significant open source project in and of itself. In addition, it also has an ecosystem of tools built on top of it as well. There are three main nagios core tools: GroundWork Open Source, Centreon and OpsView.

I haven’t been able to use Groundwork Open Source because a comparison wouldn’t be valid given how many words it is made up of. Many people may well type in Groundwork instead of Groundwork Open Source even though you will get a lot of civil engineering related results.

Configuration is one area Nagios is not very user friendly to new users, relying upon editing configuration files for changes. Both Centreon and OpsView provide an improved configuration experience, reducing or completely removing the need to directly edit configuration files. Surprisingly both Centreon and OpsView receive substantially fewer searches than Nagios.

A Comparison of the Nagios Ecosystem 2008
A Comparison of the Nagios Ecosystem 2008

Open vs Closed Network Management Systems

A comparison between a representative sample of both open source and proprietary tools shows an interesting trend.

Both NetIQ and OpenView are losing searches whilst the open tools are holding up well. Perhaps, money was tighter in 2008 due to the economic woes befalling many economies. OpenView has been particularly badly hit, being well down over the year as a whole.

Open vs Closed Network Management Systems 2008
Open vs Closed Network Management Systems 2008


The open source network management tools search volume has held up very well throughout 2008. The same cannot be said for either proprietary tools, OpenView and NetIQ. Both of the proprietary tools have seen their search volume fall. A recession started during 2008 in many countries worldwide. So, that people are searching less for expensive software tools, maybe isn’t that surprising. I doubt the Google Trends data could evidence a shift from proprietary to open source tools though, given the absence of an upshift in searches for open source tools.

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.

Open source network management comparison: Support

Attribute / Project OpenNMS Nagios Zenoss Hyperic Zabbix
Peer Support
Forum X X X X X
Mailing list X X X
Commercial Support
Support contract X X X X X
Training X X X X X
Consulting X X X X X
Learning resources
Blog X X X
Book(s) X X

Update 1: Zenoss has a forum / mailing list system. Both interoperate together so a post to one goes automatically into the other

Open source network management comparison: General

Attribute / Project OpenNMS Nagios Zenoss Hyperic Zabbix
First released 2000 1998 2006 2006 2001
Development languages Java C Python / Zope Java / C C / PHP
External dependencies RRDTool / JRobin Net-SNMP / RRDTool RRDTool SNMP4J Net-SNMP
Configuration XML files Text files Web based Web based Web based
Extensible X X X X X
User interface Web Web / WAP Web Web Web
Reporting X X X X X

Update 1: Added C to the Hyperic development languages

Open source network management comparison: Introduction

One side effect of the increased competition in open source network management is that it is becoming increasingly hard to choose which tool is right for you.

With that in mind I intend to create a comparison featuring the best known open source tools to make the process of choosing the right tool a little bit easier.

I’ll publish the comparison in tranches so that, by the end of it, a comprehensive comparison is available. The first tranches will present more general information. As the series progresses more detailed information will be presented.

The projects being compared are, in no particular order: OpenNMS, Nagios, Zenoss, Hyperic and Zabbix. These projects have been chosen because they represent the best of the “pure” open source plays and the emerging “commercial” open source companies.

Both Zenoss & Hyperic have closed source offerings. As this is an open source comparison, I will only compare the respective open source offerings.

The comparison tables include notes denoted by numbers in superscript. The tables don’t include sufficient space to include much text so any further expanatory text has been placed at the bottom of the comparison table.