I had a similar experience where we had gitlab in a previous job(recent past.)

The scattered focus seemed to be manifest for me anyway in their documentation. Finding documentation often involved going down a rabbit hole of user issues rather than looking in the official documentation. Additionally I found a lot of the documentation seemed incomplete and read more like internal notes than anything else. The contrast being github which has very polished and thorough documentation.

https://docs.gitlab.com/omnibus/update/

This page links to the following "upgrade recommendations" resource:

https://docs.gitlab.com/ee/policy/maintenance.html#upgrade-r...

This above page states "We encourage everyone to run the latest stable release", we contains an embedded link. And when you follow that link it returns a 404 with a cutesy error page! See for yourself:

https://about.gitlab.com/blog/categories/release/

Further none of those pages explains how to pass in a specific version of the omnibus package to satisfy the upgrade process in the even that the latest version fails because the upgrade version differential is not supported.

It was really frustrating. And this is but one small example of course. But I think this is typical.

I've raised an MR to fix the broken link issue: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21820. It'll be merged in due course.

I've raised an issue on our documentation to have the second point you raised looked at in more detail: https://gitlab.com/gitlab-org/gitlab-ce/issues/51666.

Thanks again!

There are so many different places containing parts of the docs about your CI, for example.

I don't think it's just a familiarity thing; I've been using it for months and still haven't adjusted. Gitlab's UI/UX has gotten better by leaps and bounds, and I prefer it to BitBucket, but it still feels like it has a ways to go.

Why move unless there's a compelling reason to?

I don't care about the integrations on Gitlab because it already has everything I need, plus they ship new features at a rate of more than one per decade.

That said, I rather miss the minimalism and focus on individual developers (vs organisations and processes) of early Github.

I find both Gitlab and Github have plenty of focus on the dev (Github more so). It just so happens that Github has developed a lot of tooling for orgs and projects since.

Compare to Bitbucket's profile pages for example: https://bitbucket.org/astanin/

Obviously, this comes down to opinion, but honestly: yes. In the case of GitHub, the point where I reached that conclusion was when they added built-in enforcement of code review workflows. A feature which I seem to recall they copied more-or-less directly from GitLab...

(And I'm not saying it's wrong for everyone. But diversity is nice...)

Github, when it came out, was the only platform that even had proper profile pages for developers. They coined the whole "social coding" thing. I find that whenever I interact with other people on the site, I actively look at their profiles, their contributions, etc.

An example of a recent-ish feature they added which IMO is a good example of "focus on the dev": Comment authors are tagged as "Owner", "Member", "Contributor" and "First-time contributor" in comment streams.

Yes. There are always trade-offs, especially when you're adding user-facing features as slowly as GitHub [1]. The author tags are one of very few that focus on individual developers. About the only other one I can think of is the option to curate the repositories that appear on your profile page (welcome, but took years of asking...)

[1] Which isn't, in itself, a bad thing -- stability is good, and GitHub's launch feature set turns out to be a pretty good match for what I want)

This turns out not to be the case. Sourceforge had many or all of these features in the early 2000s.

Usability matters. Sourceforge was atrocious.

And to your first "question", no. It had them in almost exactly the same incarnation as modern sites, but with a UX design language rooted (fatally) in the "best practices" of the web at the time. Unlike all the crazy things you'd have to do around FTP to get it to act like DropBox, SourceForge had the mentioned features built in from the start.

It doesn't really win GitHub any prizes to pretend otherwise, so I'm not sure why the pushback against simple facts.

I guess in some sense you could say it's a focus on organizations, but on the other hand it's a glaring omission of a feature that you could have implemented with a pre-receive hook years before either GitLab or GitHub had it, so it would be strange if they didn't add it.