4 ms·

We are Gitlab customers since 2017 and I can tell you that your expectations for what support can do for you are very unrealistic. Per their own policy all the

We are Gitlab customers since 2017 and I can tell you that your expectations for what support can do for you are very unrealistic. Per their own policy all they do is finding relevant tickets and send you there, from there on you are not their problem anymore. You as customers is also not a developer/product manager problem either, they do their planning and priotization using their own ideas and unless ticket is in the next milestone you won't even get response to your comments or suggestions for months. There is literally nobody, who has your interests as part of their day to day agenda. Except for sales at the time of your license renewal of course :) This time we are likely not going to renew and be switching to CE version after our current license expires.

gabeweaver 7y ago
Hi. GitLab PM here. I'm really sorry that this is your experience. Can you point me to this policy? I would like to propose a change to it given that's not reflective of how most teams do planning and prioritization. We care very much about support issues, regularly prioritize a large portion of each release to addressing them, and can not do it effectively without ongoing involvement and feedback from the wider community. I will say that it is sometimes hard to separate the signal from the noise, given my team currently has 3k+ open issues. Please ping me (@gweaver) on issues that are relevant to you and I'll do my best to provide a status update / more information or bring in the relevant PM who can.
- Aeolun 7y ago
  > I will say that it is sometimes hard to separate the signal from the noise, given my team currently has 3k+ open issues. I think this is a different problem. But not something your customers should have to care about.
  - skj 7y ago
    Even in business, empathy goes a long way.
    - Aeolun 7y ago
      I can understand why your work is difficult, but still want you to deliver me great service. Bad service is bad service, regardless of the reasons. Can you imagine sitting in a call queue and hearing, “We are sorry, but you will have to wait while we help the 2300 people in front of you.” Any sane person would think that maybe they wouldn’t have this issue if they’d hired more agents. That obviously doesn’t map 1 to 1 on dev, but it’s the scenario thst immediately popped in my head when reading the original message.
- hobabaObama 7y ago
  If the OP does not respond, she/he was probably a GitHub employee :P My experience with GitLab is simple awesome. Keep up the great work you guys!
- rossmohax 7y ago
  It is in your own Statement of Support: > Any assistance with modifications to GitLab, including new functionality, bug-fixes, issues with alpha features or other code changes should go through the GitLab issue tracker, triage, and release cycle. And it matches our experience as customer. We are power users and almost every single support issue we opened is a bugreport or a feature request. Support team can bring values to customers who don't read docs and have questions like "how do we do X", but for seasoned users of Gitlab you can't do much. It was discussed at length in support tickets as well as public issues tracker, that support team refuses to be single point of contact for paying customers, instead "we are open company, here is the issue , feel free to track it [ and best of luck convincing PM to priotise it sooner]", then support ticket get closed. This is like if you have missed delivery from Amazon, you call them, they give you driver's number, you call him, he says Police blocked roads and give local policy dept number, you call them next and they say that there is a manifestation on streets going out of control and give you leaders phone number, you call them, they tell you that energy crisis need to be solved urgently and so on... All you wanted is a replacement pair of socks, because they sent you wrong size earlier. By the way , here is a fulfilment manager phone number,ask him how come such and obvious picking error occured...
  - mikekchar 7y ago
    If you do end up moving to another provider, I'd be interested to see if you get a better experience. Once of the things that puzzles me, especially for an open core solution, is that companies really don't want to do custom development. Or possibly they don't want to have the difficult discussion about cost. I'm always harping on about this, but I don't really see open source companies trying to build value the way Cygnus did. Instead of saying, "Pay us $x per seat and you get whatever we give you", say "Have as many seats as you want and pay us $x to make it do what you want". Cygnus actually did both with GCC and were quite successful at it. It's not just Gitlabs either. I can't think of a software provider with an open core model that primarily sells software development services (Hmmm... Possibly Code Weavers now that I think about it). I remember asking this to Gitlabs ages ago and they said that they tried this model before they took VC money but that they just couldn't get it to work. It still baffles me as to why that's the case.
lkozloff 7y ago
Hi @rossmohax - Support Manager for GitLab here. > Per their own policy all they do is finding relevant tickets and send you there, from there on you are not their problem anymore. I believe you're referring to: https://about.gitlab.com/support/#we-dont-keep-tickets-open-even-if-the-underlying-issue-isnt-resolved https://about.gitlab.com/support/#we-dont-keep-tickets-open-... I think it's a bit more nuanced than that, although I can certainly understand your reading. If your support ticket does end up as revealing a fault in the product or a feature request, we will close out the ticket and prefer further communication on the resulting issue. This is in keeping with our Transparency value. We want to make sure that others who are affected can also chime in, and that the resulting issue is the single source of truth. For issues with configuration, up-time or other support-related things that aren't feature requests or bugs, we would be handling those directly. On those cases that do result in bug reports or feature requests, it's certainly true that sometimes they aren't prioritized, don't get attention, or have milestones slip. Again though, that happens transparently where you can interact directly with the PMs in question. Ultimately, it is a _different_ support experience, but we believe that it's better to have our community as close to our development process as possible. We do consider this an ongoing discussion, and have a long running issue where a number of customers have provided some feedback: https://gitlab.com/gitlab-com/support/support-team-meta/issues/1232 https://gitlab.com/gitlab-com/support/support-team-meta/issu... Please do feel free to join the discussion.
- rossmohax 7y ago
  See my response to gabeweaver above. I provided feedback on our support experience on multiple occasions both privately and publically, I have nothing more to add. Gitlab is important, but not central part of my day to day duties as a DevOps lead of a small (30 Gitlab seats) start-up , I did what I can to get heard. TLDR; support team is great for customers coming to Gitlab, but not so great once initial onboarding is done
zymhan 7y ago
> This time we are likely not going to renew and be switching to CE version after our current license expires. I can strongly recommend against doing that, GitLab almost seems to punish you if you rely on CE, just to force you to pay. It was honestly the bane of deployments.
- chinhodado 7y ago
  It's not that bad. If you only use GitLab for the git repo management purpose and already had other tools for CI (e.g. Jenkins, CircleCI) and project management (e.g. JIRA) then GitLab CE works perfectly fine. The only thing that I wish would be in the CE version is the ability to approve merge requests.
  - utbabya 7y ago
    6 years ago I was trying to setup GitLab CI. From memory, it was a bad experience since there were missing or incorrect pieces of crucial information. At the end they were figured out but if the status quo is still the same I believe it would not be easy to automate a rebuild.
    - emilycook 7y ago
      Hello, GitLab employee. I definitely hope we've matured a lot since 6 years ago! In early 2015 there were still only 9 employees [1] compared to almost 900 now. [1] https://about.gitlab.com/company/history/ https://about.gitlab.com/company/history/

gabeweaver 7y ago

Hi. GitLab PM here. I'm really sorry that this is your experience. Can you point me to this policy? I would like to propose a change to it given that's not reflective of how most teams do planning and prioritization. We care very much about support issues, regularly prioritize a large portion of each release to addressing them, and can not do it effectively without ongoing involvement and feedback from the wider community. I will say that it is sometimes hard to separate the signal from the noise, given my team currently has 3k+ open issues. Please ping me (@gweaver) on issues that are relevant to you and I'll do my best to provide a status update / more information or bring in the relevant PM who can.

Aeolun 7y ago
> I will say that it is sometimes hard to separate the signal from the noise, given my team currently has 3k+ open issues. I think this is a different problem. But not something your customers should have to care about.
- skj 7y ago
  Even in business, empathy goes a long way.
  - Aeolun 7y ago
    I can understand why your work is difficult, but still want you to deliver me great service. Bad service is bad service, regardless of the reasons. Can you imagine sitting in a call queue and hearing, “We are sorry, but you will have to wait while we help the 2300 people in front of you.” Any sane person would think that maybe they wouldn’t have this issue if they’d hired more agents. That obviously doesn’t map 1 to 1 on dev, but it’s the scenario thst immediately popped in my head when reading the original message.
hobabaObama 7y ago
If the OP does not respond, she/he was probably a GitHub employee :P My experience with GitLab is simple awesome. Keep up the great work you guys!
rossmohax 7y ago
It is in your own Statement of Support: > Any assistance with modifications to GitLab, including new functionality, bug-fixes, issues with alpha features or other code changes should go through the GitLab issue tracker, triage, and release cycle. And it matches our experience as customer. We are power users and almost every single support issue we opened is a bugreport or a feature request. Support team can bring values to customers who don't read docs and have questions like "how do we do X", but for seasoned users of Gitlab you can't do much. It was discussed at length in support tickets as well as public issues tracker, that support team refuses to be single point of contact for paying customers, instead "we are open company, here is the issue , feel free to track it [ and best of luck convincing PM to priotise it sooner]", then support ticket get closed. This is like if you have missed delivery from Amazon, you call them, they give you driver's number, you call him, he says Police blocked roads and give local policy dept number, you call them next and they say that there is a manifestation on streets going out of control and give you leaders phone number, you call them, they tell you that energy crisis need to be solved urgently and so on... All you wanted is a replacement pair of socks, because they sent you wrong size earlier. By the way , here is a fulfilment manager phone number,ask him how come such and obvious picking error occured...
- mikekchar 7y ago
  If you do end up moving to another provider, I'd be interested to see if you get a better experience. Once of the things that puzzles me, especially for an open core solution, is that companies really don't want to do custom development. Or possibly they don't want to have the difficult discussion about cost. I'm always harping on about this, but I don't really see open source companies trying to build value the way Cygnus did. Instead of saying, "Pay us $x per seat and you get whatever we give you", say "Have as many seats as you want and pay us $x to make it do what you want". Cygnus actually did both with GCC and were quite successful at it. It's not just Gitlabs either. I can't think of a software provider with an open core model that primarily sells software development services (Hmmm... Possibly Code Weavers now that I think about it). I remember asking this to Gitlabs ages ago and they said that they tried this model before they took VC money but that they just couldn't get it to work. It still baffles me as to why that's the case.

lkozloff 7y ago

Hi @rossmohax - Support Manager for GitLab here. > Per their own policy all they do is finding relevant tickets and send you there, from there on you are not their problem anymore. I believe you're referring to: https://about.gitlab.com/support/#we-dont-keep-tickets-open-even-if-the-underlying-issue-isnt-resolved https://about.gitlab.com/support/#we-dont-keep-tickets-open-... I think it's a bit more nuanced than that, although I can certainly understand your reading. If your support ticket does end up as revealing a fault in the product or a feature request, we will close out the ticket and prefer further communication on the resulting issue. This is in keeping with our Transparency value. We want to make sure that others who are affected can also chime in, and that the resulting issue is the single source of truth. For issues with configuration, up-time or other support-related things that aren't feature requests or bugs, we would be handling those directly. On those cases that do result in bug reports or feature requests, it's certainly true that sometimes they aren't prioritized, don't get attention, or have milestones slip. Again though, that happens transparently where you can interact directly with the PMs in question. Ultimately, it is a _different_ support experience, but we believe that it's better to have our community as close to our development process as possible. We do consider this an ongoing discussion, and have a long running issue where a number of customers have provided some feedback: https://gitlab.com/gitlab-com/support/support-team-meta/issues/1232 https://gitlab.com/gitlab-com/support/support-team-meta/issu... Please do feel free to join the discussion.

rossmohax 7y ago
See my response to gabeweaver above. I provided feedback on our support experience on multiple occasions both privately and publically, I have nothing more to add. Gitlab is important, but not central part of my day to day duties as a DevOps lead of a small (30 Gitlab seats) start-up , I did what I can to get heard. TLDR; support team is great for customers coming to Gitlab, but not so great once initial onboarding is done

zymhan 7y ago

> This time we are likely not going to renew and be switching to CE version after our current license expires. I can strongly recommend against doing that, GitLab almost seems to punish you if you rely on CE, just to force you to pay. It was honestly the bane of deployments.

chinhodado 7y ago
It's not that bad. If you only use GitLab for the git repo management purpose and already had other tools for CI (e.g. Jenkins, CircleCI) and project management (e.g. JIRA) then GitLab CE works perfectly fine. The only thing that I wish would be in the CE version is the ability to approve merge requests.
- utbabya 7y ago
  6 years ago I was trying to setup GitLab CI. From memory, it was a bad experience since there were missing or incorrect pieces of crucial information. At the end they were figured out but if the status quo is still the same I believe it would not be easy to automate a rebuild.
  - emilycook 7y ago
    Hello, GitLab employee. I definitely hope we've matured a lot since 6 years ago! In early 2015 there were still only 9 employees [1] compared to almost 900 now. [1] https://about.gitlab.com/company/history/ https://about.gitlab.com/company/history/