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!
I think if GitHub simply gave free private repos sooner, GitLab wouldâve had a way harder time.
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.
Anecdotally Iâve felt like most of the features GitHub has released for some time now are a clone of something that hit Gitlab first.
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
Gitlab was earlier/better at letting companies install a version on-prem.
Their CI story was also a lot better until Github added Actions
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 was able to get free unlimited private repos from github and bitbucket since 2011, but we still used the ancestor of gitlab as our local repo.
> My thought at the time was that no open source company had ever been super successful except RedHat
Sun bought MySQL for 1 billion USD in 2008, does that not count as successful?
Also, MongoDB, Elastic and many many others...
MongoDB and Elastic are successful because they are locking features behind a paid license. Does that make it a successful open source company?
GitLab has features in the Enterprise edition that arenât in the Community edition donât they?
But GitLab is the same concept...
I meant there were no successful public companies based on open source except RedHat in 2015.
I am always reminded how not so great ideas or even clones when executed well lead to good outcomes.
Any takeaway lessons for evaluating future FOSS startups? Like maybe place higher weight on rate of adding new users?
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.
See also: "create investor fomo", https://html.duckduckgo.com/html/search?q=create%20fomo%20in...
Honored to have you as an investor, jedberg!
And Iâd modify one thing you said: I believe the #1 most important skill for a startup CEO to master is storytelling â- which is critical for selling, fundraising and recruiting. https://www.founderculture.net/c/new-noteworthy/the-1-must-m...
What do you find is the âbest way to sellâ?
"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.
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
When I click on your link to find the quote, it doesn't show up. Strange. Or are you playing off of the joke?
That's strange.
Try looking for "gitlab CEO here" (with quotes) at the bottom search on HN? (and pick Comments. they won't show up in stories.)
No change :(
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.
For those who want to know more about Gitlab and its all remote approach (a lot of posts): https://about.gitlab.com/blog/tags.html#remote-work
And their handbook: https://about.gitlab.com/handbook/
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.
I very much appreciate them making that public.
Yep, that wiki is amazing.
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.
I prefer to use Intellij now for reviews. How can people review any kind of code in that PR web UI ? I mean I used to do it but not anymore
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..)
Do you review code in the code editor, the git diff, or some specialized full-PR/MR diff with integration with online comments and discussions?
https://stackoverflow.com/questions/40217494/how-to-review-a... says IntelliJ has GitHub-only specialized PR review/commenting.
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)
The only issue I had with GL is that they don't show the entire diff if the changes/files are very large.
They may have fixed this since last year, but it was super, super annoying to me at the time.
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.
Congrats on the IPO and keep pushing forward.
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.
Their search functionality is also... non functioning. Github's search is dramatically more powerful.
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.
Gif reactions in code review is something we want?
We've been building a new code review tool for the PR/MR process. Check it out at https://reviewpad.com.
We have also built a similar thing based on git-format-patch and the patch workflow: https://www.reviewpatch.org
What is your thinking around post merge reviews?
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."
https://www.lastweekinaws.com/podcast/screaming-in-the-cloud...
Anyone have thoughts on that? Or pointers to more reading?
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 has stronger 'social' features and it's better for people who want to connect to other devs or build portfolios.
GitLab is years ahead of GitHub for certain stuff (e.g. CI/CD) and IMO it has a better commercial offering for business.
I use GitHub as my portfolio profile for free and GitLab in my $JOB.
That's my opinion tho, I'm just a person who uses both.
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.
I agree GitLab's CI has many edge cases. More importantly, it feels like they stopped making it better to focus on other stuff.
That said, GH actions is really new and full of imitations / weird stuff as well. I still think GL offers more bang for the buck in 2021.
Another option is using something external like Drone CI, Circle CI, etc... Some of those look nice, but I've never tested myself.
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.
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.
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.
In an interview I had with GL the interviewer mentioned âpeople use GH for open source work, and GL for closedâ.
Thats somehow funny, as GH is closed source and GL is open source...
Yeah theyâre similar feature-wise but the communities that exists on GitHub vs. GitLab arenât remotely comparable.
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.
Actions are close If not better than Gitlabâs CI. I moved from Gitlab to GitHub Actions because they offer OSX runners too, game changer.
gitlab-runners are also installable on OSX (MacOS)[1]
Are you using enterprise Gitlab?
I don't think Gitlab is a serious player outside of enterprise clients. But that's where the money is.
As Peter Thiel repeatedly puts in Zero to One:
Monopolists love to talk about have they have competitors and act like theyâre in competition.
Competitors love to downplay that they have any competitors at all and try to upsell their business like theyâre monopolists.
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)
From their S-1:
> 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.
[1]: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2787#no...
[2]: https://about.gitlab.com/blog/2017/11/23/autoscale-ci-runner...
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.
I think it is fair to say Gitlab is already eating Github's lunch. For some time.
Are they? What's the Gitlab market share?
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.
Especially considering the coupling of GitHub with vscode
Is it?
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!
> Sytse (as Sid used to be called)
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.
Fun fact on Dutch names, his wife Karen has the same Sijbrandij, but not due to marriage, but due to them being distant cousins, who found one another on the search function of an early chat client, like ICQ, he once told us. So she could actually call herself Karen Sijbrandij-Sijbrandij.
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.