This was a question I received back from Anton Chuvakin when I asked a number of folks which features they wanted to see in rsyslog. If I could answer that question, he would reply with further details.
Actually, I think that was a very smart reply. It comes down to “why should anybody care about rsyslog at all?”. Aren’t there already enough syslogds? An interesting question.
At first, I was tempted to answer that question by talking about features, all those things that rsyslog will do to rule the world. But – does this answer the question? Nope, it doesn’t. Next, I thought to write about my goals with rsyslog. Why do I do all this work, just to create another free GPLed application. But, again, does this answer why the world needs another syslogd? Oops… no, it doesn’t. Its not about me, but about the world, that’s you, folks. So why do you need another syslogd…
Let’s look. The world is somewhat divided. In this little corner sits Windows, and in the other there is the *nix community (Linux included). There are also some other corners, but I think I can simply ignore them for the time being. Well, I think I can even ignore the Windows world, as rsyslog is not meant to play there. I could answer why the world needed WinSyslog, which I designed over 10 years ago (to be the first syslogd ever on that platform). But besides showing dad is proud of his kid, that will lead us to nowhere.
So let me re-phrase the question a little bit: “why does the *nix world need another syslogd?”
That world uses either
I have bluntly combined all other syslogds (including rsyslog) to “another solution” simply because not a single one of them has enough market share/popularity to be a major player. Face it: the *nix world currently explores two choices when it comes to syslogd. Two big choices seems to be healthy. The bad thing, however, is that stock syslogd has not been notably enhanced in the past years. Syslog-ng was the answer to this problem around ’98 (if I remember correcty), and the situation has not much improved since then. In fact, users complain more and more about the featureless stock solution and Linux distributors have begun to look for alternatives.
So in technically sound, feature-rich and widely-deployed solutions we are down to one: syslog-ng. A monoculture always scares me a bit, even if it is with open source software. So one why the world needs another syslogd is to have more choices.
OK, the smart reader will now ask, “but why haven’t you joined forces with some of the other projects? Why a new one?”. Again, smart questions. Now I need to talk a bit about Rainer, because it has a lot to do with Rainer (and not you, the world ;)). I looked around at the various syslogd projects. To be honest, I tried the easy to find ones. Many of these projects had fine code. But in one way or the other, they didn’t look like the right platform for me to start with. From day one, I thought about creating something that in the long term can become a default syslogd (yes, folks, I *am* arrogant at times and my self-confidence is, ummm, not under-developed ;-]). So I didn’t like to start from something that receives low attention and has a small installed base. And so did I start from scratch? NOT AT ALL! I may be a bit too self-confident, but I am not a fool ;) I started with sysklogd, the stock syslogd on most Linuxes! That was a natural choice. What could better be targeted to becoming the default syslogd … than itself.
I tried to extend the sysklogd project. However, I quickly realized that this project’s focus was much more on stability than on new features. The maintainers were not very eager to accept substantial changes (and I can not complain about this, given the magnitude of what I intended to do). So I did the natural thing: I forked rsyslog from sysklogd. And, oops, now the world had another syslogd.
But now back from Rainer to you, the world. Why should you need another one.
By now, you probably know that rsyslog aims at becoming one of the major players. And yes, it will even challenge syslog-ng (and I am proud to say that this has already begun, at least in respect to some features exclusively seen in rsyslog).
So one reason the world needs another syslogd is that it needs another major player in the *nix space. I honestly believe there is none except syslog-ng.
OK, so then we are back to “why is syslog-ng not enough”? Do you think my “I need choices” argument is lame? Ok, ok, then I have some real meat for you: have you noticed that syslog-ng has become dual-licensed? There is the great GPLed open source release and the even greater “Premium Edition”, which cost money. Only the premium edition offers features like native database and SSL support or queued syslog sending.
I do not bash Balabit (maker of syslog-ng) for this movement. A project needs funding and it seems only natural that some of funding should be provided by those that gain benefits from it. I have to admit that the long-term funding of rsyslog of course is under review, but I sincerely hope that we can get away with staying GPLed open source all the time (and I can guarantee this will be the case for the foreseeable future including the glory 3.0 release which will really try world domination … feature-wise, of course).
Do you think Balabit will include the premium features into the GPLed version? I’d say that’s highly unlikely – after all, why did they create two editions in the first place. So the GPLed version will become a second-class citizen and the really cool things will go into the premium edition.
“Stop”, I hear some say, “syslog-ng is GPLed, so we can take that source and implement the missing features”. Of course you can. But do you think Balabit will actually include your patches? I guess we can agree on “nope”. So you have just forked from syslog-ng … and proved my argument that the world needs another syslogd (this time your syslog-ng fork ;-]).
As I side-note, I’d consider such a syslog-ng fork unfair and at least somewhat unethical. Balabit has served the community very well and continues to do so. They are not the kingdom of evil. As such, we should respect their voiced intention and not circumvent what they have done to provide proper funding for their project. Of course, you may have a different opinion, but such a fork would definitely be against my code of ethics. I won’t do such a thing and hope others won’t do it, too (except, of course, for a *very* good reason, e.g. no further development by Balabit or Balabit turning into something like SCO – which I do not expect).
As you can see, GPL syslog-ng will possibly not be at the (b)leading edge of syslog technology anymore. I may be wrong here, but the current state of the project points into that direction.
Competition with another major player may even help to get more of the cool features into the GPLed fork of syslog-ng. This is a key thing: if there are competing projects, each of them benefits. The strong competition of syslog-vendors in the Windows space (yes folks, there *is* competition and Microsoft has not yet joined in it…) has created much better products. I assume that two *strong* competitors in the *nix workspace can do a similar thing over there. The end result will be much better than what we have today (which is admittedly not bad with syslog-ng and rsyslog in their current releases).
So – why does the world need another syslogd? It needs one that aims to be a real major player, being installed on a lot of systems. That will help to get the best out of syslog technology (and in the long term the best of logging at all). Either in its project itself of by driving competitors to be better than it. A new major player will prevent monocultures and provide a rich freedom of choice. That’s why the world needs it.
Rsyslog tries to live up to that challenge. Of course, it is not sure if it succeeds. But should we try only things we know for sure to be successful? I don’t think so – if mankind followed that maxime, we’d probably still be sitting on trees hunting for bananas. As a side note, the critical path for rsyslog will not be features or developer commitment. What is critical is you – critical is whether or not we can manage to build a community around it. And that, too, looks pretty well these days…