The icinga on the cake ...

[Andreas Ericsson]

Hi all.

First of all, let me say I'm not writing this post for Ethan's sake,
but because I'm a member of the Nagios Community Advisory board and
I feel this is information the community should take part of.

Secondly, Ethan's under quite a bit of stress right now. If anybody
wants to cheer him up, send him a postcard or a picture of a screen
showing Nagios. He told me once it would be quite cool to get such
postcards but he never found an opportunity to ask for it. I can't
think of a better time than now ;-)

The address to Nagios Enterprises is
Nagios Enterprises, LLC
P.O. Box 8154
Saint Paul, MN 55108


Now read on and, in the words of The Hitchhikers Guide to the
Galaxy: Don't panic.


Jim Avery wrote:
> I'm surprised nobody's mentioned this yet...
> 
> http://www.icinga.org/
> 
> I only noticed it myself when I visited Nagios Exchange today.
> 
> Not being a developer myself, I'm not quite sure what to say or think,

It's really the input from the community that matters the most. I *am*
a developer, and as a developer I applaud the effort to create a better
product, but as a human being I really don't like the way it's being
done.

It's been discussed quite a lot on the nagios-devel mailing list.
The facts so far seems to be thus:
* Netways registered "Nagios" as a trademark in Germany last year.
* The Icinga team is managed by Bernd Erk, who is also the chief
  programmer of Netways (to me, this makes it seem as if Netways
  instigated the fork).
* Ethan has been absent from the community for too long, stating legal
  issues against Netways for trademark violation as the reason for this.
* The primary reason stated for the fork is that the Icinga team feel
  that development isn't being done openly enough.
* Some german nagios-tribute sites claim to have received email from
  Nagios Enterprises requesting that they add a paragraph on their page
  stating that they're not affiliated with Nagios Enterprises in any
  way, and this has caused bad blood in the community (I have no details
  about this, and can therefore not give any).
* The icinga team has released no sources (ie, making a *worse* mistake
  than they feel Ethan is doing, who at least keeps his source repo
  publically available).
* The roadmap for Icinga focuses mainly on 3rd party addons that could
  easily have been created *without* forking.
* Some prominent developers and community members (no, I won't give
  names, but I'm one of them) think this is primarily an attempt from
  Netways to usurp the Nagios community.
* The german community developers that have responded on the nagios-devel
  list seem honest about their desire to create a better product.
* The development method of the Nagios core *will* change in some way.
  More on that later in this mail.

Later, it appears, is now.

So far, we ("we" being originally me and Ethan, and two emails later the
community advisory board, which presently consists of Ethan, myself, Ton
Voon, Alex Burger and Thomas Guyot-Sionnest) have discussed (nothing is
decided) increasing the number of people with commit access to the nagios
core repository.
I have been asked to join this team, and I've suggested two others whom
I feel can add value to the development process. I won't name any names
since neither have accepted or declined yet.

Me and Ton Voon argued that it would be a good idea to have all tecnical
and socio-technical (ie, patch-submission alternatives) on nagios-devel
instead of on a hidden list where a large part of the community have no
insight into the development process. Ethan hasn't responded to this yet,
but that's not so surprising as it was 2AM in Minnesota when me and Ton
wrote our emails, and it's currently 5AM (I think).

>From what I've gathered from the discussions, it seems we agree on
incorporating Icinga patches into Nagios if they hold good quality and
add value to Nagios. Since many of the developers on the Icinga team are
quite good programmers, this should benefit Nagios rather quickly.
To make it easier to incorporate patches from the Icinga team, we have
also discussed moving the core Nagios repository to git from CVS. Read-
only users won't necessarily see any changes at all, as there already
exists a cvs-server capable of serving git repositories. For tarball
users and software distributions, it has zero impact.

Anything apart from the above that's been going on is either loose
speculation, bad research or misunderstanding on my behalf or relates
to information I haven't seen. I may also have missed something, in
which case I'm sure someone will point out my mistakes.

> except that I'm continuously deeply grateful to everyone who bring us
> Nagios itself, and the plugins and tools which make it greater than
> the sum of its parts.
> 

Don't be. Well, be, but reserve some gratitude for yourself for using
it. Without a userbase, a project is just an academic exercise with as
much real value as a bucket of sand in a desert.

Oh, and send a postcard :)

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

Register now for Nordic Meet on Nagios, June 3-4 in Stockholm
 http://nordicmeetonnagios.op5.org/

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.

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null