<?xml version="1.0" encoding="iso-8859-1"?><!-- generator="b2evolution/2.4.2" -->
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:admin="http://webns.net/mvcb/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/">
	<channel>
		<title>GPL'd thoughts - Latest comments on The future of Nagios</title>
		<link>http://blogs.op5.org/blog4.php?disp=comments</link>
		<description></description>
		<language>en-US</language>
		<docs>http://backend.userland.com/rss</docs>
		<admin:generatorAgent rdf:resource="http://b2evolution.net/?v=2.4.2"/>
		<ttl>60</ttl>
				<item>
			<title>In response to: The future of Nagios</title>
			<pubDate>Sat, 06 Jun 2009 13:09:47 +0000</pubDate>
			<dc:creator>Julian Hein [Visitor]</dc:creator>
			<guid isPermaLink="false">c24@http://blogs.op5.org/</guid>
			<description>Hi everyone,&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
Regards,&lt;br /&gt;
Julian</description>
			<content:encoded><![CDATA[Hi everyone,<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
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. <br />
<br />
Regards,<br />
Julian]]></content:encoded>
			<link>http://blogs.op5.org/blog4.php/2009/05/07/the-future-of-nagios#c24</link>
		</item>
				<item>
			<title>In response to: The future of Nagios</title>
			<pubDate>Fri, 05 Jun 2009 10:06:12 +0000</pubDate>
			<dc:creator>Andreas Ericsson [Member]</dc:creator>
			<guid isPermaLink="false">c23@http://blogs.op5.org/</guid>
			<description>@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.&lt;br /&gt;
&lt;br /&gt;
@Kevin: Long time indeed! Nice to hear from you again :-)&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.</description>
			<content:encoded><![CDATA[@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.<br />
<br />
@Kevin: Long time indeed! Nice to hear from you again :-)<br />
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.<br />
<br />
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.]]></content:encoded>
			<link>http://blogs.op5.org/blog4.php/2009/05/07/the-future-of-nagios#c23</link>
		</item>
				<item>
			<title>In response to: The future of Nagios</title>
			<pubDate>Thu, 04 Jun 2009 20:09:54 +0000</pubDate>
			<dc:creator>Kevin Menard [Visitor]</dc:creator>
			<guid isPermaLink="false">c22@http://blogs.op5.org/</guid>
			<description>Hey Andreas,&lt;br /&gt;
&lt;br /&gt;
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.</description>
			<content:encoded><![CDATA[Hey Andreas,<br />
<br />
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.]]></content:encoded>
			<link>http://blogs.op5.org/blog4.php/2009/05/07/the-future-of-nagios#c22</link>
		</item>
				<item>
			<title>In response to: The future of Nagios</title>
			<pubDate>Mon, 11 May 2009 16:30:59 +0000</pubDate>
			<dc:creator>John E. Vincent [Visitor]</dc:creator>
			<guid isPermaLink="false">c16@http://blogs.op5.org/</guid>
			<description>I had the same thoughts about NETWAYS but didn't want to start a conspiracy theory.&lt;br /&gt;
&lt;br /&gt;
I think the true test would be this:&lt;br /&gt;
&lt;br /&gt;
If Nagios proper were to address the &quot;concerns&quot; 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.</description>
			<content:encoded><![CDATA[I had the same thoughts about NETWAYS but didn't want to start a conspiracy theory.<br />
<br />
I think the true test would be this:<br />
<br />
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.]]></content:encoded>
			<link>http://blogs.op5.org/blog4.php/2009/05/07/the-future-of-nagios#c16</link>
		</item>
				<item>
			<title>In response to: The future of Nagios</title>
			<pubDate>Mon, 11 May 2009 10:33:08 +0000</pubDate>
			<dc:creator>Andreas Ericsson [Member]</dc:creator>
			<guid isPermaLink="false">c15@http://blogs.op5.org/</guid>
			<description>@Chris Funderburg&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
For the scalability and GUI issues, development is under way. I invite you to check out the following links:&lt;br /&gt;
http://www.op5.org/community/projects/merlin&lt;br /&gt;
http://git.op5.org/git/?p=nagios/merlin.git;a=summary&lt;br /&gt;
&lt;br /&gt;
http://www.op5.org/community/projects/ninja&lt;br /&gt;
http://git.op5.org/git/?p=nagios/ninja.git;a=summary&lt;br /&gt;
&lt;br /&gt;
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).</description>
			<content:encoded><![CDATA[@Chris Funderburg<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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).<br />
<br />
<br />
For the scalability and GUI issues, development is under way. I invite you to check out the following links:<br />
http://www.op5.org/community/projects/merlin<br />
http://git.op5.org/git/?p=nagios/merlin.git;a=summary<br />
<br />
http://www.op5.org/community/projects/ninja<br />
http://git.op5.org/git/?p=nagios/ninja.git;a=summary<br />
<br />
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).]]></content:encoded>
			<link>http://blogs.op5.org/blog4.php/2009/05/07/the-future-of-nagios#c15</link>
		</item>
				<item>
			<title>In response to: The future of Nagios</title>
			<pubDate>Mon, 11 May 2009 09:20:37 +0000</pubDate>
			<dc:creator>Chris Funderburg [Visitor]</dc:creator>
			<guid isPermaLink="false">c14@http://blogs.op5.org/</guid>
			<description>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.   &lt;br /&gt;
&lt;br /&gt;
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.</description>
			<content:encoded><![CDATA[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.   <br />
<br />
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.]]></content:encoded>
			<link>http://blogs.op5.org/blog4.php/2009/05/07/the-future-of-nagios#c14</link>
		</item>
				<item>
			<title>In response to: The future of Nagios</title>
			<pubDate>Mon, 11 May 2009 08:20:38 +0000</pubDate>
			<dc:creator>Andreas Ericsson [Member]</dc:creator>
			<guid isPermaLink="false">c13@http://blogs.op5.org/</guid>
			<description>@txwikinger&lt;br /&gt;
&lt;br /&gt;
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 &quot;oh hey, here's a free laptop for you. Incidentally, would you be interested in this project here?&quot;). 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.&lt;br /&gt;
&lt;br /&gt;
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. :)</description>
			<content:encoded><![CDATA[@txwikinger<br />
<br />
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.<br />
<br />
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. :)]]></content:encoded>
			<link>http://blogs.op5.org/blog4.php/2009/05/07/the-future-of-nagios#c13</link>
		</item>
				<item>
			<title>In response to: The future of Nagios</title>
			<pubDate>Sun, 10 May 2009 23:30:29 +0000</pubDate>
			<dc:creator>txwikinger [Visitor]</dc:creator>
			<guid isPermaLink="false">c12@http://blogs.op5.org/</guid>
			<description>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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Keep up the good work!&lt;br /&gt;
&lt;br /&gt;
txwikinger</description>
			<content:encoded><![CDATA[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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Keep up the good work!<br />
<br />
txwikinger]]></content:encoded>
			<link>http://blogs.op5.org/blog4.php/2009/05/07/the-future-of-nagios#c12</link>
		</item>
			</channel>
</rss>
