[lxn]

Relevant is subjective. Merge request approval is not something a single contributor needs for example.

You can still get it by paying for it. In the end GitLab is a business, someone needs to pay something. As developer who runs a GitLab server for personal projects I don't miss any paid features.

[Carpetsmoker]

Rather makes sense, because for many open source projects with a single or handful or contributors it's not a very important feature, but for larger teams (i.e. companies) it is, which ensures they pay their fair share while still keeping the product available for free for most of us.

[m4rtink]

Still, having any features that are propritary and thus off-limits to contributors does not create a good community atmosphere.

Say as an example that Debian, which has a big user of GitLab wanted this feature, so the Debian project contributors create all the patches & submit them for inclusion in the open source part of GitLab. Normally, a project would welcome any (presumably) well written patches like this. But with open core project this creates an instant conflict of interest.

Either GitLab takes such patches, loosing their proprietary edition exclusive feature & possibly even compatibility with their closed source implementation of it. Or they reject the patches, presumably loosing a lot of goodwill with the community and forcing Debian to maintain those patches for ever in their own fork of GitLab.

All in all, I don't see open core companies like something to invest ones contributor time to due to this & more importantly like something to use and make you open source project to depend on.

[Carpetsmoker]

The alternative is GitLab not being able to hire developers to actually build GitLab since the "kindly ask to please pay"-model doesn't really work very well.

"The community" is often vastly overrated anyway IMHO. Patches are always good, of course, but people who actually consistently invest time in a project are exceedingly rare. You can't build a product based on sporadic patches. Besides, a lot of the time "the community" is just users (people with no contributions) complaining you're not doing stuff right.

Unless you have a viable (preferable proven) model that allows GitLab to hire developers and keep everything 100% open source, it seems to me this is the best and most balanced option. To the best of my knowledge, such a model doesn't really exist.

I continue to be surprised at the hesitancy (or even outright hostility) whenever someone tries to make an economically viable open source product, which usually involves things not being 100% open source because turns out, that's the only way to make things viable. "90% open source" is a hell of a lot better than 0% open source in my book.

[cycloptic]

The oldest viable and proven business model where you can keep 100% open source, is to sell support contracts and warranties. This model is harder for your average SaaS company to pull off but provides much better ROI if you can actually do it.

[Carpetsmoker]

It only works well if you have a decent amount of large enterprise customers (like RedHat); I don't think it will work out well for GitLab, which is mostly aimed at small-to-medium businesses. I don't think it's viable for most projects (otherwise they would be using it).

Even if it is viable, you're usually leaving a lot of money on the table, and even Red Hat – the poster child of this model – does stuff like releasing updates to paying customers first.

[cycloptic]

You are always leaving money on the table. The choice of business model is only a decision of whose table you are going to leave it on. The downsides of the open core model have already been mentioned here. I am not suggesting that GitLab change their business model, I don't have any opinion about what they should do. But I will say that releasing updates to paying customers first is still consistent with being 100% open source, as long as those updates are still released to them under an open source license.

[rpaik]

Everyone can actually contribute to both GitLab Community and Enterprise Editions. This query will actually show you a partial list of Community Contributions to EE that have already been merged: https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=...

The Enterprise Edition is under a different license but the source code is open and available to everyone.

[cycloptic]

Just a request, can you please not say "the source is open" without clarification? That seems to imply it's open source when it actually isn't, and the "different license" is actually a proprietary license. A more accurate way to say it would be "the source code is available to the public, but with some proprietary restrictions" or something like that. Otherwise you will just have to clarify later and you risk leading into nonsensical conversations like "well it's not open source but the source code is open."

[rpaik]

You're correct and apologies for the confusion. I didn't mean to imply that EE is open source. It is proprietary and source available. I was actually more concerned about the comment that EE is "off-limits" to contributors and wanted to set the record straight.

[m4rtink]

AFAIK many company employees can quite easily contribute to projects under an OSI approved license, while contributing to projects requiring CLA is generally much harder & requires clearing the given CLA with the legal department.

And I'm afraid contributing to a "source available" project that is not even open source will be even harder.

[nhumrich]

Open source projects get all "paid" features for free.

[chabad360]

That's for gitlab.com, not GitLab CE.

[mroche]

Gold (GL hosted) and Ultimate (self hosted) are available to educational institutions and open source projects. Check the pricing FAQ’s. This has been a thing since Microsoft acquired GitHub.

https://about.gitlab.com/blog/2018/06/05/gitlab-ultimate-and...

[thayne]

> Merge request approval is not something a single contributor needs

But then, is Gitlab something a single contributor for a private repository anyway? I'm sure there are use cases, but for most individuals working on a private repo, gitlab is probably overkill.

[spankalee]

Merge request approval isn't in the open source version? That's a huge missing feature.

I don't see how that fits into the pricing scheme outlined in the post either, unless they consider the maintainers of a project to be managers?

[nhumrich]

"approval" isnt really needed at all unless there are compliance requirements. A comment or reaction of :+1: is usually sufficient. Two years ago, github itself didn't even have approvals on pull requests. So yes, I think it aligns well with a feature managers need, not individual contributors.

[spankalee]

+1 is ok, but it's not the same as concrete approval bit.

GitHub was late to add it, but that doesn't mean it wasn't a glaringly missing feature from GitHub before then. Other open-source system like Gerrit and Phabricator have had approvals since their inception, I believe.

edit, just to say: I really don't get the manager tie in to approvals. I've never worked on a team where approvals were done by managers. It's always other team members, and especially required when you have code owners of different parts of the codebase.

[nixgeek]

Point being made ain’t that managers approve merges, it’s that the feature is generally something you may want to enforce formal peer review once your team grows beyond 5-6 people.

In contrast like SAST and DAST is far more common to be a requirement in large enterprises and that’s in the much more expensive tier as a result.

[Hamuko]

>reaction of :+1: is usually sufficient

If I remember correctly, you don't actually get notified of any +1 reaction.