Gitlab More Than Doubles Valuation to $2.75B Ahead of Planned 2020 IPO

GitLab employee here. Thanks so much for the kind words - I shared it on our internal Slack as a #thanks [1] to the whole team (and specifically our support engineering group who I agree are AMAZING).

[1] https://about.gitlab.com/handbook/communication/#say-thanks

> Their integrated CICD is amazing.

My company switched to BitBucket in order to pinch pennies, and now I weep when I have to get Jenkins and BitBucket to play nice with each other or to do something. GitLab CI just works, is easily horizontally scalable without paying exorbitant prices for more "agents", etc... I miss GitLab...

Concur, trying to get my company to switch. It's the best solution to all modern ci/cd and devops problems: deployment figured out, easy to configure stages, integrate with docker and run integration tests out of the box.

Personally, I stopped using them after they couldn't be bother to give back to other OSS projects which they are using.

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 :-)

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.

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.

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

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.

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 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.

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.

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.

That's interesting, my experience with GH support is the polar opposite – they've been stellar. Particularly their enterprise support went above and beyond when we had issues and never did I feel I got either a canned response or even had to wait particularly long to receive an answer. At one point we had an issue with a flaky load balancer sometimes dropping connections, but the folks maintaining the load balancer were adamant that it was a fault with GHE. Even though I was certain it was the load balancer, I reached out to GH for support and they not only responded with helpful tips to determine whether the GHE instance had a problem, but also helped me build my case that it was in fact the load balancer that was at fault. Turns out the issue was a broken NIC on the load balancer, and GH support were instrumental in helping us figure this out, even though a perfectly acceptable response from them would've been "not our product – good luck; have fun" or something to that effect.

Really surprised to hear about your experience with their support, mine's really been nothing but positive. To be fair, I haven't interacted with them for well over a year now since I'm no longer involved in maintaining GHE. Did support take a hit after the Microsoft takeover?

We are Gitlab customers since 2017 and I can tell you that your expectations for what support can do for you are very unrealistic.

Per their own policy all they do is finding relevant tickets and send you there, from there on you are not their problem anymore. You as customers is also not a developer/product manager problem either, they do their planning and priotization using their own ideas and unless ticket is in the next milestone you won't even get response to your comments or suggestions for months.

There is literally nobody, who has your interests as part of their day to day agenda. Except for sales at the time of your license renewal of course :)

This time we are likely not going to renew and be switching to CE version after our current license expires.

I can totally relate to that. In flood of notifications I missed information about expiring CC. Instead of somehow soft-locking the account they just downgraded it and all my integrations, hooks and god knows what just blowed. I managed to fix the CC in 5 minutes, but many months after I am still recovering from that disaster. Support replied that they did send warning so I should just FO.

I had only very good experiences with GitHub support (on the limited number of times I actually needed it).

> GitHub has lost its way

I've been a very early adopter, and I do not have the same impression at all today.

Working with something else than GitHub is painful for me (& I'm using a number of other hosts for various clients).

> instead of stealing TravisCIs ideas (cough GitHub Actions Cough)

Not sure how you come to that conclusion. Even _if_ that were true, that would probably be a good thing now that TravisCI is on life support.

Not sure what exact experience you made with the GitLab support but I can tell you our experience is different. It took over two months to resolve a license request we made to their support (or sales team) with multiple pushes from our side, every week. There are bugs with the CI system like an issue with the cache retrieval when multiple jobs run in different pipelines parallel to each other, that is actually blocking us from using the cache to it's meant extend and that was issued in 2016. You will find a dozens of those tickets.

Just some examples. Wouldn't say GitLab is the heaven on earth GitHub isn't. It just has it's own, different issues.

I pay a princely $7 per month for GitHub and have always had surprisingly speedy, accurate, caring results-including follow ups.

Github Enterprise support has been awesome. We had an urgent issue and they helped resolve it within the hour.

> There are so many things that can make life easier for users (better configurability for CODEOWNERS notification?)

Can you please elaborate on this? What type of configurability are you looking for? What other things do you think would make life easier for users? Please feel free to email me!

Could you please tell more about your experience with GitLab vs GitHub support team? What kind of problems did they help (or did not help) solve?

Still waiting for them to respond about a month later. Chased up multiple times. Nothing.

They won't keep me as a customer much longer.

I don't know of anyone who uses Gitlab. We use Github at work, and I know several people who use Github at work. In terms of features, I can't think of anything that Github doesn't support. If something is missing, you can always find tools/services that integrate with Github.

That said, I am quite surprized that Gitlab is growing so fast. I would be curious to know what is the source of most of their revenue. Are they targeting a specific cohort of users, which Github is not able to?

> Having better support and being more responsive to users.

Those features may fade as GitLab gets bigger and gets more customers.

Also being responsive to users may bloat product eventually.

So it's not black and white situation.

I'm a non-paying user and for the few times I actually contacted GitHub they were always very helpful and fixed the bugs in less than 72 hours.

To be fair, I find the GitHub documentation to be really well done, it shows links to relevant articles, and tend to give a clear picture.

The few times I have contacted GitHub they have been stellar. Always replied very fast and generally quite helpful.

My experience is that yes new features might get released sooner, but bugs can linger unattended for years.

I've had the same experience with GHE support.

> GitHub support is fucking horrible

When did the support started being bad? (I never used their support)

The excitement for gitlab on HN has always been a combination of “open source enthusiasm” and astroturfing. From personal experience, HN is filled with tire-kickers who will hug the crap out of any halfway-usable product that they can “migrate to” for free (and abandon said product as soon as a payment form appears). It’s a misleading signal.

Even on this thread, you can count on one hand the number of commenters who actually say they pay to use the product. The trick is to use that noise to leverage yourself into markets where people actually pay money for things.

Thanks for highlighting this! I was lucky enough to get to be the shadow this week, and it's been an incredible experience.

The program is outlined in our handbook if you want to find out more info: https://about.gitlab.com/handbook/ceo/shadow/

We are nowhere near as valuable or successful as Gitlab but we also practice radical transparency, which means that all of our material conversations happen out in the open. This saves a lot of time and makes it much easier to stay on top of what is happening. Because many of our co-workers are remote we publish a once-per-month update that goes into substantial detail about the state of the business.

I'm a firm believe that companies should be run like that but many other founders like to play their cards much closer to their chests.

Hey, CI/CD PM here. I'd love to learn more about how you're using GitLab for mobile, if you're up for it ping me at @jlenny on gitlab.com. It's an area of focus for us, and it's always great to get to know another person who is using that use case.

I'm being pedantic here, but the reason I prefer pull is because it feels more general than a "merge," which to me precludes a fetch/rebase. I guess you could consider it a merge -ff-only, but in a mergeless-master workflow, "merge request" felt awkward.

As I understand they won't give up 'Merge Request'. But couldn't they at least make it configurable? 'Pull Request' was first and, as I suppose, is the preferred terminology by many.

They've positioned themselves as an all-in-one package for every tool you'd need to implement a devops software development workflow - source control, continuous integration/deployment, etc. Existing enterprises pay different vendors to implement all of these things; new and growing companies (in theory) just need to buy a GitLab license.

Because Microsoft paid for GitHub -- since GitLab is well positioned to compete with GitHub, cash rich companies like Apple or Google could be interested purely to keep up the Jones's.

Microsoft bought Github for $7.5B so it gives them a great comparable.

> I am curious how the Gitlab is so valuable. I've never used the service, but HN posts keep me informed superficially. Could someone explain the valuation?

FOMO from the VCs. It will implode.

The only company that could potentially be the one to pay the money already bought the valedictorian of the class.

The ones that are left are Google, Apple and Amazon. Google does not buy those kind of companies. Apple is not in that business and Amazon is... well... Amazon.

GitLab employee here.

Yes - if you bring your own runner to GitLab.com you can run unlimited build minutes on it - the build minutes we count are only those on our shared compute (2000 minutes for free, etc.).

The other huge benefit is that you can put that runner behind your firewall without poking any holes - itbjust needs access to GitLab.com and it can run your builds.

Yes, have been doing this for a year in autoscaling configuration on gitlab.com

Edit: see https://docs.gitlab.com/runner/executors/docker_machine.html

You can also do this with Buildkite without having to drag along the rest of the cruft that is GitLab. It’s free for individuals, if I recall.

Buildkite is an excellent CI tool.

Yep, we do this on GitLab.com - it’s one of the most well thought through systems I’ve worked with tbh. We use autoscaling EC2 spot instances for almost everything, incredibly cost efficient and unlimited.

It absolutely is. That's what we do at company I work for. We use free gitlab mintues and when it runs out we use runner running on one of our own local machines.

I'm not sure about gitlab.com, but you could always run a self-hosted instance.

what happened with the MM deploy ooi?

Yes. All of that said, if you're an insider with equity you'll have access to a 409A valuation, which does take all of that into account when coming up with the number. It's closer to what the market will pay for common stock in a theoretical IPO at the time of valuation. It's definitely not in any way what the market will actually pay in a real IPO.

I assume, not an expert here, that GitLab’s runners spin up when you make a push that triggers a build.

I’ve set up my own pipeline with Jenkins, Docker Registry, and Gitea and when I push a change to Gitea, a hook is called in Jenkins which starts executing relatively simple bash scripts for building images, pushing them into the Docker Registry, fetching them on my server, and restarting them.

Runners are almost certainly the equivalent of Jenkins here. A hook is called, and Gitlab’s runner starts executing some script to build images and assets, and deploys them for you.

If you add in tests things can probably get pricey.

But I bet you can have multiple runners building different parts of your system in parallel which is why their by the minute charging scheme makes sense (as opposed to number of runners required per build or something).

And it seems fair to charge you a combined total of ten minutes of processing time for two parallel runners, one of which started at the 0th second and ran for one minute and one which started and ran for 9 minutes.

If you don’t use it now, it can be a lot of initial work to set up, but watching your CI/CD pipeline chug along and deploy your work can be really really satisfying.

Was definitely overkill for my personal home page but really enjoyable to build and have it come together.

The runner is the piece of software that executes pipelines. You can install it on any machine and connect that to a gitlab instance. On hosted gitlab, they provide the runners, but limit how long you can these runners execute, which they measure in minutes.

Entirely optional. You can just use it for code, connect your own CI/CD or use theirs.

Just an assumption, but maybe the time each stage/step takes? Maybe there are improvements that can be made to Gitlab to speed them up, or something to that affect. (I don't know the specifics so this is completely a guess)

But I am curious... Why wouldn't you want to use a CI?

Hi - thanks for the feedback, we aren't where we want to be with performance. We are working hard to improve responsiveness and memory consumption, and have a recently started a team focused on just these aspects to accelerate the improvements. You can read more about the rationale here, including stories like yours: https://about.gitlab.com/2019/09/13/why-we-created-the-gitla...

One of the major projects the team is working on, is to switch from unicorn to puma: https://docs.gitlab.com/omnibus/settings/puma.html

We are also continuing our broader effort at improving performance each release, for example in 12.2 we had 58 MR's focused on performance improvements: https://about.gitlab.com/2019/08/22/gitlab-12-2-released/#pe...

Hopefully you will start to feel the impact of these investments soon.

Sluggish and nearly unusable describes every experience I have ever had with GitLab.

I'm spinning up a new architecture for my homelab and personal stuff and that slowness is why I'm installing Gitea for repos and Drone for CI/CD. The combo seems to give me everything I want without taking a huge share of my limited server space.

I thought the Github support department is called "Stackoverflow".

Thank you! GitHub is unchallenged in open source but it turns out you can change all the people in one company to a new tool without much of a problem, especially if you can replace 10 other tools.

We switched to Zulip because of a bad experience with Slack holding our message history hostage. At the same time we switched to GitLab because we didn't want a similar issue to arise with our issue tracker.

It was non-trivial to get the issues out of GitHub, and we lost metadata in the process. But now we're on a platform that has an "Export Everything" button, and in the worst case we can self-host our own data.

Although that's why we moved, and we didn't know about it at the time, "Service Desk" became a killer feature. That lets users file issues directly into our GitLab issue tracker by sending an email -- no account setup necessary. The majority of our users are non-technical and this has made it much easier for them to communicate with us.

Reasons for initially switching to Gitlab:

- Pricing structure made much more sense than Github's at the time. I would've been willing to pay for Github, but their pricing for private repos (now unlimited on the free plan) scaled steeply for any reasonable number.

- In addition to private repos, their free plan still offers many features that Github's free plan lacks, and their paid plans have many more features again than Github (Github focuses on polish, while Gitlab bundles the kitchen sink). While they may lack polish, some of these features are genuinely useful. Particularly around CI. Github's Actions API is an embarassingly recent addition.

- Gitlab Sites: their answer to Github Sites is an underadvertised and wickedly powerful feature. Github Sites really pales in comparison.

Reasons for staying:

- Responsive / active / communicative support team. Getting talking to Gitlab staff is incredibly easy.

- Proactively/playfully innovative culture, evident on tickets and MRs throughout their projects. I also really liked their approach to GithubLab: https://hub.gitlab.com/

- Transparent process. Finding out what's cooking in Github is frustratingly impossible, and why Github holds off supporting seemingly obvious things for eternity is just odd.

- The warm fuzzy feeling of storing my code on an open-source stack.

Reasons for wanting to leave:

- Stability and site performance have always been and continue to be abysmal. This seems to be a result of a reasonably good team being lost in a sea of complexity in a platform on which new features are prioritised over a simplified architecture. They do seem to spend a lot of time working on polish and performance, but never actually managing to achieve either of these things.

We use GitLab because you can self-host it. GitHub is not an option for us, because we must maintain control of our data and source code. So GitHub was never really an option.

But we'd likely be using GitLab even if we didn't have this limitation. There's a bunch of features that make GitLab better for our specific team / situation. From my personal experience, GitLab CI is better than CI options available on GitHub. We use gitflow (ie. feature branches in the same repo), rather than pull requests. And it seems like GitLab supports this flow well.

I also tend to like GitLab issues much better than GitHub. The time tracking feature in EE is really useful (not sure if GitHub uses this). And issue boards across projects is also a very popular thing where I'm at, because we have lots of repos, rather than fewer big ones.

We also heavily use the deployment / environment features and built-in prometheus.

I want to say it's the freedom to self-host, but really it's the CI.

Throwing a .gitlab-ci.yml file into my repo is by far the easiest way to get CI/CD incorporated into a product. The configuration of test runners (or lack thereof) is both a breeze and extremely powerful.

I'm not even talking about the auto-devops thing that I haven't tried; writing your own gitlab-ci file worked in frictionless ways that CircleCI, Travis, and (especially) Jenkins didn't.

The "Create merge request" (from issue) button.

It creates a new branch, with a smart name like 123-my-issue-title, and a new "pull request" for that issue and branch.

I'm not currently using Gitlab anymore, but in the past, it was their CI that won me over. I was always felt left wanting more though because there wasn't a true sense of community/explore.

If there's one thing I value most about Github today it's the ability to easily discover new projects and human beings; and Github helps tremendously with that whereas Gitlab I feel like you end up fighting the system to discover new and interesting things and people.

Our devops team loves Gitlab pipelines and pushed the decision through. If you're looking for a "killer feature" on Gitlab, pipelines is probably it.

As a developer I don't think there's a huge difference, especially since we don't use the issue tracking or wiki stuff (we're all in Jira/Confluence). My main complaint about Gitlab is that there are a lot of places where the UI is rough around the edges (lots of pages lack or have very minimal search/sort options) or has outright bad UX, as well as lacking some features that feel pretty basic to me.

My main complaints about Gitlab at the moment:

* Lack of search/sort, as mentioned above

* We created teams in Gitlab to mirror our scrum teams... when you look at the team list in Gitlab, it shows everyone who has access to the team, which is our whole damned Gitlab account. The only way to find the actual team members is to scroll down the list looking for users with a delete icon by their name (which removes them from the team).

* If you want to set a required number of approvals on merge requests, you also have to set the list of reviewers. I wanted to set two required approvers but let the devs assign who (normally their team)... no can do.

* Poor support for making merge requests build the result the merge (instead of just the branch). We've tried setting it up a couple of times, but usually end up with MR's hung because Gitlab doesn't firing the right builds and end up having to turn it off.

* If you have the server squash commits when closing a MR there's no way to set the commit message in advance; you have to type in the message just before you click the merge button. This wouldn't be an issue if it defaulted to using the MR description as the commit message, but it doesn't do that either...

Basically, corporate people are allergic to paid managed services and are afraid of proprietary lock-ins (unless a VP heard it was what all the other VPs were doing). If the open source software has support contracts, and is cheaper, they leap on it. We're actually moving off GitLab onto Github, because it's just... better. Not only because managing it internally sucks, but also Github is just more polished. Still won't pay for GitHub Enterprise though, because we're cheap.

Can self-host behind an enterprise firewall and get all the benefits of open-source software model within the company without exposing proprietary software projects to the whole world.

We can self host it, it had (and still has) a great CI (before GitHub had it) and personally it had free private repos before GitHub had it.

I'll admit that I mostly switched because of the MS buyout of Github.

The issue wasn't specifically because I have any particular issues with MS, but more due to the fact that Github can be bought. I felt like the epicenter of open-source software should be built on something open-source, especially when that open-source thing has nearly 1-to-1 feature parity.

I know Gitlab has a fair amount of proprietary stuff, but at least I can build my own Gitlab server for free on my own hardware if I decide that I really hate their free hosting.

My employer uses gitlab for most internal projects because of ITAR and other legal restrictions (aerospace). No external hosted services allowed, except obviously for released open source code.

At work: our campus has a local instance running, likely for code security issues, and so it integrates with our login service. Integrates nicely with JIRA and TeamCity as well.

Personally: I leverage both GitHub and GitLab. GitHub has the greater community, but GitLab Pages is far easier to use. So my workflow process is to have GitLab mirror GitHub repos.

Free private repos was a feature of GitLab, but once GitHub implemented that it just resulted in me dropping the paid tier I was on.

So I guess GitLab Pages is the feature I use it for the most.

It's open source and extensible.

Built in CI that you can run on your own servers trivially, free (private) docker image repo, great support for "teams", even free ones, which allows me to offer my CI boxes to my friends for their side projects.

I've had a few vague uptime issues whenever they get a big spike in popularity, but otherwise no complaints.

Private Repos by default, not owned by Microsoft, alternative to the established player, built in CI features.

I first used it for a free repo.

After using it, it just had a better vibe. Features seem similar enough for me, but it seems like Gitlab just lined up with what I want more than Github.

An example of this is the default page when I log in. On Github I'm given my activity feed -- which 90% of the time is absolute noise. Gitlab presents me with a list of repos, which is typically what I want.

It's easily self-hostable.

Self hosting is super easy with docker https://docs.gitlab.com/omnibus/docker/

Gitlab-CI is easy(ish) to learn and extremely well documented. The built-in container registry and artifact repo are super useful.

We need on-premise installation of Gitlab. Github enterprise was too expensive for a small team. Integrated CI/CD is a plus.

Possibly SEC rules and/or advice from lawyers to only say anything when needed - they are at or getting to a critical point in the journey. The PR/support staff can run the comments for now.

GitLab employee, pokstad is correct he's at GitLab Commit today! We're passing along stuff we think he might be interested in though ️:P

Busy today: https://gitlabcommit2019brooklyn.sched.com/directory/speaker...

Totally agree with this, I think a lot of it stems from Github getting open source code in early and Gitlab having free private repos. I use Gitlab because of that. All of the open source work I did is done through Github.

Ultimately, I'm glad they both exist, my go to is Gitlab though. And I'll be looking closely at their IPO to be an investor.

As far as I know we don't have any recurring reports on data like this, though I think we may have mentioned it in the odd blog post in the past.

My guess too. I'm almost tempted to start coding :)

Hi, GitLab employee here. Sorry to hear that! This funding should enable us to throw more resources at maturing some of our features (e.g. we tripled our employee count this year). We spun up this product maturity page to make this a little more transparent: https://about.gitlab.com/direction/maturity/

Hi! GitLab employee, we have an epic open here to improve diff performance: https://gitlab.com/groups/gitlab-org/-/epics/1816

It occurs as part of a fundraising process in which an investor invests money at a valuation that's double the previous one. As part of that there are forms filed that effectively say: "yeah just double it" but you don't file this forms outside of a fundraising process.

Hi! Better support for monorepos is in our roadmap, you can see our handbook entry here: https://about.gitlab.com/direction/verify/continuous_integra...

and the relevant epic: https://gitlab.com/groups/gitlab-org/-/epics/915

I mean, with GitHub's price being 7.5 billion, it's not outrageous as one of their leading competitors. I also was feeling like a Google acquisition wasn't impossible, they did move their entire platform to Google Cloud recently.

Microsoft and Google seem on pretty good terms lately, but right now, a lot of Google's public projects are posted on a Microsoft code hosting platform. I could see a day where Google says they need their own, buys GitLab, and moves over everything.

Oh it'll get acquired eventually, the question is when, and at what price, and by whom? How valuable is a Github competitor if nobody's leaving Github to use it? I don't see Google being interested; they know it won't make any money but from corporate users, and corporate users don't take Google Cloud seriously. Someone like Atlassian might be interested if they didn't already have 5 CI/CD solutions.