Forks can serve useful purposes for projects and communities. They can also divide and damage projects and communities. They are neither inherently good nor bad.
They’re a natural protection mechanism built into Open Source projects. An escape hatch of sorts. They can be invoked by the community with abandoned projects, threats of proprietary lockdown or power grabs, hampered development cycles, or substantial difference of opinion with regards to future roadmaps. These are all valid reasons for a community to consider using a fork.
I do not, however, agree with forks that are launched without the leaders of the proposed fork having first engaging with the leaders of project they intend to fork. Relationships can run into big problems when there are communication breakdowns and misunderstanding. The only way to determine whether or not a fork is truly necessary is to first communicate one’s intentions and plans with the other. After that, if a fork is still deemed to be required, proceed with your plans.
Realize though, that when you set out with the intention to use a fork, you are setting the table for things to come. Prepare to deal with the spoon and knife that accompany the fork. By that I mean you need to prepare to “eat your own dog food”, put your money where your mouth is, deliver what you promise, stick with your endeavor for the long run, and build and nurture your newly-formed community. You must be prepared for the cuts and wounds that the knife can create within both the old and the new communities, between developers, and between all the affected constituents.
Neither I, nor anyone else, can say for sure what long-term effect the Icinga fork will have on Nagios. I do, however, believe that misunderstandings and damaged relationships can be solved with better communication moving forward. It may cause Nagios development, innovation, and adoption to explode like never before. It may just be one of the best things to ever happen to Nagios.