Nagios Founder Comments on Icinga Fork
Nagios Enterprises founder and Nagios maintainer Ethan Galstad has admitted to development bottlenecks in his project and recognizes that Nagios developers want a stronger participation in the Icinga fork project. Nevertheless, he's disappointed that Icinga didn't engage with him before they struck off on their own.
Responding to Icinga's claim that a lack of communication on Galstad's part was one reason for the fork, Galstad said, "I am disappointed that no one from the Icinga project contacted me directly about this before the decision to fork was made... The unexpected announcement of this fork clearly demonstrates that there are communication problems on both sides of the issue." He also posed the question to Nagios critics why they didn't just request more participation in Nagios: "It's apparent that we all need to improve our communication and demonstrate better understanding of each other."
No one with years of experience in open source projects is under the illusion that community projects are the wonder drug, said Galstad. "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." When Galstad spoke of "true intentions" and "personal character" exposed by the fork and his conviction that it will lead to an even stronger Nagios project, an accusation of treason by the Icinga project was not far off.
Galstad concretized his disappointment in a blog entry. "Forks can serve useful purposes for projects and communities... They're a natural protection mechanism built into Open Source projects." But not "first engaging with the leaders of project they intend to fork" was a problem for him. Clearly rattled by the circumstances, Galstad was uncertain about the repercussions of the split on Nagios users. But he was feisty and almost threatening when he wrote, "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."
Galstad suggests "one more fork for Nagios. That being a mental fork - a change in mindset - rather than a code fork." He sees constructive collaboration on the horizon: "Are changes necessary? Yes. Will changes happen? Yes. Is Nagios dead? Hardly."
In another blog, Galstad took a stand on Nagio's trademark policy, one of the issues why Icinga wanted to split off in the first place. He used Ubuntu's trademark policy as an example and model of "allowing for advocacy and individual development, while at the same time restricting and regulating commercial usage." (See recent controversy surrounding Canonical's use of the Ubuntu One name.) Rest assured, the Nagios name will continue to be protected and nobody can use it commercially without their consent. "I realize that any confusion on the part of the community as to our stance on the Nagios trademark and our trademark policy may very well have been due to lack of clear communication on our part."
Prompting Galstad's comprehensive blog on the Icinga fork was a thread on the Nagios developer mailing list with the subject "Nagios is dead! Long live Icinga!" (the thread beginning "6 May 11:57"). Galstad's blog includes links to further blog entries related to trademarks, forks and the future of Nagios.
great postThanks a lot for sharing the article on cash. That's a awesome article. I enjoyed the article a lot while reading. Thanks for sharing such a wonderful article.I want to say very thank you for this great informations. now i understand about it. Thank you !
Linux Foundation's big event celebrates the 25th anniversary of Linux
Competitors get in the game with RHEL without Red Hat
Security researchers have already notified Microsoft; some fixes are available
The company is collaborating with Google and Intel to use Kubernetes as an engine for Fuel
Customers can take a free test drive of SLES for HPC on the Azure Cloud
San Francisco-based chip company announces their first fully open source chip platform.
The whole distro gets rebuilt on glibc 2.3
Ubuntu Vendor tries to solve app packaging and distribution problem across distributions.