Firstly, thank you for the complete, well researched, well thought out response. Too often I see arguments in which neither side is willing to attempt to truly understand the other, and I don't believe that is the case here. Balabit is just now entering the discussion that two other large, open-source projects underwent a few years ago: MySQL and Snort. MySQL's A/B model made many angry, but it's been years now and I'm now glad that it happened because it's easy to pitch open-source to management when you can say that it's supported by a company (especially a big one). It's possible that MySQL development has suffered because of the new "corporate overlords," but I have no evidence to show for that, and I think that would be difficult to prove. I think that Balabit's new plugin system for Syslog-NG very closely mirrors what Sourcefire has done with Snort. A few years ago they moved to "shared object rules" which are binary plugins for detection. They did this for a number of reasons, but the primary reason was that Microsoft was not willing to let them publish the IDS rules which detect exploits against Microsoft vulnerabilities in an open-source format due to trade secrets, etc. So, Sourcefire had to make a decision: did they release rules fully open but imperfect, and weeks behind when vulnerabilities were discovered, or did they publish these closed-source rules in a timely fashion? They opted for the closed-source rules which compliment their open-source offerings. As an IDS customer, this was good in that I got good rules and quickly, but bad in that I could no longer inspect the rules myself to see what they were hitting on. That's a critical part of tuning an IDS, so that was a real blow. The outcry from Sourcefire's decision was enough to spur the creation of the OISF Suricata IDS project. However, unlike Balabit, Sourcefire had originally created Snort as completely open-source, so having any closed-source at all was completely new. Balabit has always had some closed-source, so this really shouldn't be a new thing. What this boils down to for me is what Balabit decides to release as a closed-source plugin, and not the fact that there are closed-source plugins. I'm not worried because I know that the competition from rsyslog will ensure that if Syslog-NG becomes too closed, users will migrate over to rsyslog. This is what will continue to drive innovation and continue to bring us great features like the patterndb. --Martin On Sat, Aug 14, 2010 at 1:46 AM, Balazs Scheidler <bazsi@balabit.hu> wrote:

Hi,

since the email gateway from my new blog doesn't work yet, I copy this post to the list, as again this is an important topic.

As you may have seen in my last post, syslog-ng was quoted as an example of "open core" development model, which has problems in the eyes of some Open Source purists. I was trying to do my homework and understand their point of view and see what we can do about it. If you are interested, you can read these articles:

     * Dave Neary's Rotten to the Open Core      * Simon Philip's Open Core is Bad For You      * Henrik Ingo's So if I don't call myself 'open source vendor',        then everything is fine? (yes)

People who know me either personally or through the syslog-ng mailing list would probably know that I by no means want to publish something substandard or cripple the syslog-ng open source functionality in any way. I wanted to start with this statement as the way I see there's only a small and subtle difference between an "open core" and a "true open source" project. I'd like to explain why I feel that syslog-ng is still a "true open source" project.

The most to the point explanation why "open core" is bad I saw thus far was: "The question this boild down to is: Does the Open Source version exist because it’s a nice selling point or does it exist because someone believes in the values of Free Software?" [link]

I'd say that both is true for BalaBit: we do believe on Free Software and we do publish a lot of that, outside syslog-ng as well (our TProxy work was integrated in kernel 2.6.28, various libdbi/dbi-drivers patches, iptables-utils, jailer, restrict and a couple of others, read this page for more). Some of these are more successful, others less so, but I guess the same applies to other free software hackers too.

So why I think there's only a subtle difference between an "open core" and "true open source" development? Because at the fact-side, they look _very_ similar. Some quoted "true open source" projects (Apache, rsyslog, JBoss, Tomcat) and probably others support commercial development on top of them: their "core" license is compatible with commercial licenses (either LGPL or something else). The difference seems to be the very existance of a commercial offering from the same author.

So while syslog-ng 3.2 will have the same licensing structure as rsyslog, some still say that syslog-ng is not a true open source project. Again, the root cause for that is the existence of the syslog-ng Premium Edition package. I was trying to understand the logic behind this stance and came up with the following list of reasons (not necessarily applying to syslog-ng, but more on that later):

     * with "open core" development, products usually fork the Open        Source part of the project for their internal development and        the flow of bugfixes and features on the open source portion        happens in a closed way as a code dump      * the development is driven by the commercial edition, changes are        trickling to the OSE version with a delay      * because of this setup, the community has no say in the features        or in the way those features are developed      * because of this setup & without extra effort the open core part        can quickly deteriorate      * the neglection of the open source portion can go as far as being        completely unusable (that's why the word crippleware)      * this process may not be visible right from the start, Open Core        development may look like a true open source at first, but this        can happen with time, effectively pushing users to pay money        when the OSE version deteriorates and the replacement of a core        component of a system would be more expensive      * when a competing open source solution is contributed, such a        contribution is not accepted into the upstream project, because        that would compete with the commercial edition.

The way I see it, the line between "open core" / "true open source" is very thin and also difficult to judge for an outsider. These are the reasons why I think that although syslog-ng does have a commercial edition, it is still an open source project.

Code base fork

Right now the code base for the OSE/PE editions are in different repositories. However one reason of the licensing change in 3.2 is to eliminate this and use the same core in both the PE and the OSE editions.

It must also be added, that the current setup was created because of community needs: in the early days, only a single, internal repository was used and the OSE edition was exported as a tarball every night as a snapshot. As the lack of a real version control system was a problem for the community we came to the currently used setup: two git trees, patches synchronized between them. This is of course much more work, but we volunteered to do that.

Development drive

Right now, the development on syslog-ng happens in three parallel teams. They each create original work. These are:

     * the syslog-ng Store Box team,      * the syslog-ng Premium Edition team and      * the Open Source team.

The method used to synchronize work is as follows:

     * bugfixes are done in the code base the bug report is coming from      * bugfixes in parallel branches are synced as the first task of        every maintenance release

This means that it is true, that with PE related features OSE is behind, but this is also symmetric: OSE developed features take their time to propagate into the Premium Edition.

One noteworthy thing is that there are several people inside BalaBit who contribute their free time to syslog-ng development, you can find their git trees on git.balabit.hu.

And the features in the OSE edition are not worthless, they are really important in the future of syslog-ng. Some examples:

     * db-parser to parse log messages (in 3.0)      * change from syslog-only implementation to a syslog-independent        one (nvtable in 3.1)      * the new plugin architecture (in 3.2)      * syslog-ng configuration library (in 3.2)      * first support to non-syslog messages (3.2)      * and so on.

Community involvement in development decisions

Well, this is a though question. syslog-ng may not attract that many contributors or I myself suck at this, but it has nothing to do with the current PE/OSE division. Even if I was directly asking, I received only little feedback and this was in no way different in the first 8 years (1998-2006) of syslog-ng when there was no commercial fork. In fact, the community seems to be more active these days.

But anyway, since I myself develop the OSE version and it is out in the open (as the git history and my blog posts prove), the community would have a chance, at least in the features that BalaBit itself has chosen to implement. Also, small feature requests on the mailing list are quite rapidly implemented (the last thing I remember from the last couple of weeks is the "condition()" option to rewrite expressions).

With the current architecture/license change, I plan to go back and seek for contributors who didn't want to sign the CLA whether they'd be interested in contributing their code as a plugin, or perhaps directly into syslog-ng.

Open Core deterioration

I myself worked very hard for this not to happen, and if you look at the mailing list archive, a lot of this time actually was spent from my free time.

Since the project/release overhead of a fix is smaller in the case of the Open Source development, it quite often happened that the fix was first made available as a git commit in the OSE branch. Then integrated tested and released in the Premium Edition as well with a slight delay.

Forcing users to use the Premium Edition

I always said and I believe that the Open Source Edition is a full featured syslog implementation. I'd say nothing proves my word better than that it became and was proposed as the default syslog implementation of various distributions. The existance of the Premium branch even created further features in the OSE, which may or may not have happened without that.

It is perfectly acceptable for us, that someone will stick to the Open Source edition. We work hard to update syslog-ng packages in distributions to its latest version, even though that competes with our commercial offering.

So I wouldn't say we force them, not on the feature and neither on the quality side of things. The Premium Edition offsers the following added value compared to the Open Source Edition:

     * support for a wide variety of Opearing System and CPU        combinations (about 27 right now, but about 10 new combinations        are in the pipeline for 4.0)      * longer support cycles      * support services      * maintenance & bugfixes      * .... and additional features.

Right now, our feeling is that the additional features is a selling point and without it, we'd be earning less money. With less money, we could allocate less time for syslog-ng. And I'm sure that'd affect syslog-ng, both Open Source and Premium Editions negatively.

Competing features

One more complaint against the "Open Core" business model is that there's a conflict of interest on the maintainer of the Open Source portion whenever the community is contributing a feature that is present in the commercial edition.

The way I see it and with the advent of the new plugin based architecture, this is not necessarily a problem, since a plugin doesn't have to be distributed with the main distribution tarball. In fact I expect several plugins that wouldn't be added to the distribution. For example gyp's Twitter destination is a nice hack, but I probably wouldn't include it. Also, a Linux distribution is in the position that a plugin/functionality can easily reach much more users than the syslog-ng packages that we ourselves publish.

But anyway, once a feature is in the scope of syslog-ng (and being a feature in the commercial edition certainly proves that point) and a working implementation is contributed on the syslog-ng mailing list, then I hereby state that we are willing to include it in the main syslog-ng distribution. Of course technical and quality issues do still apply, but if there's enough support from the community (e.g. on the syslog-ng mailing list) and if at least the plugin names are different from the commercial edition (this is purely a technical reason to make the maintenance feasible and user confusion low).

Since I feel that this topic is one of the strongest arguments against the "freeness" of syslog-ng, but with the above statements we are at the same level as any other projects "true open source project": you need to take our word for it. I hope that with this post and with our last 12 years of open source work, we earned this trust. And if we don't keep this promise we can be blamed.

But until that happens, please don't judge syslog-ng's freeness.

Conclusion

I agree that trying to balance between the Open Source and Premium Editions of syslog-ng is a difficult task, one that requires a lot of work too. We may have made some mistakes, but our intention is clear: OSE is an independent entity, standing on its own feet.

I hope this blog post clears up some of the confusion around this.

PS: Thanks for reading until this far.

-- Bazsi

______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.campin.net/syslog-ng/faq.html