[HEADS UP] New project name: Monitoring Plugins

[Andreas Ericsson]

On 2014-01-17 00:57, L. V. Lammert wrote:
> At 05:21 PM 1/16/2014, Jan Wagner wrote:
> 
>> > can't you guys play nice?
>>
>> Play nice? From my point of view all actions was public, even when
>> representatives of "Nagios Enterprises, LLC" tried to force the
>> developers things to do or even not.
> 
> "Play Nice" from the standpoint that this is the first the lists heard
> of any discord. "Play Nice" from the standpoint of acknowledging that
> different team members have different views, objectives, and resources.
> "Play Nice" from the standpoint of appearing like a nice, cohesive
> project for the muggles.
> 
>> "Out of control" for just developing and maintaining a peace of
>> software that "Nagios Enterprises, LLC" is using and has "na*ios" in
>> it's name? For just naming some of the projects which are compatible
>> with the plugins on the website?!?
> 
> If it were that simple, it would seem possible to work out the issues,
> would it not?
> 
>> > I read their post and it was misleading at best. We emailed them in
>> > the past about certain thing's and told them that it needed to be
>> > corrected. We never received a response back from them so we had to
>> > take back control of the site.
>>
>> Why is this statement not sent to the developers team?
> 
> If you did not receive it, that would seem to point to bad
> communications? Of course there are two sides to the story, and the do
> not need to be aired on a public list.
> 
> The point is that Nagios is not really the "dark side", rather from a
> user perspective it seems like the do try to support the OS community in
> many ways; the fact that it IS possible to fork a project just means
> that another option exists for the community.

Except it comes at a cost. We've sent quite a lot of patches (bugfixes
only) back to Nagios from Naemon. They're being ignored, which is sad,
because if they fix bugs that Naemon also has, we'll have to sort out
the mess of ignoring old bugs that we've already fixed, so we can't get
the synergy that multiple similar projects should have (and that
benefits the users).

I should also mention that the same day I forked Nagios into Naemon, I
got a message from Nagios Enterprises (well, one of its employees, but
she's about as high up as you can get without being Ethan), saying
"The real Andreas Ericsson has shown itself, and it is ugly."

Ad hominem arguments for utilizing my freedom to fork code that I
alone maintained for the past four years. How's that for "playing nice"?

The fact of the matter is that I was treated as shit. Not because I'm a
particularly horrible guy (I can be at times, but who can't?) or because
of any technical reasons, or because op5 acted unethically or marketed
Nagios aggressively. The fact of the matter is that people started
associating Nagios development with me, to the point where people from
all over the world actually came to visit op5.com to find supported
Nagios-based solutions. That was obviously bad for Ethan and his
company, so they had to get rid of me as fast as possible.

And the weird part is that all that happened because I maintained the
core for several years without Ethan having to pay a single cent for it.
If he'd been clever, he would have utilized that fact in his marketing.
"Hey, even our competitors are sponsoring our development. That's how
fucking awesome we are!". Instead, paranoia was allowed to reign free
and fear was allowed to make technical decisions. Never a good thing.

> It does not mean that it
> is the best solution to the problem. In this case, forks do the Nagios
> community a disservice, as having five or six Monitoring projects and
> code bases is just is an indication of a fractured community where folks
> can "take the only baseball to another field". Not many users are going
> to switch projects just because there is somebody or something they
> don't like - they have to stick with the original project as long as it
> has not been abandoned or trashed in some way.
> 

Nagios was abandoned in 2007. That's why the forks popped up in 2009,
when the mountain of patches had simply gotten too big. During those
two years, I maintained a patch queue and a sort of "this is stuff I
think is good, and I'll make sure Ethan looks at it when he can".
That wasn't good enough, and when nothing still had happened in 2009,
Icinga and Shinken came to life.

Fun anecdote about shinken btw; It started as a discarded patch to
Nagios, which me and Jean Gabés mentally refactored into the scheduler
+ workers concept that gives such an amazing performance boost to
Nagios 4 and Naemon. Ethan wouldn't let anyone near the code, so Jean
hacked it up as a proof of concept that our brainstorming was sound.

In short; Neglect and general assholeness from the part of Nagios
Enterprises has been behind pretty much every fork.

> In addition, the fact that there IS a commercial project is a big
> benefit in that is makes the entire project visible, which makes it
> possible for commercial users to contribute - *especially* when they
> want something done and they pay a developer to solve a problem that is
> then added back to the project.
> 

You can't pay Nagios Enterprises to do anything at all. Lots of people
have tried. You can pay them to use Nagios XI, which is inferior to
every other Nagios-based solution I've seen in every respect imaginable.

>> > We have another team in place and are always looking for more
>> > contributors if you interested in submitting patches.
>>
>> I hope it will be more patches, then the plugins projects has recieved
>> from "Nagios Enterprises, LLC" representatives!
>> With kind regards, Jan.
> 
> That would be a nice goal, but it probably won't happen - it doesn't
> make sense for Nagios to push patches to a forked project, does it?

No, but unless they close their sources it's easy for other projects to
keep an eye on what they do and figure out if the patch should be
applied to the fork as well.

> *Especially* since that forked project probably is no longer compatible?

Where did you get that idea? Most of the code in Naemon is identical to
the one in Nagios, although we have a bit different layout on the source
files since we want to be able to build modules directly from a checkout
of Naemon.

> All that produces is a bunch of unsupported forks, which dilutes the
> pool of talented folks that DO wish to contribute.
> 

Not really, no. I wrote 98.5% of all changes that went into Nagios 3
in order to make it Nagios 4. Another guy (Robin) at op5 wrote 0.5%,
and a guy from Nagios Enterprises wrote 0.5%. The rest of the community
shared the remaining 0.5%. The only thing that got diluted was Nagios
itself, which lost at least 99% of its contributions when they kicked
me out.

-- 
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.