13 ms·

Gitlab features that are moving to open source

389 points by markdog12 7y ago

chrisseaton 7y ago
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!
- rpaik 7y ago
  Please see my response above. Enterprise Edition(EE) code is open to everyone and wider community members have also been contributing to EE.
  - deleted 7y ago
    [deleted]
  - chrisseaton 7y ago
    Ah it’s about licence not code availability.
    - yjftsjthsd-h 7y ago
      Yep. After all, Windows was source available in different forms even in the "old Microsoft" era (education and government programs, IIRC).
    - IshKebab 7y ago
      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.
  - ddevault 7y ago
    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 https://opensource.org/osd If GitLab truly cares about open source (and I believe you do), you should be protecting the term from misuse.
    - sytse 7y ago
      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-github-is-closed-source/ https://about.gitlab.com/blog/2016/07/20/gitlab-is-open-core... Sorry for the inconsistency in this thread.
      - ddevault 7y ago
        Thanks, "open core" is a classification I would agree with for GitLab. Cheers!
    - cortesoft 7y ago
      That is the definition as defined by that one group... but others have a different definition. Just because you own the domain name doesn't mean you get to be the only source for a word's definition.
      - ddevault 7y ago
        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.
  - deckar01 7y ago
    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.
    - deleted 7y ago
      [deleted]
- Polylactic_acid 7y ago
  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.
veeralpatel979 7y ago
Will these features be available in gitlab.com for free users as well?
- sytse 7y ago
  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.
- deleted 7y ago
  [deleted]
mch82 7y ago
Nice set of features! I’m especially excited about the package managers.
2ion 7y ago
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.
- lxn 7y ago
  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 7y ago
    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 7y ago
      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.
xrd 7y ago
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.
- rattray 7y ago
  Have you tried Github Actions? (I haven't, just want to calibrate).
  - nhumrich 7y ago
    Github actions is nowhere near as polished/mature ad gitlab ci. Github actions feels more like a "hack blocks together" than a true pipeline.
    - tamalsaha001 7y ago
      Do you mind to elaborate? We have migrated from Travis to Github Actions and love it so far.
      - chabad360 7y ago
        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.
        xrd 7y ago
        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.
zmmmmm 7y ago
Gitlab as both a product and a company continues to amaze me with the quality and value of what they create and give to the community.
- mekster 7y ago
  Have they started hiring shills? These reactions defer greatly from what I had seen a year ago for bad designs and high load.
  - zmmmmm 7y ago
    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).
ddevault 7y ago
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.
- sytse 7y ago
  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-gitlab-6-0-enterprise-edition/ 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-being-open-source/ https://about.gitlab.com/blog/2018/11/09/monetizing-and-bein...
  - ddevault 7y ago
    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: https://sourcehut.org/blog/2019-10-23-srht-puts-users-first/ https://sourcehut.org/blog/2019-10-23-srht-puts-users-first/ 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.
mgbmtl 7y ago
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).
- sytse 7y ago
  Awesome! Getting your support emails converted into issues so you can work on them as a team tends to make it much clearer who is handling what.
apple4ever 7y ago
That's great! Changes I'd really like to see: Down to starter: epics, roadmaps, HA, Free Guest users Down to premium: SAST, Dependency Scanning, DAST, Vulnerability Management
nmaludy 7y ago
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.
- Aeolun 7y ago
  I agree with this thing. But it's probably something that is mainly something director or higher level want. Developers just want it because it'll allow them to sell the product to their director.
- davidcorbin 7y ago
  This. Pull mirroring is a must before my team would considering using it.
- ahuang1018 7y ago
  Thanks for reaching out with your input! For now, know that we have passed your notes along to the Team, thanks again!
- tyeager 7y ago
  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).
laktak 7y ago
Will it be possible to customize these features? I'd like to turn off Kubernetes integration for example.
weitzj 7y ago
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? - 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#enabling-the-feature 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/#add-gitlab-ci 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 7y ago
  Hi there! 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 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 https://gitlab.com/groups/gitlab-org/-/epics/100). Thanks! -James H Product Manager - Testing
Freak_NL 7y ago
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.
- foepys 7y ago
  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.
  - clarry 7y ago
    > 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.
  - KaoruAoiShiho 7y ago
    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.
    - tosser678 7y ago
jbk 7y ago
This is really cool. 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 7y ago
  Hi there! 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-coverage-report-badge 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-coverage-report-with-gitlab-pages/ 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 https://gitlab.com/groups/gitlab-org/-/epics/100). Thanks! -James H Product Manager - Testing
deckar01 7y ago
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.
- rpaik 7y ago
  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)
  - deckar01 7y ago
    Description change history just landed as a paid feature. https://gitlab.com/gitlab-org/gitlab/-/issues/10103#note_152161361 https://gitlab.com/gitlab-org/gitlab/-/issues/10103#note_152... Repository push mirroring is available in CE, but pull mirroring is a paid feature. https://gitlab.com/gitlab-org/gitlab/-/issues/19095#note_272839987 https://gitlab.com/gitlab-org/gitlab/-/issues/19095#note_272...

389 points by markdog12 7y ago

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!

rpaik 7y ago
Please see my response above. Enterprise Edition(EE) code is open to everyone and wider community members have also been contributing to EE.
- deleted 7y ago
  [deleted]
- chrisseaton 7y ago
  Ah it’s about licence not code availability.
  - yjftsjthsd-h 7y ago
    Yep. After all, Windows was source available in different forms even in the "old Microsoft" era (education and government programs, IIRC).
  - IshKebab 7y ago
    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.
- ddevault 7y ago
  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 https://opensource.org/osd If GitLab truly cares about open source (and I believe you do), you should be protecting the term from misuse.
  - sytse 7y ago
    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-github-is-closed-source/ https://about.gitlab.com/blog/2016/07/20/gitlab-is-open-core... Sorry for the inconsistency in this thread.
    - ddevault 7y ago
      Thanks, "open core" is a classification I would agree with for GitLab. Cheers!
  - cortesoft 7y ago
    That is the definition as defined by that one group... but others have a different definition. Just because you own the domain name doesn't mean you get to be the only source for a word's definition.
    - ddevault 7y ago
      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.
- deckar01 7y ago
  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.
  - deleted 7y ago
    [deleted]
Polylactic_acid 7y ago
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.

veeralpatel979 7y ago

Will these features be available in gitlab.com for free users as well?

sytse 7y ago
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.
deleted 7y ago
[deleted]

mch82 7y ago

Nice set of features! I’m especially excited about the package managers.

2ion 7y ago

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.

lxn 7y ago
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 7y ago
  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 7y ago
    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.

xrd 7y ago

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.

rattray 7y ago
Have you tried Github Actions? (I haven't, just want to calibrate).
- nhumrich 7y ago
  Github actions is nowhere near as polished/mature ad gitlab ci. Github actions feels more like a "hack blocks together" than a true pipeline.
  - tamalsaha001 7y ago
    Do you mind to elaborate? We have migrated from Travis to Github Actions and love it so far.
    - chabad360 7y ago
      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.
      - xrd 7y ago
        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.

zmmmmm 7y ago

Gitlab as both a product and a company continues to amaze me with the quality and value of what they create and give to the community.

mekster 7y ago
Have they started hiring shills? These reactions defer greatly from what I had seen a year ago for bad designs and high load.
- zmmmmm 7y ago
  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).

ddevault 7y ago

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.

sytse 7y ago
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-gitlab-6-0-enterprise-edition/ 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-being-open-source/ https://about.gitlab.com/blog/2018/11/09/monetizing-and-bein...
- ddevault 7y ago
  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: https://sourcehut.org/blog/2019-10-23-srht-puts-users-first/ https://sourcehut.org/blog/2019-10-23-srht-puts-users-first/ 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.

mgbmtl 7y ago

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).

sytse 7y ago
Awesome! Getting your support emails converted into issues so you can work on them as a team tends to make it much clearer who is handling what.

apple4ever 7y ago

That's great! Changes I'd really like to see: Down to starter: epics, roadmaps, HA, Free Guest users Down to premium: SAST, Dependency Scanning, DAST, Vulnerability Management

nmaludy 7y ago

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.

Aeolun 7y ago
I agree with this thing. But it's probably something that is mainly something director or higher level want. Developers just want it because it'll allow them to sell the product to their director.
davidcorbin 7y ago
This. Pull mirroring is a must before my team would considering using it.
ahuang1018 7y ago
Thanks for reaching out with your input! For now, know that we have passed your notes along to the Team, thanks again!
tyeager 7y ago
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).

laktak 7y ago

Will it be possible to customize these features? I'd like to turn off Kubernetes integration for example.

weitzj 7y ago

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? - 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#enabling-the-feature 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/#add-gitlab-ci 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 7y ago
Hi there! 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 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 https://gitlab.com/groups/gitlab-org/-/epics/100). Thanks! -James H Product Manager - Testing

Freak_NL 7y ago

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.

foepys 7y ago
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.
- clarry 7y ago
  > 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.
- KaoruAoiShiho 7y ago
  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.
  - tosser678 7y ago

jbk 7y ago

This is really cool. 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 7y ago
Hi there! 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-coverage-report-badge 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-coverage-report-with-gitlab-pages/ 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 https://gitlab.com/groups/gitlab-org/-/epics/100). Thanks! -James H Product Manager - Testing

deckar01 7y ago

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.

rpaik 7y ago
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)
- deckar01 7y ago
  Description change history just landed as a paid feature. https://gitlab.com/gitlab-org/gitlab/-/issues/10103#note_152161361 https://gitlab.com/gitlab-org/gitlab/-/issues/10103#note_152... Repository push mirroring is available in CE, but pull mirroring is a paid feature. https://gitlab.com/gitlab-org/gitlab/-/issues/19095#note_272839987 https://gitlab.com/gitlab-org/gitlab/-/issues/19095#note_272...