[samcday]

I recently started a new position at a company that is using Gitlab. In the last month I've seen a lot of degraded performance and service outages (especially in Gitlab CI).

And then I see stuff like this that makes me scratch my head: https://about.gitlab.com/product/service-desk/

If anyone at Gitlab is reading this ... please, please slow down on chasing new markets + features and just make the stuff you already have work properly, and fill in the missing pieces. Example: https://gitlab.com/gitlab-org/gitlab-ce/issues/63880

[tylfin]

> please, please slow down on chasing new markets + features and just make the stuff you already have work properly

I really agree with this. I was working at a company where we were exploring switching from Github enterprise to Gitlab for the K8s integrations, the docker registry, and the CI features.

Following the helm chart installation instructions was a nightmare because we were on-prem w/ a custom cluster. There were a lot of assumptions we had to find workarounds for (e.g. we used an f5 integration to manage our ingresses and performed SSL termination elsewhere so the nginx thing was awful).

The other terrifying bit was the number of services / pods that got brought up with the installation. If I have to monitor my team's services, I really don't want to monitor the health of: NGINX, Postgres, Redis, Minio, Registry, GitLab/sidekiq, GitLab/gitlab-shell, GitLab/gitaly, GitLab/unicorn, and GitLab/migrations.

When it comes to on-prem or self-hosted software I actually prefer running a monolithic application that worst-case I can just bounce or reboot the server.

Slow down, simplify things, and improve the user experience. Gitlab already has enough features to be competitive for a while with the Github + marketplace model.

[citruspi]

> When it comes to on-prem or self-hosted software I actually prefer running a monolithic application that worst-case I can just bounce or reboot the server.

So why not just skip the helm chart and install the omnibus package on a dedicated server? If you want you can even disable stuff like the omnibus Postgres/Redis/etc and manage those yourself elsewhere.

That's what I do - run the omnibus package sans fancy helm chart - and it works out pretty well. Granted it does require a fair bit of RAM to run smoothly.

> Slow down, simplify things, and improve the user experience. Gitlab already has enough features to be competitive for a while with the Github + marketplace model.

Completely agree with this and what the parent said - I think this is part of why running Gitlab seems to require an ever increasing amount of compute resources :(

[maverwa]

> That's what I do - run the omnibus package sans fancy helm chart - and it works out pretty well.

Can second that. Hosting a instance for our (quite small) dev team on a kinda-small VM and the GitLab Omnibus Package has been one of the nicest (while biggest) piece of software to administrate. Updates are super smooth, the things we use seem to be stable over the last two years. Only three unplanned downtime’s in that time and all because our hoster is plain terrible (hi Telekom!).

[kennyGitLab]

For a bit more about WHY we choose breadth over depth - We believe that the company plowing ahead of other contributors is more valuable in the long run. It encourages others to contribute to the polish while we validate a future direction. You can read more on our company strategy page - https://about.gitlab.com/company/strategy/#breadth-over-dept...

As open-source software we want everyone to contribute to the ongoing improvement of GitLab.

[rightisleft]

"We're Open Source!" isn't a valid defense when you have paying customers. That pitch sounds great for your VCs, but for someone who spends a portion of their budget on your cloud services - i'm appalled.

Gitlab is a SaaS company who also provides an open source set of software. If you don't want to invest in supporting up time - then don't sell paid SaaS services.

[godzillabrennus]

Your logic and reason have no place in VC land.

They need more users!

[jacques_chester]

> We believe that the company plowing ahead of other contributors is more valuable in the long run. It encourages others to contribute to the polish while we validate a future direction.

I feel like this is a non sequitur. There's no reason why breadth would increase outside contributions other than sheer surface area, but that relationship isn't very linear, especially if the surface area is being created by Gitlab rather than others.

Meanwhile, "polish" is often the unglamorous work which people typically don't want to do for free.

Try to imagine an exchange at Torvald's Bazaar and Emporium. Gitlabbers offer to work on the fun stuff and get paid for it. In exchange they ask everyone else to work on the boring stuff without being paid.

For some mysterious reason, this exchange fails to happen.

[bdcravens]

I think I understand the perspective, but the messaging sounds a bit like, "Pay us full price while serving as our beta tester; sacrifice the needs of your company so you can fulfill the needs of ours"

[aeyes]

Wait, you are saying that your current customers aren't valuable?

Thanks, I am now convinced that I'll never do business with GitLab.

[afandian]

We are paying money for the service. Yesterday we did not get good value for money.