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...
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.
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.
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.
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.
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.
[+] [-] ddevault|6 years ago|reply
[+] [-] sytse|6 years ago|reply
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...
[+] [-] Freak_NL|6 years ago|reply
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.
[+] [-] foepys|6 years ago|reply
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.
[+] [-] xrd|6 years ago|reply
[+] [-] rattray|6 years ago|reply
[+] [-] jakecopp|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] zmmmmm|6 years ago|reply
[+] [-] mekster|6 years ago|reply
[+] [-] chrisseaton|6 years ago|reply
[+] [-] Polylactic_acid|6 years ago|reply
[+] [-] rpaik|6 years ago|reply
[+] [-] nmaludy|6 years ago|reply
[+] [-] davidcorbin|6 years ago|reply
[+] [-] tyeager|6 years ago|reply
[+] [-] Aeolun|6 years ago|reply
Developers just want it because it'll allow them to sell the product to their director.
[+] [-] ahuang1018|6 years ago|reply
[+] [-] mgbmtl|6 years ago|reply
[+] [-] sytse|6 years ago|reply
[+] [-] veeralpatel979|6 years ago|reply
[+] [-] sytse|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] mch82|6 years ago|reply
[+] [-] laktak|6 years ago|reply
I'd like to turn off Kubernetes integration for example.
[+] [-] apple4ever|6 years ago|reply
Down to starter: epics, roadmaps, HA, Free Guest users Down to premium: SAST, Dependency Scanning, DAST, Vulnerability Management
[+] [-] jbk|6 years ago|reply
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...
[+] [-] jamesh-gl|6 years ago|reply
GitLab Product Manager here. You can generate code coverage reports today and use the generated value to populate a project badge value (https://docs.gitlab.com/ee/ci/pipelines/settings.html#test-c...) or publish the report(https://about.gitlab.com/blog/2016/11/03/publish-code-covera...).
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).
Thanks!
-James H Product Manager - Testing
[+] [-] deckar01|6 years ago|reply
[+] [-] rpaik|6 years ago|reply
[+] [-] weitzj|6 years ago|reply
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?
- Unit Test Results:
Collecting JUnit test results is disabled by default, since there is a warning about a performance issue when collecting them https://docs.gitlab.com/ee/ci/junit_test_reports.html#enabli...
- collecting multiple artifacts as HTML pages:
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”
https://about.gitlab.com/blog/2016/04/07/gitlab-pages-setup/...
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.
[+] [-] jamesh-gl|6 years ago|reply
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).
Thanks!
-James H Product Manager - Testing
[+] [-] 2ion|6 years ago|reply
[+] [-] lxn|6 years ago|reply
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.
[+] [-] pknopf|6 years ago|reply
[+] [-] CameronNemo|6 years ago|reply