Nagios – A Fork In The Road

The Father of Nagios

As many of you know, a recent fork of Nagios has been announced, accompanied with a flurry of activity in both the community and press. An email thread titled “Nagios is dead! Long live Icinga!” began last week on the nagios-devel mailing list to kick this off.

What are my thoughts on this announcement? I think its one of the best things to ever happen to Nagios.

Why? The announcement of the fork, along with the community’s reaction to it has brought to light several things:

  • Community interest in furthering Nagios is at an all-time high
  • Community developers want to get more directly involved in the future project direction
  • Nagios development has been slowed by some bottlenecks
  • When the community perceives a problem, the community reacts
  • Communication within the community needs to be improved

This entire event has seen some ugly misconceptions and half-truths lobbed in the direction of Nagios Enterprises, the Nagios Project, the Nagios Community, and myself as an individual. That’s unfortunate.

I am disappointed that no one from the Icinga project contacted me directly about this before the decision to fork was made. One of the reasons that was stated for the fork was lack of communication on my part. The unexpected announcement of this fork clearly demonstrates that there are communication problems on both sides of the issue.

Many of the individual developers in the Icinga project did what they felt was best in the situation they believed to be true. They appreciated Nagios, wanted to see it succeed, and wanted to play a direct role in its evolution. Many of them have been very active in the Nagios project and community over the years. Their efforts have been much appreciated by both myself and the community as a whole. To those individuals, I pose this question – If what you wanted to do was help create “the” new Nagios interface and be materially involved in the future development of Nagios, why didn’t you just ask? It’s apparent that we all need to improve our communication and demonstrate better understanding of each other.

In the course of discussions about this fork within the Nagios community, many concerns have been raised, including: the future of Nagios, the Nagios trademark policy, and the commercialization of Nagios.

In an effort to begin to address these concerns, I have penned some of my thoughts in the following write-ups:

Open Source communities are not a panacea. The sky is not always blue. Anyone who tells you otherwise is likely delusional. Community can be great, and community can be frustrating. Ask anyone with long-term involvement in an Open Source project.

It’s interesting to watch how individuals and companies react to situations of distress and change. Challenges can bring out the best and worst in all of us. True intentions, motivations, and personal character are often brought to light. I’m sure that the result of all of this will be a stronger Nagios project and community that endures far into the future.

To those of you who would complain about the state of things now or in the future, the time has come to “put up or shut up”. If you see the need for change, you must be willing to materially involve yourself and commit your time, effort, and resources to affect that change. Don’t assume that someone else will do things for you, and don’t complain if they don’t.

As things move forward, I can almost certainly guarantee you that you will not always get what you want and things will not always be done the way you want them to. Neither I, nor anyone else involved in the Nagios project, will attempt to please everyone. That is neither possible, nor beneficial to the overall effort.

I would suggest that we need one more fork for Nagios. That being a mental fork – a change in mindset – rather than a code fork. Lets all work together to improve the way we think, communicate, and affect the direction of Nagios for the better.

Are changes necessary? Yes. Will changes happen? Yes. Is Nagios dead? Hardly.

Bookmark and Share

6 Responses to “Nagios – A Fork In The Road”

  • It may simply be a question of power. In the almost 20 years that I have been involved with open source software, one of the more common reasons for forks is not an issue that the original is “bad” or cannot do the job, it is because one or more people want a particular feature or other change and they don’t get what they want. So, like a little child, they take their ball and go play somewhere where *they* can be the boss. I am not saying that this what is happening here, but it is common enough for me to want to pose the question.

    In some cases, the people in the other project *try* to run the new project as a complete democracy, where everyone has an equal say. However the progress of the fork is extremely slow because they are trying to satisfy everyone. I have seen cases, where the fork dies because the it is mired in the desire to make everyone happy and the orginal dies because a lot of the developers moved to the fork.

    I think it is a necessary aspect of any project that there is someone who does have the final word. In the case of Nagios, Ethan has earned that right and I support him 100%, even if there would be cases where he decided not to implement something I wanted. Unless I am mistaken, Linus still has the say as to what goes into the “official” Linux kernel and that is a good thing.

    If there are people who want to leave for whatever reason we should wish them luck. Hopefully they are doing so for the right reason.

  • I worked w/ Ethan when advertising my product (plug intentionally left out). I’m surprised to see anyone complain about Ethan’s communication. He was always very quick to respond and very thoughtful. I guess either the requirements on his time have gone up, or some people are more sensitive to minor delays than I am. *shrug*

    That being said, I see this as a good thing. No offence, Ethan but your UI design skills leave a bit to be desired. Seriously…HTML embedded in C code? Yuck! Having some people w/ HTML/UI skills might be a real benefit. I hope they opt to port their changes back into the main branch.

    -Dave Rudder

  • I’ve ready everything I could find on this recent bump in the road for Nagios, as a heavily vested user of Nagios I’m very interested in it’s future. It seems to me that Ethan has handled this with as much class as I’ve seen him (from afar) handle anything regarding Nagios, most notably to me, are the numerous offers (3 that I heard of) to sell Nagios at different times in it’s history. He has once again put a priority on the Nagios community and what’s best for it over personal gain. May my dealings with others both professionally and personally be as honorable as his have been in this situation. My hat’s off to you sir.


  • Ethan has dedicated the bulk of his professional career to the development of Nagios. I have been honored to share in his successes and frustrations regarding the project for the past ten years and I can assure you that Ethan has the best interests of everyone in view regarding this powerful project. It amazes me that users throughout the world have been able to save multiple tens of millions of dollars in the application of Nagios to their systems and yet there are those who believe that he ought to continue to offer his program and services gratis. If you support what he has done for you it is time to step up both financially and with your encouragement.

    As many of you know there have been offers to purchase the company but to his credit Ethan has been extremely careful about the kinds of business relationships he is willing to enter into. While at times I have been advising “take the money and run” Ethan is steadfast in his dedication to the Nagios project and the open source community. He will not let you down, I only hope you do not let him down.

    Piracy of his project by whatever other name including “forking” should not be respected or tolerated. Work with Ethan, communicate with him, as he has always been open to you and deeply appreciates your suggestions and input.

    Along with Greg, my hat is off to you son for your professionalism and dedication to the project and the users of your worldclass offering.

    Dad (Roger Galstad)

  • Roy Sigurd Karlsbakk

    What I see as main problem with Nagios today, is that there is one guy with CVS access. The development group should be extended, and perhaps, but not necessarily, CVS could be replaced by something a little newer (svn? git?)

  • I have only been developing a Nagios system for a short period of time. I do not blame Ethan for using a compiled language to create the core system. Intellectual property theft is running rampant in the information technology world. Why should Ethan place the core wide open to everyone?

    You really need to consider the entire project. What about the addons and pluggins? Anyone can create pluggins for their own system. Try doing that with Tivoli. Or how about the macros embedded in Nagios?

    My organization has a help desk. They currently have three methods for monitoring systems: home grown scripts, Nagios and Ciscoworks. Guess which was the winner? Nagios! Why? Because Nagios enables you to set up parent-child relationships, customize messages that each group receives, generate custom reports on any objects being monitored and also create custom pluggins as your enterprise identifies new concerns.

    I think Ethan is doing a great job! In my opinion, what the community needs at this point is to get out the word on Nagios and provide Case Studies. Let Ethan continue the great job with the core and we should start providing as many properly designed pluggins as possible to build the project.

    Check out the WordPress community if you think I am mistaken.

Comments are currently closed.