Geekly Articles each Day
📜 ⬆️ ⬇️

Nagios vs Icinga. The real story of one of the “hottest” branches in free software

From translator


This is a translation of last year’s, albeit still relevant, article on the conflict of property rights in the area of ​​free software. Only at first glance it seems to be an oxymoron, because the public code is not only hard work, the desire to benefit other people and your own self-expression; behind him are often personal aspirations and interests, which, when multiplied by gaps in legislation, gives unexpected effects. The conflict did not reach the judicial stage, although it was very close to that. Its participants got rid of a waste of nerves, time and effort. Perhaps this story will be instructive for all those involved in free software.

Original article: Free Software Magazine, April 27, 2012.
Tony Mobily. Nagios Vs. Icinga: The Most Heated Forks in Free Software

From the author

On March 14, 1999, Ethan Galstad released the first release of Nagios. Then, almost exactly 10 years later (May 2009), Icinga (a derivative of Nagios) was born. What happened? Why are the projects divided? In this article, I will try to shed some light on the reasons that forced the developers of icinga to separate and start their own project (although they still send their ideas to Nagios). In this article, I will quote excerpts from my conversations with Ethan Galstad and Michael Lübben (one of the founders of the Icinga team and developer of add-ons for Nagios). I will quote literally Michael and Ethan and you will get the opportunity to get acquainted with their points of view.

Start: Netsaint / Nagios, debugging and functionality

Nagios, like many other free projects, began as a hobby. Ethan said: “I started practicing Nagios in the fall of 1998, then it was also called NetSaint. I started working on development, because I needed some kind of hobby for practicing myself in my spare time, and I also thought that this could be useful for providing commercial monitoring services in the future. When I looked at the solutions that existed at that time, I thought that they were all not flexible enough and did not meet my future needs, so I decided to start my own project. I decided to release NetSaint with open source because I wanted to make a contribution to the community, and also understood that community involvement would help to quickly improve the quality of the product. ”
')

Ethan speaks here about Nagios Core, since Nagios is divided into two major parts: The core itself (Nagios Core) and its plugins. The real power of nagios lies in its ability to expand with various additions. Ethan also talks about how from the very beginning he laid the nagios opportunities for the work of plugin developers: “It was not more than a few months after the first release of NetSaint, when the first contributors joined the project. I remained the 'keeper of keys' and responsible for the core code for many years to come, but I quickly decided to allocate the plug-ins into a separate project, hoping to attract more people. ” As a 'custodian', Ethan had to solve the dilemma of every maintainer - taking over the work of the new code and spreading the functionality associated with it (feature creeping). He said: “For many years, I personally created most of the kernel code and looked through the many patches offered by contributors before they were included or rejected. Maintaining a balance between the endless increase in functionality and retention within the monitoring engine has always been a difficult task, but I still believe that this was one of the reasons why Nagios became the most widely used solution in its field. ” I asked him a question: “What was the acceptance of code from developers by?” To which he replied: “Opening a development team for unfamiliar people is not always an easy task and not always acceptable. You need to build a trusting relationship with contributors who provide patches, both in terms of the quality of the code, and in their understanding of the problems of architecture that affect the long-term viability of the project. After all, some projects are more adapted to a large development team, while others are not. I was quite satisfied with how the Nagios development team grew during this time, as well as how the community members became more active and offered to make their contribution in any accessible way. ”

From the very beginning, Ethan was very serious about trademarks. He told me: “I took a number of steps to protect the Nagios brand — it happened right after I changed the name of the project from NetSaint to Nagios. The name change was caused by the fact that NetSaint was pretty close to another brand on the market, so I figured the name change would be the best way to continue. This showed me the importance of using trademarks and gave an understanding of how legislation in this area works, as well as an awareness of the need to protect one’s own brand, which somewhat upset the balance with the current use of the brand in the community. Since the first release of Nagios in 2002, I have published guides on the use (and usage restrictions) of the Nagios brand, as well as the requirements for attribution. Community members (including Nagios core contributors, plugin and add-on developers) for the most part understood the importance of regulation and paid tribute to these rules. We later adopted a modified version of Ubuntu’s trademark policy for Nagios, because we felt it was a good example of a balance between the trademark protection requirements and the established practice of using them in the community. ”

Six months before separation


Michael Lübben said that among some developers, especially towards the end, there was growing discontent with the ways in which Ethan led the Nagios Core project. Michael, who was involved in the project at the time, said: “Six months before the project was divided, there was a slight concern among the developers of extensions for Nagios: Nagios Core was solely maintained by Ethan Galstad; In contrast, several programmers worked with plugins and add-ons for Nagios. At that time, Ethan never asked the community to bring in more developers. Third-party patches have not been included in the project for a long time, as well as requests to support more DBMS servers. Ethan considered this state of affairs to be balanced, while other developers did not consider such a balance a strong position.

When I asked Michael if there was any problem, which was especially annoying for him before the separation of projects, he replied: “Yes, in general, nothing special, but the desire to see how the community’s practices regularly flow into the project for me. In addition to fixing bugs, there was a need for major improvements in the kernel, which our plugins and add-ons could not provide — for example, support for PostgreSQL and Oracle, the ability to extract data for add-ons that worked with reporting, an API to facilitate the integration of extensions, and this list goes on. These were not just user hackers — the lack of implementation of these properties in the kernel limited the community’s ability to develop extensions for Nagios. At that moment, there was a two-year stagnation in the release of Nagios Core releases. Therefore, when we decided to separate, we set a number of priorities for ourselves - to offer the community a choice of several DBMS, which it had asked for so long ago; provide a PHP interface, as it was once promised in Nagios, as well as a way to make the life of developers easier — at first Icinga API. At the same time, compatibility with nagios for configuration files and plug-ins was maintained, and in addition, we were going to improve our versions of cgi-components. In addition, since the separation of projects, we continued to send bug fixes to the new Nagios Core project team. Here is even a review. You can also find their traces scattered over the change logs of Nagios. ”

Ethan’s view of the moment before the division is different: “It’s not clear what these were such special bugs / features that they were so anxious about when they decided to separate. In addition, none of the members of the initial Icinga team offered to become a kernel developer, or to help with bug fixes or kernel feature extensions before they decided to separate. The efforts of the present community should be completely wrong. ”Then Ethan added:“ Comparison of properties and errors of Icinga [compared to Nagios] is wrong, especially in that part of the “functional extensions” along with errors. The list of errors, in this case, is distorted, since the kernel development team of Nagios did not implement some things in the kernel due to the negative side effects that affect key Nagios additions. ”
Ethan’s attitude to the situation will be familiar to many programmers: “The problem is presented not so much by mistakes as by the expectations of some people regarding what can be done in the core. The difficulty with Nagios Core for the most part is that it already does what it was intended for, and that some functionality that users want to see there should not be added to the core. Maintaining the core in relative order and architectural separation from external add-ons was a major factor in the success of Nagios. Additional features and functionality that users often want to see do not belong to the monitoring system core. Examples of such functions are web-interfaces, additional APIs, reports, distributed monitoring, and so on. A good architectural understanding of what Nagios is, and how different things are designed to dock with each other, being separate components instead of a monolithic solution, is important for anyone who is going to develop software for Nagios. "

His plan worked: To understand the idea of ​​net code, which we talked about earlier, just look at Nagios exchange : hundreds and hundreds of extensions, plug-ins and information documents. This is all created and managed by the community, so that a random message “File not found” may sometimes appear. However, they are quickly caught as a team of developers from the inside, and community members - from the outside.

Before separation

About two years ago, when the separation took place, Ethan had problems with a German company called Netways Gmbh. Nagios tried to solve this problem amicably for two years, but nothing happened. Ethan wrote then: “About four years ago we discovered a serious international trademark infringement by a commercial company from Germany called Netways. These violations included the registration of the Nagios trademark in Germany, which the company's founder, Julian Hein, initiated in order to use the Nagios brand for the commercial gain of his company. At first we tried to settle the conflict with Netways and Julian Heinom in a friendly way, but after Netways and Hein refused to work with us, we had no choice but to involve our lawyers in the conflict. Then everything became even more interesting. The battle took place on several fronts: there were even problems of a PR character. As Ethan said: “After more than two years of ignoring requests from us and our lawyers, refusing to resolve the issue properly, Netways was able to convince some members of the Nagios community that we are pushing and annoying the whole community with our trademark policy. After that, Netways planned and launched a separate Icinga branch, using many tactics to inflame fears, uncertainty and doubt, which used links to our trademark policy and its protection.

When I talked with Michael about attacks on the Nagios trademark, he told me that he did not directly participate in them, but at the same time he said, “I knew from others that Nagios Enterprises (Ethan and Mary) were contacted by the German side - they were talking and communicated by email, demanding the transfer of domain names. This was described in the IT magazine ZDNet DE-edition , which unfortunately is written in German, but you can use Google Translate "(Note that the Nagios team does not recognize this article, in their opinion, it contains" inaccurate information and opinion that presented as a fact ").

Ethan's position on the alleged "attacks" is expressed in the fact that Nagios never attacked the community. He said: “It’s very inappropriate to speak here about attacks related to the protection of the Nagios trademark. Nobody touched the community. We simply took steps to protect the trademark from commercial misuse. The only thing we did was contacting trademark offenders who were commercial companies, but not members of the community. So the events that Michael mentions are related to a commercial breach of the trademark. ”

Nobody personally asked Michael to give up any domains. However, he points out that "if you look on the Internet, then nagios-fr.org is now monitoring-fr.org, the domain formerly formerly nagiosexchange.org is now monitoringexchange.org, and nagiosplugins.org now belongs to Nagios Enterprises.". Ethan’s reply prot: “The domain nagios-fr.org was a direct violation of our policy. While we asked to stop using the domain and transfer it to us, he [his owner] tried to establish the commercial organization Nagios in France. We tried to settle things in a friendly way with him (even by offering assistance in organizing a commercial organization), but he refused to work with us. Nagiosexchange.org was one of more than 60 “nagios” domains that Netways owned in violation of our trademark policy. Only after we told what they were doing in social media did they transfer the domains to us. ”

Separation

So, after all these events came the moment of birth of the project Icinga. The new Icinga team included:

Five days after the separation (May 6, 2009), Ethan finally got two programmers, and from that moment on he finally ceased to be the sole developer and responsible for the kernel code for Nagios. Andreas Ericsson and Ton Voon became members of the Nagios development team. [In the summer of 2012, Ton Woon left the project - pr. trans.] Ethan said: “The announcement of the new Nagios branch revealed some of the weaknesses of the Nagios project, which hampered its further evolution. Two of them consisted in the fact that I was the only developer and project manager. The time I could devote to the development of Nagios has recently become less. And the further, so it will be even less likely. And I will have to take on other responsibilities than to be a Nagios developer, and in order to accomplish this, I authorize other people to develop, and I myself will be engaged in architecture and acting as a mentor. And when the time comes for this, I will transfer these functions to someone else. ”

About the people who joined the kernel development team, Ethan says the following: “despite the fact that the Icinga project team claims the opposite, I was open enough to accept people in the project who want to help him. All that Icinga developers had to do to start participating in it was to offer their help. Andreas and Ton both offered their services and I gladly accepted their offer. This is how the community should work. ”

What about copyright and trademark issues?

As for the new branch, Ethan also points out a number of interesting facts about the registration of the Icinga trademark by Netways: “People who initially supported Icinga are not noticeable, but we immediately noticed that Netways acted when registering the icinga trademark very fast. We thought it was interesting enough, especially considering that they didn’t really stand on ceremony with the Nagios trademark, and in some cases behaved as if the laws regarding trademarks were completely unfamiliar to them. This was immediately after the facts of the transfer of dozens of domain names and the trademark registered in Germany to us became available to the public in social networks. I personally, and we, as a company, were forced to protect the Nagios trademark from improper use (especially commercial) for the past ten years and will continue to do so in order for the project to continue to exist. We found that most people who complain about problems with a trademark usually use the trademark themselves or work for companies that use the trademark for their own benefit. Our experience can serve as a good example of why each open source project needs a policy on its own brand and its protection from the very beginning of the project’s existence. ”

When I asked Michael, who actually “owns Icinga” what he thinks about this, he replied: “Good question! From the point of view of the conditions of the copying right, the right to it belongs to anyone who contributed his code to the project. Mostly owns Ethan Galstad himself, as well as the other people who contributed to the Nagios code. ” So the owners of the code are all those who were contributors - all their improvements belong to them, and even the new versions of Icinga are the result of their collective efforts for a long time.

According to Ethan, the real problem is not the copy right, but the trademark itself: the trademark Icinga, which is probably the most valuable asset since the code is free, is owned by Netways. Michael disagrees with this: “If we consider the Icinga team, then I don’t consider the Icinga trademark as the most valuable asset, the most valuable for us is the community of developers, contributors and users. Netways makes a significant administrative contribution, such as hosting a website, as well as providing a physical mailing address for formal procedures.
It also includes assistance in the current legal transfer of our activities to a special fund, or what we call here, in Germany, a registered association. Their assistance in managing the legal aspects of the project Icinga does not conflict with the development of our code. Everything that concerns trademarks does not interest us - we decided to focus our attention and devote maximum time to improving the functionality of Icinga. This support for PostgreSQL and Oracle, which the community has been asking for so long, user interface improvements, built-in reporting and just the development that our users can count on. The results speak for themselves and our users also talk about it .)

Consequences: Icinga and Nagios.

A year after the release of Icinga, the project team noted the ten-thousandth load of the application from their website, which they proudly spoke about in their press release, where they were happy to see success: having a reliable and understandable project roadmap, support for PostgreSQL and Oracle, presence of 16 active of contributors, the availability of Icinga in several languages, approval of the corporate sector, 1000 followers on Twitter and so on. A year later, the project felt great, despite the fact that the developers released separate versions of the kernel, API, and web applications. After 8 months, Icinga has a second version. In the announcement announcement was announced: The kernel, API and web application were unified and included simultaneous support for IPv6 / IPv4, optimized support for the database, a new web interface and integrated addons (PNP, LConf, Heatmap and BPA); over 70,000 downloads and 23 members.
The Icinga project team told me that Icinga is not Nagios plus its own web interface, but rather a framework. Indeed, most of the Icinga components are optional, so Icinga is like a toolbox. You can take Icinga Core + database (MySQL / PostgreSQL / Oracle) and you can add:


So in fact, Icinga offers more flexibility.

What about Nagios? Ethan writes: “We have attracted additional programmers to develop the kernel in the past few years to help us with bug fixes and new solutions in Nagios Core, NSCA, NRPE and also other new Nagios projects that we have released. For example, we developed a new PHP interface for Nagios (V-Shell), a new add-on for business logic (Nagios BPI), a new mobile interface (Nagios Mobile) and a new trap interface for SNMP (NSTI). We are also working on a new configuration web-interface. These are all open source projects that are developed by our company, both for use by our commercial partners and the growing Nagios community. Ethan continues: “The pace of development of Nagios has grown steadily since the first release in 1999, and undoubtedly improved further after we started commercial activities and got the opportunity to hire additional developers. Last year (in 2011) there were about six hundred (600) new projects that were developed and released for the community. There are currently thousands of free, open source add-ons for Nagios that extend its functionality and help meet the needs of many users. The flexibility of Nagios and its capabilities (both the product itself and the use of additional add-ons) were a major factor in the development of Nagios as an industrial standard for monitoring. ”

What about plugins? Are plugins designed for Icing compatible with those designed for Nagios? Fortunately, the location of the stars is extremely favorable. According to Michael: “All plugins that are designed for Nagios also work in Icinga and vice versa. Nagios Plugins Development Team is an independent development team that creates and maintains plugins for Nagios. Just like the configurations for Nagios, they are all compatible with Icinga - so the migration is very simple. Most Nagios add-ons work with Icinga's classic web interface unchanged, but with Icinga-web they need to be modified. This can be done in the form of a widget for an external addon with a simple xml snippet , although a little more programming is required for full functionality. And as already mentioned, a couple of addons are fully integrated - including BPM business process monitoring, created by Bernd Strøssenreuter, PNP4Nagios - Jörg Linge, Lconf - Yannis Mosshammer and my own Nagtrap. Here they can be regarded as quite "relatives."And we would like to see them even more, so we try to make the development process easier for creators of extensions by creating Icinga Web development guides , which also explain how to work with the DBMS work with the database and the REST API . On smartphones, several Android and iOS developers have created their applications , or made them compatible with Icinga. As Icinga is used more and more, we expect that more and more add-on developers will also join the project. ”

However, Ethan stipulates that compatibility is not always easy and explains: “Plugins can work with both Nagios Core and Icinga Core, but not all Nagios addons will work with Icinga, there are some extensions and additions that will only work with Nagios ".

Today

Today, the project Icinga has become a reality. Icinga developers have a good comparison of the bugs and features of Nagios and Icinga , so you can always understand where each project is located. Ethan’s comments on the above page are crucial: “This comparison on the wiki is inaccurate and distorted, as it contains incorrect information about errors and mixes them with the new functionality that has not yet been implemented. Obviously, this is done to make Nagios look worse than Icinga. ”

But when viewed from the point of view of code, there are interesting things. Michael writes about the possession of the code: “The original code was written by Etan Galstad, but the code falls under the GPL, which means that anyone can take the code, modify it and distribute it further. What the Icinga team did when starting a new project. My knowledge of the law is limited, so I cannot judge if there are any problems with copyright, and I doubt it just in case. ”

How about making money with Icinga? Michael says: “I personally do not make any money with Icinga and I have no such plans. Some of the Icinga team provide paid services and support. This is also important because many companies use Icinga or some other open source software, and would like to have a contact to solve possible problems. There is no intention to make Icinga or one of its components paid, either now or later. ”

As for the code, Ethan writes: “Although I own most of the core code, part of it belongs to the contributors. We have no plans for dual licensing of the kernel code, we are completely satisfied that it remains a free open source project that the community is developing. Our commercial efforts focus on other offers. Nagios XI - our commercial version of Nagios - is built on the core of the monitoring system and provides functions that long-time users of Nagios and those who are just starting to work with it are looking for - including integrated performance graphs, dashboards, advanced reports, configuration wizards, graphical interfaces for the web -configuration, visualization tools, detailed control of user rights and much more. We also offer support contracts,training and will soon offer official certification. ”

When I asked Ethan how he feels about the separation of projects, he spoke very bluntly: “It was sad to see some community members building relationships with Netways to launch Icinga. Despite the fact that they constantly talked about their separation from the slow development of Nagios, they never offered help in improving the Nagios project before deciding to separate. From my point of view, there should be no such things in open source software. But sometimes there is no blessing in disguise when situations like this happen. Most of the developers of Icinga (not related to Netways employees) left the project, besides the results of discussions with various community members show that they seem to have concerns about methodologieswhich were used in the project and its parent company - Netways. There are many forks of Nagios. Only some of them survived, most died within a short time. What distinguishes Nagios from all its clones is that people know about it, create systems based on it, and they trust it. We have not seen a single project that would even come close to the power of Nagios, if we count it in the number of community members and additions that our project has. This is what brings people to Nagios - a name you can trust. ”which would even come close to the power of Nagios, if we calculate it in the number of community members and additions that our project has. This is what brings people to Nagios - a name you can trust. ”which would even come close to the power of Nagios, if we calculate it in the number of community members and additions that our project has. This is what brings people to Nagios - a name you can trust. ”

It is obvious that Ethan is very proud of what he was able to achieve. He says, “Our statistics shows that there are over a million active Nagios installations around the world. While there are many derivative projects like Icing, people continue to choose Nagios among its competitors because of its long history of stability and development. ”

Michael and another part of the Icinga team sometimes get involved with the Nagios core development team: “We maintain contacts and exchange ideas. Sometimes more, sometimes less, although Ethan behaves quite quietly - he appears mostly in the mail lists among the developers. Especially when it comes to errors, etc. This can be seen from the list of comparison of errors and functionality, where we exchange patches. In my impression, the relationship is rather positive, which allows us to develop the code. ”

Future

When I asked Ethan about the future of Nagios, he wrote: “On the horizon of Nagios, a number of amazing things appeared. We are currently working on a new web configuration utility that will make the installation and configuration of nagios easier. We are already close to starting official certification for the levels of Nagios Professional and Nagios Administrator. About 40 new projects have been drawn on our office boards, to which the efforts of our developers in 2012 will be made. Projects cover a large number of needs of our commercial users and community members, including SNMP, Netflow, log file monitoring, incident management, visualization, and virtualization. We give user innovations a high level of significance and the things we are working on directly reflect the wishes of our users. Generally speaking,half of our work is devoted to work for commercial users, and the second is devoted to open source projects from which the entire community benefits. We believe that this is a wonderful way to manage our company. Based on the constant growth that we have around the world, we expect 2012 to be another record year for Nagios, with several hundred new projects released before the end of the year. Users can see how our new projects take shape by visiting ourthat 2012 will be another record year for Nagios, with several hundred new projects released before the end of the year. Users can see how our new projects take shape by visiting ourthat 2012 will be another record year for Nagios, with several hundred new projects released before the end of the year. Users can see how our new projects take shape by visiting ourDevelopers blog or periodically checking Nagios Exchange for new or modified projects that appear every week. Nagios remains the industry standard in monitoring because of its long history, flexible architecture, active community, broad support, and the thousands of free add-ons available to it. This is what makes Nagios a great product and community. ”

Regarding Icinga, Michael said:“ Having reached version 1.7, our team continues to implement the Icinga roadmap. We continue to work on such new properties as IcingaMQ - managing message queues for high-performance distributed monitoring, improved reporting, graph visualization tools and business monitoring tools. They all use the existing modular core structure of Icinga, the DBMS, the classic and the new Web UI, Icinga Reporting, Icinga Mobile, which, in combination with the extensions created in the community, form an enterprise solution fully compliant with the needs - free and 100% open. And when we look at 128,000 downloads for the moment and a growing community of users who share their impressions of the project, we are sure that we are on the right path of the leading open source project in the field of monitoring. ”

What does Ethan think about developing Icinga? He says, “Although Icinga still issues new releases, they have extremely high developer turnover in a relatively short history. I believe this may cause project problems in the distant future. Netways and the Icinga team had multiple violations of international intellectual property laws (including copyright and trademark rights), which significantly impaired them in terms of public perception. Many companies have tried to stay away from this project because of potential problems with the property. More information on trademark and IP issues is provided in an article on my blog.

Regarding the high turnover, Michael says: “At the time of the separation, our team was in the education phase, when we only worked out routes for our joint work. Many people wanted to enter the project and participate in it, both then and now. There will always be people who will no longer be able to devote time to the project and for some time they will leave the official team. That is why we have a six-month introductory program so that contributors can explore the internal structure of the project before they are announced as new official participants. We called it “Icinga Jedi Apprenticeship” so that it would not be taken too seriously. Two of our latest graduates and official team members recently released a new project Icinga Virtual Appliances , so we believe that we will successfully develop further.

Conclusion

Writing this article was a big challenge. It took me a few weeks to talk and exchange mail with Michael and Ethan. I still do not have a correct understanding of what happened, but in some cases a clear explanation does not clarify anything.

Sometimes, as they said: "It is difficult." And this is actually the case!

Tony Mobili, 2012, April.

Comments on the article


From translator

It would be strange that the article dealing with such a difficult topic of mutual relations between the two projects was left without the attention of the community members. I thought it worthwhile to include a discussion in this article, especially since the two participants (Olivier Jan and Michael Friedrich) were directly related to these events. Indeed, not everything is so simple.

dnsmichi ( ) 2012-04-27.


First of all - thanks for your hard work, that you told the story itself, and what was done on both sides.
The second, and why I am writing here is my own opinion. It does not reflect the opinion of the whole team or anyone else about the incident, so if you want to blame someone, then please - I'm here and listening, exactly as long as no one becomes personal. Just a few things about myself before I set out my own opinion. My name is Michael Friedrich, I live in Austria, and have been working on the Oracle NDOUtils project since April 2009. Before that, I was engaged in Nagios, but was not associated with any development in this area. And although I am a coder and hacker, I still continue to study in various fields.

Big fat remark: I DON'T SELL products somehow connected with Icinga and do not make money on this project.

When I heard about the creation of a new Icinga branch in early May, I tried to explore the question of how to return to the main project the NDOUtils Oracle tools that were available at that time (the predecessor left the project). I estimated my opportunities and chances and wrote to them, asking if there is a possibility to work with Oracle support in the Icinga project. At that time, I was not the original initiator of the project, and joined it on May 15, 2009, then there was still a lot of emotion about the separation and everything else ...

Reading the Nagios mailing lists of that time, it is already clear that the patches hang for a long time before committing, error discussions merge into / dev / null, and so on. So independent work on the code, and at the same time, transferring the developments to Nagios, from this point of view, was a good enough idea.

When Nagios opened up a bit, announcing a set of developers, it was a logical idea to join them. At least I talked to Hendrik Becker ((Hendrik Baecker), he later became the leading developer of NDOUtils, but after a while, unfortunately, left the monitoring community), I would be happy to join the NDOutils team, along the way developing IDOUtils. By doing things in a similar way, it would be possible to support Oracle from the very beginning in both projects.

Everything would be fine, but it would “hurt”. My proposal was rejected (as Hendrick told me), I did not have the opportunity to send patches to Nagios, nor to prove my coding abilities. In fact, this is a good answer, because it was true at the time: it seems they simply did not want anything. Yes, Nagios, [like Icinga] could also get support from Oracle DBMS, and a little later - in September 2009 and support from PostgreSQL, but everything happened differently. Although I never talked about offering Nagios help, I’ll come back to this a little later.

Regarding the change of participants in the development team and the lack of a stable basis. I read about this in various interviews of Ethan, and I think that the time has come to clarify something in this matter. I don't see a problem with a large team of free code enthusiasts who share the burden. Of course, project management is not so simple, but this is the path that all successful projects are following today.

The so-called “theater of one actor” has the right to exist, but if you fail once, then people will think the opposite. I'm not saying that organizing the kernel and add-ons section is a bad idea. Not at all, but such a project is a little more than just code. When users ask me what I want from the project, it’s quite normal that I get back, "... but I can't program in C or Perl." Yes, but in fact the matter is no longer in any particular language. Icinga is developing in so many directions that programming is still important, but does not add the last percent of the volume to the product that Icinga users like so much - and for free, since we are a growing community.

The documentation has been reworked into a docbook and fully translated into German - work on other languages ​​is also underway. While it takes a little more effort to write XML than HTML, it adds the ability to generate man pages and so on. The documentation itself is an important part of the project, so we keep it up to date.

Generating new ideas is not an easy thing if you are not actively working with user support. So there are always those who work on social networks on the team - they support Twitter, actively read mailing lists, filter feedback.icinga.org for new ideas, hang on IRC and help there, organize development on the tracker of developers, add articles on the wiki, write blog posts on interesting topics - in short, work for the community.

This work not only provides documentation or better quality wiki articles. Ideas are distributed over the network, sometimes brought in by nagios users who have shared their patches, or by Icinga users who also create their own patches. All this is carefully considered taking into account personal requirements, as well as work and friends. You will learn a lot just by reading the history of the development tracker, where programmers help each other, as well as expressing gratitude to users who have reported an error; it also discusses the changes and works on them. This is done in every release we release. I know this - since the release of 0.8.3, I was the release manager for some parts of the kernel. And I am also following version 1.7 - which was done this week (April 2012 - pr.perev.).

Our business was good enough, and indeed, Nagios also woke up. The new round of the project was not bad at all, since it’s good that two new valuable and respected people appeared in the team responsible for the core of Nagios - Ton Woon and Andreas Eriksson. Both did and do great work on the core code, just as Ethan did in those days when he was not all in business and trademark protection. Later, the releases of Nagios became full of errors and were not tested properly, which saddened me greatly. As I continue to support Nagios users, such thoughts come to my head more and more often (basically I have to learn from their problems and share this with the nagios and icinga users in the wiki, and even better - in the documentation).

I took it as the offensive of the freedom to dig into the Nagios code again, believing that Ethan and the project deserve "some gratitude." Not so often, but sometimes I found that my patches were taken. Some are still pending, especially for NDOUtils, if you look at the comparison of properties and available errors.

Well, I wrote it. You may ask - why? Basically, for the reason that a simple comparison does not show anything, each of the parties tries to be better than the other, and all just because people simply require comparison. I am not a supporter of such things, and when Nagios Enterprises decided to delete all its comparison tables from OpenNMS:

www.adventuresinoss.com/?p=2324
plus.google.com/114835305606981163109/posts/haB4ZWhE7az

... then I thought it was worth doing something besides summarizing the story. The article really does not concern everything that happened. Some things happen outside the public eye, and only insiders know what was childish behavior and what was not.

For example, the threat of Olivier Jean for talking about Icinga on nagios-fr.org and the requirements for the transfer of domains - this is why the French community Nagios died.

www.monitoring-fr.org/2010/02/accuse-nagios-fr-org-levez-vous

Of course, then there was also a ban on Shinken (rewritten by Nagios), deleting this system as an official idea with rank number 1 from ideas.nagios.org, and Jean Gabe’s threats (by Jean Gabes [author of Shinken - pr.perev.]) licensing.

www.shinken-monitoring.org/news/shinken-integration-into-nagios-wont-be-possible
sourceforge.net/mailarchive/forum.php?thread_name=4C20D2A8.9040502%40nagios.com&forum_name=shinken-devel

Some may recall the orgy of wikipedia editing that someone from Nagios Enterprises did, which led to a ban. Basically, this was due to the removal of references to Icinga and Shinken as branches of Nagios, while at the same time links were added to the commercial product Nagios XI (which is not free).

en.wikipedia.org/w/index.php?title=Nagios&action=history

Why did I add this? Because, I think that people should know the truth about what was happening then. The article also has a reference to the "truth about the brand." This topic is very complex and there are a lot of emotions in it, since Nagios already had problems in 2002, when it was also called Netsaint. But, in fact, I sincerely believe Julian when he talks about protecting the wrong behavior associated with the registration of the Nagios trademark in Germany. I also believe that this was mainly a political motivation to exert pressure on the owner of a company operating in the same sector - the sale of Nagios consulting, which was a clear competition. Everything that happened behind the scenes was (and should have been!) To remain closed. The fact is that I trust people who I like, and in this case they are on the attacked side of the story. So I first asked myself whether it was worth making it public.

community.nagios.org/2010/09/28/nagios-trademark-truth/http : //community.nagios.org/2010/10/25/nagios-trademark-victor/
www.netways.de/de/info/trademark

Even if it is presented in the form of “winning a trademark for a community,” then, as a member of the community, I wondered: “what the fuck do I need a trademark for?” But in any case, they returned their trademark and nagiosexchange. org, who then died. An add-on for business processes, too, because it is hosted on nagiosforge.org - this domain was also transferred to Nagios Enterprises. In this case, thanks for nothing, google rating is not a very good thing. By the way, the new url is here:

bp-addon.monitoringexchange.org

In fact, I later had the idea that NagiosQL is no longer a “specialized” product on nagiosexchange, because it is also supported by Icinga, the same thing happened with pnp4nagios over time. [What did Nagios have to do] add censorship to possible unwanted addons? Waste of energy.

Speaking of censorship, this means that I no longer have the opportunity to send mail to their mailing lists, perhaps due to the fact that I have spoken too often there about Icinga. Although, such a restriction saved me from wasting my free time on porting patches from Icinga to Nagios, and although I understand a lot of things in this hellish kitchen, this is not the worst.

The funniest part in talking about project branches is to create your own software license, which prohibits making derivatives from their code. So, the so-called Nagios Core Config Manager is a branch of the popular NagiosQL configurator, which is free to be developed and freely available. Or take Nagios SNMP Trap Receiver - this is a branch of the NagTrap project, which is developed by Michael Lübben (see the article above). Or Nagios Mobile - Teeny Nagios branch. As you can see, the real truth about derivatives is somewhere here. Perhaps it is also in the fact that someone else has succeeded with the things that you created.

Returning to the comparative matrix. I was absolutely not going to retell to people all the above, why a fork arose and so on, I just wanted to show what we really did. And yes, I made a comparison only for the error identifiers in Nagios, which I discovered. Most of them lit up either on the notorious nagios-portal.org or ideas.nagios.org, or were found on the web. And in fact, Icinga now looks better than Nagios. But my main idea was to share with the other side. The current state of Nagios SVN shows that this idea was not lost, as Eric Stanley commits Icinga patches to Nagios Core (without forgetting that dnsmichi / Michael Friedrich with both hands behind Icinga)

nagios.svn.sourceforge.net/viewvc/nagios/nagioscore/trunk/?view=log

It is also worth adding that if Andreas Erickson were not such a hero and enthusiast, the Nagios core code would have died long ago. Although the core of Nagios should be called the core of op5, considering commits and the time spent on it last year. Maybe I will change my mind and start sending patches from Icinga to Nagios after the release of version 1.7. In addition, I must have missed something in the entire history of Nagios from 1999 to 2009, and therefore my opinion about the story that has happened may differ.

Understand me correctly, I quite like the state of things, after everything has entered its rut. True, the last steps of Nagios Enterprises do not reinforce my belief that Nagios aims to work with its own community or with the OSS community.
In any case - I hope that everything that happened will be the last mention. For all involved the story has already ended.

And while the comparative matrix is ​​modified from time to time, we focus on real affairs. You can see what we do:

dev.icinga.org/projects/icinga-development/activity

I admit that I really like ohloh and gource for visualizing activity.

www.ohloh.net/p/icinga
www.icinga.org/2011/01/20/icinga-development-visualized-by-gource-revisite

Thank God, we have an active community Icinga, and most of the famous plug-ins and add-ons are compatible with Icinga. Sometimes in direct contact with the developers, and if necessary, with those who create packages, we extend grace. Perhaps there are add-ons that do not work with Icinga out of the box, but this is not a problem, stay with the community - I am sure that together we will be able to find a solution.

For those who do not like Icinga and those who prefer other forks of Nagios - Shinken, Centreon-Engine, Opsview - please go ahead! Competition is always good, but it is worth continuing to share information, as I do sometimes with Olivier Jan, regardless of whether it is C or Python.

Last but not least, Netways sponsors our servers and invests human resources in our project, just as other companies and those who support Icinga do. So now the open community works. I am happy that it does not look like a chaotic meeting, which is difficult to organize. All the available ways of working and subdomains are linked together as a whole and are designed to make the lives of users and developers easier, giving you the opportunity to focus on important things. And when we meet together - we always have time to drink some beer. So that Icinga is alive and well, and I, too, after three years. And you?

Comment dnsmichi (Michael Friedrich) from 2012-05-07. "As for the nagios patches ..."

I want to add one more thing. Not long ago, I sent a patch on behalf of the Icinga development team to the nagios developer list. This time on behalf of the team, because we made the patch together.

www.mail-archive.com/nagios-users@lists.sourceforge.net/msg37118.html

After a while, he was commited.

twitpic.com/9iicbj/full

Then Ethan Galstad “clarified” something in the change log:

nagios.svn.sourceforge.net/nagios/?rev=1936&view=rev
twitpic.com/9ii1zu/full

I can say nothing more, only: This is not the spirit of OSS, of which I would like to be a part. Goodbye, Nagios.

Tony's comment (Tony Mobili is the author of the original article) Wed, 2012-05-23. "Well...."

I can’t say anything about this, but what could it be, if not the application of a policy that claimed external additions require the presence of a “name” attached to it, so that they can make additions to the code, without any vague provisions!

Comment dnsmichi (Michael Friedrich) from 2012-05-07. "Good..."

Of course. This is a personal opinion and the right of everyone to have their own idea of ​​what happened. I somehow touched all of this, so excuse my attempts to shed light on this not very good story. I was shocked by the threats against nagios-portal.org, so there would be no explanation on my part. Thank you for your work and the opportunity to share my comments with the general public.

Comment dnsmichi (Michael Friedrich) from 2012-05-07. "Inglorious end"

Please note that the well-known site nagios-portal.org was blackmailed by Nagios LLC, which declared the presence of the trademark in the domain name. This portal is the largest platform in the world of Nagios and other monitoring systems, with more than 10,000 registered users and an active community among users and developers - plug-ins, add-ons and kernel components. The success of Nagios lives in the history of this portal ...

Because of this blackmail, the site has now moved to www.monitoring-portal.org so update your bookmarks. Let this community live and live!

All the best, Michael.

Comment by Tony Yarusso (Internet Technical Support Technician at TIES) dated 2012-04-27

It bothers me that Ethan still uses incorrect terminology in order to blacken Icinga. He insists that there was a “trademark violation” and “counterfeiting”, but in reality this was not the case. Ethan registered a trademark in the United States that had no international power, so the actions of Netways are absolutely legal. The reason that he got involved in this case by starting with a muddy PR campaign that plagued them and prevented them from getting domains and registering [trademarks] was because his lawyers knew that he was not able to act legally, so that they could not defend his interests in court. In addition, he declares that his company produces "tons of add-ons with open source", the reality, however, is that most of them were not released under an open source approved by the community, but for the most part have a private access license. In my opinion, this is not a level of honesty that inspires great confidence.

Comment by Renaud Hebert from 2012-05-07

Lawful! = Moral. Registering a trademark in a country existing in another country is definitely a bad idea, even if it is legal.

Olivier Jan (Catholic University of the West) 2012-04-27

« Nagios . ( ), ».

It is sad to see how such a bright developer like Ethan drops to such a lie. As usual, he presents himself as a good guy against the rest of the world who is trying to steal his property and his works from him, but we are not in American cinema and the truth is that everything is a little more complicated.

I have never had the desire to form a commercial structure related to Nagios in France. I have worked and continue to work in the company, and I am not going to start my own business on the basis of Nagios or something else. I do not feel in myself the abilities for this, as well as the lies that I just do not like in business.

At the time, I was trying to help spread Nagios in France (by writing the first bookin French about Nagios and having organized a French community, which is possibly also a violation of the trademark :). My numerous e-mails to Ethan, where I turned to him for help in organizing an active community around Nagios, here, in France, remained unanswered for about six months. Although the community in his head is apparently also a kind of business? Maybe this is what he called “train to work with us” :)

Could Ethan bring at least one piece of evidence in favor of what he says? Can he show at least one e-mail or something else that shows that he wanted to help us organize a commercial structure? No doubt not.

I changed the domain name from nagios-fr.org to monitoring-fr.org because Nagios asked me (and the entire French community behind me) to discuss only Nagios on the nagios-fr.org website and nothing more, and this is definitely not the case. what we wanted. That's all.There are not so many words for the final and nothing about eternity :)

(I signed with Michael Friedrich, asking him to comment on the current state of affairs - pr.perev.)

Michael Fridrich e-mail from 2013-02-25


Radical for the year nothing happened. Those who deal with Nagios are still porting Icinga patches (and do not reflect any changes in copying rights (when we declared our copying rights, my account was deleted from the tracker tracker.nagios.org). Someone might call it theft but it's worth it; I decided for myself to completely throw out any experiences on this issue, and focus exclusively on those things that help Icinga to become better. You can even check why this is so by reading my comments in the article nagios vs icinga: - that means enough. "

I try to stay away from the nagios community, being active only on monitoringexchange.org, where the two worlds intersect with each other. Somewhere in the future, the version of Nagios 4 will be released, but only the logic of checking, parsing configs, and the unfinished socket api will be rewritten; I regret the lack of major changes here; especially after the base of the main code remains the same porridge as it was ten years ago.

So we (the Icinga team) are now working on expanding the version 1.x tree (recent bug fixes for the kernel 1.8.4 and web version 1.8.2). On the latest OSMC, we announced version Icinga 2. We released the first signal version, and everything is going according to plan for the release of the second signal version Icinga 2.

www.icinga.org/2012/11/08/osmc-2012-slides-surprises
www.icinga.org/2012/10/25/icinga-2-v-0-0-1-released www.icinga.org/about/icinga2
dev.icinga.org/projects/i2/roadmap

Icinga

version 1.9 is planned for Release 25.4.2013, 1.10 will be released on OSMC 2013, where we plan to present the final version of Icinga 2.

Good luck to all!

Source: https://habr.com/ru/post/170751/

More articles:


All Articles