GitLab massively behind GitHub in discoverability

I’ve favored GitLab over GitHub ever since the latter was purchased by Microsoft. It offers superior service in several ways, but there’s one important area that if not improved will ensure that GitLab forever remains an underdog. I write this out of worry.

When someone creates an open source project, perhaps one the of the greatest benefits they get from this is that if the project is successful this will greatly improve their resume and give them better job opportunities. Collaborating or networking with people on GitHub repositories is a very positive sign for employers as well.

GitHub is increasingly filling a similar role to LinkedIn. It has some social media elements and high discoverability for projects. Employers often have a field in their application forms set aside especially for linking your GitHub. It’s the place to have your open source contributions on for all to see.

Unless GitLab starts improving the social media and discoverability aspects, this trend will continue. And the trend will get massively worse if Microsoft figures ways to increase user lock in via network effects.

I don’t want GitHub to be the industry default.
I don’t want to feel like my projects are less likely to be found on GitLab.
I don’t want to feel like my projects are less likely to be contributed to on GitLab.
I don’t want to feel like I need to min/max my GitHub profile somewhat for job hunting purposes.

Currently, if you choose to host on GitLab, you’ll get fewer views, fewer stars, and much less interaction, let alone contributions to your projects.

I’m going to go through the relevant differences between GitHub and GitLab to show what the problem is exactly and hint at how it could be improved upon.

1. GitHub is much bigger and much more active.

GitHub reports having 33M users as of May 4th 2019. I can’t find any numbers on how many users GitLab has. My ballpark estimate would be 2-6M.

Though what matters massively more than number of users is how many high quality / popular repositories each has. The best way to see this is to look at all projects on each site and sort in descending order by the number of stars.

GitLab
GitHub

You will notice that after the 1st page on GitLab, you’ll start finding repositories with under 100 stars, meaning that past the second page there are no repositories with more than 100 stars.

You can go past the 100th page on GitHub and you will still see repositories with over 10k stars.

That difference is insane. Stars are not the best metric of high quality code, but it clearly indicates that a lot of people think those repositories are good. The amount of active repositories and how popular they are massively outweighs GitLab by a metric tonne.

2. GitLab’s Search and Explore Projects is deficient compared to GitHub.

GitLab:

• Offers two different interfaces from which to find projects: Search and Explore Projects. They compete with each other somewhat, there’s some overlap in their functionality.
• Explore button is nested in the Projects menu.
• Search does not let you order results by any criteria.
• Explore lets you order results, but lets you filter only by name (which also searches the description).
• Neither Search nor Explore seem to take tags into consideration. (Unless you manually write them in a GET parameter in the URL.)
• No cheatsheet available for advanced search features and no advanced search page.

GitHub on the other hand:

• Does not have the same Search vs Explore distinction. There is no overlap between Search and Explore. Search offers almost fully featured query capabilities. Explore lets you browse arbitrary collections of projects GitHub throws at you.
• Explore button is a top level button, directly visible on almost every page.
• Search lets you sort by many criteria.
• Search lets you filter by several criteria. Takes tags into consideration.
• Search allows you to use advanced search terms such as stars:>13000.
• Exposes an Advanced Search interface and a cheatsheet.
• Automatically lets you filter by language in a sidebar.

GitHub goes further:

• Generates suggestions for projects that might interest you based on projects you’ve visited and starred.
• Presents these suggestions in Explore and also in a sidebar on your dashboard/main page. This further establishes Explore as occupying a distinct and useful space from Search.

I almost never find myself exploring projects on GitLab. But I do it quite regularly on GitHub. A lot of things about the search/explore feel wrong to me on GitLab and I also expect that any project I might explore will be found on GitHub and not GitLab.

3. GitHub has stronger social media features.

I’m not a fan of social media and I imagine a lot of programmers aren’t either. But it helps users find each other, it gives the place a bit more of a community, it helps networking. All of this affects the growth of the user base a lot and how it’s perceived by employers.

• GitHub lets you pin your most important projects so they appear first on your profile, GitLab does not. This is important when your profile is representing you professionally.
• GitHub has a more attractive activity timeline than GitLab.
• GitHub presents profile data in a much better way. GitHub immediately lets you know how many repositories, projects, starred projects, followed users and followers a profile has. It lets you know how many contributions the person made in the last year. GitLab, on the other hand, only lets you know how many projects and contributions a person has made if you go and count them.
• GitHub aggressively informs you of what people you follow are doing. GitLab’s subscribe doesn’t seem to be in any way equivalent. GitLab only offers an Atom syndication feed.
• Subjectively speaking, I think GitHub hits several more tiny UI and UX pleasantness aspects that stack up and make it more fun to browse.

GitLab is great still. I think there’s a lot of focus on winning the “CI War”, which I do think GitLab has been doing.

But mark my words, neglect the Social War and GitLab will, ironically, always be massively behind Microsoft on how attractive the service is for open source projects that care about being discovered. Please don’t let that remain the case. I want GitLab to flourish.

@AnLog thanks for choosing GitLab and for taking the time to share such detailed and helpful feedback! I’m a Product Manager at GitLab, and your input is much appreciated.

Search and discovery is a priority. Lot’s of the open source projects I use in my own projects are hosted on GitHub, and I regularly find myself using their global search to discover new libraries, or see how other people are using them or mocking them out in their unit tests.

Right now we’re working on enabling Elasticsearch on GitLab.com https://gitlab.com/groups/gitlab-org/-/epics/153 which is preventing us from offering global code search on GitLab.com, but as you point out there are a lot of other discovery and search tasks that aren’t source code related.

I’ve created an epic https://gitlab.com/groups/gitlab-org/-/epics/1283 and quite a few issues based on your feedback for some of the filtering capabilities you highlighted, and I’ve also created https://gitlab.com/gitlab-org/gitlab-ce/issues/61524 to coordinate discovery and planning about how to remove the duplicate places for find projects.

As we continue to make progress on Elasticsearch you can expect to see some discussion on those epics and issues as we work out which ones to look at first, how they would work and when we can buikd them. Your feedback on any of those issues or epics would be very welcome, as would any new issues for anything we might miss!

I’ve also shared your feedback with one of our other Product Managers, Jeremy, who should be able to respond to some of your other feedback too

Thank you! Frankly, I didn’t expect a response.

In retrospect I was worried I came off as overly negativistic or proselytizing, and as time went by, I started seeing more silver linings. Such as the one mentioned in the GitLab Reddit I crossposted this to: the better distribution channels for language-specific ecosystems (e.g. crates.io, nuget) do in terms of giving people discoverability, the less the gap between GitLab and GitHub will matter.

Those issues seem right on the money. I seriously considered looking through a lot of issues before posting this, but their quantity felt really daunting, so I only browsed a little.

This does a lot to reassure me that GitLab does have its eyes open on this. I would never be as foolish as to think that I, with access to much less data, somehow have a better idea about how “run things”, but it is sometimes the case that companies just do not address some key challenges for one reason or another.

Having a proper search system will do a lot to move things in the right direction. I’ll look forward to progress on this~

@AnLog: Seconding what James mentioned above: thanks a million for such a thoughtful post. I’m super grateful that you took the time to share such extensive feedback. I never read these types of posts as “overly negativistic” and appreciate that we have users like you who are willing to share their thinking and passion for GitLab.

James spoke to some of the problems we’d like to solve on the search front, and I’ll (another PM at GitLab) chime in on your points around project exploration/discovery you wrote about in 2 and the social features you mentioned in 3. In short, I don’t disagree with any of your points and we’re planning to improve on all of the fronts you mentioned.

Exploring projects

• I agree that there’s some room to differentiate Explore and Search.
• We also plan on an improved Explore tab that takes a step toward improving project discoverability.
• You’re right that searching by project tag should be available without modifying a URL, and we’re doing that by adding filtering to the project explore tab now.

Social features

• We’ve explored pinning projects to a profile and will add this.
  • We want to extend pinning to groups as well. Group overviews are another opportunity to improve project discovery.
• We explored and implemented an activity feed redesign on the way to adding a follow user feature.
• For user profiles, you make some great points and I’d love to hear what you think of some of our planned improvements in this epic. You mentioned employer perception, which is a focus for planned improvements like enhancing social factors and eventually adding a CV/timeline to a profile.

As we iterate on some of these improvements, I’d be really grateful to have you involved in the process - please feel free to share your feedback/thinking on whether or not these proposals make sense to you, and please consider creating a new issue or two if we’re missing something.

What do you think?

I took the time to read through all of them and it was quite comprehensive. They’re all steps in the right direction, to the point that I suspected you had made all of them just now ;p But that wasn’t the case at all.

SO integration is interesting and not available on GitHub. Though pinned repositories are probably still the most critical of the listed features.

Any sort of trending feature will help seed a more active community really easily because features like trending are much more likely to help an individual repositories because there’s fewer repositories here that on GitHub, so there’s a better chance to actually end up on trending. But as the community grows, you’ll definitely want to look into splitting trending by criteria.

Related projects and interest-based suggestions are great ways to let more successful projects “infect” less successful ones, really looking forward to having those.

I’m slightly questioning the division between personal and contributed projects at all in the profile tab, as the repository owner becomes increasingly less important comparatively as the repository has more contributions from other people. I’m talking a bit out of turn here, in so far as I don’t know how groups/organizations work here, and this comment in particular hints at more complexity here than I was aware of. On some level the distinction is useful, since on GitHub you can pin any repository at all, so pinned repositories are just what the user is interested in and doesn’t indicate level of contribution. So GitLab’s distinction might turn out to be a better feature in that respect.

The activity feed issue also poses the interesting problem of being able to tweak your feed enough for it to be useful. On GitHub I struggle between it being filled with garbage and it being really empty and this is a place where GitLab could easily do better by letting users fine-grain set the kind of events being reported.

You might want to know when a close friend does a commit or something that has unique relevance like a user’s first commit, a user’s first repository with 10 stars etc. (achievements are a pretty good way to seed activity). But for most people, you probably don’t want to see what they starred today, or who they followed today, because if you’re following 100 active users that can fill your feed up super fast.

GitHub makes following an all or nothing proposition, GitLab doesn’t have to. And while the current activity level wouldn’t make the fine-graining a very impactful feature currently, it’s probably a good idea to future proof a design by having that in mind? GitLab is already ahead here by having a dropdown menu that filters by event type. That’s not a per followed user fine-graining, but it’s still something useful.

I’m not sure I have much else useful to add right now. You’re on the right track. GitLab is offering me a free service and I don’t really make it a secret that I find it to be a much healthier company to have in the industry doing this than its competition. Having this level of interaction with the staff only confirms that belief for me. So I’m happy to strive to keep my feedback helpful as the issues progress.

GitLab should consider this as top priority features!

Hi guys, Is there any update on this?