There are some high-profile FOSS projects using GitLab, but they're not as visible as they would be on GitHub because they host their own instances:

- https://gitlab.gnome.org/

- https://gitlab.freedesktop.org/

- https://salsa.debian.org/ (AFAIK this is an ongoing migration)

Others are considering a migration:

- KDE: https://gitlab.com/gitlab-org/gitlab/issues/24900

- GNU Emacs: https://gitlab.com/gitlab-org/gitlab/issues/28152

Maybe someday we'll have federation to work around this: https://gitlab.com/gitlab-org/gitlab/issues/30672 :-)

We have over 700 users on https://lab.civicrm.org (a FOSS CRM for non-profits). While bits of the project still rely on Jenkins and Github, having most of our community on Gitlab really changes the dynamics of the project.

At first people were worried about losing contributors because "everyone is on Github", but increasingly it's the other way around. We have a lot of accidental techies who start issue tracking, testing patches, etc, and so it's nice to have a clear project structure.

And Drupal just finished switching over (self hosted).

The Debian migration is actually finished.

Awesome, as a long-time Debian user myself that makes me very happy :)

I notice that the Qt project has a GitLab instance:

https://git.qt.io/public

But everything seems to be done on their Gerrit for now.

U-boot just made the transition.

It's the network effect. GitHub was first-to-market. Almost all open source contributors have a GitHub account these days. Many older projects started there long before GitLab was a viable competitor.

Now assume you're starting a new open source project. Most of the other open source projects you've seen are hosted on GitHub. Most of the other developers you interact with have GitHub accounts. GitLab has all the same features and is slowly growing, but still isn't nearly as popular as GitHub is. Which platform do you choose for hosting your project?

GitLab is certainly a worthy competitor, but unless there arises a strongly compelling reason to switch I can't really see it overcoming that barrier and becoming the new de-facto standard for open source projects for quite some time.

I disagree that signing up for an account at gitlab.com is a barrier. Anyone willing and capable to make contributions won't be stymied by that step. There's even a "Sign in with GitHub" button..!

I think the biggest thing is the context switching between different projects. I have open source projects that I wouldn't be able to move to GitLab as I would have to coordinate the move with all the other collaborators and make sure the users of the repository are aware that the new code will be in GitLab.

Gitlab doesn't have even basic notification centre, people been asking it for years.

Github API integration is stellar, API token permissions can be configured granularly, Github apps marketplace is awesome way to start using third party services.

First class integration experience is opposite from Gitlab goals, they try to be everything and capture every single usecase and it shows .

Hi, we do believe in the single application offering the best long term user experience and outcomes, but do understand that all of our features may not work for everyone. This is happens for a variety of reasons (completeness, migrations, specific project requirements, etc.)

Because of this, we do offer our API and the ability for our community to contribute integrations directly to the codebase. We have a pretty rich set today, you can see at: https://docs.gitlab.com/ee/user/project/integrations/project...

We're also working to further improve our integration options, with a dedicated team: https://about.gitlab.com/direction/ecosystem/. This team will be responsible for our broader API, an upcoming SDK, as well as continuing to improve our existing integrations like JIRA and Jenkins. This team is just getting under way, but I wanted note our investments here.

> Github API integration is stellar, API token permissions can be configured granularly, Github apps marketplace is awesome way to start using third party services.

PAT granularity has indeed been a pain point, and we should be solving this soon by offering the ability to restrict them by groups/projects: https://gitlab.com/groups/gitlab-org/-/epics/182

Integrations go both ways. While Gitlab debates how to strip down Junit XML test result processing or represent arbitrary artifacts , Github has Checks API https://developer.github.com/apps/quickstart-guides/creating... where any third party system can provide feedback on a pull request and even veto it's merge.

Gitlab has many strengths, but integrations is by far the weakest one.

It's a barrier not just because of the sign up process which might only take a minute or less.

It's the ongoing thoughts that go through your mind like using github 99% of the time but having to context switch to a completely different app / UI for that 1 other project that uses gitlab. Unless that 1 project is incredibly useful then most of the time you'll talk yourself out of signing up or even browsing the repo (let alone contribute to it).

It's almost like people who use mailing lists for bug reports. It's such an out of place / cumbersome thing to sign up for vs filling out a github issue that you've done a 100 times already.

The power of familiarity is real. It takes astronomically sized benefits to get people to switch and from what I've seen gitlab has not done that (not because they are bad, it just hasn't happened yet) and the proof is in the results. If they did offer a massively better service than github then people would have already switched for open source projects.

You might be right but it sounds pretty thin. Are developers really roaming the internet aimlessly in search of something to develop on, and decide based on whether it's hosted on github or gitlab? That's not consistent with my experience, I use gitlab, bitbucket, github, gnu savannah, etc, due to various scattered projects and I don't find that the git hosting platform even registers as a consideration when finding projects to contribute to.

On switching -- from GitHub, yes you might need some compelling reasons to go through all that resetup work. Migrating to GitLab from some ageing bespoke system is a much easier choice.

I remember the supposed mas-exodus that would occur when Github was acquired by Microsoft.

Many still choose Gitlab, since it's not associated with MS.

Or simply want a self hosted solution.

Or prefer open source software. If all fails we can read the source or even patch it.

That said I must say it has worked well enough for us, that the occasional swearing that it does not do what we want has been the more comfortable solution than really patching it:)

Search friendliness.

Quite a few open-source projects rely heavily on being findable, and often use their Github README as a sort of "marketing site" for developers.

Finding projects organically on Gitlab is a nightmare.

A related note is that Github repos have much better SEO than gitlab repos. It is probably a combination of Github being weighted more heavily by search algorithms, but also because Github has a far better network effect. I've tried searching for a repo that is hosted on Gitlab, that is an extremely well written Pytorch library with hosted HTML documentation, etc, and it wouldn't even show up on the first page of Google search results. Meanwhile, a couple of repos on Github with the same or similar names (of far lower quality) were in the top-5 results. The only way I could reliably find the repo is by adding "Gitlab" to the search terms.

I'm also convinced that the repo would be quite popular were it posted on Github because many related Pytorch repos on Github with far poorer code quality and documentation have 1000+ stars. As much as I love Gitlab, it is very hard for me to use anything but Github when working on an Open Source Project that I want to get lots of eyeballs on and hopefully the satisfaction of having other users use my code.

It's worth mentioning that Gitlab does facilitate mirroring to Github in quite an easily configurable, pretty zero-maintenance way.

This of course won't benefit Gitlab's SEO in the long run, but it does allow using Gitlab with less of the cons.

Search in general in Gitlab is painful. Searches seem to require 3 or more characters, but if you put two you just don't see any results. No warning saying add more. Pretty intuitive.

The file name search is pretty rapid though.

We have an ongoing project to enable Elasticsearch on gitlab.com, which will greatly improve this: https://gitlab.com/groups/gitlab-org/-/epics/153

There's also a dedicated Search team being built at the moment to focus just on this.

That's good to know, thanks!

Gitlab is one of the few products where I look forward to each release. You guys are doing a great job at keeping interest high and your communication is great.

Github search is not much better.

I've resorted to using google search and append site:github.com to my query.

When was the last time you found a project organically on GitHub?

Not sure what counts as organic, but if I find a project that impresses me on github I often click through to their repos and scroll through to look for other gems. I found bottle.js that way a week ago.

I also cross reference people from Twitter if they seem smart. And I click back and forth between NPM pages and GitHub pages to see people’s work.

Some of that is pretty doable if they switched to Gitlab... except the Twitter cross reference, just because I would have to remember to search both gitlab and GitHub.

Well, organically is a vague term. My usage of it was: go to GitLab/Hub and type into global site search box to find a project.

This seemingly simple action does not work on Gitlab.

To answer your question, I do the above often on Github. Probably found projects that way as recently as last week.

Interesting. Site-wide search in both cases has almost always been next-to-useless for me.

We are offering our top tiers (Ultimate or Gold) for free to open source projects [1]. You can see the complete list in our repo [2]. Some of the most recent projects that received our free license are Arch Linux, the Tor Project, edX (currently migrating). Just to add a few more: Drupal, Haskell, VLC, Kali Linux, Lineage OS, and more on this comment [3].

[1] - https://about.gitlab.com/solutions/open-source/program/

[2] - https://gitlab.com/gitlab-com/marketing/community-relations/...

[3] - https://news.ycombinator.com/item?id=18724015

Part of the application for open source projects here requires you specify how many "seats" you need.

> The number of seats is the number of different users that will use this license in the next year.

This seems counter to how many open source projects work where contributors come out of nowhere to make a contribution and may or may not stick around. How does this work when you have hundreds or thousands of unique contributors a year, and you have no good way of predicting?

Note: not a GL employee, but EE subscriber

IIRC seats are calculated based on monthly active users, and are a soft cap: we've outgrown our license, so we will have to retroactively buy the missing seats on our next license renewal.

I expect this is no different from a OS license, except that that OS project doesn't pay for the license.

Corporate usage.

GitHub is the standard so pretty much everyone has a GitHub account, companies ask for GitHub accounts on applications, it's the hub currently.

GitLab is the superior product in all regards, but GitHub has the network.

>GitLab is the superior product in all regards, but GitHub has the network.

I could agree on features, but not UX. Github is still the king.

I'd like to share more data on the UX front. There are two efforts underway to establish the experience baselines [1] as well as a common design system [2]

Hopefully these efforts allow us to look at our UX holistically, and to focus on making high-quality components that are used throughout the product.

[1] - https://about.gitlab.com/handbook/engineering/ux/experience-...

[2] - https://about.gitlab.com/handbook/engineering/ux/pajamas-des...

One thing that bugs me really hard about gitlab.com (and gitlab ce) is the broken flow when I come about an interesting repo and want to star it. I'm logged out, click on "Star", log in and I'm at my profile. I have to navigate back to the repository in question and click "Star" again.

Other than that it's really great software. I wouldn't want to miss running Gitlab CI.

The github pull request UI is severely lacking. Even something as simple as being able to see changes that address PR comments is surprisingly difficult.

When I was applying for jobs recently, a few of them had explicit GitHub link fields, sometimes even regex validated to ensure ONLY GitHub links got posted.

I didn't finish filling out those applications.

Echoing that. I was looking for several jobs as a senior dev. 15 years of work experience in corp. environments do not necessarily result in much GitHub activity -- I discarded every opening that required linking your private repo.

Looks like freedesktop.org hosts their code on a private GitLab instance now: https://gitlab.freedesktop.org/explore/groups

I'm guessing GitLab will slowly gain more and more traction in the OSS community. It hasn't been around for nearly as long as GitHub, and has several compelling reasons to be used over GitHub specifically for open source projects.

> Does anyone know why GitLab hasn't taken off so much amongst open source projects?

The marketing is pretty bad for one. Go to gitlab.com and you see a site that is mostly extolling the virtues of their commercial product and pricing. There is a "try gitlab for free" but it is aimed very much as a try-before-you-buy for businesses. That's all good and fine, but it is the polar opposite of how github went about acquiring their network. github was marketed heavily as a social site, their marketing was viral.

I don't think it is wrong, but if gitlab is trying to convey messaging that they are "social coding" platform or even an open-source project host, and not just b2b, they are doing a pretty poor job of it.

I recently started to ship around for hosting solutions and this showed me how much github is leeching off the openly visible projects. Everything is focussed on making projwcts and users as visible as possible. Site wide search, directories of hosted projects, free user account to get started as a contributor...

Extreme SEO for hosted public projects aerves as a marketing trojan hirse for their commercial offers. At the same time, the networking effect forces everybody to stay on github or massively lose visibility. The frustrating part is that most other hosters don't get that - especially none that support some actual VCSes instead of a glorified patch database manager.

If I could stomach writing all the web frontend and plumbing stuff for a hosting service and doing all the marketing, I'd try to start my own. I have harder and more interesting problems to solve, though.

I dont understand their UI at all. Whenever some project is hosted on gitlab I just stare at the page for a while and give up.

I work on git hosts integration, we aim to support Github, Bitbucket and Gitlab. I don't understand Gitlab api just like I don't understand their UI. It's confusing. For example while the others call Repo as Repo, Gitlab call Repo as Project, and call Tree as Repo.

I understand your point, however I've come to enjoy the separation between Git concepts (Repository) and GitLab features (Project, Issues, CI/CD).

That said, I still find GitHub's UI and UX more appealing.

Do not just stare, hover over the icons.

SEO and the website isn't as friendly to navigate as Github is. Github makes your project look like a first class citizen while Gitlab has too much going on.

On-premise hosting. This is so important to organizations that can't use internet hosted services, for all sorts of various reasons.

Github Enterprise.

The pricing for GitHub Enterprise is "Contact Sales", which as a smallish yet privacy focused company we don't even bother with anymore. That uncertainty plus the keyword "Enterprise" have always amounted to "ridiculously expensive".

That I agree certainly agree with. However, the other approach is the one that certainly should put a damper onto the valuation.

Honestly for me it's mostly because I started using GitHub first. The products aren't that different to me, mostly because I'm not a power user trying to squeeze the most of every last feature.

To overcome an entrenched competitor with network effects, the upstart has to be significantly and obviously better for a new project to adopt. To maintain market and mindshare, GitHub doesn't have to become/stay better than GitLab; they just have to be good enough, or at least appear to be.