When I became the OpenNMS maintainer in 2002, I wasn’t sure if I was up to the task of not only keeping the project alive but making it better. I knew the trick would be to surround myself with people smarter than me, and I somehow managed to do that with the creation of the OGP.

In 2003 we had a client who wanted to integrate a monitoring system with their in-house customer management application. Due to the architecture of OpenNMS, it was pretty easy to set up an extremely scalable monitoring platform. The only problem was that there wasn’t an easy way to get the monitoring information into OpenNMS and then back to their system.

This was well before the Importer was created, so since OpenNMS was able to receive arbitrary events from external systems they contracted with us to write some code to make the integration easier. This resulted in the creation of the xmlrpcd daemon. It is a daemon that isn’t used much, if at all, outside of this one client.

Now, when a client contracts with us to write custom code, we strongly suggest that the modifications be added to the code base. The project’s main architect, Matt Brozowski, introduced the concepts of extreme programming into OpenNMS, which include things like unit tests. This means that as OpenNMS grows, even older, legacy code will be kept up to date as the unit tests will fail if changes are made to the code that breaks their functionality.

That system we wrote in 2003 has been in continuous production since then, monitoring tens of thousands of servers in four data centers around the world. It is running on OpenNMS 1.1.1, on Debian Woody and PostgreSQL 7.2.

Today we configured the migration servers running 1.3.9 on RHEL 5 and PostgreSQL 8.1. After working out some issues with SSL certificates in the test environment, it turns out that the xmlrpcd code works just fine, something like 20 releases, and 5 years, later.

That’s the kind of stability that rates the name “enterprise-grade”, and why we use it in our tagline.