Neary: Rotten to the (Open) Core?

Part of the reason why pretty much every distribution has moved from syslog to rsyslog instead of syslog-ng.

Except that enterprise features migrate fairly rapidly into non-enterprise, and people do sometimes (not often) contribute features to non-enterprise which then go the other way.

syslog-ng's case is *much* more like what Artifex used to do with ghostscript.

First of all, I want to make it clear that I'm biased on the syslog-ng case, but still wanted to express my opinion here. I'm biased as I'm the primary author of syslog-ng.

I think syslog-ng is a completely different case from the one described by Neary. The GPL version is not crippleware, it was never published for marketing purposes only and for the majority of syslog-ng's existence only the Open Source stuff existed. The Premium Edition is only about 3 years old and syslog-ng started in 1998.

We never removed features from the OSE version, the Premium Edition only included _additional_ features, and a lot of those are already available in the OSE.

Some examples:
* TLS support (became available in 3.0, almost 2 years ago)
* SQL destination (became available in 2.1, 2.5 years ago)
* performance improvements (3.0)
* etc.

In the other direction, we usually receive bugfixes and it is a pure technical reason that we used to require copyright assignment: I wanted to keep the two branches as close as possible (which if not done is the reason #1 why Open Core products become crippleware fast). _And_ since we heavily invested in automatic testing and our customers report bugs directly to us, we fix way more bugs in the OSE version than the community.

But anyway, I didn't think that the dual license model was so problematic at the time we made this decision 3 years ago. Our efforts have never been "Rotten to the Open Core". If you don't believe that, check out the git repository or read the mailing list archive and see it yourself.

And this whole mess is the past, OSE 3.2 has been relicensed, and it is true that we're going to publish non-free plugins, but anyone else is welcome to join and do the same.

Bit of self contradiction there. There is no legal basis whatsoever for complaining about it if companies called themselves Free software companies. If the community can discourage one, it can discourage the other as well. Why do you believe that "Free software companies" have a objective meaning but not "open source companies" I doubt everyone has a single definition for either in mind. It affects customers, community and companies which genuinely are in the business where free and open source software is key.

I don't even mind the proprietary fork, except that the next step is always to prevent the opensource version from gaining some of the features that the proprietary version has to protect the company income.

That model as such might be OK in theory, but in practice there often seem to be several problems:

- The "GPL" version as it's often called (it's usually GPL) is marketed as some sort of demo. This on its own will create resentment, and will stop many people from even considering looking at your software. Selling additional propriteray components is fine, (subtly) trying to imply that the GPL version is somehow inferior is insulting to the people who worked to make the GPL ecosystem great.

- What happens to outside contributions? Will you refuse a patch because it reimplements a proprietary feature? If so, prepare for some bad feelings.

- If these companies accept outside contributions at all, they usually require some sort of copyright assignment or unlimited rights to use the contributions in the proprietary version. The outside contributor often does *not* receive the right to also sell a proprietary version. This is fundamentally asymmetrical, and enough reason for many people (including myself) to not work on this software. (aside: I don't necessarily *want* to release my own proprietary version, I just want equal rights for equal effort. If you don't expect (at least) equal effort from the community in the long term, why do you even want this community?). Using a BSD style license would solve this of course, but one gets the feeling that this was a deliberate choice.

There are a number of advantages people have in mind with respect to "Open Source" or "Free Software". One of them is independence of the vendor. If Oracle goes down, or loses interest in OpenSSO, someone can take over. If Sun/Oracle has slightly conflictling business interests with Novell, the latter can maintain its own semi-fork of OpenOffice.org.

Will the users of the software be indeed independent of you?

If you retain vendor lock-in, then maybe it is a bit misleading to call the resulting product "Free Software / Open Source". "Inexpensive" is an expected by-product of the lack of vendor lock-in (in most cases), and not the other way around.

I think that, in order to have an "open core", you really have to have a "core" as an entity. If you do, it's perfectly reasonable to have proprietary plugins, and there aren't the same conflicts over whether you'd accept contributions that would compete with them, because it would be a layering violation to accept plugins in the core. Open source plugins, whether or not they compete with proprietary offerings, are a separate project from either the core or the proprietary plugins, in much the same way that mod_python is separate from apache.

The issue is that a lot of companies seem to be claiming an open core when they don't have a division between a core and non-core in the first place, but rather have a single project with more and less functionality in branches. This puts the maintainer in a conflict of interest, rather than cooperating on one front while competing on a different front. It only makes sense to make something open source when you and the community would both be motivated to make the part you share as complete as possible within the scope of that part.