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