Bazsi's blog

I got some interesting comments in a forum posting, outlining a perception how syslog-ng’s development is driven by BalaBit. The original post is here, but the interesting quote I’d like to react is this:

@all Some general points:
A main difference between rsyslog and syslog-ng is that syslog-ng is backed by a large commercial organisation and a commercial fork of syslog-ng. This is not necessarily bad. But it is a difference to how rsyslog is driven: I get some funding for rsyslog development from Adiscon, but Adiscon is much, much smaller. So rsyslog is more of a community project. I have to admit that we at Adiscon still hope to find some commercial funding, e.g. via support contracts or custom development. But we do have far less of the traditional commercial machinery behind that (maybe it would be better we had, at least for me ).

[...]

To sum up: both rsyslog and syslog-ng are quite good implementations, each with their own strength. I think the main difference is the process in which they are created (more commercial-focus vs. community/technology-focus).

This is an interesting perspective, although as you may imagine doesn’t match my own idea how things work. But probably many of my reasons are not visible from the outside, thus this post. I hope to shed some light on how syslog-ng development is being done, maybe that’ll help you understand the situation better.

BalaBit may be larger than Adiscon, but syslog-ng development has never been its primary focus. syslog-ng was represented differently in the company for a long time: it was my hobby. Later on, we’ve received so many development requests and support queries that we’ve decided to build a product that is not simply a game (and responsibility) of one single guy, and thus Premium Edition was born. The way we’ve carried that out could have been done better, but I think this was discussed well enough in earlier posts. (here, and here). I think we’ve addressed most of the concerns in this area with the change in licensing, dropping the requirement for copyright assignment and so on.

Today, there’s a development team inside BalaBit, which delivers Premium Edition to paying customers, and there’s me and a couple of other guys in the company, who are not members of that team, but still want to work on syslog-ng. Since we fulfill other roles, in work-time we are not working on syslog-ng, but in our free-time (and coffee breaks we can talk, extend and work on syslog-ng hand-in-hand with the community.

That’s how syslog-ng is driven.

This means that the Open Source and the Premium editions are on a different track, features/bugfixes may be present in one, and not-present in the other. This would be quite cumbersome to maintain, thus from time-to-time we synchronize them up. That’s when features go to the OSE version or vice-versa.

The point is that syslog-ng Open Source Edition is independent from the Premium Edition, different people are doing it, with a different motivation. The OSE version in our case is not a bait for people to buy the Premium Edition, you can be a happy OSE user and be completely satisfied, or you can be a PE user if you need the backing services. It’s up to you.

The motivation for customers to buy syslog-ng Premium Edition is the professional support, the predictable release schedule, the number of platforms it realiable runs (and gets tested) on, the installation packages and the fact that you can actually have legal assurances that a piece of your infrastructure works, and there’s someone to blame and turn to if it doesn’t. Also, the PE team does a thorough testing on functionality coming from the OSE branch, not because it’d be done badly on purpose, but people usually focus to different things when they implement a functionality in an open source setting.

I don’t see the big difference between syslog-ng and rsyslog in the way it is driven. In fact Rainer is in about the same position at Adiscon, as I’m at BalaBit.