XML Feeds
The future of Nagios
by Andreas Ericsson 
Some of you might know that a fork of Nagios has appeared recently. If you don't, go read about it in the nagios-devel mailing list archives. They're available on sourceforge somewhere, but I can't be bothered to look for them right now.
Working for a company that makes a living out of supporting and writing addons for Nagios, I must say I'm a bit sad. Being an enthusiastic and optimistic guy, I must say I'm thrilled.
A couple of facts before we set off:
- The fork was instigated largely by german members of the community. It appears to have been spearheaded by a german company (though I don't know this for sure) that makes its living selling customized Nagios solutions and/or support. I don't know this for sure, but it sure looks as if that's what's happened.
- The german company have unlawfully used the Nagios trademark after being asked not to do so. It has also registered Nagios as a trademark in Germany, to which is a huge slap in the face of an opensource project. They are naturally not on the best of terms with Nagios' founding father, Ethan, at the moment.
- Ethan has been absent working with the aforementioned lawsuit (or whatever it is a trademark violation results in when friendly talk is no longer enough), and also trying to put together a new webbased user interface for Nagios.
- Patches from all levels of the community have been erratically ignored during Ethan's absence. Some were picked up, but as many or more slipped between the cracks.
- Ethan has always been the single person with commit access to the Nagios CVS (yuk) repository.
- The fork uses git to track their patches.
The community developers have voiced a complaint that they cite as the primary reason for the fork:
Nagios is not being developed fast and openly enough.
I agree with this, and I'm currently discussing with Ethan about expanding the developer-base. Unfortunately, the scarce resource "trust" is even scarcer for those developers who joined the fork, which leaves the available candidates rather few. Happily, I count myself among them, and apparently so does Ethan. He emailed me away from public channels asking if I'd be willing to become a core developer, and op5 has graciously given a tentative promise to devote one to two days per week to Nagios development / patch management. Nothing's settled yet, but development has to continue even if the core maintainer takes a leave of absence, so one way or another, we'll make sure this happens.
In a perfect world (ie, one where I get to decide everything 
), here's what will happen:
- Nagios incorporates the good changes that the fork produces.
- The benevolent but previously frustrated developers from the fork hop back to working on Nagios when they see it's once again moving forward. They could actually do that by keeping on working on their fork, although that would set them apart from the Nagios community a bit rather than make them members of it.
- Nagios development picks up its pace and a new GUI is added to it which fulfills everyones wildest dreams.
- Nagios development moves to using git instead of CVS. Since git actually invites people to fork the code but makes it incredibly simple to merge those changes back to the pre-fork project again, there could be any number of forks and Nagios would be the grand total of the best of all of them. Who would win on that? Well, the Nagios users for a start, and Nagios itself, and Ethan, and every company making a living off of Nagios one way or another. So that'd be a win-win-win-win-win situation? I like it.
For those who wonder where I'm standing in all this, I'll be working with Ethan to make the community developers happy while at the same time trying to prevent the community users from living through the confusion that a long-lived fork means. In the end, I hope Nagios becomes a better product with a stronger and better community backing it, which seems rather inevitable now that more people than ever are working frantically at making it so. Hopefully it results in a happy community where The Right People(tm) are part of a Nagios steering committee or some such.
Time will tell. It always does ;-)
05/07/09 03:52:34 pm, 
10 comments
Comment from: Paul Etcheberry [Visitor]
Very good posting. I hope you and Ethan will provide clarity soon. At least it's good to see someone getting involved who isn't driven by craving for admiration, power and money, so the whole fuss will soon go up in smoke.
05/09/09 @ 02:43
Comment from: Christian Mies [Visitor]
Hi Andreas,
very good post of you. I also hope, that all will be friends again in future time, and the german guys will come back to such a good project like Nagios. It will be quite good idea to open the Nagios CVS for more than only one developer.
regards,
Christian
very good post of you. I also hope, that all will be friends again in future time, and the german guys will come back to such a good project like Nagios. It will be quite good idea to open the Nagios CVS for more than only one developer.
regards,
Christian
05/09/09 @ 17:52
Comment from: txwikinger [Visitor] · http://blog.txwikinger.me.uk
I am not involved closely enough with the nagios community to understand all the details, however, since I am very involved in the FLOSS community, I would like to share some thoughts.
FLOSS lives from the free flow of ideas and features. When these cannot be accessed by users or contributors easily the process does not work efficiently.
There is nothing wrong when someone who has started a project and is passionate about it feels strongly about its progress and acts as a gatekeeper.
On the other hand, others might be as passionate about their fixes or additions. There is absolutely nothing wrong to create technical means and processes to allow an efficient dissemination if necessary.
While I understand that sometime different interests create emotional reactions, I find it dangerous to portrait people that are passionately pursuing the dissemination of FLOSS almost as traitors and a reduced trust due to the fact that they do what is the idea of FLOSS, the free distribution of it.
We need to be careful in FLOSS that we do not fall into the same traps as proprietary interest do. John Nash, the acclaimed Mathematician and Nobel Prize winner clearly showed that acting in the interests of all parties are far more beneficial to every individual as well as the community at large.
Trust should be build on the quality of the materials produced, not on a condition to abide by everything a certain person or group demands. Otherwise, FLOSS loses its edge and competitive advantage.
I seriously hope that nagios and its fork will prosper even more due to the additional diversity that will now be built in. As long as both allow free usage of each others code, good fruits can come probably even more than ever.
Keep up the good work!
txwikinger
FLOSS lives from the free flow of ideas and features. When these cannot be accessed by users or contributors easily the process does not work efficiently.
There is nothing wrong when someone who has started a project and is passionate about it feels strongly about its progress and acts as a gatekeeper.
On the other hand, others might be as passionate about their fixes or additions. There is absolutely nothing wrong to create technical means and processes to allow an efficient dissemination if necessary.
While I understand that sometime different interests create emotional reactions, I find it dangerous to portrait people that are passionately pursuing the dissemination of FLOSS almost as traitors and a reduced trust due to the fact that they do what is the idea of FLOSS, the free distribution of it.
We need to be careful in FLOSS that we do not fall into the same traps as proprietary interest do. John Nash, the acclaimed Mathematician and Nobel Prize winner clearly showed that acting in the interests of all parties are far more beneficial to every individual as well as the community at large.
Trust should be build on the quality of the materials produced, not on a condition to abide by everything a certain person or group demands. Otherwise, FLOSS loses its edge and competitive advantage.
I seriously hope that nagios and its fork will prosper even more due to the additional diversity that will now be built in. As long as both allow free usage of each others code, good fruits can come probably even more than ever.
Keep up the good work!
txwikinger
05/11/09 @ 01:30
Comment from: Andreas Ericsson [Member]
@txwikinger
If it hadn't been for the german company that appears to have instigated the fork, no trust would have been lost what so ever. A company can provide value for developers that have nothing to do with technical excellence (such as "oh hey, here's a free laptop for you. Incidentally, would you be interested in this project here?"). The lost trust comes from the thought that the german company may have done something like that for the developers who joined the fork, and the fact that community developers joined a project that is, in every aspect, controlled by a company. I have nothing against company-controlled projects, but when it starts as a fork of a person-controlled project, something doesn't feel quite right.
While I sincerely hope that that is not the case, I cannot exclude it with 100% certainty, and the doubt it induces causes a (very slight) loss of trust on my behalf. It's been mostly alleviated for the majority of the community developers after having communicated with them though. I hope to meet most of them later this year and talk things over a bit with them. Hopefully over a good dinner and a beer or two. :)
If it hadn't been for the german company that appears to have instigated the fork, no trust would have been lost what so ever. A company can provide value for developers that have nothing to do with technical excellence (such as "oh hey, here's a free laptop for you. Incidentally, would you be interested in this project here?"). The lost trust comes from the thought that the german company may have done something like that for the developers who joined the fork, and the fact that community developers joined a project that is, in every aspect, controlled by a company. I have nothing against company-controlled projects, but when it starts as a fork of a person-controlled project, something doesn't feel quite right.
While I sincerely hope that that is not the case, I cannot exclude it with 100% certainty, and the doubt it induces causes a (very slight) loss of trust on my behalf. It's been mostly alleviated for the majority of the community developers after having communicated with them though. I hope to meet most of them later this year and talk things over a bit with them. Hopefully over a good dinner and a beer or two. :)
05/11/09 @ 10:20
Comment from: Chris Funderburg [Visitor]
I'm afraid I can only see this as a good thing. Nagios has gotten a little too commercialized for my liking for a start. And quite frankly it's slipping well behind other monitoring solutions. If it was *just* a case of having a new web interface that would be less of a problem. The bigger issues are that the api is just flat awful, and the database integration isn't enterprise ready or even maintained. Without these two things fixed, distributed monitoring isn't a real possibility when you have hundreds of servers and thousands of services to monitor over a number of datacenters.
The ability *to* fork is a good indicator of the true health of an open source project and I really don't see how this could hurt. If the better changes get rolled back into Nagios proper then great but frankly Ethan's created a lot of bad blood in the community over the years with his decisions and lack of innovation so this we'll have to see how it plays out.
The ability *to* fork is a good indicator of the true health of an open source project and I really don't see how this could hurt. If the better changes get rolled back into Nagios proper then great but frankly Ethan's created a lot of bad blood in the community over the years with his decisions and lack of innovation so this we'll have to see how it plays out.
05/11/09 @ 11:20
Comment from: Andreas Ericsson [Member]
@Chris Funderburg
I agree that a fork isn't necessarily a bad thing. I don't quite understand how you can like the fork but dislike commercialization though, as Icinga is controlled by a german company. If anything, its development is likely to be controlled by corporate desires rather than community wishes. That's not necessarily a bad thing, ofcourse, but it'll most certainly be more commercial than Nagios is now.
What parts of the API is it you don't like? If you're talking the module API, I agree. It's hard for eventbroker modules to modify Nagios' in-core memory, because the functions to do so pretty much all do too much. Otoh, Nagios doesn't implement data model opacity, so it's perfectly OK to modify the objects directly. Icinga have stated that they want to improve the API. So do I. It's just sad that Icinga haven't released their sources yet, as I'd hate to waste work (be it mine or theirs) if I don't have to.
If you're talking about the plugin API, I strongly disagree. Making it extremely simple is one of the things that makes it so powerful.
If you're talking about the command pipe API, I sort of agree and disagree at the same time. If I'd designed it now, I'd have added a small helper program to read from the pipe and then submitted commands to Nagios via a socket. Either unix domain one or a network socket listening on 127.0.0.1 only (by default anyways).
For the scalability and GUI issues, development is under way. I invite you to check out the following links:
http://www.op5.org/community/projects/merlin
http://git.op5.org/git/?p=nagios/merlin.git;a=summary
http://www.op5.org/community/projects/ninja
http://git.op5.org/git/?p=nagios/ninja.git;a=summary
As you can see from the gitweb, both of these projects are being developed quite heavily. Ninja and Merlin are due to be released as beta in time for Nordic Meet on Nagios in three weeks. Merlin is more or less beta-complete (nice word, isn't it? :)), while quite a bit of work still remains to be done for Ninja. I realize that Ninja doesn't exactly look revolutionary right now, but it has a lot of features that the community has wanted from the standard Nagios GUI a loong time (such as pagination, better search/filter functions, customizable widgets and a database backend that seemlessly cooperates with distributed monitoring).
I agree that a fork isn't necessarily a bad thing. I don't quite understand how you can like the fork but dislike commercialization though, as Icinga is controlled by a german company. If anything, its development is likely to be controlled by corporate desires rather than community wishes. That's not necessarily a bad thing, ofcourse, but it'll most certainly be more commercial than Nagios is now.
What parts of the API is it you don't like? If you're talking the module API, I agree. It's hard for eventbroker modules to modify Nagios' in-core memory, because the functions to do so pretty much all do too much. Otoh, Nagios doesn't implement data model opacity, so it's perfectly OK to modify the objects directly. Icinga have stated that they want to improve the API. So do I. It's just sad that Icinga haven't released their sources yet, as I'd hate to waste work (be it mine or theirs) if I don't have to.
If you're talking about the plugin API, I strongly disagree. Making it extremely simple is one of the things that makes it so powerful.
If you're talking about the command pipe API, I sort of agree and disagree at the same time. If I'd designed it now, I'd have added a small helper program to read from the pipe and then submitted commands to Nagios via a socket. Either unix domain one or a network socket listening on 127.0.0.1 only (by default anyways).
For the scalability and GUI issues, development is under way. I invite you to check out the following links:
http://www.op5.org/community/projects/merlin
http://git.op5.org/git/?p=nagios/merlin.git;a=summary
http://www.op5.org/community/projects/ninja
http://git.op5.org/git/?p=nagios/ninja.git;a=summary
As you can see from the gitweb, both of these projects are being developed quite heavily. Ninja and Merlin are due to be released as beta in time for Nordic Meet on Nagios in three weeks. Merlin is more or less beta-complete (nice word, isn't it? :)), while quite a bit of work still remains to be done for Ninja. I realize that Ninja doesn't exactly look revolutionary right now, but it has a lot of features that the community has wanted from the standard Nagios GUI a loong time (such as pagination, better search/filter functions, customizable widgets and a database backend that seemlessly cooperates with distributed monitoring).
05/11/09 @ 12:33
I had the same thoughts about NETWAYS but didn't want to start a conspiracy theory.
I think the true test would be this:
If Nagios proper were to address the "concerns" from Icinga would they gladly cancel the fork? If the concern is truly based around the community and not what's best for NETWAYS, it seems to me that if there's a roadmap on the Nagios side to address those concerns that the need for the fork is pointless.
I think the true test would be this:
If Nagios proper were to address the "concerns" from Icinga would they gladly cancel the fork? If the concern is truly based around the community and not what's best for NETWAYS, it seems to me that if there's a roadmap on the Nagios side to address those concerns that the need for the fork is pointless.
05/11/09 @ 18:30
Comment from: Kevin Menard [Visitor] · http://nirvdrum.com/
Hey Andreas,
Long time, no speak. I've seen you active on the git user list. If you could coerce Ethan into hosting Nagios on GitHub, that'd be awesome. As you know, it makes it considerably easier to produce a patch, too.
Long time, no speak. I've seen you active on the git user list. If you could coerce Ethan into hosting Nagios on GitHub, that'd be awesome. As you know, it makes it considerably easier to produce a patch, too.
06/04/09 @ 22:09
Comment from: Andreas Ericsson [Member]
@John E. Vincent: Regarding your test-theory, I agree, but it's not as simple as that anymore. It's turned political. Netways can't cancel their fork without losing face. They really have put some effort into the fork, but most of the effort has been spent renaming things from Nagios to Icinga. We'll see how it goes.
@Kevin: Long time indeed! Nice to hear from you again :-)
Yes, I'm as active as time permits in the git sphere, but at the moment there isn't much time to spare for work on it. That's quite sad, as I'm the libgit2 co-maintainer since a couple of weeks.
nagios.git won't be hosted on github, but on git.nagios.org or code.nagios.org. We'd like to have full control of the update and post-receive hooks in order to share access to the repository more easily and automate build- and release-processes. We'll switch to using git after Nagios 3.2.0 is released, as Ethan feels he needs some patch-free time in order to grok properly how it works.
@Kevin: Long time indeed! Nice to hear from you again :-)
Yes, I'm as active as time permits in the git sphere, but at the moment there isn't much time to spare for work on it. That's quite sad, as I'm the libgit2 co-maintainer since a couple of weeks.
nagios.git won't be hosted on github, but on git.nagios.org or code.nagios.org. We'd like to have full control of the update and post-receive hooks in order to share access to the repository more easily and automate build- and release-processes. We'll switch to using git after Nagios 3.2.0 is released, as Ethan feels he needs some patch-free time in order to grok properly how it works.
06/05/09 @ 12:06
Comment from: Julian Hein [Visitor] · http://www.netways.de
Hi everyone,
as there is a lot of speculation in this post and in the comments, I would like to clarify some things, or at least the way we think about it.
First, there is indeed an issue with the trademark. We registered the trademark in Germany years ago, because it was not registered, just to cover ourself from people registering trademarks of open source projects and then requesting money from companies marketing services related to the project. This has happened a lot in Germany. When we recieved it, we put it in a folder and never used it for anything. We are currently talking to Ethan about transfering the trademark to him, which we are happy to do.
Second and much more important: Icinga is not a NETWAYS fork: We did not initiate or instigate the fork. We were approached by community members and asked if we would support it. We also do not control it in any way. 3 members of our staff are working part time for Icinga, but that is it. There are much more people outside of NETWAYS involved.
The fork was done, because we all thought that Nagios is too important for us to see it slowly dying. And that is what has happend at least over the last two years. Not a single new feature, the long talked about webinterface did not make any progress and NDO kept being totally buggy and messed up for over 2 years. While other systems like Zenoss or Zabbix were going full speed ahead. And we all believed that we all had tried to talk to Ethan often enough about this issues before and we also had tried to offer concret help, but nothing happend.
So we (and that includes 50% of the Nagios community advisory board) decided to do the fork to revitalize Nagios. We consider Icinga to be kind of a friendly fork: We do not want to split the Nagios community, but consider Icinga still being part of it. Also there there is no need for us to win any kind of competition or defeat Nagios in any way. We even do not really want to be responsible for developing an alternative monitoring product or managing a project of that size. If Nagios development gains speed again and that proves to be steady and sound, we will be more than happy to stopp working an Icinga, merge back into Nagios or whatever makes sense at that time. This would in no way be a loss of face. The opposite is true, because than we would have reached our goal. At the moment everything looks good and even Ethan seems to be happy with the new energy that the project has.
Regards,
Julian
as there is a lot of speculation in this post and in the comments, I would like to clarify some things, or at least the way we think about it.
First, there is indeed an issue with the trademark. We registered the trademark in Germany years ago, because it was not registered, just to cover ourself from people registering trademarks of open source projects and then requesting money from companies marketing services related to the project. This has happened a lot in Germany. When we recieved it, we put it in a folder and never used it for anything. We are currently talking to Ethan about transfering the trademark to him, which we are happy to do.
Second and much more important: Icinga is not a NETWAYS fork: We did not initiate or instigate the fork. We were approached by community members and asked if we would support it. We also do not control it in any way. 3 members of our staff are working part time for Icinga, but that is it. There are much more people outside of NETWAYS involved.
The fork was done, because we all thought that Nagios is too important for us to see it slowly dying. And that is what has happend at least over the last two years. Not a single new feature, the long talked about webinterface did not make any progress and NDO kept being totally buggy and messed up for over 2 years. While other systems like Zenoss or Zabbix were going full speed ahead. And we all believed that we all had tried to talk to Ethan often enough about this issues before and we also had tried to offer concret help, but nothing happend.
So we (and that includes 50% of the Nagios community advisory board) decided to do the fork to revitalize Nagios. We consider Icinga to be kind of a friendly fork: We do not want to split the Nagios community, but consider Icinga still being part of it. Also there there is no need for us to win any kind of competition or defeat Nagios in any way. We even do not really want to be responsible for developing an alternative monitoring product or managing a project of that size. If Nagios development gains speed again and that proves to be steady and sound, we will be more than happy to stopp working an Icinga, merge back into Nagios or whatever makes sense at that time. This would in no way be a loss of face. The opposite is true, because than we would have reached our goal. At the moment everything looks good and even Ethan seems to be happy with the new energy that the project has.
Regards,
Julian
06/06/09 @ 15:09
This post has 5 feedbacks awaiting moderation...