Since there are GitLab insiders in this thread, a question: has GitLab ever discussed the possibility of simply making Enterprise Edition actually open source/free software, all at once, and simply continuing to charge for it like you already do? You can sell free/open-source software, and you already offer things like paid support in your pricing model.
Thanks for asking Drew and congrats the rapid progress on sourcehut.
Yes, we actually started by making making Enterprise Edition actually open source. When we announced there would be a proprietary part of GitLab people mentioned that Wordpress plugins where able to make it work with an open source license. It was a comment on https://about.gitlab.com/releases/2013/08/22/introducing-git... but the comments there seem to have disappeared. So instead of making it proprietary we licensed it with an open source license but without offering a download, you had to pay to get access to the source code (this is similar to the Wordpress plugins and also not unlike Red Hat Enterprise Linux updates).
We were afraid that people would put up a mirror with the paid code, this didn't happen. But our customers told us that it was hard to justify paying for open source code, they got lots of questions from their managers. So we switched to making the additional features proprietary.
We tried charging for support but it is hard to make enough margin to be able to invest in the things we wanted (scalability, security, library upgrades, easy of use, etc.). People tended to cancel after they didn't use support for a year. I believe that most companies charging only for support are tempted to make the product harder to use to increase the need for support. More about the business models we tried can be found on https://about.gitlab.com/blog/2018/11/09/monetizing-and-bein...
Thanks for the detailed answer! I'm glad to hear that some thought has gone into this. For a direct comaprison of SourceHut's financial model with GitLab, see:
Though it's definitely easier to go with the GitLab approach to monetization, I pointed out a lot of problems that these incentives set up. I'm not sure how you're going to avoid some of these problems. That being said, I imagine that it would be extremely difficult GitLab to change course so sharply at this point in its life.
To be clear, I recognize that GitLab EE, as a source-available distribution, is a measurable improvement over GitLab's closed-source offerings. I think GitLab is a valuable tool and an ecosystem without it is poorer than an ecosystem with (though, an ecosystem without SourceForge would be nice...). I hope that you guys are able to balance your incentives and stick around to provide a good service to the community, and I hope you keep it up with merging EE features into CE.
I am not sure I had ever read Gitlab's rationale for its business model outlined in this detail anywhere, and I found it fascinatingly similar to our own. I wanted to share that Canonical's 15-year experiment in business models has lead to similar conclusions: if you want to scale, you need to 1) to make it very clear why your customers should pay, and 2)take into account that buyers in general are less sophisticated in their decision making than we would hope for. I think the general move to freemium/open core models is recognition that other models are very high-risk.
I can't tell you how many times I have heard from a suit and tie buyer that they can't justify paying [that much] for open source, and even when you can answer that question in a compelling way, the message is diminished along the way to procurement. And that's erosion of margin.
You're right that there is an inherent conflict in freemium between the free version's feature set and the paid-for version, but that just means you need to weigh your options carefully along the way, and ideally come up with some simple to understand strategies/rules of thumb that your team can use when deciding where the products need to go.
Note also that it's not like other less controversial models aren't without conflicts of their own. For instance, support models set up a conflict with the quality of the product, because high quality, "It Just Works" products don't help users value support highly -- yes, even when the users are Fortune 100s, amazingly. Similarly, SAAS models are naturally incentivized to make the software complex, undocumented, hard to install and challenging to operate, lest the value proposition of the paid offering becomes convenience only, which is very hard to capture margin with for relatively low-volume B2B products.
In the end, I guess I'm saying that Gitlab's approach isn't necessarily easier; it's just much less risky and therefore scales much better.
Yeah, one of the important lessons here is: Buyers just aren't rational. Even multi-billion companies are driven by manager egos and biases and they will make dumb decisions based on prejudices.
Unfortunately, the Oracle/IBM marketing of "Opensource is trash" has proven to be very sticky so selling OSS to Enterprises companies can be a hugely uphill battle when managers think that OSS products are inherently low quality in comparison to highlghy priced "brand name" stuff. Giving them away for free with paid support is very contraproductive when your purchaser has this line of thinking - they just percieve this as "this product is so bad they need to give it away for free".
Note that I explicitly pointed out that you don't have to give it away for free - you can charge people for the source code and use a free/open source software license at the same time. It does prevent you from charging a subscription fee (or at least makes it ineffective), but you can also deny them access to updates unless they pay up. Sure, someone could stick the code online somewhere else, but now customers would have to trust some random third party to forward the legitimate code to them, and this third party has to compete with your established marketing funnel.
> But our customers told us that it was hard to justify paying for open source code, they got lots of questions from their managers
This is, unfortunately, a real problem. I've worked in huge companies that will happily shell out hundreds of thousands for Atlassian crap, but if you were to suggest paying less for a better product that could be got for free you'd be laughed out of the room. What's more likely is the fact that it's free would be used as its main selling point.
I can tell you from the point of view of a very large corporation who uses Gitlab internally. I think it's a good model.
Free Gitlab got our bosses attention. Once they saw the value it added to the org. our managers started bringing up the Enterprise license. Not us techs, we were fine with the free version.
"I believe that most companies charging only for support are tempted to make the product harder to use to increase the need for support."
I agree with this. Many advocates of open source software continue to push the paid support option as a viable route for open source developers. But often the suggestion is made without thinking through the implications of such a proposal. And the idea of deliberately making a product complex or poorly documented in order to encourage paid support is inherently unattractive to any customer.
For solo developers or small developer teams, I can't think of anything less appealing that having to focus on paid support as the benchmark for financial success for their business.
A paid 'source available' option is one way to charge for the actual product and give your customers access to your source code (which can include provisions to modify the source code). This model may not be popular with open source advocates, but it provides a way for the developers to keep their focus on the product and on making it as easy as possible to use.
In fact this model isn't new. There is a long history of developer tools sold, not as open source, but with the source code available for modification and incorporation in to other products.
Thanks for the comment. Its always cool to see gitlab comments sharing insights that would be hidden by other companies.
Off topic but while you are here I was wondering if gitlab would consider having the bot that tags issues as open for community contributors not tag issues on enterprise edition features since community members are unable to develop on these and it makes it hard to find issues that are actually open for the community to contribute to.
Thanks for asking. Right now we have one label accepting merge requests and then labels by tier. Does it work to filter on two labels? Or are we not consistent in labeling the tier? Another option would be to have an accepting merge request label per tier. But this might cause other problems, such as getting out of date when we change the tier before the feature is made.
I just had a look through some of the recent issues with the accepting merge request label and most of them refer to enterprise edition issues but only a small number have the label "enterprise edition". Many of them have other tags like "Category:Epics" but there seem to be a very large number of these EE edition labels making it not simple to just filter out enterprise edition features.
Thanks for pointing that out. I've also seen missing "enterprise edition" labels in some MRs and can make a request to GitLab team members not to forget about the enterprise label.
Gitlab is really great for companies who wish to self-host their tools, and as a source code repository it is great at the free tier. But for small companies who might wish to migrate their issue tracking to Gitlab as well the pricing of the paid tiers is prohibitively expensive.
What would really help me is a self-hosted pricing tier that includes things like epics and roadmap management, for something like $2/user/month. No need for support, just a way to contribute to the product without breaking the bank. After all, we're already self-hosting the software, so without support exceeding that of the free tier it wouldn't cost Gitlab a thing, but it would allow smaller companies to support Gitlab financially.
You pay your employees thousands per month and rent an office for several hundreds per month. Most people here seem to buy absolutely overpriced Mac Book Pros for $3000. When you cannot pay $4 or $19 per month extra for each employee to be more productive, you have problems beyond that.
This "everything must be free" mentality is driving me crazy. And yes, $2/month/user is still ranging in the "free" region, even $4 is ludicrously cheap when you are even a minute more productive each day. Somebody has to pay Gitlab's employees and VC money wont do this indefinitely.
You seem to be well aware of the financial resources at my disposal and the salaries paid at my company. Do we have a data leak?
Besides, epics and roadmaps pushes the price to $19/user/month, which we can't afford. $4/user/month might be possible, but the epics and roadmap features are a must have at that point.
It would be nice to have country-dependent pricing, relative to their poverty index or some other quantifier. That way everyone could afford to pay for the service and would "feel" the price in a same way.
I am aware of expenses that are the same for maintainers, no matter where their clients come from. But wouldn't it be nice?
In our company we are going to experiment with such pricing to give everyone equal chance to use our software. Some countries are going to have it for free.
I don't think the poster wants to drive you crazy. I don't think the poster said they wanted everything to be free. What I believe they're asking is a pricing plan that offers a feature without support for a reduced price. It is an idea, and GitLab's staff who are lurking here are smart enough to check if there's a business opportunity there, and a need that can viable be filled.
In many parts of the world, $200 is a salary.
The tiered pricing concept and the upgrade pushed by induced demand and "Parkinson's law" has changed the world as it allows companies to start working using free or low priced tiers instead of needing high initial capital. As these companies grow, they will use more features and pay more.
I'm not sure how to understand this. In American practice, salaries are quoted annually. You pretty much have to look at sub-Saharan Africa to find annual earnings that low. In Chinese practice, they're quoted monthly. That covers a lot more of the world.
Mostly this comment is a note that "is a salary" isn't really a meaningful predicate. It means wildly different things in different places.
My users are not employees but random people contributing to an OS project. There should be a per-project pricing model that the certain situations where that makes sense.
But these pages are not easy to find, I had to use search.
This should be mentioned on the pricing page.
TBH all these features on Gold and Ultimate for free are game changers (specially Gold since you won't need to manage and install so many things that used to be many different systems), GitLab should advertise it more.
> Your project must not seek to make a profit from the resulting project software
My project is my job, it's OS but I need to profit from it. I don't mind paying, but just per project. I just don't want to pay for the thousands of people on it who's just making spelling corrections.
"Open source is great! We heavily rely on open source! We support open source! So let us maybe give you a key that lifts artificial restrictions from our proprietary code. Only if you're open source. Oh and you mustn't do exactly the thing we do: try to make profit with open source."
If I had made something Gitlab needs, they would not need to ask me to give anything for free because that's what I do by default. I don't build artificial scarcity in my stuff.
I assume you have a day job and in the course of your duties, you charge people for your time while working with open source frameworks. Would it be hypocrisy for you to expect a wage while building solutions based on other people's efforts?
> When you cannot pay $4 or $19 per month extra for each employee
Not per employee, per user! Letting customers file issues and participate in the process can be impossibly expensive if they're paying $10/month for your product.
Admittedly the $99/seat/month supports free guest users.
Gitlab CE is just amazing. It's hard to fathom going back to GitHub (and I wrote a book for O'Reilly about the GitHub API). The tight integration with CI rather than using external services is amazing.
Are you suggesting gitlab ci isn't docker? All my pipelines are some docker variant. I'm not sure if you are just suggesting actions was done the right way with docker, but that's nothing special with gitlab ci. Can you clarify? You can even use your own docker repository with gitlab, though I'm unsure if that's something that only comes with EE (I haven't needed it yet, I just keep all my extras in the gitlab ci yaml file).
Sorry, I'm honestly not familiar with Gitlab CI. I was just originally mentioning how the use of Docker in Github Actions allowed for amazing flexibility, which I thought was cool.
What makes Gitlab CI a better or more polished API than Github Actions? At first glance they look very similar
Gitlab has a few different modes for its runner. One of them uses docker to run your script in a container. But you can also have shell executors which is more like Jenkins, for example. That can actually be better if what you're doing is building a lot of Docker images.
It's also slow and difficult to cache build artifacts which makes it immensely painful to debug if you have anything of moderate complexity.
Allegedly there's a way to cache image layers and artifacts on Github. I've taken to pushing them to S3 buckets so my CI runs can be incremental where possible.
Agreed, it's much better than Travis. But the GP is right, it's more "hack blocks together", where each action does its own thing and acts on the files independently, and there isn't much control over the whole process. Heck, they don't even fully support the entire YAML spec (I'd give citations on that but I'm writing from my phone, and don't have the time to pull it up).
I haven't used GitLab for a while because most of the projects I'm working on are on GitHub, so I can't comment on GitLab CI.
It's much better than Travis in every way except one: GitHub Actions pull request checks are against the PR branch, while Travis pull request checks are against a merged tree.
The most common case where this matters is if someone pushes a failing commit to master, and then all PRs based on that commit will also fail, and then a fix is pushed to master. With Travis, you just need to re-run checks, but with GitHub actions, all those PRs need to be rebased on the new master.
Yeah, that's interesting. Being able to run the runner on my own instance on Google cloud is so easy to troubleshoot. I've not played with actions but when I need to shell into my runner and check something, having root and owning the machine makes that really fast.
I just went through the process of setting up GH Actions to replace Circle CI for a Rails app. It was depressingly inflexible, considering that GH is a Rails app, and I would have expected it to be straightforward.
I have done elaborate pipelines in Gitlab, and echo the thoughts of it being lightyears ahead.
I don't think there is any reason to believe that github itself uses github actions for its ci/cd process. They must have had something in place before actions came on the scene, and even if they are migrating to actions it would likely be a long process.
I would just expect that if they want it to be a major feature, to dogfood it themselves. If it would be a long process to migrate, then how could they expect anyone else to migrate with the state of the feature?
I am not sure on how Bitbucket compares because I haven't tried GitLab in a while, but we use Bitbucket at work.
Bitbucket works well and the Pipelines functionality is a life saver for us. I wish I started my projects differently though. After bringing on my first employee it takes a lot of reorganizing of the projects to get them access to it. That's not an issue with Bitbucket though... just a cautionary tale.
No relationship to Gitlab. But do work for an organisation that uses it very heavily and gets entirely by with the open source version (plus various scripts that use the API to fill in some of the gaps).
I had no idea there were any closed-source features - I thought Gitlab was a passionately completely open-source company. They even open-source their arguments between their legal counsel and their developers!
The entire app is source available, you can download it and look at it all but a section of the features are licensed under a proprietary license which is what you pay for when you pick a gitlab plan.
This code might not be closed source, but it's definitely not open source - please be careful about your language. It's source available. Open source software is software which meets the open source definition: https://opensource.org/osd
If GitLab truly cares about open source (and I believe you do), you should be protecting the term from misuse.
I totally agree we shouldn't call it open source if we mean proprietary and source available. We changed the classification of our company from open source to open core a while ago https://about.gitlab.com/blog/2016/07/20/gitlab-is-open-core... Sorry for the inconsistency in this thread.
Historically, the only people who have ever rejected the OSD have been people who think that open source ought to be more conveniently defined so that they can capitalize on the marketing potential of the phrase without meeting the actual criteria for being open source software. There have been systemmic efforts to gaslight the open source community like this. The fact is: term is and has always been defined by the OSD, the OSI is the group which invented the term "open source", and you cannot change the meaning of the phrase to suit your perverted financial needs. The term was never controversial before it started catching on and being a nuisance for people trying to sell proprietary software.
Calling software open source when it's not is lying at best and outright fraud at worst.
> the OSI is the group which invented the term "open source"
This isn’t true. They used an existing term. Have you ever wondered why it’s not a trademark to protect it? They weren’t able to trademark because it was an existing descriptive term.
This is complete revisionism. The OSI set out to create a new term, one that they could trademark and would otherwise match the meaning and intention of "free software".
They may have failed in the end, for a numer of reasons, but they were very rigorous in their search of prior usage and very open about their work. We can speculate in retrospect about what could have done differently, but saying they used an existing term is wrong both in intent and in practice.
It's not a trademark because they didn't apply for one. They regret this. The origin of the term is well documented: OSI did invent it. To argue otherwise is historical revisionism.
"OSI's application for an Open Source trademark had lapsed"
Why did they let it lapse? Because (as they knew) it wasn't trademarkable as it's a simple generic descriptive term.
"We have discovered that there is virtually no chance that the U.S. Patent and Trademark Office would register the mark "open source"; the mark is too descriptive."
> The origin of the term is well documented: OSI did invent it.
Not true!
See the links the my sibling commented posted for prior specific examples of 'open source software'.
And of course 'open source' is just a normal phrase that's been in use for much much longer! That's why they can't trademark - it's just a normal phrase people were already using.
The trademark is front and center in their (original) mission statement:
> The Open Source Initiative's mission will be to own and defend the Open Source trademark, to manage the www.opensource.org resources, to develop branding programs attractive to software customers and producers, and to advance the cause of open-source software and serve the hacker community in other appropriate ways.
No, it's well documented that the term was in use referring to "source available" software before they claim to have invented it. It might be a case of two groups coming up with the same term, but they were not the first.
You can't actually build EE from source. The license "key" is a block of code and if you've never payed for one, you don't know the format. Dev versions of these licenses are restricted to GitLab employees only, even though the license terms explicitly allow building and testing for development purposes.
Code availability is important too though. I'd much rather use something that had code available (e.g. Unreal Engine) than something that didn't (Unity) because sometimes things aren't documented and you need to read the source to find an answer.
Bummed that Pull Mirroring isn't on the list. I really want to use GitLab for CI/CD, but we dont want to store our code there exclusively. Instead we use a series of scripts to work around this problem. Would be great if the core platform just supported this.
GitLab PM here. Glad to hear scripts allow you to use our CI/CD, but sorry to hear that remote repository pull mirroring not being in Core prevents you from using it. Hope you know we do make it available at our lowest priced tier (Starter: $4/month/user).
I'm really excited by the availability of the helpdesk feature. It will help our FOSS project reduce the number of mailing lists we have (such as the security@ or some other public-facing lists).
Yes, free users with private repos have the same functionality as is in the Core edition of GitLab self-managed, the open source feature set. Free users using a public repo additionally get all proprietary features.
I just wished they had moved Scoped Labels to Free too.
And I would love that the SAST framework goes to Free too and kept have the security scanners Premium. That would allow to have basic code coverage directly in Free, without the complex static analyzers, which would be reserved for premium...
We understand these are not the only use cases for code coverage and really just scratch the surface. We are working on the next set of features to build this category out further and would appreciate any input you might have on the issues there(https://gitlab.com/groups/gitlab-org/-/epics/100).
I am a GitLab contributor. I have been fighting for years for them to explain why basic features were getting shoehorned into paid tiers. This is years too late, and it falls short of addressing the source of the issue. The people who are making these decisions seem to have an incentive to restrict features to paid tiers. It's a business, I get it, but they are taking basic features that the community could implement, and locking them away in a paid tier. Sometimes a front-end only change, all the data is already available, marked as a paid feature. I used to constantly come across features I needed that had landed in a paid tier where I could write a grease monkey script to do it in a few lines of code, so I would post it as a snippet to illustrate how ridiculous it was.
First of all, thanks for being a GitLab contributor. Could you share other features you're concerned about? (If you have a link to issues that'd be great)
I am using GitLab in my work environment and I really try to embrace it. But some features one just expects from a basic Jenkins setup are either missing or weirdly implemented and feel like duct-taped into GitLab.
Take for example:
- Code coverage reports:
You can have one absolute number to get your total coverage. To get the number you have to provide a Regex deep down on the main project settings. This Regex has to match some log output of your CI job in order to be picked up, e.g “Total 87%”.
Why can’t GitLab collect cobertura Test reports for example?
to circumvent the above downsides, you can get creative, and generate HTML websites of the Unit test and Coverage reports themselves and publish them somewhere. An ideal place would be GitLab pages.
But you are only allowed to have one publish job for GitLab Pages. And this publish job has to have a special name so it is recognized for publishing GitLab Pages. The artifacts you want to publish have to be in a special named folder in order to publish them. So you fallback to some hackery by using “mv,mkdir”
These were some examples which I find not that exotic for a CI setup and I know from previous experience that Jenkins handles all these with ease.
To circumvent this shortcoming, we introduced SonarQube.
I feel that people often are drawn to a shiny, small GitLab CI yaml and are happy to get started so fast.
But again having Jenkinsfiles with shared libraries, which you can program in Java and Groovy, is superior to the next yaml include/extend you are going to add.
My 2cents are that:
If you are a solo developer or a small company Gitlab might be fine for you. When your company is larger and you want to be able to share knowledge using shared libraries, have a streamlined CI setup with GitLab includes from multiple departments, GitLab gets tough.
How could one be confident to use for example their 1-click deployment (autodevops) Feature if the implementation of CI basics like collecting test results and coverage reports have this weird taste to it?
I wish these features will get better and please don’t take this too harsh. My tone might sound worse than it is.
GitLab Product Manager here. I really appreciate the feedback on those features and it helps inform some upcoming work to make them better. The team is currently working on improvements to JUnit parsing (https://gitlab.com/groups/gitlab-org/-/epics/2854) so we can enable those Junit reports by default.
We are also working on the next set of code coverage features to build this category out further and would appreciate any input you might have on the issues there as we're prioritizing and scheduling for the next few milestones (https://gitlab.com/groups/gitlab-org/-/epics/100).
All not very relevant. They keep the core business features (like merge request approval) carefully out of the OSS edition. And they haven't fixed the pricing for their premium offering either.
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.
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.
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.
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.
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.
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.
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.
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.
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."
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.
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.
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.
> 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.
"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.
+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.
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.
Package registry is pretty important for my organization. We need to do builds with jndi and other similar java libraries. We deployed Nexus OSS because we did not want to pay for GitLab Premium.
