I'll write up a new post on the topic of libgit2, since quite a lot has happened in the last couple of months.

Hello,

how's the current status of libgit2? I've found your blog post by googling libgit2, and was wondering if you can give me such information.

Looking forward to reading you

Rno

Hi Tom! Long time indeed.

Sadly, I haven't had time to work on the certificate authentication stuff :-/

We're doing a release to our customers tomorrow. After that I'm hoping to be able to hack in some more features into merlin, although unless our customers or the community requests SSL-certification specifically, I fear it'll be hard to get the boss to prioritize it. We'll see how it goes :-)

Hey Andreas, Long time no speak. I was wondering if you ever got the cerfificated server stuff working?

Hi everyone,

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.

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.

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.

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.

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.

Regards,
Julian

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

@Kevin: Long time indeed! Nice to hear from you again :-)
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.

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.

Hey Andreas,

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.

HI
looks very interesting!
bookmarked your blog.
john brightman

HI
looks very interesting!
bookmarked your blog.
john brightman

I had the same thoughts about NETWAYS but didn't want to start a conspiracy theory.

I think the true test would be this:

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.

@Chris Funderburg

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.

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.

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.

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


For the scalability and GUI issues, development is under way. I invite you to check out the following links:
http://www.op5.org/community/projects/merlin
http://git.op5.org/git/?p=nagios/merlin.git;a=summary

http://www.op5.org/community/projects/ninja
http://git.op5.org/git/?p=nagios/ninja.git;a=summary

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

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.

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.

@txwikinger

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

Keep up the good work!

txwikinger

Hi Andreas,
very good post of you. I also hope, that all will be friends again in future time, and the german guys will come back to such a good project like Nagios. It will be quite good idea to open the Nagios CVS for more than only one developer.

regards,
Christian

Very good posting. I hope you and Ethan will provide clarity soon. At least it's good to see someone getting involved who isn't driven by craving for admiration, power and money, so the whole fuss will soon go up in smoke.

That remains to be seen, but is not something we decide. If Ethan likes it enough, it may be (so we'd better make a damn good job ;-)).

Irrespective of that, we will make sure that it's easier to install than NDOUtils + GUI-tools is today, and the GUI will cover most of the shortcomings of the current GUI that we're aware of. Once a beta-release is available, I'm hoping we'll get plenty of feedback (and patches) from the community.

Sounds awesome. Will this new GUI be a part of the official Nagios?

@Miguel:
Yes, I'm aware of that. I just think the entire feature complicates rather than simplifies, that's all. :)
As for memory consumption, it would be as bad or better to use a separate variable that says if the original one has been set or not, and it would make the code quite a lot clearer imo.

hello,

Michael pointed me here.

I was curious, why do you think that you can assign null to int?

The only case where this is possible is if you use a feature in C# called "nullable types" which exist basically to deal with situations where a value might not have been set, and that is a different type (it is written "int? a").

Miguel.