At the heart of Opsview is the Nagios monitoring engine. One of the policies we have with Opsview is to keep the number of changes of our dependent software as low as possible. We do this by keeping track of all the patches we apply and pushing these back upstream (though recently we haven’t had as much time as we’d like…).

Looking back over the last year, we’ve compiled a report of the number of patches to Nagios.

Or if you prefer a graph:

So you can see that we’ve been working hard on reducing the number of changes to Nagios. Are we stripping functionality out of Opsview? Not at all – we’re trying to push as much back to the main project as we can. There was a big drop down from 40 to 30 when we upgraded Opsview to Nagios 3, mainly due to all the patches we already informed the project about.

There was a small increase between February to September 2009 – this was due to customer changes that we needed to apply. But there was another major drop again when we upgraded to Nagios 3.2.0 – this time due to my involvement in the core Nagios team. We’ll do a similar review on NDOutils since my colleague Duncan has been updating code there.

So by definition, Opsview uses a forked version of Nagios. But we call this a shallow fork, because we’re keeping our changes to a minimum and trying to make sure that the core project benefits from the enhancements and fixes and testing procedures that we use.

We’re proud of our involvement with the Nagios project and we’re committed to making Nagios better for everyone, driving standards higher and improving core technologies.