As a transparent company, our roadmap (what we spend time on) along with our strategy (why we spend it there) is public. https://about.gitlab.com/direction/ https://about.gitlab.com/strategy/ The "breadth over depth" section might help to shed some understanding.

Same issue, it seems to have become an "eierlegende Wollmilchsau" (German for Swiss Army knife, but with a negative conotation).

I recently move to gittea[1] for the very reason that I dont need 90%+ of Gitlabs features. Also Gitlab chews up RAM and IO, while gittea is barely noticeable even on a low end server. [1] https://gitea.io/

I have to agree a bit on the "Eierlegende Wollmilchsau". Features are not everything, regressions and degraded core functionality impact current users, which will impact whether you are getting new users in the long run.

For example, recently the number of characters before line-wraps in the MR diff view changed. Not sure if this was intentional or accidental. I know two companies using Gitlab, both based the max-line length in their style-guide on what fit the diff-viewer. I guess Gitlab became a worse tool for code-reviews for them with that change.

"You need to optimize for the people not using your product yet because it is missing features." doesn't sound very fair to current users, and I don't think that will work long term.

I’m not aware that we intentionally changed anything with the line wraps.

But if you go to User Settings > Preferences, you can select between Fixed vs Fluid layout width. Do you recall making any changes here recently?

Here’s an issue with some discussion on the design of fixed vs fluid options. https://gitlab.com/gitlab-org/gitlab-ce/issues/27347

Thanks for replying to this. The fluid settings will help, although it is not quite the same on small laptop screens as before the change.

At the same time I think the issue you link really highlights what some people have been saying: stable quality of the core product hasn't had the focus that customers would like it to have. Apparently you changed the line-wrapping behaviour twice in a year, without even realising that 1) you changed it, and 2) that some of your customers rely on this being stable. Of course you could argue that it was silly to rely on this behaviour, and that the new behaviour is in fact an improvement. But personally I think functional stability is important to all customers, and the fact that this was not a deliberate change is odd.

Obviously such a small change will never drive away customers, but I do think quality is the difference between having users and having users that are also ambassadors that will recommend your product.

Thanks for that quote. I wrote that when we were much smaller. I now release it was worded to strong. I'll change it to something like: "You need to optimize for all people, both the current users and people not using GitLab yet because it is missing features" when I land.

I've asked Victor to look into the max line length change.

I landed and changed the text https://gitlab.com/gitlab-com/www-gitlab-com/commit/bc9087f9... Thanks for noticing and caring.

Very cool to see that feedback is appreciated and that change happens fast at Gitlab.

I agree that GitLab is using too much RAM. Stan Hu, all time MVP record holder, will start working to reduce this. Options are removing Ruby code in Gitaly 1.1 and using multi threading in the application server.

What is all time MVP record holder? Is it a rails community competition or something else?

For every release GitLab gives an MVP award to the community member who contributes in an impactful way to that release. Stan has earned it the most times: https://about.gitlab.com/mvp/

The direct translation, "egg-laying wool-milk-sow", gets the point across fairly well.

Have you ever old software to an enterprise customer? Making your product look special by offering a bazillion features they will never use is surprisingly successful.

Only if you actually then invest some time in selling it. I've had radio silence from their sales team when requesting to purchase an self-hosted licence. The one thing I know about Microsoft (GitHub) - they _get_ enterprise sales.

Hi Simon, I work at GitLab. Sorry for the radio silence. I do know we prioritize follow up based on company size & order size. If a smaller company requests a few licenses it can slip through the cracks. I've tracked down your record in our CRM and am escalating to our sales team so that you get a response.

Thanks William. I look forward to hearing from them. We only have 10 days left on our trial.

In our environment, a vendor would probably be better served to offer a no frills basics thing and then just sell customization support (or painless customization). You could probably check off every bulletpoint imaginable and then we would still have things that need customizing.

That sounds like Atlassian's products to me. That can backfire after a few years of use when every page is customized to hell and back and no one knows how it works.

The biggest picture thing we're spending our time on is creating a single application for the whole DevOps lifecycle. See https://about.gitlab.com/2017/10/11/from-dev-to-devops/ for more context.

No ones giving money for bugfixes, folks. People who pay money choose the product they are going to buy according to feature lists. Good enough quality is good enough.

Perhaps not, but they stop paying money because of bugs.

It all depends on pro and cons. And if the gitlab people are doing this rather than fixing bug, is because they estimated that this is their best move right now.

It seems like an even mix of new features, enhancements to existing features, and maintenance.

some of their features are also pretty half-ass baked. like time tracking.

Is there any particular time tracking feature you are interested in?

at least some kind of reports..

Please see https://gitlab.com/gitlab-org/gitlab-ce/issues/25532 that has links to open an source application to generate reports from GitLab data. And the tracking issue to add this to GitLab is https://gitlab.com/gitlab-org/gitlab-ce/issues/37605

In GitLab Starter, we have the export issues to CSV functionality, which includes two time tracking fields: time estimate and time spent. Is this the kind of reporting functionality you are looking for?

https://docs.gitlab.com/ee/user/project/issues/csv_export.ht...

Anything else that makes sense that we can log an issue for?

if I need to write my own tool, than I probably don't need to pay EE for csv exports, since your api can export issue's as well.