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.
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.
The Enterprise Edition is under a different license but the source code is open and available to everyone.
And I'm afraid contributing to a "source available" project that is not even open source will be even harder.
"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.
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.
https://about.gitlab.com/blog/2018/06/05/gitlab-ultimate-and...
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.
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?
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.
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.
If I remember correctly, you don't actually get notified of any +1 reaction.