I'll admit that I was wrong about GitLab. I had the chance to invest in them way back in the day, and passed. My thought at the time was that no open source company had ever been super successful except RedHat, which was more of an outlier than a pattern. And my other thought was that they are competing against GitHub, which was extremely popular and well funded.
I honestly didn't think they stood a chance.
I'm happy to have been proven wrong. Congrats to the whole team on their successful exit!
Disagree. Github's self-hosted product is trash compared to Gitlab. Plus they were very late to the game when it came to stuff like CI, package management, project tracking and a whole suite of enterprise features. Github had (and still has) a huge lead in public open-source development, but that's it.
While yes, my first usage of Gitlab was an on-prem install, things really took off with Gitlab.com in ways I don't think anyone expected with healthy competition from Bitbucket and Github. I do think it was the unlimited free private repos with unlimited contributors that really skyrocketed the success of the Gitlab.com path.
Github is initially B2B SMB and B2C and Gitlab is B2B Enterprise. 10% of Github employee are sales , 25% for Gitlab. I would say they are not even competitors
We have been happy customers for many years. It has been a breeze to manage and upgrades, backups, and DR have been very good for us. For an on prem software of this complexity it is quite a feat. It has also always been at a very reasonable and affordable price point for enterprise-y on prem software. As an infosec consultancy that used it for projects and code we always appreciated being able to manage the security of our installation.
I've found that my bar for investing is the same no matter what kind of company it is -- how quickly can they sell me on investing? As much as us engineers hate to admit it, the most important skill for a founder is the ability to sell. Besides the obvious of having to sell to customers, they also have to sell their vision to VCs, sell their company to potential employees, sell their vision to journalists and potential customers, etc.
If I'm not convinced to invest after one meeting, I usually don't invest. On the other hand, if I'm convinced after five minutes, I'm usually asking where to send the wire by the end of the meeting.
Armory is a good example of an open source/open core company I did invest in. They had me convinced in just a few minutes. They had an answer for every one of my objections and made me feel like I'd be missing out if I didn't invest. And so far they're doing really well and it's one of my best investments to date.
> ...how quickly can they sell me on investing? As much as us engineers hate to admit it, the most important skill for a founder is the ability to sell. Besides the obvious of having to sell to customers, they also have to sell their vision to VCs, sell their company to potential employees, sell their vision to journalists and potential customers, etc.
As cynical and hollow as it sounds, pretty sure this advice is consistent with what I have heard in multiple videos and blogs from YC.
Have an answer to every objection. First figure out all the ways you would object and make sure you have an answer, then note down any objections you don't have an answer to during your process and make sure you have a good answer next time.
And if you're selling a product, make sure you know your competitors well because a lot of objections will be in the form of "but competitor X does this, how do you solve that problem?" and "what do you do that X doesn't do?". So you better know X really well because the person you're talking to already does and will know if you're making stuff up.
I’ll echo a sentiment I also had but perhaps I was wrong. I believed that users of GitLab used GitLab because they didn’t want to pay a premium (or pay at all) for GitHub; thus I viewed it as a cheaper alternative in the same vein as buying a Hyundai vs buying a Mercedes. I assumed only frugal “developers” were using it, and surely any legit companies would opt for the superior GitHub.
Just one user here, but I definitely prefer GitLab over GitHub.
Not because GitHub is bad in any particular way, I just like the feature set and UI of GitLab better. Less of a "Hyundai vs Mercedes" thing, and more of a "Ford vs Chevy" thing.
They're both decent and they both have approximately the same level of "premium-ness". They're just feature-wise and aesthetically slightly different in arbitrary ways. And some people either do or don't vibe better with the one or the other.
Interesting comparison with cars, I would think a Hyundai is much more reliable and less expensive to maintain than a Mercedes, and Hyundai is now being positioned as a more premium brand than it once was.
On topic, GitLab is great at CI/CD and awesome for self-hosting things.
That'd be me, but I stuck around because issue management on GitLab is miles ahead of GitHub - however... if GitHub added scoped labeled I'd have a hard time convincing myself to stick around as the sheer number of users + discovery features blow GitLab out of the water.
VCs are the most risk averse people you will meet. They pretty much only look for patterns. That's why it's so hard for minority/female founders -- because it doesn't fit their pattern. I actually invest mostly in minority/female founders for exactly this reason.
NOTE: I'm not associated with GitLab at all I just found the topic interesting. I don't know of many other projects that actually do things this way, with all the commercial licensed code mixed in with the open source code.
It is not. They're better than most – and I know that's not a high bar, but they clear it by a wide margin. Nonetheless, their software is better described as "open core".
Gitlab always felt like a set of checkboxes to appease non-technical managers. In my experience, most features are half-baked. Even the code review/MR experience is frustrating compared to GitHub. The UX for security scans is _really_ rough.
It feels like at first, Gitlab was trying to build a few great features, which is how we got CI, but then they started instead to focus on breadth, and that’s how we got everything else that’s now in the product.
I work for two clients (one of them is a huge German company) as a consultant who are both using GitLab simply because they can host it on their infrastructure. Makes it easier for them to satisfy internal security policies I guess.
Microsoft is the largest open source organization in the world today. What else do they need to do to gain some kind of trust? I love what they do with Github since the acquisition. VSCode is amazing. They've open source most of their programming language. Github is free for open source org and there are no limits to the CI usage.
Trusting Gitlab more than Github is naive at this point. They are in the position of needing to generate as much revenue as possible to satisfy their investors. Github is not in this position anymore.
> What else do they need to do to gain some kind of trust?
Stop doing shady shit. The whole .NET Foundation kerfuffle from last week... Or concerns about how Copilot trains its data...
I like some of the open source work they do. It's nice that they opensourced LSP and built VSCode. I like some of the language research they do (their contributions to Haskell, Pony and F* more or less originated there, plus their mainstream languages) but can't shake the feeling that they only embraced open-source to get developers back on their side after losing out on mobile and much of the initial cloud rush.
Anyhow, I use some of their stuff, but I only trust the licenses, not the company. Not huge on having them lock me into a platform.
Like any big company, they have no ideology beyond making money. That actually makes it easy to trust them in a certain sense: they're not going to do things that don't benefit them, but they're not going to do something utterly crazy the way ideology-driven organizations can.
I agree that the main reason they're doing good things for developers is to get developers on board. But that doesn't negate that they're doing good things for developers.
But that's the whole problem with "trusting" microsoft. Their stated motto used to be "embrace, extend, extinguish". How do we know that has seriously changed on all levels?
I do not believe that Microsoft is fundamentally on board with the open source model. Its an alliance of convenience. If suddenly they think they can make more money some other way, they'll do that. They might not even actually destroy anything explicitly, merely ruin things out of indifference.
"Gitlab CEO here, getting rich and feeling proud" [1] ;-) – congrats to the Sid, Dmitriy, and the rest of the Gitlab team. Always appreciated your presence on HN.
We've been GitLab customers for 2-3 years now (what was attractive was having "everything in one SaaS subscription") and it's worked out quite well.
There's always papercuts for sure and the product could always use more polish, but overall it has been nice to have most of our dev processes under one umbrella.
Now when is Hashicorp going public? I've got my wallet ready for that one.
I used to work at Uber's Amsterdam office at a time where the remote nature of the office (from SF HQ) was a struggle for some teams because of strong dependencies on teams located at SF HQ.
Sid came to the office and talked to us about some strategies Gitlab used for remote work, timezone differences etc.
Not only the talk was very helpful, Sid was an incredibly clear communicator, calm and humble. He really seemed to be a great leader and someone it must be nice working with.
We used this as a template the year before the pandemic to get our mostly remote teams working well. Once the pandemic hit, there were few issues we had to address.
A paid user + big fan of gitlab. They exist in a strange valley between github and Atlassian where usability has remained high while also being featureful.
Their kanban is 10% more functional than Trello, which is all our small team really needs, they give you everything and they don't nickel and dime you.
The only feature I would like to see improved is their PR process. Seems a bit buggy with remotely large changesets, and the digest for the PR should provide a bit more context to reviewees.
Yes! Gitlab's offerings are great, and our team doesn't even scratch the surface of what's possible with its feature set.
That said, MRs with over 1000 lines of changes are painful sometimes impossible to review. Even small MRs feel clunky, due to how many panels there are (yes, I know they're collapsible). Because MRs are one of our most used features, it sometimes makes me consider switching to GitHub for their much nicer PR UX/UI.
yeah there seems like there is some web -> idea connection that should exist for super slick in-IDE reviews. Best reviews means most context, IDE has the most context about the code (is why its best to resolve merge conflicts too) so we should be leveraging it more.
Always surprised to see people resolving merge conflicts anywhere other than their IDE, IDE has the most knowledge about the inputs to the merge and your chosen resolution, why would you ignore that important info? (like.. does the resulting file compile? for ex..)
Would be very curious about your thoughts on Reviewpad (https://reviewpad.com). The interactions you have on the IDE are very different than a tool that was specifically made for code reviews.
Yeah, I should really quit struggling with Gitlab's.
For really large MRs, I use Tower + Kaleidoscope to view the changes. But then I can't easily leave a comment on a line of code (a big part of the review process)
Nope, they still arbitrarily decide to "fold" big changes (file with a large diff), causing me to miss entire files when reviewing on occasion.
In all honesty, their pull request pages need a lot of UX work: too much stuff going on on the overview pages, jumping to unresolved threads does not work when they are in previous commits...
There's also that merge train confusion where merge trains get "cancelled" without an obvious explanation ("this was cancelled because it is included in a new one" would do). In a sense, I'd say that their UX is pretty bad, but the API is not much better either (you can't fetch pipeline log files with individual script timings that you see floating on the right in the web UI). If anything, all of this only goes to show that you don't need to be perfect to be good!
But I applaud the effort, mission and dedication they put up, and especially their open core nature.
You can "expand" the diff, but sometimes that breaks the UI, makes it unable to add comments, etc. That's probably the reason they don't show large changesets by default.
Neither GitHub nor GitLab quite hit the mark for me with regards to code review. Phabricator (RIP) was close IMO, with first class support for (1) seeing comments and code on one view and (2) supporting stacks which prevent mega changes.
I've been working with some peers on a better code review tool since hearing about Phabricator shutting down: https://graphite.dev/
It syncs all data to GitHub while offering things like a review queue, gif reactions, stacked diffs, etc - all inspired from Phabricator.
I haven't used gitlab much, but I was shocked to hear GitHub's CTO (at the time of the interview, he has moved on since) state that GitHub didn't consider them a competitor.
"I do think that people still, to this day, think of GitLab as one of our main competitors, and I never have ever saw GitLab as a competitor."
I think the CTO's reasoning comes from that while GitLab is competitive in terms of usage and features (actually offering a more complete CI experience imo), it's influence is still relatively miniscule in comparison to GitHub.
I wouldn't be surprised if you tried asking random people in public or in a university whether they know GitHub or GitLab and came to the conclusion that GitLab basically does not exist for many people.
Especially for newer programmers, the vast majority tutorials/educational courses and whatnot probably don't even mention any alternatives to GitHub, much less an explicit reference to GitLab.
I say we just give it time, GitLab as a company seems like a way more inviting environment to me and if they keep up the good work GitHub may have to start acknowledging them more.
> I wouldn't be surprised if you tried asking random people in public or in a university whether they know GitHub or GitLab ...
When I first heard of GitLab, I assumed it was GitHub's "experimental" playground where they test features before deploying it on GitHub ... the power of branding ...
GitHub's CI pipelines are behind GitLab? My lord, here I was thinking about moving to GitHub Enterprise when our subscription expires because everything in GitLab feels like an unfinished weekend project. Seems like nobody can get anywhere near the functionality of Jenkins.
Github makes you do a ton of goofy side work to get simple things you'll expect in Gitlab/etc to work. Want to check out multiple repos? You'll need someone with org admin to create a service account and to manually pull each repo in a CI step with that service accounts token. This means tons of people are using their own PATs to get around "who is the github org admin?" sort of stuff.
I could go on and on, Github Actions are horrid compared to Gitlab. I wish, wish wish I could go back but I don't have that power here. Github doesn't have scoped issues like Gitlab, the issue board is so lacking, "projects" is stale and featureless so many things.
But I AM the one who deals with the aftermath. I've spent days fixing one simple github action and I have plenty I don't even wind up deploying they're so problematic.
> Seems like nobody can get anywhere near the functionality of Jenkins.
I've heard Jenkins is a nightmare to administer (not sure about the new versions). Seems like an opportunity: the power of Jenkins with modern sensibility.
Jenkins is a nightmare because everyone decided to spend months customising it with groovy and it became overly specific to your team/dept. The servers themselves are quite simple (single .jar, etc). These days we have containers, and it's made CI a much better thing.
I agree with this. The quality of your Jenkins experience will be pretty much inversely proportional to how much groovy script is in your Jenkinsfiles.
Every new permutation of parameters is a new chance for something to go wrong, and there's basically no sane way to unit test or validate any of your "helper" functions, so they're all write-once-change-never.
Which is not necessarily a problem inherent in Jenkins— Jenkins just gives you more than enough rope to hang yourself. GitLab CI can get silly too, but culturally it inherits from the much simpler Travis model, where you're basically expected to just be wrapping some other build tool (eg, tox from the Python world) rather than rolling the whole thing yourself.
Groovy is arguably the wrong language choice, even if it worked fine in other aspects. The string handling situation alone is crazy, which is compounded if you are using it with bash (which has its own crazy ideas about string escaping). That's a not too uncommon scenario.
To be fair, basically everything that interops/embeds bash like this ends up in a similar place— you see the same double-escape ridiculousness in CMakelists files and Nix package definitions.
> Jenkins is a nightmare because everyone decided to spend months customising it with groovy and it became overly specific to your team/dept
Yes. One thousand times this.
If you are running simple scripts it's fine. If you are using the declarative pipeline, it's fine. The moment you start adding Groovy you'll be down a path that is filled with sadness and anger. Mind you, even the folks behind Jenkins will advise you not to use any complex Groovy scripts(including for performance reasons - you can easily overwork the jenkins master).
I've been focusing on Concourse because it forces the usage of containers for everything. You don't have to care about what's installed in the worker node, you just use a container that has the stuff you want. Simple inputs and outputs.
You _can_ do the same sort of thing with Jenkins (but be aware of all the bugs still open regarding containers). But Jenkins doesn't force you to do anything, nor it gives you an easy and out of the box solution to string containers together. Left unchecked, you have your reproducible builds running in completely unreproduceable magical build machines – that noone really understands how it all works.
Did a migration of a few hundreds of pipelines from one server to another and it exposed a lot of dependencies we didn't know we had. Plugins, jars, packages installed in build machines, you name it.
If you must use Jenkins, please try to avoid Groovy to the max, write anything that's non-trivial as an executable (even if it is a bash script) and call it from the main pipeline. Use containers if you can to avoid build machine dependencies. Try to use declarative pipelines too unless your jobs are very simple, and avoid the 'script' blocks. Do not use the scripting pipeline to avoid inviting groovy to your home.
I worked on a Jenkins cluster with around 150 agents and many, many builds per day. It all ran so smoothly and I swear it was because there was zero groovy.
Just to contradict the complaining about groovy scripts: I reduced something like 100 jobs to 2 using groovy in jenkins, and it has been a godsend. I'm not having any problems with it.
Mind you, the Groovy stuff was implemented as an afterthought, and if you aren't handy with Groovy (I am) it can be challenging to learn. But compared to the horrible GUI-driven alternative, it was a no-brainer in the end.
Really, the more you're doing CI, the more you want scripts - doesn't have to be Groovy. I'd honestly be perfectly fine just doing things with a bash shell on a vanilla linux install. I only use Jenkins because my team insists on it, for what? So we can put a web UI in front of CI. I'd even tend to agree that with supply-chain attacks being what they are, and jenkins being a never-ending fountain of security patches, putting a web UI in front of CI isn't worth it.
Seriously, they're miles behind. It doesn't even really support Kubernetes, you have to have long running 'runner' servers ala Jenkins and you need to have all your build tools installed on those. It's miserable, fragile and I've dearly, dearly missed gitlab CI the last few times I've had to go anywhere near actions.
It’s probably because Actions is a fork of Azure Pipelines, which was originally designed to coordinate runners on Windows (where containers aren’t nearly as flexible or compatible as they are on Linux). Microsoft came up with some fancy internal magic to have hot pools of ephemeral VMs ready to assign in seconds, which nobody outside can really replicate (I don’t think), and then everyone sits in sadness while they try to debug why their tests run fine on “runner-1” but not on “runner-2”.
My company extracted us from github+teamcity paradise to force fit us to gitlab, it's not going well. Try both and for real, build a real project pipeline and see if that works for your dev before moving to either.
And here I am planning on replacing Jenkins with GitLab CI.. do you really think Jenkins is better? Do you have any examples or thoughts you can share?
Really the most egregious thing: Manual job runs. They're a first-class citizen in Jenkins, where it lets you make a rudimentary UI by having several types for each variable (e.g. a selectbox). In GitLab the manual run just gives you a list of defined variables and a small text input next to each.
Then there's dependencies between jobs which has gotten better lately but again it seems less developed compared to Jenkins. I also managed to kill the web UI with some of my pipelines when using dependent jobs because the javascript fails somewhere deep when trying to visualise the pipeline and the page just stays blank.
Honestly it really depends on what you're doing. If you're mostly replacing automated builds and tests triggered by git changes then GitLab works just fine.
We did a talk on it, happy to answer any questions. It’s definitely worth it.
A lot of our Jenkins issues came down to “we are not very good at managing Jenkins”, but even if we where the massive jump in productivity, flexibility and team independence we saw after rolling it out makes me believe it’s just better.
Your plan is solid (source: building ci stuff for >10 years). I wouldn't really suggest much else, although argo is getting pretty good if you're deploying to k8s, I'd still keep gitlab around for creating your images.
Jenkins has felt like an unfinished weekend project for going on ten years now. It may once have been state of the art, but that was in a time when people barely knew what a xmlhttprequest was.
Remember that GitHub is not MS's enterprise product in this space. When they acquired GH everyone waited for "the merge" and I think they've been really smart to (at least) appear to be hands off. I can happily use GH for my stuff while cursing Azure DevOps for work without going crazy.
Makes perfect sense to me. Because GL is open source, it can be easily self hosted, which is great for data residency compliance, or specialized security needs.
It wasn't a problem of losing the DB. The database got corrupted some how. All of the backups eventually became corrupted. This prevented us from upgrading from some version to some other version.
In the same way the Nintendo Switch and Xbox Series X aren't competitors.
Many hard core gamers will have both. My Switch is for Smash Bros and the Advance Wars reboot. Advance Wars was one of my favorite games as a kid, and I'll pay 300$ for a machine just to play it.
The Series X also plays games, but it's a completely different experience. No one expects Switch quirkiness on an Xbox, and no one expects 4K gaming on a Switch.
GitHub is for your public portfolio. Gitlab is for getting stuff done once your GitHub portfolio lands you a decent job.
GitHub is synonymous with programmer portfolio, but it's CI/CD system is rather primitive.
This is also where MS pushes Azure DevOps because it is inline with their subscription approach for Enterprise Office, Project Management and DevOps. It is really easy for a company that already pays for Office 365 to add on Azure DevOps. It's a lot less easy for the teams to adopt it, but we all know you sell to the front office, not the back.
You can only sell so much to the front office, if it's significantly harder to get things working on Azure, new features are going to ship later if they do at all.
I think the grandparent is referring to Azure DevOps which is a Git / Issues product like Github and Gitlab, not Azure Cloud. Azure DevOps is "fine" though I feel like MS is pushing Github and will deprecate DevOps at some point in the coming years.
I don't think it's a serious player at enterprises either. MSFT is giving away GitHub Enterprise to sell Azure and Visual Studio licenses coupled with other perks. GitLab can't compete on that level and they lose to GitHub/MSFT on a fairly regular basis.
Seems pretty serious to me. I was running my entire CI/CD process with gitlab.com and deploying to k8s clusters before GitHub Actions were even launched.
Github should see them as competitors, because Gitlab has definitely taken business from them.
Back in 2014 I started at a company that was still using a hand-rolled git server. They tried out Github enterprise but were unsatisfied with GH's lack of LDAP integration, so they were going to continue to frankenstein their in-house git server. I pitched them Gitlab instead, which did pretty much everything GH enterprise was doing, plus LDAP integration, plus was a fraction of the price. They were sold, I migrated the company to Gitlab, and continued to be impressed as Gitlab ran laps around Github on features.
While anecdotal, we see a lot of development environments for a lot of companies and the amount using github vs gitlab is like 5 or 6x to 1. So, in that sense I get what the CTO of github is saying.
I do think they are in a different market though. In that despite there is a Github Enterprise Product, the self host market shares are going to GitLab for one reason or another. i.e I would not be surprised if GitLab is actually winning in Enterprise / Big Spending Client self hosting Market.
For Github, it seems most of its strength is in their SaaS, contractors and SME which trends towards this solution. Your personal contribution to Open Source as well as profile / portfolio would also live on Github like on a Social Network.
And I can see both Github and Gitlab continue to evolve their strength for at least another 5 years. Generally speaking I dont see how Gitlab could ever compete with Github on SaaS given the advantage M$ has with Azure and DataCenter infrastructure as well as social reach. While Github wont have an easy path to evolve into something that compete directly with GibLab on self hosting solution and their trend is to move towards Azure Cloud solution offering to further gain synergy with other Microsoft Enterprise products.
I do wish Gitlab put lots and lots of work into performance though. As in performance improvement measured in order of magnitude, not small percentages.
I really like Gitlab, and I wanted to move my team onto their hosted offering, but earlier this year they changed the pricing so abruptly and drastically that it just killed it as an option.
It just feels like it does too much, and unless you want to commit to having everyone using it for _everything_ the pricing doesn't seem to make sense.
Same thing happened to me at a previous company: I had just migrated from Github to Gitlab and was planning on getting on the paid plan, when they suddenly did the price bump. Worse of all is that it is not possible to pay monthly (Github allows this). So we got back to Github.
The pricing model with GitLab is really unfortunate for certain types of companies. For our developers who really do most everything in Gitlab, it's great, but buying the same licenses for literally anyone else who might need to peek in there a couple of times a month? Hell naw.
Our spend would be much higher (probably 3-4x) if they allowed some type of reasonable mix of license levels.
Thats is what sales team is for. Talk to them, explain you usecase and set of features you are looking to use, they'll give you a discount based on that. If I remember correctly we managed to get a license for all users who ever need to login, but for the price of number of core active users.
I recently wanted to try adding some diagrams to a markdown-formatted README file in a Github Enterprise repo. I saw a few solutions but they all seemed to require me to roll some kind of service or automation to generate a raster image of the diagram and reference that from the markdown. There's an outstanding feature request for Github to integrate this kind of thing in their markdown rendering. But it's been languishing for years. Of course, Gitlab has had it for a while.
If Github's not careful, Gitlab will eat their lunch.
Gitlab should be careful not to make their product into "The Homer" [1], though.
GitLab has already turned into "The Homer". It has hundreds (thousands?) of features, but if you stray away from the core git functionality you'll very quickly realise they're pretty bad.
I've always seen GitLab as a useful tool for smaller companies where you can use it to replace several other applications (e.g. JIRA, Jenkins, or wiki), but if your company already has those established it all becomes somewhat useless.
Have you read the GitLab S-1? They have great retention with larger companies. Can you substantiate any of your claims? (FYI I have no horse in this race, I evaluated GH vs GL recently and decided to stay on GH for now)
> We do not have an adequate history with our subscription or pricing models to accurately predict the long-term rate of customer subscription renewals or adoption, or the impact these renewals and adoption will have on our revenues or operating results.
For context, GitLab recently axed their lowest priced plan and grandfathered in existing users at cheaper rates for the next year. Their retention rate may drop once discounts run out and the new pricing kicks in.
As to the parent's comment about "The Homer" and non-core features being bad, I'd point to their CI autoscaling solution as an example of being underdeveloped, over-marketed, and suffering from technical debt. Their autoscaler uses docker machine behind-the-scenes, which hooks into various cloud providers to abstract away the act of spinning up new VMs. It works reasonably well, but Docker has archived the repository and no longer supports the software. GitLab forked the repository and maintains it for critical fixes, but is not willing to develop or accept new features. It has been known to break against new versions of Docker, does not handle concurrency very well in new environments, and does not allow [1] executing multiple concurrent jobs within spun up VMs, despite marketing that it can [2].
While the autoscaler does work, it's limitations and quirks reduces it's utility and cost-savings significantly within smaller organizations. The technical debt leaves me doubting any improvements will come within the next few years as they try to architect a new solution to replace the existing one.
I have no idea how GitLab compares in other areas, but within CI autoscaling it seems they're stuck with a cliff to climb down before they can move forward again.
CI is moving in Kubernetes everywhere I know. Builtin kubernetes pod autoscaler can add capacity based on job queue length metric, so no need for docker machine anymore.
To some extend, yes. On the other hand, they’re currently the only service where I can set up one VM, give it my AWS credentials, and have fully automated scaling.
The hoops you have to jump through in Github are absolutely unfun.
I never said they don't have retention with large companies. In fact I work at one that uses GitLab, which just proves the points in my comment - nobody uses features like issues, wiki, or pages because it's already established via other applications.
I agree with the general thrust of your comment (and I've been happy to see that GitHub's feature development pick up over the past few years), but I don't know if Markdown is the best example: I've lost track of how many times I or someone else I work with has written some Markdown, only to discover that it's a GH or GL extension and that our deployed documentation (or package index pages) don't render our hard work correctly.
Also, it sounds to me like Github is leaving the old lunch of "Git hosting + issue tracking" on the table, and moving on to being a kind of web-based all-in-one full-service collaboration/dev platform with a social network built in. So even if Gitlab picks up some single-digit-percentage market share, that's not what Github cares about anyway.
> a kind of web-based all-in-one full-service collaboration/dev platform with a social network built in.
Why would I want a social network built into my version control & ci/cd pipeline (I assume you're referring to the "stars" feature, and not about issue reporting).
Maybe I'm just a curmudgeon, but I'm sort of sick of everything becoming a social network. I neither have nor do I want internet clout, and all social networks feel like they're trying to force me into "keeping up with the Jones'" in whatever way they're relevant.
In OpenSource space there is a small value: If I get a contribution from a stranger and I see they are respected contributor to trustworthy other organisations I can derive some trust from that. (Doesn't mean handing out access and blindly merging, but helps to judge)
Also for people looking for jobs it can be a tool for self promotion.
I worked with Sytse (as Sid used to be called) back in 2011/2012 in The Hague when he consulted at Digidentity, with Marin. Great guy back then, used to run around in a lab coat, the GitLAB guy. Wonderful to see what Gitlab has become, well done!
That explains a lot. I thought Sid was an unusual name for someone with that surname. But it makes business sense to use something more internationally pronounceable.
I remember in 2014, a coworker of mine talked me into creating a Gitlab account, claiming "it's basically just Github, but you get free private repos".
I liked it, used it occasionally, but didn't care much about it until Github was purchased by Microsoft. I didn't have a problem with Microsoft buying Github per say, but it made me realize that Github could be bought, and it wasn't some kind of glorified charity. I don't think MS has done a bad job with Github at all, but the very fact that the biggest home of open source itself isn't open source made me uneasy. On the day the MS buyout was announced, I moved all my Github repos to Gitlab.
Gitlab, while still a for-profit company, at least believed in open source enough to release the source code for their core product into the wild, and have proven that they can be successful doing it. I'm extremely happy that they've managed to create a pretty outstanding project that I am happy to use, and I just bought three shares to prove my dedication to it.
Gitlab is definitely very neat. But I always worry when these sorts of companies go to IPO. What is their financial situation like? Are they currently able to become profitable without drastically changing the deal with users?
They had $192M losses in 2021 and $152M revenue. So no, not even remotely profitable, but it is common: Atlassian, Jira, Datadog, PagerDuty, Snowflake, CloudFlare, Fastly all IPOed and succeeded on the market without being profitable even once.
Nope, CloudFlare has a negative EPS so they are still not 'profitable'. But they are focused on growth, so that is not necessarily a bad thing for investors. If they can grow to compete with AWS through offerings such as R2 storage, that is far more valuable in the long run than turning a profit today.
Have any of the finance minded HN commenters decided if the $10B valuation is justified? I'm usually pretty negative about high valuations, but given their enterprise penetration, this one seems almost reasonable.
Define "justified". For most purposes, the market looks at valuation on a relative basis¹.
Their S-1 says GitLab generated revenues of $152 million in FY 2021 (ending Jan 31), up 87% from the year before². For the sake of argument, let's assume their growth rate slows down "slightly" to 50%. That's ~$230 million projected for FY 2022
At $10 billion, that implies a forward revenue multiple of ~43.5x, which does seem high—but it's not necessarily "unjustified". I haven't read the S-1 and the market reaction to the IPO has been quite positive so far. You'd need to know the business and the market well to make your own individual assessment of why it commands this premium multiple. Customers, TAM, growth, churn, competition, etc.
––––––––––
1. For better or worse, relative valuation is viewed as "more defensible". If you're wrong, you can simply say, "well, that's how the market was pricing it at the time" whereas if you are wrong with your intrinsic valuation model (like a DCF), you have no one to blame.
However: If they don't want to (fully) sell basing the price on a value someone else might eventually pay for a (full) acquisition doesn't make much sense. (Unless you assume they revise the decision, but then the argument about not selling is moot again)
First 6 months of this year Gitlab took in $108M in revenue, and had $177M in expenses. Would you pay $10B to own a company that loses $10M/month, with the hopes they will continue to increase revenue in the future and become profitable?
In the 6 months before their IPO - Square had net revenue of $200 million and expenses of $260 million, also losing $10M/month. Would you have paid $3 billion in 2015 to own that business?
If you had you would've had a 30x return today... (current market cap is ~$112 billion).
Personally I'd buy an aircraft carrier if I had $10B. Nevertheless, there are plenty of people willing to put it in Gitlab or they wouldn't IPO. A better question might have been: what's the bull argument for Gitlab?
The usage argument is: buy your own "self-hosted" cloud offering, deployed over any combination of AWS/Azure/GCP/onprem that you like.
The bull argument probably looks something like: replace Microsoft Office 365 / Azure with an integrated "self-hosted" solution, easily deployed to any commoditized compute...handled by GitLab for paying customers, assurances of "escape hatch" to DIY open-source when you stop paying.
As with GitHub, the bigger value is owning shift left disruptions for enterprise and cloud sw+he services: security scanning, backups, prod server hosting, ... .
It is hard to compete with AWS, and a lot easier if you own the UI+APIs for how software teams do CI+CD: you become a default preferred vendor for all IaaS/PaaS add-ins, and can proactively recommend and even trial them well before any competitor. IBM, Oracle, SalesForce, SAP, Alibaba, etc could all win big -- imagine if IBM bought GitLab instead of RedHat to fix their data center strategy.
Microsoft only paying 7.5 billion for GitHub definitely makes me less confident that GitLab is worth 10 billion.
Much as I personally prefer GitLab, GitHub had a bigger customer base back then than GitLab has now. GitLab may be gaining market share, but it’s mostly eating Atlassian’s portion of the market and not GitHub’s. It’s plausible GitHub undervalued themself in the sale to Microsoft of course, so a careful look at the numbers is required to evaluate the valuation, but the value comparison isn’t a great sign to me.
Separately of course, GitLab might be in line with the valuation of companies on the stock market in general which have ballooned heavily in recent years. Whether that's a bubble or permanent inflation in stock prices then becomes the relevant question to answer, I suppose.
>Microsoft only paying 7.5 billion for GitHub definitely makes me less confident that GitLab is worth 10 billion.
It's worth considering that between 2018 and now, tech valuations have exploded. MSFT is up 300%. QQQ is up 100%. I doubt GitHub is valued anywhere near 7.5B today.
GitHub wouldn’t sell for only $7.5b today though, it would probably be in the $25b or higher place. The explosion in valuations, especially in enterprise SaaS stuff over the last few years has been remarkable. I don’t know if that is sustainable or not, but in three years, the metrics have changed significantly.
Dmitriy Zaporozhets is explicit mentioned in the blog and on the photo. The S1 doesn't mention him https://news.ycombinator.com/item?id=28573867. Anyone know why Dmitriy owns less than 5% of the outstanding shares of the Class A or Class B common stock?
Dilution plus private stock sale or unequal share provisioning among founders? Probably a handful of things, though not sure if it has any bearing on Gitlab's success.
What has really bothered me about Gitlab is that everytime Github copies a feature, there's a testy blog post about "we did it first!" when Gitlab as a business is a copy of Github.
Sure, though some of the ergonomics around git hosting are different from what was available on Sourceforge, especially looking at features like pull requests, which Gitlab cloned pretty much 1:1
The CTO position isn't for everybody. A few years ago, I used to work at another tech unicorn from Amsterdam, at a time it was rapidly expanding.
The CTO at this company was the first engineer. He was talented, and more passionate about engineering than management. He eventually stepped down to a similar role as they brought in a suit from the corporate world to replace him. That was around the time that I left.
Funnily enough, I always thought he was the most grounded person on the leadership team.
Congrats to the team and I'm very thankful that there are alternatives to GitHub out there. Not that I don't like GitHub (I do) or use GitHub (every day), but lately it seems like they are sherlocking a whole lot of ideas from the OSS "marketplace" into their main product. That kind of irks me.
If GitLab were able to add something like GitHub Actions into their platform I would leave GH in a second.
The phenomenon of Apple releasing a feature that supplants or obviates third-party software is so well known that being Sherlocked has become an accepted term used within the Mac and iOS developer community.
I've used Gitlab constantly for many years, and they stand out to me as a company that delivers new features at an astounding pace and with a relatively high level of polish. I really don't know how they do it. Congrats to the Gitlab team, your success is well deserved!
Elastic (NYSE: ESTC) was pretty much a fully distributed team upon IPO. They had offices, but they were more like "coworking cafes", where folks who happened to be in the same geographic area would meet up, or have social celebrations. At least, that's my understanding, tracking the company since its early days. On a recent podcast, Shay Banon described it as a fully distributed team of 2,000+ folks.[1] They IPO'ed in 2018.[2]
Ever since I found their company handbook online, I have been in love with their process/culture and wanted to work for them. But I don't write Ruby and they don't seem to need a lot of DevOps/SysEng/SREs.
I guess after GitHub and gitlab i will have to find an alternative, so long and thanks for all the fish, I'm not really sure why we need to pursue growth at all cost, a perpetual hunt for currency on daily basis, of a number we will never be able to spend
Kudos to GitLab for boldly and successfully going where (almost) no company has gone before - to having a worldwide, distributed workforce. Truly the way of the future, and (IMO) better quality of life for employees once they get used to working remote and stop fighting it. I've been working primarily remote for the past 3 years, and my QOL has never been better. No commute, working hours can be when I feel productive (which tends to be in the evening), and if I'm tired nobody will look at me funny if I take a nap, except maybe my cat.
Most importantly, this forces folks into asynchronous and written communication, which both makes my work less interrupt driven, and reduces reliance on institutional knowledge. I think we're yet to fully realize the benefits of this brave new world. And yes, I'm aware that some folks need water cooler conversations. I don't though.
Sid, if you're reading this, do please write a book on how you did it, so others could replicate your success in terms of geographic distribution. Knowing the legal / accounting / tax pitfalls, and how to avoid getting screwed when hiring abroad would be pretty invaluable to others.
I honestly didn't think they stood a chance.
I'm happy to have been proven wrong. Congrats to the whole team on their successful exit!