[syslog-ng] syslog-ng & open core, why we think it is different

[Martin Holste]

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 at 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
>
>