Hacker News Reader

Comment by nightfly | Hacker News Reader

Projects that follow the "open core" model bother me when they gate useful features behind their paid version like Gitlab does. My organization would benefit from the "Rebase merge requests before merge" and "Use fast-forward merges when possible" features quite a bit, and we are an in educational environment with lots of volunteers so using the Enterprise edition isn't viable at all. These features aren't technically difficult to implement, but even if we wrote open source versions of them we'd have to carry our own internal fork of Gitlab since there is no chance upstream would accept them since they've already decided they don't /want/ those features in the "community" edition.

View on HN

> Projects that follow the "open core" model bother me when they gate useful features behind their paid version like Gitlab does.

I understand that criticism, but what else would you gate except useful features? The entire point of this style of sales is to enable a "freemium" model with highly valuable features locked behind the pay-gate.

In the parent's defense, the two features listed aren't really what I think of when I think of "enterprise" features. I think more of things like SAML and Active Directory integration, auditing, etc.

Sure, but that's essentially a branding criticism (labeling them "enterprise" features) rather than a criticism of the "open core" model.

This isn't really the "open core" model if the core is not actually open. GP would like to contribute these features themselves to the open core but GitLab likely would not allow it.

I don't agree with this assessment. Open Source does not require that the maintainers will allow you to push changes upstream that they don't like. Is AOSP not open source? Chromium? Atom? Linux? Linus rejects a lot of stuff.

Now, it may be poor stewardship if valuable changes are rejected, but Open Source is about your freedom with the code, not the willingness of the project maintainers to commit your pet features.

But absolutely nothing is preventing you from using a a fork of CE which adds every EE feature so long as they were developed independently of the closed-source EE code-base.

Open source doesn't mean the maintainers have to accept your patches.

My personal take on the open core model is that I'm generally in favour with it, so long as the paid features are significant and make sense to be paid features. Like, the two features the parent are asking for could be added by an open-source contributor in an afternoon. Removing them from the CE edition and only including them in the paid version just feels like picking and choosing things to include or not include.

An open core model done well is great. This doesn't seem to be an instance of that :)

Alfresco does this as well, and they removed things that worked in the community edition, like clustering, requiring people either switch to the EE version or implement the missing/removed features themselves as a plugin or fork.

TypeSafe/LightBend removed a fully functional MS SQL implementation from Slick.

I've written about this type of split in OSS software and what it means for developers:

https://penguindreams.org/blog/the-philosophy-of-open-source...

That seems to be part of the $4 / mo / user subscription. A server to self-host costs $100-$500 / mo, so it doesn't seem like an impossible obstacle with < 100 users.

What fee structure would work for you? Maybe per-installation or per-repo?

I am genuinly curious about your view, so please be patient with me when answering.

The way I see it, someone is providing a free product and is maintaining it. They are even doing (imho) a great job. Of course, that costs money - and we only need to look at other opensource solutions to see what kind of UX they have if the creators are only charging for support.

So the options I see are:

  - have a worse product, but truly opensource
  - have a great product, fully opensource, but some features will never be added

If you develop the missing features, you would need to maintain a clone. You could do it if you really wanted to, it would take a lot less work than developing the whole solution from stratch. But - and this distinction is important for me - if the company ever went under or, worse, got sold to Oracle, community would almost surely take the CE sources, add those features and maintain a clone. At least for a while...

In my view GitLab is a perfect example how to make a sustainable business around opensource core. So the question is - can you think of a better sustainable business model to support development of opensource solution?

   we'd have to carry our own internal fork of Gitlab

So you have the choice between buying Gitlab or coding yourself. You would prefer it to be free and without hassle, but lack to see everything has a cost.

That's not OP's main point. It's that even if they implement it (as in a clean room), there is no chance of it being merged upstream. Now, if the OP implements some entirely different feature not related to gitlab's pricing, it can be merged upstream in the CE. This is in contrast to conventional open source projects.

uh, a lot of patches to open source get rejected for all kinds of reasons, incl code quality, being off topic or just because the maintainers (irrationally) dislike the patches.

GNU emacs (or more specically RMS) rejected patches that would integrate clang, or provided colorful emoji support on OSX, for political reasons, and that's perfectly fine for a project to do.

Gitlab will reject some patches for business political reasons, which is also perfectly fine.

If you don't like that, fork. If a lot of people don't like it, then the fork becomes effectively the new upstream (e.g. GCC/ecgs).

There is no "Right to have my patch merged" anyway.

The incentives are really not aligned here. Over time it's likely more features will be removed from or never added to CE. Gitlab provides only a very basic plugin system [1] so that nobody else can provide these basic features into CE. (Instead users are encouraged to contribute back to CE.) So, yes, the only option is "fork and fuck off." I don't predict a happy future for users of GitLab CE.

[1] https://docs.gitlab.com/ee/administration/plugins.html

> if we wrote open source versions of them we'd have to carry our own internal fork of Gitlab since there is no chance upstream would accept them since they've already decided they don't /want/ those features in the "community" edition.

This has come up in the past; they've stated that this hasn't happened yet, and that they wouldn't outright reject it, but would have to consider the situation.

So you might want to give it a try.

Check out the issue list on gitlab-ce and see if anyone has requested it come to CE. They may have other reasons or they may bring it over if enough people ask. I've seen threads on HN where they've agreed to bring something over from EE because someone was asking about it so they definitely are happy to do that where it makes sense.

I'm not familiar; are the features you mentioned new and perhaps not "ready" or ported to Gitlab OSS? But if they're older features in "proprietary" Gitlab then I'd have to agree.

Edit: a bit off topic, but why do you want "Rebase merge requests before merge" - wouldn't `s/merge/testing/` be much more useful?

Reply on news.ycombinator.com