(In reply to Kurt Seifried from comment #42)
> (In reply to Andy Brist from comment #7)
> > (In reply to Michael Friedrich from comment #6)
> > > Actually the old Nagios Plugins Development Team was required to rename
> > > their project due to the fact that Nagios Enterprises hijacked the DNS and
> > > website and kicked them out. 
> > 
> > The domain was, and continues to be, owned by Nagios Enterprises.
> > 
> > > Whilst the original memebers are now known as 'Monitoring Plugins
> > > Development Team', the newly formed 'Nagios Core Plugin Development Team' is
> > > actually providing a fork of their work under the old name.
> > 
> > nagios-plugins is not a fork, but a rebase with new team members. 
> > monitoring-plugins is indeed a fork, as their new name suggests. 
> > 
> > If you need any further clarification, please contact Nagios enterprises
> > directly.
> > 
> > Thank you kindly.
> 
> I would prefer these discussions to happen publicly in a transparent manner,
> especially as this involves the entire community. 
> 
> My concern is with regards to "but a rebase with new team members", how
> familiar is your team with all the existing code? Will this impact security
> response times (e.g. the original authors of the code whom are familiar with
> it vs. a new developer that has perhaps never seen the code before can have
> a huge impact on the time involved in a security response). If you can
> clarify this I would appreciate that greatly.

There seems to be an answer from a sales guy being leaked onto the mailinglists but I wouldn't treat that as official statement though.

https://www.monitoring-plugins.org/archive/devel/2014-January/009420.html

For what it's worth, inspired by all the comments on slashdot and reddit, I'll have to add in regards of maintaining the code and project:

The Nagios code, and all of its sub projects such as NRPE, NSCA, NDOUtils and also the Plugins project, contain a huge history of changes. While the plugins project has been moved into a community project, the rest is still maintained by Nagios core developers (or - was, as Andreas Ericsson was kicked out in October 2013, and the "rest" of the nagios team remains unknown, as the compiled list on http://www.nagios.org/about/team sounds more of a list of support, sales & trademark guardians).

In any attempt of fixing a bug, or a security issue even, you need to know the code, its origin, how to debug it, and also - who to ask in case. There's no technical documentation publicly available, nor anything else that would be helpful in this regard - other than mailinglist archives, or git history.

I'm familiar with the Nagios code and its flaws - I've been digging and modifying the core code for the past 4,5 years in Icinga. And so do others maintain the long history of the former Nagios Plugins, now representing that knowledge and power as "Monitoring Plugins Development Team".

If you don't know about the code, and have never patched a series of bugs requiring you to fully understand the code, it's unforseeable if you can catch up with security incidents or bug reports in a decent time manner. I'm not saying that the newly formed Nagios Plugins Development couldn't do that. It's just the feeling that I get when I'm looking into their repositories and grepping for their names in terms of commits.

Likewise, the more fancy comparison for that exists already - thanks to ohloh.
Since they forked off the monitoring-plugins project I would expect at least some contributions in the past. Apparently there are none. 

http://www.ohloh.net/p/monitoring-plugins/contributors?query=&sort=commits

Mine is zero as well. But I am not applying as upstream source for the official nagios-plugins package here.