Really surprised to hear about your experience with their support, mine's really been nothing but positive. To be fair, I haven't interacted with them for well over a year now since I'm no longer involved in maintaining GHE. Did support take a hit after the Microsoft takeover?
The rep was very knowledgable and took the time to explain exactly what would happen.
This was years ago, but I appreciated the support at the time, and as a Support Manager at GitLab would still point to it as an example of a quality response.
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.
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.
My experience with GitLab is simple awesome. Keep up the great work you guys!
> 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...
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.
I think this is a different problem. But not something your customers should have to care about.
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.
> 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-...
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/issu...
Please do feel free to join the discussion.
TLDR; support team is great for customers coming to Gitlab, but not so great once initial onboarding is done
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.
And I agree. If that happened to me, I would move, without a doubt.
Ideally your service provider helps you through accidents. Both sides benefit from that.
> GitHub has lost its way
I've been a very early adopter, and I do not have the same impression at all today.
Working with something else than GitHub is painful for me (& I'm using a number of other hosts for various clients).
Not sure how you come to that conclusion. Even _if_ that were true, that would probably be a good thing now that TravisCI is on life support.
There is a third party orb that attempts to do this, but it costs significant numbers of build credits to run as it implements queueing of builds as busy-waiting, plus we've got evidence that there are bugs in it as we have seen out of order deployments.
It's very difficult or near impossible to build edge-triggered features based on build states. We want to be able to notify when the build goes red, notify for every red build, and notify when it goes green again, and just for the master/deployed branch. This is not possible (you either get all builds or no builds).
There is again a third party orb that implements some of this, but it's pretty inflexible.
We've had them remove features we were sold on. Not huge features, but we were told their billing worked one way, budgeted for it, and then they changed that because they couldn't get it to work correctly. They didn't tell us about this, except for just failing our builds as we were under provisioned on users.
Their support takes on average around 2 working days to respond, and often requires chasing to get a response. Once they do respond it's typically a fairly shallow response without much information, or that has misunderstood the issue, and so queries often take multiple rounds to get help on.
They sell a premium support package, but that is pitched as more about helping you to use the service better and I have an objection to paying for support in getting the service to work in the way it should.
1) It's a feature that is fundamental to continuous delivery that is missing, yet CircleCI market themselves as a CI and CD product. I think they need to be more realistic in conversations with customers, in their documentation, in their marketing material, etc, and give significant time in their documentation to workarounds and discussion of the issue.
2) They need to seriously work on their customer communication about the prioritisation system they use. Being constantly told to vote on "ideas" (when they are essentially bug fixes) is quite insulting, and as a customer makes me feel like my input is trivial, it's "nice to haves", rather than being something that genuinely matters to me. They need to have some empathy! Communicating more about the roadmap would be great. Maybe even communicating about all the things from the community site that they are doing each month would be an improvement. Right now it feels like being told our input doesn't matter.
Just some examples. Wouldn't say GitLab is the heaven on earth GitHub isn't. It just has it's own, different issues.
Is this the issue you are referring to about the cache issues? https://gitlab.com/gitlab-org/gitlab/issues/21409 If so, it seems like it got lost in our triage system, I've set appropriate labels so now it should get the appropriate visibility.
Can you please elaborate on this? What type of configurability are you looking for? What other things do you think would make life easier for users? Please feel free to email me!
> GitLab offers a variety of support options for all customers and users on both paid and free tiers. You should be able to find help using the resources linked below, regardless of how you use GitLab.
Please highlight why and how GitLab support team is better than X with some examples. I really want to learn about real cases.
I appreciate you’re trying to be helpful but don’t really have any useful info.
Sometimes the very friendly PR tone is considered out of place and obviously forced. Especially on a developer forum.
[PR for devs must be so much "fun" - you have my sympathies]
I was pleasantly amused at the possibility of GL having a chatbot loose on HN but figured you were just a person trying to be helpful.
Comically, your response still could be generated, but I trust you enough that you don’t have to post additional proof you are human. Spend that resource on accurately counting the pets in the office.
They won't keep me as a customer much longer.
Not calling you out on this personally, just noting a general trend that's become really common the last few years.
I don’t see it from competitors nor do I see the long string of terrible complaints, handle your business in advance this doesn’t have to happen.
(It appears that Gitlab actually pays some of them to do this as part of their job, whereas for others it is not in their job description).
But yeah my team (of 3 members lol) was spun up primarily because Sid our CEO wants to make sure that everyone in the company is plugged into what users are saying about us, and he cares about hackernews specifically since GitLab was founded here [1]. So my team mainly just triages mentions about us so devs/managers/etc don't miss feedback but can still focus on their jobs. I do see first-hand that everyone in the company really does care about what people are experiencing.
[1] https://about.gitlab.com/company/history/#2012-gitlabcom
[1] (in case you care at all about my job description lol) https://about.gitlab.com/handbook/marketing/community-relati...
That said, I am quite surprized that Gitlab is growing so fast. I would be curious to know what is the source of most of their revenue. Are they targeting a specific cohort of users, which Github is not able to?
As for what Gitlab has that Gitlab doesn't:
* Built-in CI/CD that's actually pretty decent (easy to configure, you can restart subtasks, you can use your own runners)
* An issue tracker that supports estimates & time tracking. There are "solutions" for github that work with external services, but they cost money, and have strange workflows.
* The ability to self-host without huge piles of money.
* A lot of features that I'm not currently interested in, but others would be, like k8s and serverless support.
Those features may fade as GitLab gets bigger and gets more customers.
Also being responsive to users may bloat product eventually.
So it's not black and white situation.
Their Product team is the absolute worst too. There are so many things that can make life easier for users (better configurability for CODEOWNERS notification?) and they will flat out ignore you.
Gitlab on the other hand seem much more responsive to users... their actions speak volumes. They recognized the need for integrated CI/CD with code and instead of stealing TravisCIs ideas (cough GitHub Actions Cough), they built one years ago.
I really do hope they grow to be the tool of choice for devs. GitHub has lost its way: from being the place that devs loved, to a corporate soul sucking behemoth made of a seemingly insensitive product team.
Gitlab on the other hand, release new features, have better support, give interesting talks etc. Very excited to see where they go and I wish them the very best.