[HEADS UP] New project name: Monitoring Plugins

Andreas Ericsson ae at op5.se
Fri Jan 17 17:30:39 CET 2014


On 2014-01-17 00:49, William Leibzon wrote:
> On Thu, Jan 16, 2014 at 2:50 PM, Michael Friedrich
> <michael.friedrich at gmail.com> wrote:
>> On 16.01.2014 22:48, L. V. Lammert wrote:
>>>
>>> At 06:12 PM 1/15/2014, Holger Weiß wrote:
>>>>
>>>> As some of you might've noticed, we, the Nagios Plugins Development
>>>> Team, renamed the "Nagios Plugins" to "Monitoring Plugins".
>>>>
>>>> Why?
>>>
>>>
>>> Yes, Why? Seems like Nagios has a slightly different opinion, ... why
>>> can't you guys play nice?
>>
>> Because Nagios Enterprises tries to censor every mention of any fork.
>> Mention Icinga on your website containing nagios in your domain, say
>> nagios-portal.org - ban hammer & domain lost. Claim Icinga copyright on your
>> patches at tracker.nagios.org  - banned. Wikipedia article mentions Icinga
>> and other forks - Nagios Enterprise users edit the page and get banned by
>> Wikipedia for being a sock puppet. More on that fights at
>> http://www.freesoftwaremagazine.com/comment/79247#comment-79247
> 
> I'll give you my personal opinion since we're discussing it.
> 
> I think this all started with people at Netways. I was under the
> opinion that they way they were doing things (with nagiosexchange but
> also a few other projects) was as if they were trying to take project
> away Ethan while promoting their own software and company. I was very
> reluctant to add my plugins to their site because it was not official
> nagios and they were promoting themselves too much. I also had private
> discussions with them in regards to some of my own work and they
> refused to allow me to contribute unless I give up copyright to them,
> which I refused because this is not how its done in open-source unless
> copyright holder is a neutral organization. At the time ICINGA
> appeared there were also quite a few other software packages based on
> nagios that did not actually fork it. There was no need to fork and
> force the issue. And that it happened got Ethan really really
> irritated and strongly in favor of keeping nagios private for his own
> company.
> 

I first thought Netways were a bit too aggressive in their marketing,
and I wasn't too fond of many of their technical decisions (such as
using NDOUtils to get data and not addressing the pressing performance
issues for large networks), but after what happened to me I realize
that they were just an earlier version of me, and came from a corporate
standpoint rather than a community developer one.

>> Kicking Andreas Ericsson out of the Nagios Core development team, who wrote
>> 99% of Nagios 4 and then let him fork Naemon? Priceless. (you might need to
>> see the full presentation from last years OSMC:
>> http://www.youtube.com/watch?v=YgbbyyNIiHc )
> 
> Andreas did major rework on nagios3->nagios4. Its really good work.
> But he is really hard on policing what goes into core and not allowing
> fully joined development. This happens in open-source regularly when
> lead developer is a bit of a nazi but this does not promote
> cooperation and growth of the project and without new developers
> project stagnates. I told him all that privately.
> 

True that. I've blocked more patches than I've let in, but I've never
blocked a single patch without reading it properly, applying it and
then thinking about how it affects other parts of everything. Most
patches I've blocked have been blocked because they would force a
version number bump, and only Ethan can do that (and he tends to do it
with a one-day advance warning saying "Now's the codefreeze, so stop
committing anything at all and we'll cut a major version tomorrow").
That means API-altering patches can't go in nilly-willy, or every
single module would break randomly.

Unfortunately, Nagios core is quite convoluted and messy to begin with,
with several functions having a LoC-count in the thousands. Figuring
out the sideeffects of changes is never easy in a project like that,
and bugfixes (usually) aren't as obviously good as one would want.

> All that said kicking him off core team was absolutely wrong thing to
> do, and shows Nagios & Ethan's interest in keeping project private
> rather than truly open-source. There were other solutions available
> that would not cause yet another split in the community. Some time ago
> in private I tried proposing having a technical review/advisory board
> of about 5 people so that there would not be one person making
> decisions on the core and the decisions and work on the core would be
> more transparent to the open-source community. There was not enough
> interest and without multiple people a board like this a split was not
> surprising.
> 

I was actually for that idea. The problem is that there already was a
steering committee, which formed in 2008 and was never asked about
anything at all. I was on it, as was Ton Voon (who was kicked from
both core and plugins projects in 2011, I think) and neither of us got
any steering power at all. Since Ethan would've had to approve of things
like that, and Ethan is a professional procrastinator when it comes to
making decisions that let others do anything at all with Nagios, it all
fell through the cracks and noone could do anything about it.

> I'm quite disappointed how because of their personal egos and/or
> business interests the developers couldn't work together to continue
> the project in open-source collaborative way. Multiple forks is bad
> for everyone and actually means less contributions and development.
> Notice how Shinken does not have this issue where as original nagios
> core code development does.
> 

Naemon doesn't either. We're averaging six new developers per month,
which is quite good for such a young project :-)

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.



More information about the Help mailing list