Gitlab S-1(sec.gov)
sec.gov
Gitlab S-1
https://www.sec.gov/Archives/edgar/data/1653482/000162828021018818/gitlab-sx1.htm
294 comments
Yeah I absolutely support Gitlab and love seeing new projects use Gitlab over Github.
But to be fair, they have a massive backlog of issues to fix. Basic issues too, like variables not expanding correctly in CI jobs, or Google not being able to index projects on gitlab.com unless there's another page already linking to it.
I've been using Gitlab.com and Gitlab on-prem since 2013 and over the years I've found many of these bugs that I feel should be top priority instead of new features.
But to be fair, they have a massive backlog of issues to fix. Basic issues too, like variables not expanding correctly in CI jobs, or Google not being able to index projects on gitlab.com unless there's another page already linking to it.
I've been using Gitlab.com and Gitlab on-prem since 2013 and over the years I've found many of these bugs that I feel should be top priority instead of new features.
[deleted]
With their business model, a constant stream of new features is the only thing that pays the bills. Their paid tiers get the new features, and almost all of them eventually wind up in the open product. With a healthy IPO they should be resourced enough to put some extra hands on the backlog. +1 for prioritizing old tickets!
I don’t really think that IPOing is about acquiring more resources. The point is to get rich. The resources are the means to do that, and everything else is a happy side effect.
Hopefully, yes, they will choose to do as you say. But the tickets didn’t language because they were resource constrained. They languished because they were worthless, in the monetary sense.
Hopefully, yes, they will choose to do as you say. But the tickets didn’t language because they were resource constrained. They languished because they were worthless, in the monetary sense.
It'll get worse.
This is a YC site so it's a dick thing to say but look at every YC company that got big. They might start out with nice ideas and bloviate a lot about bullshit (Reddit still has the tagline about staying for empathy - lol).
But every single one of them gets worse after cashing out. They do not give a shit. It's always been about the money. If it weren't they'd have enough pride to make better software then they do and more than that enough pride to actually fix things instead of bloviating.
Their business model ensures that they will continue to add features to a bloated and overmarketed project to people that don't know better. We better off? It's possible. But I know that watching their interactions here over the last past decade, when I had the chance, I made sure we didn't use Gitlab for some unis you've heard of and going forward I always will.
I'll never get over their data loss incident. Not so much that it happened (though they should have had enough expertise around to make sure it never happened), but the reaction to it like it was just a funny mistake. I realized then that these guys haven't been in real small companies that could go bankrupt if they lose a chunk of data or they had and didn't realize how careless they were.
https://news.ycombinator.com/item?id=13542587
This is a YC site so it's a dick thing to say but look at every YC company that got big. They might start out with nice ideas and bloviate a lot about bullshit (Reddit still has the tagline about staying for empathy - lol).
But every single one of them gets worse after cashing out. They do not give a shit. It's always been about the money. If it weren't they'd have enough pride to make better software then they do and more than that enough pride to actually fix things instead of bloviating.
Their business model ensures that they will continue to add features to a bloated and overmarketed project to people that don't know better. We better off? It's possible. But I know that watching their interactions here over the last past decade, when I had the chance, I made sure we didn't use Gitlab for some unis you've heard of and going forward I always will.
I'll never get over their data loss incident. Not so much that it happened (though they should have had enough expertise around to make sure it never happened), but the reaction to it like it was just a funny mistake. I realized then that these guys haven't been in real small companies that could go bankrupt if they lose a chunk of data or they had and didn't realize how careless they were.
https://news.ycombinator.com/item?id=13542587
As a counterpoint, the data loss incident made me a fan. They didn't treat it as a funny mistake, I don't think -- I remember one comment from one of the Gitlab engineers of "everyone is very sad, but we're trying." Something in that spirit.
Anyone who's ever worked with production systems knows how absurdly easy it is to ruin them. Yes, it was careless, but they responded with class: they didn't fire the engineer that made the mistake. That would have turned me into a gitlab enemy.
Recognizing that a process is dysfunctional is one of the hardest things for any company to do. There's an incredible amount of corporate inertia preventing such recognitions from taking hold. Are you sure it wasn't worth applauding?
There's also nothing wrong with getting big, or getting worse. The trick is to get worse in the ways that matter the least.
Anyone who's ever worked with production systems knows how absurdly easy it is to ruin them. Yes, it was careless, but they responded with class: they didn't fire the engineer that made the mistake. That would have turned me into a gitlab enemy.
Recognizing that a process is dysfunctional is one of the hardest things for any company to do. There's an incredible amount of corporate inertia preventing such recognitions from taking hold. Are you sure it wasn't worth applauding?
There's also nothing wrong with getting big, or getting worse. The trick is to get worse in the ways that matter the least.
I think it’s about being the dominant player or not, as a long time employee of a very very well known and large company once complained to me “We care about the user experience, but only when we’re not doing well”. Gitlab will continue to impress as long as GitHub exists - I’d start to worry if gitlab “wins”
GitHub seems to care about user experience even though they're winning though.
i've opened multiple, detailed support tickets over the years about different UX wtfs they rolled out that removed vital functionality.
not one of my complaints has ever been addressed. my last complaint was ghosted after i pointed out that they should actually read my lengthy analysis instead of giving a worthless canned response.
still waiting for reply since Jan 4.
not one of my complaints has ever been addressed. my last complaint was ghosted after i pointed out that they should actually read my lengthy analysis instead of giving a worthless canned response.
still waiting for reply since Jan 4.
Are you a paid user?
no, but i author and maintain some pretty popular projects and now work for a company that does pay, and also has a massive github and OSS footprint.
> no, but i author and maintain some pretty popular projects and now work for a company that does pay, and also has a massive github and OSS footprint.
Would you say that you (and your projects) and employer are to some degree locked in now? Are either you or your employer likely to move away from hosting your projects on GitHub?
Would you say that you (and your projects) and employer are to some degree locked in now? Are either you or your employer likely to move away from hosting your projects on GitHub?
my employer uses a lot of paid github features, while my projects use none, so moving away would be simple for me, but difficult for them.
the real lock-in is no different than any other social media platform: network effects. most people who follow you on X rarely bother also having an account on Y. unless you're Taylor Swift, moving away means diminished visibility/reach, and dilution of any reputation accumulated e.g. over a decade of activity, interactions, etc.
the real lock-in is no different than any other social media platform: network effects. most people who follow you on X rarely bother also having an account on Y. unless you're Taylor Swift, moving away means diminished visibility/reach, and dilution of any reputation accumulated e.g. over a decade of activity, interactions, etc.
GitHub SAAS consumer experience. It doesn't go as far for users who would like to run their own GH instance as open source. And in some areas GitLab has done better, such as CI.
GitHub enterprise on prem is an offering I thought? Sure it is not open source, or even source available. But they are still trying to compete against GitLab in that space.
Right, but I doubt GH let's on prem users modify the source to suit their needs.
Ensuring there are regular backups of the organizations data is the responsibility of the organization and not the responsibility of GitLab.
Disaster recovery did not go away with the advent of cloud providers. It morphed from having a plan to recover when fire takes out a data centre to having a plan to recover when provider X whose free plan we base our business on no longer has our data.
Disaster recovery did not go away with the advent of cloud providers. It morphed from having a plan to recover when fire takes out a data centre to having a plan to recover when provider X whose free plan we base our business on no longer has our data.
What makes you think their new shareholders will tolerate bug fixing? It doesn't generate revenue and hence doesn't contribute to constant growth, which seems to be the only thing that matters to investors these days.
And that's why we can't have nice things in for-profit software nowadays.
And that's why we can't have nice things in for-profit software nowadays.
Bug fixing likely helps with retention, which shareholders _will_ be interested in.
Especially for products with higher levels of network effect.
Why would I want to use a bug ridden, poor performing tool?
There are alternatives with less features if you don't need them all.
There are alternatives with less features if you don't need them all.
Their paid users also switch to GitHub when they get annoyed by bugs. I did it once myself.
I have been using it for a couple months. You are very correct. I guess when are as open as they are it kind of gets lost in translation. Hopefully becoming a shareholder in a truly public company is the push for us to fix these kinds of issues.
No notifications on the platform is a deal breaker for me.
Do you mean no push notifications? Because I get emails for stuff. The rest is integrated into our chat client, mattermost. I actually prefer using that as a centralized place for work notifications.
I see notifications for starting Gitlab CI pipelines in Google Chrome on MacOS. What kind of notifications do you want exactly?
I would rather have less notifications, they distract me too much.
I would rather have less notifications, they distract me too much.
Took em' about 2-3 years to add the "What's new" link in the top menu bar since the issue was opened.
> Gitlab is one of the pioneers of "remote-first"
I once looked at their wages when I was in Asia, they wouldn't even cover my rent working full-time. Until they pay for skill rather than area I'm going to be a sceptic sorry, far better companies to work for.
I once looked at their wages when I was in Asia, they wouldn't even cover my rent working full-time. Until they pay for skill rather than area I'm going to be a sceptic sorry, far better companies to work for.
For all the work they have done in getting remote-first culture established for large corps, their salary protocol is pretty backward.
Normalizing on employee locale adds so many assumptions about the life and lifestyle of the employee and their market that are somewhat unfair to incorporate into compensation.
Our company is far smaller, but also been remote-first for almost a decade, and flat salary structure based on role (we pretty much have just IC, lead or junior) and fully independent of location was the best.
Since we have two founders living in the Bay Area and in New York, two of the most expensive cities, a comfortable wage for those founders should be good enough for anyone anywhere.
For our own simplicity, we aligned compensation on gross (pre-tax) pay, so the take-home is slightly different between regions.
Normalizing on employee locale adds so many assumptions about the life and lifestyle of the employee and their market that are somewhat unfair to incorporate into compensation.
Our company is far smaller, but also been remote-first for almost a decade, and flat salary structure based on role (we pretty much have just IC, lead or junior) and fully independent of location was the best.
Since we have two founders living in the Bay Area and in New York, two of the most expensive cities, a comfortable wage for those founders should be good enough for anyone anywhere.
For our own simplicity, we aligned compensation on gross (pre-tax) pay, so the take-home is slightly different between regions.
There's nothing "fair" or "unfair" about salaries: it's just an open market. And their strategy is not a winning one. On my last remote job search, I encountered a few companies which were mimicking gitlab's approach (they actually said out loud that gitlab was where they got the idea). Needless to say, I accepted the offer from an American company which offered American salary instead. Three times as much as companies with "gitlab-like" policies offered me.
They apparently can find talent at their current rates. Good for them.
But certainly there will be pressure on them and on all others, as US companies start to hire globally, and offer more-or-less US wages.
But certainly there will be pressure on them and on all others, as US companies start to hire globally, and offer more-or-less US wages.
Is there so much demand in the US that it will impact global wages? I'm not sure.
As a foreigner is not in my interest but I do wonder if, just for the sake of coherence, shouldn't the import of labor be taxated in the same way goods are taxated.
As a foreigner is not in my interest but I do wonder if, just for the sake of coherence, shouldn't the import of labor be taxated in the same way goods are taxated.
If you're a software developer, have you tried to find a job in last, like, 20 years? While doing so, you likely noticed how many recruiters are interested in you.
There is a serious deficit of software developers, the industry is striving to hire much more that currently available. If they can now make up their mind and keep hiring remotely, the will market grow a lot, but equally will grow the desires, see Jevons Paradox.
There is a serious deficit of software developers, the industry is striving to hire much more that currently available. If they can now make up their mind and keep hiring remotely, the will market grow a lot, but equally will grow the desires, see Jevons Paradox.
> While doing so, you likely noticed how many recruiters are interested in you.
I'd appreciate that more if not for the fact that I regularly get emails and cold calls from recruiters who do the following:
- ...want me for a job that has zilch to do with my skillset. I'm an SRE and a general infrastructure engineer. 90% the jobs I get calls about are for frontend stuff and/or involve languages I've never touched. Want me to maintain a container orchestration platform? Great! Want me to write a bunch of Python scripts to serve as the glue that holds together a complex Rube Goldberg machine? I love doing that! Want me to maintain a set of monitoring systems that alert people according to ever-changing requirements? I can do that. But if you want me to write a UX in JavaScript? Excuse me while I spend the next half hour laughing.
- ...cold call me during work hours. If you do that, I will never do business with you ever again. It's not so bad now that I'm fully remote forever, but when I worked in an office I would straight-up ask some of them "are you trying to get me fired?" before hanging up on them. Usually they cold-call and send an email simultaneously, which is especially ridiculous. With some people I've gotten repeated cold-calls during work hours multiple days in a row, so I spend some time online finding the names of their recruiting firm's head of HR, general counsel, CEO, COO, and any number of executives who look like they might be in this person's reporting chain, use the name format in the email the recruiter sent me to guess their email addresses of said bigwigs, and then send all of them a C&D letter. I've gotten profuse apologies from HR people.
- ...want me for short-term contracts in parts of the US I would never live in if you paid me. Like I'm going to give up my nice house in Dallas and quit my full-time job with fantastic benefits and generous PTO to take a six-month contract with no benefits or PTO in Lansing, MI where there's nothing to do but fentanyl. And I had that problem before I decided I intend to be remote forever and never want to set foot in an office again.
- ...lie to me about jobs being remote. Here's an example: guy cold-called me and sent an email, and normally I would've just hung up on him but I was desparate to find a remote job before my old company made us go back to the office so I listened to him. I told him I'll have to read the email first, and I hung up to read it. He called me back less than five minutes later and asked me if I'd made a decision yet. He told me on the phone the job was remote, but the email said it was just temporary until the end of the pandemic and they insisted that anyone who gets the job relocate to the metro area immediately even before the pandemic is over. I called him on his lie and told him I'll pass because the position isn't full-time remote. He lied again, said "but it's full-time!". I read back the email word for word, and just to get back at him for lying to me I lied to him back and told him I have a medical condition and I'm permanently housebound for the rest of my life. He then said "but what about after the pandemic?". I lied again and said "no, even after the pandemic I'm physically unable to leave my house". He then said "even after the pandemic is completely over?". I had to lie to him further and basically convince him that I'm in an iron lung before he finally agreed I'm not a candidate for the position.
I'd appreciate that more if not for the fact that I regularly get emails and cold calls from recruiters who do the following:
- ...want me for a job that has zilch to do with my skillset. I'm an SRE and a general infrastructure engineer. 90% the jobs I get calls about are for frontend stuff and/or involve languages I've never touched. Want me to maintain a container orchestration platform? Great! Want me to write a bunch of Python scripts to serve as the glue that holds together a complex Rube Goldberg machine? I love doing that! Want me to maintain a set of monitoring systems that alert people according to ever-changing requirements? I can do that. But if you want me to write a UX in JavaScript? Excuse me while I spend the next half hour laughing.
- ...cold call me during work hours. If you do that, I will never do business with you ever again. It's not so bad now that I'm fully remote forever, but when I worked in an office I would straight-up ask some of them "are you trying to get me fired?" before hanging up on them. Usually they cold-call and send an email simultaneously, which is especially ridiculous. With some people I've gotten repeated cold-calls during work hours multiple days in a row, so I spend some time online finding the names of their recruiting firm's head of HR, general counsel, CEO, COO, and any number of executives who look like they might be in this person's reporting chain, use the name format in the email the recruiter sent me to guess their email addresses of said bigwigs, and then send all of them a C&D letter. I've gotten profuse apologies from HR people.
- ...want me for short-term contracts in parts of the US I would never live in if you paid me. Like I'm going to give up my nice house in Dallas and quit my full-time job with fantastic benefits and generous PTO to take a six-month contract with no benefits or PTO in Lansing, MI where there's nothing to do but fentanyl. And I had that problem before I decided I intend to be remote forever and never want to set foot in an office again.
- ...lie to me about jobs being remote. Here's an example: guy cold-called me and sent an email, and normally I would've just hung up on him but I was desparate to find a remote job before my old company made us go back to the office so I listened to him. I told him I'll have to read the email first, and I hung up to read it. He called me back less than five minutes later and asked me if I'd made a decision yet. He told me on the phone the job was remote, but the email said it was just temporary until the end of the pandemic and they insisted that anyone who gets the job relocate to the metro area immediately even before the pandemic is over. I called him on his lie and told him I'll pass because the position isn't full-time remote. He lied again, said "but it's full-time!". I read back the email word for word, and just to get back at him for lying to me I lied to him back and told him I have a medical condition and I'm permanently housebound for the rest of my life. He then said "but what about after the pandemic?". I lied again and said "no, even after the pandemic I'm physically unable to leave my house". He then said "even after the pandemic is completely over?". I had to lie to him further and basically convince him that I'm in an iron lung before he finally agreed I'm not a candidate for the position.
This all shows a huge underserved market.
Because of its being underserved, we're in a privileged position to ask more money, better hours, longer-term contracts, etc. Compare that to the situation of warehouse workers or ride-hailing drivers, where the situation is opposite.
Because of its being underserved, we're in a privileged position to ask more money, better hours, longer-term contracts, etc. Compare that to the situation of warehouse workers or ride-hailing drivers, where the situation is opposite.
I'm grateful to GitLab for providing an alternative to GitHub, and an open source one. It's an open core product with the community edition providing a lot of value. Here are some community hosted instances: https://wiki.p2pfoundation.net/List_of_Community-Hosted_GitL...
The CI system is quite powerful, and Travis CI's struggles before and after acquisition has shown that it's hard to host a major CI platform.
I hope the company and the open source product will continue to thrive.
The CI system is quite powerful, and Travis CI's struggles before and after acquisition has shown that it's hard to host a major CI platform.
I hope the company and the open source product will continue to thrive.
Who can edit that page? https://git.drupalcode.org/
The owners/maintainers listed here probably:
https://git.drupalcode.org/project/drupal/-/project_members
https://git.drupalcode.org/project/drupal/-/project_members
Yes, Gitlab has been leading the way for a while now, consistently introducing new features that Github eventually copies. It's a real testament to the power of competition. I first started using Gitlab due to free private repositories, which Github eventually added. Gitlab had free built-in CI/CD first, and Github eventually followed. I'm still on Gitlab these days despite Github catching up, and still enjoying features like organizations with subfolders that Github lacks.
In addition to the above, GitLab Pages continues to be easier to setup and use (on GitLab.com) than GitHub Pages.
GitLab pages started with the incredible idea that you could provide your own docker container and use the CI to build using whatever tools you want while github only supported jekyl at the time.
Except Github Actions is leaps and bounds above Gitlab CI.
It really is, they one-upped Gitlab, and you can tell there is a clear difference in resources between the two companies. Yay competition! I especially like how you can run parallel builds on Windows, Mac, and Linux with one line of code with GitHub actions.
What’s nice about Git as a distributed VCS is I can use both GitHub and Gitlab and get the best of both worlds very easily. I win either way, and neither can lock me in (you know Microsoft would do it if they could, but they can’t). Therefore we see actual legitimate competition, where one has to constantly improve to outdo the other. I wish more things worked that way.
What’s nice about Git as a distributed VCS is I can use both GitHub and Gitlab and get the best of both worlds very easily. I win either way, and neither can lock me in (you know Microsoft would do it if they could, but they can’t). Therefore we see actual legitimate competition, where one has to constantly improve to outdo the other. I wish more things worked that way.
>neither can lock me in
That's true for the core git piece, but if you're a big enough org the CI/CD features, or issues, or pages, etc, could effectively lock you in.
That's true for the core git piece, but if you're a big enough org the CI/CD features, or issues, or pages, etc, could effectively lock you in.
Really?
I have consistently heard the opposite.
Actions has more polish but is not as feature rich is what I have heard.
I have consistently heard the opposite.
Actions has more polish but is not as feature rich is what I have heard.
Yeah also a doubter, you can get to pretty DRY workflows with GitLab extends, caching is great, built in artifact repositories (including image registry), workflows/rules on when to build (i.e. run certain tasks specifically off MRs), granular approval rules, review environments and the paid for version has pretty awesome security primitives that are really easy to incorporate (sast/dast/container scanning et al.). I may be a bit biased but having kicked the tyres on actions my feeling is GL is miles ahead on the CI front.
Ha ha, no way. Very basic things (like caching) are riddled with bugs and (undocumented) limitations. Documentation is poor compared to GL, there are much less features and UI is confusing at best. GH needs to do better if they want to compete here.
It can only be true if you had experience with Gitlab CI 5 years ago and compare with current Github Action offering. There is no way a person who actually build CI pipelines in Gitlab and Github today can call Github a winner.
These all sound like features that GitHub also had, but Gitlab needed to offer for free to gain users, rather than a technological superiority of Gitlab over GitHub. I don't think it's correct to interpret that as "Gitlab leading the way".
Note: I've preferred Gitlab, for exactly this reason
Note: I've preferred Gitlab, for exactly this reason
I really wanted to like gitlab, but have had so many reliability issues. The UI thinking the source branch doesn’t exist, CI jobs not running for hours etc.
Haha that UI branch name thing is hilarious. Everyone at work has the same problem and has had it for the year and a half we have been using gitlab but the gitlab devs insist it doesn't happen for them.
You can workaround it by pressing the right arrow at the end of the text.
You can workaround it by pressing the right arrow at the end of the text.
I've been using GL at work for many years now and while it has many faults (the MR comment/thread/discussion UX is atrocious for example), I don't think I stumbled across this one. What is it about?
(I still like GL, and I much prefer their CI to GH Actions - I just wish they would put more effort in improving existing features)
(I still like GL, and I much prefer their CI to GH Actions - I just wish they would put more effort in improving existing features)
On that blue "create merge request" button on the issue page, there is a drop down arrow to let you pick a branch to start from. That text input is super buggy and often says the branch does not exist even if the name is correct.
Interesting, I never noticed because I usually make a MR from the link I get when I do a git push (which I find super useful btw). It does sound like a myriad other smallish annoyances. Thanks for describing it!
Some times when trying to merge in a MR, the UI will say the source branch doesn’t exist so the MR can’t be merged. Wait a bit and it usually resolves itself. But it’s super annoying when you are in a rush.
I haven't personally had a compelling enough reason to move from GitHub to GitLab, so I mostly just use it to mirror a couple of my repos there in case people prefer to browse various open source projects via GitLab. Regardless, I think competition in the space is a great thing.
GitLab has come a long way and there are certain things I really like about the company. For example, I love how they tend to do everything "in the open" and have most of their development work and business documents public. It's a great resource for aspiring entrepreneurs. I have been a bit concerned about some of the architecture of GitLab lately, with quite a few security fixes resulting in unusual edge-case bugs. My only other complaint is that they tend have a very wide but shallow pool of products. They have ambitious goals with their platform, but I hope they are able to build real value and add features to the existing core products.
Congrats to everyone on the GitLab team. Keep doing good work.
GitLab has come a long way and there are certain things I really like about the company. For example, I love how they tend to do everything "in the open" and have most of their development work and business documents public. It's a great resource for aspiring entrepreneurs. I have been a bit concerned about some of the architecture of GitLab lately, with quite a few security fixes resulting in unusual edge-case bugs. My only other complaint is that they tend have a very wide but shallow pool of products. They have ambitious goals with their platform, but I hope they are able to build real value and add features to the existing core products.
Congrats to everyone on the GitLab team. Keep doing good work.
I'm the opposite actually. I do all my dev on Gitlab, and mirror on Github for the exposure.
Maybe this is the time for a big shout out to the creators of git for making use cases like these a first class citizen.
And imagine that… it hasn’t stopped other sites from making their successful products around a free and open backbone.
To me it was very compelling before GitHub actions and only slightly compelling now.
Mind to share a "quick link" to the mentioned documents?
Sure, the most obvious link is this: https://gitlab.com/gitlab-com
Here's a few examples:
Runbooks: https://gitlab.com/gitlab-com/runbooks - which I've used as inspiration for runbooks on my own team.
Handbook: https://about.gitlab.com/handbook/
Roadmap/Product Vision: https://about.gitlab.com/direction/
A note in their handbook on transparency: https://about.gitlab.com/handbook/values/#transparency
Here's a few examples:
Runbooks: https://gitlab.com/gitlab-com/runbooks - which I've used as inspiration for runbooks on my own team.
Handbook: https://about.gitlab.com/handbook/
Roadmap/Product Vision: https://about.gitlab.com/direction/
A note in their handbook on transparency: https://about.gitlab.com/handbook/values/#transparency
I think that the most fascinating fact about this upcoming IPO is that, to the best of my knowledge, GitLab is the first remote-only (i.e., no-headquarters) company in the world filing for an IPO. In any case (meaning even if I'm wrong that they are the first), I wish them luck and welcome the competition.
It's interesting to see that GitLab has adopted dual-class common stock structure, though I'm certainly not surprised. Some people and organizations (including some investment firms and stock exchanges) are not fans of multi-class equity structures, but I'm not sure that this fact would have any significant negative impact on GitLab's IPO. At least, these popular 10:1 or slightly less popular 20:1 voting schemes are not as aggressive as Palantir's three-class stock structure, where Class F (just three founders - out of five!) would hold practically 50% of the total voting power.
One strange thing that I've noticed while browsing through this S-1 document, though, is the lack of mention of GitLab's co-founder (Dmitriy Zaporozhets) in the stockholders table (p. 148). I would expect him to hold about the same ownership of the Class B shares as the other co-founder Sytse Sijbrandij holds, but definitely more than 5%, which requires a disclosure there. I'm not sure how to interpret the absence of his name.
It's interesting to see that GitLab has adopted dual-class common stock structure, though I'm certainly not surprised. Some people and organizations (including some investment firms and stock exchanges) are not fans of multi-class equity structures, but I'm not sure that this fact would have any significant negative impact on GitLab's IPO. At least, these popular 10:1 or slightly less popular 20:1 voting schemes are not as aggressive as Palantir's three-class stock structure, where Class F (just three founders - out of five!) would hold practically 50% of the total voting power.
One strange thing that I've noticed while browsing through this S-1 document, though, is the lack of mention of GitLab's co-founder (Dmitriy Zaporozhets) in the stockholders table (p. 148). I would expect him to hold about the same ownership of the Class B shares as the other co-founder Sytse Sijbrandij holds, but definitely more than 5%, which requires a disclosure there. I'm not sure how to interpret the absence of his name.
Well spotted. Based on this wording:
> each person known by us to be the beneficial owner of more than 5% of the outstanding shares of our Class A or Class B common stock; and
It seems that Dmitriy owns less than 5%.
As usual though, the wording in here is unnecessarily opaque and overcomplicated — it's possible there's some other technicality that allows him to be omitted from the list.
> each person known by us to be the beneficial owner of more than 5% of the outstanding shares of our Class A or Class B common stock; and
It seems that Dmitriy owns less than 5%.
As usual though, the wording in here is unnecessarily opaque and overcomplicated — it's possible there's some other technicality that allows him to be omitted from the list.
> I think that the most fascinating fact about this upcoming IPO is that, to the best of my knowledge, GitLab is the first remote-only (i.e., no-headquarters) company in the world filing for an IPO.
"Akshually" that was Coinbase [0]. Although maybe not, because they did a direct listing so not strictly an IPO. Matt Levine talks about both these points in his Feb 25th 2021 Money Stuff newsletter.
[0] https://www.sec.gov/Archives/edgar/data/1679788/000162828021... "Address not applicable"
"Akshually" that was Coinbase [0]. Although maybe not, because they did a direct listing so not strictly an IPO. Matt Levine talks about both these points in his Feb 25th 2021 Money Stuff newsletter.
[0] https://www.sec.gov/Archives/edgar/data/1679788/000162828021... "Address not applicable"
Good point. In that case, it's fair to consider both being the first remote-only/first public companies in respective categories (IPO and DL).
> is the lack of mention of GitLab's co-founder (Dmitriy Zaporozhets) in the stockholders table (p. 148)
Indeed, interesting question. I’d expect that a S1 would clarify Dmitriy Zaporozhets position & role.
Indeed, interesting question. I’d expect that a S1 would clarify Dmitriy Zaporozhets position & role.
Not all co-founders are co-owners. He likely owns below 5% of shares.
I'm not sure why that would be the case here. Unless, for some reason(s), he has sold most of his share of the company to Sytse, I don't see why Dmitriy would own less stock than his co-founder. Especially considering that Dmitriy has started the relevant open source project prior to Sytse's involvement and then, after the company's formation, has actively participated in technical decision making and software development.
So GitLab is advertising that it's the one place to do the entire software development lifecycle. Are there any big shops that have converted to 100% (or almost 100%) GitLab? Out of the six big names they list on their website, the only one that they have a case study for is Thomson Reuters, and they used Jenkins for CI (and it's from 2017, so a lot of this other functionality wasn't built yet).
It's just a somewhat different strategy. Most of these tools (GitHub, Azure DevOps, Jira) only cover some of it (GitHub and ADO can both do deployments and code storage and ticketing, but not any of the monitoring stuff or security stuff, as an example), and even then people often bolt on whatever they like anyway. But with GitLab betting that people will pay more (a lot more if you want everything -- $99 per month), is anyone actually doing that at scale?
Because for $20 per user per month (the middle tier), I'd just spend the extra buck to get GitHub, given that the features in that tier are very similar (GitHub doesn't have complex issue management yet, but it's coming). Or maybe just do the Azure DevOps $6 per user per month plan and endure the whining from the devs :P.
It's just a somewhat different strategy. Most of these tools (GitHub, Azure DevOps, Jira) only cover some of it (GitHub and ADO can both do deployments and code storage and ticketing, but not any of the monitoring stuff or security stuff, as an example), and even then people often bolt on whatever they like anyway. But with GitLab betting that people will pay more (a lot more if you want everything -- $99 per month), is anyone actually doing that at scale?
Because for $20 per user per month (the middle tier), I'd just spend the extra buck to get GitHub, given that the features in that tier are very similar (GitHub doesn't have complex issue management yet, but it's coming). Or maybe just do the Azure DevOps $6 per user per month plan and endure the whining from the devs :P.
I've been using ADO for the past year or two and I don't hate it. While it absolutely lacks features, and most ADO things have relatively tough to use UIs, it _is_ extremely fast compared to GitHub and has some amazing UI designs for a couple things (especially reviewing large PRs).
Although from what I heard they're porting the good parts into GitHub and deprecating/putting into maintenance mode ADO soon.
Although from what I heard they're porting the good parts into GitHub and deprecating/putting into maintenance mode ADO soon.
> Although from what I heard they're porting the good parts into GitHub and deprecating/putting into maintenance mode ADO soon.
Hush hush! By now that’s pretty much an open secret covered by various NDAs :)
What even the NDAs won’t tell you though is how much time ADO has before it’s fully “dead”. If Microsoft’s track-record is anything to go by, I would assume ADO customers will be “encouraged” to migrate 3-5 years from now, with at least another 5 before they start closing down, if not more.
Will be interesting to see how it plays out when the time comes.
Hush hush! By now that’s pretty much an open secret covered by various NDAs :)
What even the NDAs won’t tell you though is how much time ADO has before it’s fully “dead”. If Microsoft’s track-record is anything to go by, I would assume ADO customers will be “encouraged” to migrate 3-5 years from now, with at least another 5 before they start closing down, if not more.
Will be interesting to see how it plays out when the time comes.
I’m curious as to how the heck they’ll move the data over. ADO projects are made up of many git repos with a shared ticket setup and all of the links are configured that way. I have no idea where I’d even start with that.
I am not a big shop - I work on a team on the order of 10
We use GitLab as our "one place to do the entire software development lifecycle". It's a really good CI/CD runner in my opinion, the .gitlab-ci.yml files are expressive and enable reuse thru a pretty nice inheritance model, and integrating new service (container) builds is literally 4 lines of code to have every push build a new container and put it in GitLab container registry.
It also makes developing NPM packages a breeze, thru the same reuse of CICD files we can drop 4 lines into an JS/TS repo and have it publish to the built-in package registry on tags.
On top of this, its ticketing system is worlds better than GitHub's. Less clicks, more available relationships & tags, more views, inheritance/rollup via the group structures you can put in place let you view tickets at a repo / group level, and since you can create trees from the groups you can have reasonably expressive places to view groups of issues.
Finally - it's all free! We're using free tier self-hosted, and it's far superior to my experience with GitHub paid. I admit, we have decent (read: overscaled) hardware to self-host on, but GitLab really does offer a ton of useful tools to building software.
We use GitLab as our "one place to do the entire software development lifecycle". It's a really good CI/CD runner in my opinion, the .gitlab-ci.yml files are expressive and enable reuse thru a pretty nice inheritance model, and integrating new service (container) builds is literally 4 lines of code to have every push build a new container and put it in GitLab container registry.
It also makes developing NPM packages a breeze, thru the same reuse of CICD files we can drop 4 lines into an JS/TS repo and have it publish to the built-in package registry on tags.
On top of this, its ticketing system is worlds better than GitHub's. Less clicks, more available relationships & tags, more views, inheritance/rollup via the group structures you can put in place let you view tickets at a repo / group level, and since you can create trees from the groups you can have reasonably expressive places to view groups of issues.
Finally - it's all free! We're using free tier self-hosted, and it's far superior to my experience with GitHub paid. I admit, we have decent (read: overscaled) hardware to self-host on, but GitLab really does offer a ton of useful tools to building software.
> we can drop 4 lines into an JS/TS repo and have it publish
Could you talk a bit about this, or link out to any docs they've got for this? I'm curious about setting that up
Could you talk a bit about this, or link out to any docs they've got for this? I'm curious about setting that up
I will give a high-level overview. Essentially, it is a workflow runner. You can set up "jobs" in a "pipeline" (dependency graph of jobs), and each job is just a bit of yaml. This yaml has individual keys controlling things like running a script, configuring the environment, controlling the docker image executing the job, etc..
These jobs / yaml blobs can be included into other files / projects using another one of these keys, "including" another job/pipeline via configuring the path to the repo & path to the file you want to import. You can override any properties really easily on these includes as well. Anyways, my .gitlab-ci.yml for building a container (any repo containing a top-level Dockerfile works zero-config, non-top-level can be configured) looks like this
These jobs / yaml blobs can be included into other files / projects using another one of these keys, "including" another job/pipeline via configuring the path to the repo & path to the file you want to import. You can override any properties really easily on these includes as well. Anyways, my .gitlab-ci.yml for building a container (any repo containing a top-level Dockerfile works zero-config, non-top-level can be configured) looks like this
include:
- project: 'public-tools/gitlab-extensions'
ref: master
file: '/.gitlab/ci/Docker-build.gitlab-ci.yml'
You don't even need to do that. Gitlab has repository configuration option to take CI config from another place. So you can have code only repo being built by a CI pipeline described elsewhere.
NPM Private registry doesn't really work for me with Yarn and NPM v7 when trying to run binaries. This is a major blocker for a lot of things.
Also the `npm install` is really flaky multiple times a day I get 404s for packages in the private registry. You need to keep retrying jobs that use that command until succeeds.
Also the `npm install` is really flaky multiple times a day I get 404s for packages in the private registry. You need to keep retrying jobs that use that command until succeeds.
I experienced some initial configuration pain with their Package Registry, but after generating PATs for local use and passing secrets thru the CICD build runner nicely - and using yarn - I have had no issues publishing nor installing my own private modules.
Here are the commands I suggest you run to authenticate your local machine to GitLab:
Here are the commands I suggest you run to authenticate your local machine to GitLab:
yarn config set "@example:registry" "https://gitlab.example.com/api/v4/packages/npm/"
yarn config set //gitlab.example.com/api/v4/packages/npm/:_authToken "<your PAT here>"
yarn config set //gitlab.example.com/api/v4/projects/:_authToken "<your PAT here>"
yarn config list
> I also suggest you fully commit to yarn or npm, they are definitely different enough to be awkward to combine.
I can't even migrate to Yarn because of issues. Try using a package that has binary (`bin` in `package.json`) or other metadata and publish on your private NPM registry and then use it with Yarn or NPM v7 you won't be able to as it strips away this metadata.
For example, if I want to push a patched version of Playwright to my NPM registry. I can't use it if I don't use NPM v6. Also the daily 404s errors when trying to install your private NPM packages which requires retry your jobs isn't help either.
Sadly it's not an important enough issue for them to fix. I am really wondering if Gitlab is using their products themselves.
I can't even migrate to Yarn because of issues. Try using a package that has binary (`bin` in `package.json`) or other metadata and publish on your private NPM registry and then use it with Yarn or NPM v7 you won't be able to as it strips away this metadata.
For example, if I want to push a patched version of Playwright to my NPM registry. I can't use it if I don't use NPM v6. Also the daily 404s errors when trying to install your private NPM packages which requires retry your jobs isn't help either.
Sadly it's not an important enough issue for them to fix. I am really wondering if Gitlab is using their products themselves.
Obligatory: My statements are my own and do not reflect the opinions of my employer. I'm not going to name that employer, but let's be honest, I can't stop you from figuring it out if you really want.
> Are there any big shops that have converted to 100% (or almost 100%) GitLab?
We use a combination of GitHub, GitLab, and Azure DevOps across the various SW Eng orgs in our company.
On GH, we split across both GitHub.com and internal GitHub Enterprise instances. There's been some shift to put everything on GH.com, but GH Actions for private repos are kind of busted, and it's really causing us problems. Staying on GHE is less painful for some of our orgs. Some teams use Jenkins instead of Actions, which is, as the kids say, "a whole mood".
Our GitLab-using orgs generally have tighter CD integration. As much as I prefer the GH UX, I have to admit GL has a much smaller gap between "I have an idea" and "my implementation is now CI-ed, CD-ed, and published to Artifactory".
Our ADO using orgs have an even smaller gap. Seriously. If you've never used ADO, you'd be impressed by how easy it is to get a full build pipeline set up in minutes. That is, as long as you stay on the garden path. These teams also have the hardest struggles when they stray off the path. (But my intuition here is that this isn't definitively an ADO problem and might actually come down to the skill sets of those teams.)
All told, we're several hundred engineers across these solutions. By my rough count, the total number using GitLab may be a hundred or so. They really like it, and it suits them very well.
(And before anyone says "omg why do you have so many solutions", the Eng efforts at our company are thoroughly distributed instead of consolidated. And, at least at an executive level, there's currently more faith in "right tool for the job" than in "alignment". For now.)
> Are there any big shops that have converted to 100% (or almost 100%) GitLab?
We use a combination of GitHub, GitLab, and Azure DevOps across the various SW Eng orgs in our company.
On GH, we split across both GitHub.com and internal GitHub Enterprise instances. There's been some shift to put everything on GH.com, but GH Actions for private repos are kind of busted, and it's really causing us problems. Staying on GHE is less painful for some of our orgs. Some teams use Jenkins instead of Actions, which is, as the kids say, "a whole mood".
Our GitLab-using orgs generally have tighter CD integration. As much as I prefer the GH UX, I have to admit GL has a much smaller gap between "I have an idea" and "my implementation is now CI-ed, CD-ed, and published to Artifactory".
Our ADO using orgs have an even smaller gap. Seriously. If you've never used ADO, you'd be impressed by how easy it is to get a full build pipeline set up in minutes. That is, as long as you stay on the garden path. These teams also have the hardest struggles when they stray off the path. (But my intuition here is that this isn't definitively an ADO problem and might actually come down to the skill sets of those teams.)
All told, we're several hundred engineers across these solutions. By my rough count, the total number using GitLab may be a hundred or so. They really like it, and it suits them very well.
(And before anyone says "omg why do you have so many solutions", the Eng efforts at our company are thoroughly distributed instead of consolidated. And, at least at an executive level, there's currently more faith in "right tool for the job" than in "alignment". For now.)
My company (several thousand) uses GitLab for code, CI/CD (which has security and monitoring in some add-on YAMLs we have to include, not directly through GitLab), packages (python wheels, jars) and docker images, and we're slowly moving to GitLab for terraform and kubernetes integration. We plan to stay on JIRA, though.
> is anyone actually doing that at scale?
per the prospectus on page 16 the answer is definitely yes:
Net Dollar Retention Rate for customers who paid more than $100,000 in ARR is 283% as of 12 months ended January 2021 and 383% for YTD 2021, meaning this customer cohort increases on average the spent by 2.8x.
The highest net-dollar retention rate among all SaaS publicly-traded companies, whose average is around 120%.
per the prospectus on page 16 the answer is definitely yes:
Net Dollar Retention Rate for customers who paid more than $100,000 in ARR is 283% as of 12 months ended January 2021 and 383% for YTD 2021, meaning this customer cohort increases on average the spent by 2.8x.
The highest net-dollar retention rate among all SaaS publicly-traded companies, whose average is around 120%.
That average is across all price points though right, not 100k+ customers? That seems a very apples to oranges comparison.
Fair enough: the average dollar retention rate among all gitlab's customer is 152%, behind only Snowflake, Blend Labs, nCino and UIPath afaik.
I was just trying to emphasize that for the highest paying cohort, retention is best class.
I was just trying to emphasize that for the highest paying cohort, retention is best class.
Air Force Platform One uses it.
It's hyperbole to say you can use it for the entire lifecycle. That might work fine for one-product monorepo shops, but Gitlab still doesn't scale well right now. Aside from basic issues like the runners not working well, the binary artifact repositories are way behind what something like Artifactory or Nexus offers. It's extremely annoying not having group and server scoped registry tokens except for the container registries. It makes it more difficult than it should be to publish modular libraries to be used elsewhere in your organization by other products. It's effectively unusable if you're working behind an air gap and trying to mirror public registries. The only way I can think to do it is creating a dummy projects with every kind of package registry enabled and push all of them into that one repo, but that won't work for things like Maven that have a notion of namespacing.
It can't really replace something like Jira, either (and in Platform One's case, it doesn't). You can only create an issue in a repo, but there is plenty of work organizations do and want to track and organize that can't be directly tied to a code change, let alone a code change in only one repo. So where do you raise an issue to track work not related to writing code or related to writing code but across multiple repos? I've seen people create dummy repos that serve no purpose except being a central place to put issues, but that is just working around the limitations. It's fine as a bug tracker, but not a general purpose work tracker and project management solution.
It's hyperbole to say you can use it for the entire lifecycle. That might work fine for one-product monorepo shops, but Gitlab still doesn't scale well right now. Aside from basic issues like the runners not working well, the binary artifact repositories are way behind what something like Artifactory or Nexus offers. It's extremely annoying not having group and server scoped registry tokens except for the container registries. It makes it more difficult than it should be to publish modular libraries to be used elsewhere in your organization by other products. It's effectively unusable if you're working behind an air gap and trying to mirror public registries. The only way I can think to do it is creating a dummy projects with every kind of package registry enabled and push all of them into that one repo, but that won't work for things like Maven that have a notion of namespacing.
It can't really replace something like Jira, either (and in Platform One's case, it doesn't). You can only create an issue in a repo, but there is plenty of work organizations do and want to track and organize that can't be directly tied to a code change, let alone a code change in only one repo. So where do you raise an issue to track work not related to writing code or related to writing code but across multiple repos? I've seen people create dummy repos that serve no purpose except being a central place to put issues, but that is just working around the limitations. It's fine as a bug tracker, but not a general purpose work tracker and project management solution.
Also, in Jenkins' defense, it's often nice to have a general purpose automation server. I never liked Jenkins, but I miss being able to create jobs that check the health of your deployments, report filesystem usage to user of your developer workstations, run very large-scale end to end integration tests independently from builds, update wikis and documentation automatically. There is plenty of automation that can happen outside of code CI that may not be related to code changes at all but is still useful.
Understanding of course Gitlab does have a notion of scheduled jobs that just run on a timer rather than being triggers by a changeset push, but that still isn't enough, and embedding shell scripts in yaml strings is a very poor substitute for Jenkins' Groovy DSL when there is any kind of complicated logic required by your jobs.
Understanding of course Gitlab does have a notion of scheduled jobs that just run on a timer rather than being triggers by a changeset push, but that still isn't enough, and embedding shell scripts in yaml strings is a very poor substitute for Jenkins' Groovy DSL when there is any kind of complicated logic required by your jobs.
Gitlab does have some features like rules and triggers that can do medium-ish complexity flows. Still not where Jenkins is, but there's some framework pieces there.
My company uses GitLab for repo, CI/CD, image management, package management, issue management and K8s with the $20 plan.
Having all those things in the same place does wonders for my sanity.
Having all those things in the same place does wonders for my sanity.
I believe a Splunk uses it.
Intel was (is?) using it to some extent. I owned a repo from 2019 - 2020 and there was a big push/timeline of all the different repo services and their EOL/move to Gitlab. Unsure it that's still the case or if the new POR is GitHub, thought I heard whispers of that about to change before I left.
Anyways, I had to migrate like 100+ users into Gitlab and setup/babysit the CI/CD output of that repository (which is not software, just documentation but the build/release process is not trivial). I actually didn't have too bad of a time all things considered, and none of the problems described here. Unsure how much of that was use case or people above me keeping my life easy but I was a happy user.
Anyways, I had to migrate like 100+ users into Gitlab and setup/babysit the CI/CD output of that repository (which is not software, just documentation but the build/release process is not trivial). I actually didn't have too bad of a time all things considered, and none of the problems described here. Unsure how much of that was use case or people above me keeping my life easy but I was a happy user.
I realize plenty of tech companies IPO and aren’t profitable. But it seems scary to be losing more money than what you generated in total revenues.
REVENUE:
2021: $152m (loss of $192m)
2020: $81m (loss of $130m)
EDIT: reworded for clarity.
REVENUE:
2021: $152m (loss of $192m)
2020: $81m (loss of $130m)
EDIT: reworded for clarity.
I am by no means a finance or investing whiz. But the first thing I like to do is skip ahead to the cash flow statement.
In this case https://www.sec.gov/Archives/edgar/data/1653482/000162828021...
The income statement, balance sheet, and cash flow are connected; sides of a triangle.
Each of the three views alone is potentially misleading. But for an initial impression and quick gut check I like to start with cash flow.
In this case https://www.sec.gov/Archives/edgar/data/1653482/000162828021...
The income statement, balance sheet, and cash flow are connected; sides of a triangle.
Each of the three views alone is potentially misleading. But for an initial impression and quick gut check I like to start with cash flow.
60M cash loss in 2021, with over $100M stock based compensation expense. Maybe with Phabricator shutting down they'll see more growth but the last time I used Gitlab it was not comparable to Phabricator's (and Gerrit's) usefulness for large orgs. It's more like a Github clone in the way it functions.
gerrit was a decade ahead of the competition for code review. github is just starting to catch up now to where gerrit was in 2011
Would you mind sharing a ELI5 of how you go about reading these?
Most S1 on HN are companies that spend $3 to get $1 in revenue. It was explained to me that this is totally normal and very different from DotCom companies literally buying revenue.
Are you being sarcastic or not? And what are the explanations you've heard?
Half sarcastic, half serious? I think the prevailing theory is that yes these companies are spending tons of money to get a little bit of money, but it's a one time per customer expense and that customer will still be there for many more quarters, paying monthly dues.
Sounds a lot like:
https://en.wikipedia.org/wiki/Predatory_pricing
And is illegal in some jurisdictions and frowned upon in others.
https://en.wikipedia.org/wiki/Predatory_pricing
And is illegal in some jurisdictions and frowned upon in others.
No? The point is just that revenue for subscription models recurs whereas build cost does not (handwave).
Yes? There are operational costs involved as well. It's not like a company fires half of their team after the product is launched.
> It's not like a company fires half of their team after the product is launched.
Not an uncommon VC/PE strategy. Wait two years and see what happens.
Not an uncommon VC/PE strategy. Wait two years and see what happens.
The theory is lot stronger/valid in enterprise sales like gitlab, customers take a lot of time to switch even if they are not satisfied with a product, there may not viable competitior with bespoke solution the same your current provider gives you etc
It is far less true for consumer/SMB mid market products as cost of leaving there is not high.
It is far less true for consumer/SMB mid market products as cost of leaving there is not high.
Oh yeah, I think GitLab will make a fine company. Even if as a user of their product I routinely find it to be half-baked, but of course in enterprise the actual user is commonly the least important aspect of any deal.
> Even if as a user of their product I routinely find it to be half-baked
I thought so too, but then my enterprise started moving to Github. Hoo boy, that’s a whole different can of worms. Their core functionality is great, but if you need anything outside of that you are shit out of luck.
I thought so too, but then my enterprise started moving to Github. Hoo boy, that’s a whole different can of worms. Their core functionality is great, but if you need anything outside of that you are shit out of luck.
A lot of that money gets spent on adding features to win sales and those features are a one time cost so they can be used for free to win new customers later. GitLab pushes hard to be the do everything tool.
Here's a good analysis of the financials in the S1: https://cloudedjudgement.substack.com/p/gitlab-benchmarking-...
I guess if you look at it, they almost doubled their revenue in last 1 year but the loss only went up by a fraction compared to last year. So they are on a high growth path which is what investors want I assume.
Income of 152 with total expenses of 344 in 2021 and income of 81 and total expenses of 211 means expenses grow at 1.61x of revenue (344/211) whereas revenues are growing at 1.876x yoy so revenue growth exceeds loss growth in time they’ll be profitable. Especially if in 2021 they were profitable when companies were cutting down on things.
1.61x of costs not revenue. I was dividing the expenses from year to year.
It depends on why they're losing money.
Are they losing money on each customer per year? Are they spending a ton on sales that they expect to earn back over a decade per customer plus, but with a huge initial cost.
Are they losing money on each customer per year? Are they spending a ton on sales that they expect to earn back over a decade per customer plus, but with a huge initial cost.
It requires closer inspection in this particular case, but losses are not always bad if they’re calculated. For example, if you spend $100 to bring in a customer that yields $200 in a year, it makes sense to “buy” as many customers as you can.
But is the company “default alive”, as I think Paul Graham calls it? That is, could they cut that spending tomorrow and actually have money coming in that more than covers the costs of keeping the lights on?
But is the company “default alive”, as I think Paul Graham calls it? That is, could they cut that spending tomorrow and actually have money coming in that more than covers the costs of keeping the lights on?
The overwhelming majority of high-growth technology companies recognize a net revenue loss going into IPO. The purpose of the IPO and prior VC rounds is to finance a strong company & product, and more importantly, help win enough market share early enough in the sector's lifecycle to recognize a full or partial monopoly over the space.
The fact Gitlab are recognizing a loss at IPO could have been predicted at the company's inception.
The fact Gitlab are recognizing a loss at IPO could have been predicted at the company's inception.
152% NDR tells me they should either buy as many customers as possible right now (IE burn), or they are under pricing and should raise prices and increase revenue that way.
Cash flow on its own is kinda meaningless.
They did quite recently [0].
The bronze plan (4/user/mo) was burned and moved into premium (19/user/mo). If you have any sort of moderately active company, going back to free tier is really not an option (the feature reduction would be simply too much, plus a lot of previous ci/cd work would be binned).
[0] https://about.gitlab.com/blog/2021/01/26/new-gitlab-product-...
The bronze plan (4/user/mo) was burned and moved into premium (19/user/mo). If you have any sort of moderately active company, going back to free tier is really not an option (the feature reduction would be simply too much, plus a lot of previous ci/cd work would be binned).
[0] https://about.gitlab.com/blog/2021/01/26/new-gitlab-product-...
only CI related feature previously available on bronze, but not on free anymore is branch protection. Rest of bronze CI should work just fine.
The most important one for us is the `environments` feature, but indeed a lot of four-eyes-principle controls are also missing in free tier (MR approval requirements, committer verification, push rules...).
If that kind of growth is sustainable, it's only a couple years out from profitability. Admittedly it's a runway, but the growth is impressive.
Yeah, remember how Amazon got theirs. Not that those results will apply here of course. A lot depends on how much upside your investors and stock holders believe will eventually come to pass. Hard to say you are going to take much market share from a project owned and backed by Microsoft though.
Yes and seeing the loss grow like that yearly is not a good look. Otherwise the product is really good.
Can’t really say that without a cost breakdown. If the LTV of a customer is greater than the CAC then your losses will grow as you do until you reach a more steady state and reduce your marketing spend.
It takes awhile for a SaaS customer to pass their CAC. But if they do then they should be closer to 80% margin after that.
It takes awhile for a SaaS customer to pass their CAC. But if they do then they should be closer to 80% margin after that.
Yeah, but burning $183 to add $71 in revenue is a tough pill to swallow.
Sure, it probably will pay back eventually, but as an investor, you really have to be bullish on retention/expansion. to get a reasonable LTV out of that.
Most bulls have been right in the past, but eventually the music stops (look at the tenuous position Slack was in before acquisition).
Sure, it probably will pay back eventually, but as an investor, you really have to be bullish on retention/expansion. to get a reasonable LTV out of that.
Most bulls have been right in the past, but eventually the music stops (look at the tenuous position Slack was in before acquisition).
You just need to be confident the LTV estimate is correct. That being said I'm pretty bearish on dev tooling in general as it seems like companies don't want to pay for it (but they will pay for expensive AWS services!)
or use it's subpar _cloud native_ tools for the "magic integration"
>You just need to be confident the LTV estimate is correct.
I've yet to see an LTV calculation at a VC or from FP&A that is even close to reality (Who cares about WACC, even though the capital we raise is actually very very expensive? Why should we consider Gross Margin? What do you mean we can't just take our best cohort?).
But to mirror the fatalistic tone from my other comment, we're in an easy growth environment, so it kind of doesn't matter (until it does).
I've yet to see an LTV calculation at a VC or from FP&A that is even close to reality (Who cares about WACC, even though the capital we raise is actually very very expensive? Why should we consider Gross Margin? What do you mean we can't just take our best cohort?).
But to mirror the fatalistic tone from my other comment, we're in an easy growth environment, so it kind of doesn't matter (until it does).
Isn’t your second sentence just a truism on the first sentence?
profit = revenue - costs
profit = revenue - costs
Maybe a better way of saying what I meant is, gitlab is losing more than 2x their total generated. That’s what seems scary.
It is also somewhat easy to enter the market. You do not need a hundred million dollars upfront investment to build a competitor, at least in terms of functionality of provided services. A good example in my opinion is how BitMart is eating up Coinbase US market with many of my friends moving on to safe money on the fees since "crypto is crypto". From their IPO coinbase is 25% down as of today, and I don't see any compelling reasons for the stock to rebounce.
[deleted]
he means losses > revenue, in other words costs > 2xrevenue.
No, you're conflating "loss" (negative profit) with "cost". The first sentence acknowledges that plenty of tech companies IPO and are not profitable, so their revenue is below their costs. The second sentence is about losses (negative profit) exceeding revenue.
For a naive example, a company can have $1m in revenue and $1.1m in costs, therefore profit is negative 100,000 dollars - the company is unprofitable. However, they are not losing more money ($100,000) then they are bringing in ($1,000,000 is greater than $100,000) - though they are spending more money ($1.1m) then they are bringing in. This would not be a concerning amount of loss, many companies are deliberately outspending current revenue in order to increase future revenue/growth/market share, but could become profitable if they wanted to.
In this case, the person you replied to is remarking that the losses/negative profit ($192m, $130m) are greater than the revenue ($152m, $81m). This is a concerning sign, as the path to profitability is much further away.
For a naive example, a company can have $1m in revenue and $1.1m in costs, therefore profit is negative 100,000 dollars - the company is unprofitable. However, they are not losing more money ($100,000) then they are bringing in ($1,000,000 is greater than $100,000) - though they are spending more money ($1.1m) then they are bringing in. This would not be a concerning amount of loss, many companies are deliberately outspending current revenue in order to increase future revenue/growth/market share, but could become profitable if they wanted to.
In this case, the person you replied to is remarking that the losses/negative profit ($192m, $130m) are greater than the revenue ($152m, $81m). This is a concerning sign, as the path to profitability is much further away.
First sentence: 'I realise many ... profit < 0'
Second sentence: 'Seems scary ... profit < -revenue'
Second sentence: 'Seems scary ... profit < -revenue'
The majority of their costs are sales, and R&D. Those will almost certainly start to grow much slower than sales, and then they'll be fine.
They have to take customers while they can.
They have to take customers while they can.
this is actually quite surprising to me given what their product is...
this is what I was thinking. I installed a gitlab instance on an old laptop for a friend and myself to use to collaborate on a couple small projects a few years back. I haven't checked in to see what gitlab offers today but I'm having a mental disconnect between all those millions of dollars and what my understanding of the product is. there must be something the product offers that I'm ignorant to that justifies all that money.
GitLab is not just a git hosting and collaboration tool. They want it to be the single tool you use for almost everything to do with an application including monitoring, controlling infrastructure, error logging, project management/planning, security auditing, and a bunch of other things.
If you are using GitLab in a hobbyist or solo way, you are touching about 5% of the features that GitLab provides. Which is fine and a valid way to use it but its easy to see how customers justify spending big dollars on the top plan with hundreds of user licenses when the tool does so much. We even have customer support and project managers using the tool because it caters to them well.
If you want you can even use gitlab to replace something like zendesk as it provides an email address which puts all emails in to a "support desk" queue.
If you are using GitLab in a hobbyist or solo way, you are touching about 5% of the features that GitLab provides. Which is fine and a valid way to use it but its easy to see how customers justify spending big dollars on the top plan with hundreds of user licenses when the tool does so much. We even have customer support and project managers using the tool because it caters to them well.
If you want you can even use gitlab to replace something like zendesk as it provides an email address which puts all emails in to a "support desk" queue.
> We have been a 100% remote workforce since inception and, as of July 31, 2021, had approximately 1,350 team members in over 65 countries. Operating remotely allows us access to a global talent pool that enables us to hire talented team members, regardless of location, providing a strong competitive advantage.
Will be interesting to see how many publicly traded companies are fully remote in 5, 10, 15 years.
Especially since many new startups are starting as fully remote (and will probably stay that way and eventually IPO) and some publicly traded companies have shifted to fully remote (Coinbase, Square, Twitter)
Will be interesting to see how many publicly traded companies are fully remote in 5, 10, 15 years.
Especially since many new startups are starting as fully remote (and will probably stay that way and eventually IPO) and some publicly traded companies have shifted to fully remote (Coinbase, Square, Twitter)
And famously they're leaders on the location-based pay side of the remote pay argument (as opposed to the "we pay everyone based on the value they bring" side): https://about.gitlab.com/handbook/total-rewards/compensation...
Interesting, thanks for the link.
Median salary seems to be $170k according to Levels.fyi -> https://www.levels.fyi/company/GitLab/salaries/Software-Engi...
Median salary seems to be $170k according to Levels.fyi -> https://www.levels.fyi/company/GitLab/salaries/Software-Engi...
You can actually see their salary calculator here https://about.gitlab.com/handbook/total-rewards/compensation...
Are you able to actually use the calculator? You’ve linked the documentation page for it, but the actual tool seems restricted.
You can't see the calculator, but you can see most of the inputs - for this discussion, the factors that weigh on the location-based adjustments are here:
https://about.gitlab.com/handbook/total-rewards/compensation...
https://about.gitlab.com/handbook/total-rewards/compensation...
[deleted]
Another way of saying they'll never retain the best talent. At best they'll have "good" to mediocre. The best will move on.
If you're the best at your language/library/framework you'll always find better compensation than a company that normalizes compensation by locale.
There's plenty of top tier talent in cities across North America and Europe who can find remote employment at companies paying bay area rates.
If you're the best at your language/library/framework you'll always find better compensation than a company that normalizes compensation by locale.
There's plenty of top tier talent in cities across North America and Europe who can find remote employment at companies paying bay area rates.
> Will be interesting to see how many publicly traded companies are fully remote in 5, 10, 15 years.
I'm willing to take that bet. I've already suggested in numerous places on HN (pre-pandemic) that the commercial real estate market itself is going to collapse in the next 10 years because in a remote economy, office spaces have zero or even negative value, and I do see us gradually moving in that direction. Even tasks that traditionally require physical presence (working with CNC machines, materials engineering, etc) have found ways to work remotely using remote-presence robotics, etc., during the pandemic, and all the trustworthy research on the topic has pointed to remote = increased productivity, with FANG companies in particular spearheading the effort to publish bogus studies indicating the contrary.
So in the long-run I think we're going to have a bunch of empty buildings and skyscrapers. As far as the CRE market goes, all those empty buildings would be a great opportunity to create high quality low-cost or free public housing, as is already done with great success in the Netherlands and many of the Nordic countries.
Once remote becomes the norm, the obvious downside of offices (greatly increased cost for decreased productivity and grossly increased negative environmental impact) will do the rest of the work imo.
I'm willing to take that bet. I've already suggested in numerous places on HN (pre-pandemic) that the commercial real estate market itself is going to collapse in the next 10 years because in a remote economy, office spaces have zero or even negative value, and I do see us gradually moving in that direction. Even tasks that traditionally require physical presence (working with CNC machines, materials engineering, etc) have found ways to work remotely using remote-presence robotics, etc., during the pandemic, and all the trustworthy research on the topic has pointed to remote = increased productivity, with FANG companies in particular spearheading the effort to publish bogus studies indicating the contrary.
So in the long-run I think we're going to have a bunch of empty buildings and skyscrapers. As far as the CRE market goes, all those empty buildings would be a great opportunity to create high quality low-cost or free public housing, as is already done with great success in the Netherlands and many of the Nordic countries.
Once remote becomes the norm, the obvious downside of offices (greatly increased cost for decreased productivity and grossly increased negative environmental impact) will do the rest of the work imo.
Just wondering, how do you convert the large office buildings to residential when (at least in much of the US) a bedroom requires a window? A lot of office buildings have a lot more internal space then anything close to a window. It seems like that leads to long narrow shotgun type apartments.
It very well might. This would vary heavily on a per-building basis. Perhaps some buildings would simply go vacant.
I partly disagree. There will be high demand for co-working spaces because employees like to go to the office once you remove the cons (commute, sitting next to your boss, etc). Companies will gladly pay for that too. Commercial buildings will just convert to co-working spaces.
I do see a problem for the centers where there's a high concentration of commercial buildings, esp if they are not nearby residential neighborhoods. Remote works want offices close to where they live, so co-working places need to be spread out and not all concentrated in one main area.
I do see a problem for the centers where there's a high concentration of commercial buildings, esp if they are not nearby residential neighborhoods. Remote works want offices close to where they live, so co-working places need to be spread out and not all concentrated in one main area.
Right but that's assuming 100% of employees even want a co-working space when it's more like 40% if that. That would leave 60% of office building space still vacant, which would be enough to make most landlords / CRE brokers default after a few years.
A lot of those companies are fully remote*
*Timezones and working locations restricted.
*Timezones and working locations restricted.
This seems like a weird move given that developer tools seldom do well on public markets. I can’t help but think that staying private would do more to maintain their community & preserve the reasons people opt for GitLab over GitHub.
Source? Look at MongoDB, Okta, Datadog, Elastic, etc... they wanted more capital, I'm sure their staff wanted liquid equity, this seems like a win for everyone.
MongoDB and Twilio have both done reasonably well haven't they?
Which developer tools have not done well?
Which developer tools have not done well?
Atlassian too
Docker is the main one I can think of that has flopped financially despite being widely use.
Docker has never gone public.
https://www.crunchbase.com/organization/docker
https://www.crunchbase.com/organization/docker
... and it hasn't actually flopped. It just reached its level of... usefulness. As others commented a few weeks ago in a different conversation, Swarm had/has significant utility for smaller deployments, but K8S has sucked the air out of the (marketing) room. So life goes on, as does docker and Docker Hub. Many of us small potatoes users will continue to use docker until we can't, and then probably wind up on podman, or lxd. That will be OK too: as long as the work gets done. We survived the demise of Solaris Freeware, we'll survive this too.
twilio is not a developer tool. twilio is a communications company that has great developer outreach
"... twilio is not a developer tool ..."
Thank you. Strongly agree.
Every day I run into something Twilio could be doing to make development and tooling and workflows better for people who are actually using twilio for telephony.
Instead, they are spending their time, energy and acquisition dollars building "customer engagement at scale" which is a fancy term for spam.
Thank you. Strongly agree.
Every day I run into something Twilio could be doing to make development and tooling and workflows better for people who are actually using twilio for telephony.
Instead, they are spending their time, energy and acquisition dollars building "customer engagement at scale" which is a fancy term for spam.
Twilio’s product is an API.
The end-user of (most of) their products are developers.
The end-user of (most of) their products are developers.
the product is the communications. the people on the phone. reading sms. getting emails. the end user of twilio’s products probably have never heard of twilio and don’t even know their using it
And their product is for developers.
Are you trying to claim that AWS is not for developers because the end users who visit website hosted on AWS are not developers?
Are you trying to claim that AWS is not for developers because the end users who visit website hosted on AWS are not developers?
Perhaps a better way to phrase it: Twilio’s customers are developers.
Their products are built to be used by developers.
As an analogy, AWS’s customer is Netflix. Not the end user who is watching a movie that streams out of an EC2 instance.
Their products are built to be used by developers.
As an analogy, AWS’s customer is Netflix. Not the end user who is watching a movie that streams out of an EC2 instance.
with the clever “ask your developer” billboard campaign
What do you mean? There are tons of developer tools doing great on the market?
DDOG, PD, DOCN, FSLY, NET, TWLO, MDB, TEAM, etc
All of those are doing great, and there are probably like 50 more.
DDOG, PD, DOCN, FSLY, NET, TWLO, MDB, TEAM, etc
All of those are doing great, and there are probably like 50 more.
I write extensively about developer businesses and markets: https://tylerjewell.substack.com/p/developer-led-landscape-2...
What private companies do you have an eye on?
[deleted]
Like Atlassian? (Now at a $100B valuation on the public market)
I'd expect M&A since their competitors are owned by larger companies with a suite of developer productivity offerings.
Good for them, they do a lot of open-source. And they have brought something to the market when GH was the only sheriff in town.
GH was far from the only one around at the time, but it was by far the most market-friendly for what it was. Timing was a big deal too, I think.
But yes, agreed.
But yes, agreed.
Our entire company was on Gitlab.com for 4 years without paying a single dime to them. Unfortunately we moved off (decisions above my head) but I loved how simple everything worked. Their CI is top-notch.
I replaced all of our old not very well integrated tools to GitLab:
Mercurial -> Git(Lab)
Mantis -> GitLab Issues
Dokuwiki -> GitLab Wiki
Jenkins -> GitLab CI
Before, everything was disconnected from each other , Jenkins was not working most of the time, and we didn't even have merge request reviews. Now I can cross-reference everything, have a beautiful working CI and only merge things that are fine. This even made us move from 4$ to 19$ after they announced the cancelation of the smallest plan. We have a local 6 core Ryzen running Ubuntu 18.04LTS with GitLab locally and update every month for the new release and never had a single issue for the past 3 years.
Mercurial -> Git(Lab)
Mantis -> GitLab Issues
Dokuwiki -> GitLab Wiki
Jenkins -> GitLab CI
Before, everything was disconnected from each other , Jenkins was not working most of the time, and we didn't even have merge request reviews. Now I can cross-reference everything, have a beautiful working CI and only merge things that are fine. This even made us move from 4$ to 19$ after they announced the cancelation of the smallest plan. We have a local 6 core Ryzen running Ubuntu 18.04LTS with GitLab locally and update every month for the new release and never had a single issue for the past 3 years.
Text based pipeline YAML files are so powerful.
From page 135 you have what it may be consider one of the most ambitious founder-performance compensation plans ever. The latest tranche, to be observed between 2027 and 2030, will be granted if the share price of Gitlab reaches $500, or 26x the price per share of the most recent fundraising (Series E at $18.6294 per share)
Here is the text if anyone cares fo cmd+F: "The following table indicates the price hurdle and the corresponding performance period in which that hurdle must be achieved and the service vesting date upon which the corresponding vesting is contingent"
Here is the text if anyone cares fo cmd+F: "The following table indicates the price hurdle and the corresponding performance period in which that hurdle must be achieved and the service vesting date upon which the corresponding vesting is contingent"
Maybe they're counting on inflation ;)
What happens if USD is no more in 2030?
"The applicable price hurdle must be achieved during the relevant performance period (as set forth in the table below corresponding to the price hurdle) in order for the applicable tranche of RSU Awards to be earned, but once a price hurdle is achieved, the price hurdle need not be maintained in order for the applicable RSU Award tranche to continue to vest based on service. Once a price hurdle is no longer achievable due to the lapse of a performance period or if Mr. Sijbrandij ceases to be the CEO, any then-unvested portion of the RSU Award will be immediately forfeited."
I wonder how many other CIA funded companies have gone public. Gitlab is funded by In-Q-Tel which is CIA's version of ycombinator basically[1][2].
1. https://www.iqt.org/portfolio?&search=gitlab&taxonomy=&tax_i...
2. https://en.wikipedia.org/wiki/In-Q-Tel
1. https://www.iqt.org/portfolio?&search=gitlab&taxonomy=&tax_i...
2. https://en.wikipedia.org/wiki/In-Q-Tel
Was wondering why their FY21 costs where much higher than first half of this year, this probably explains it:
> Stock-based compensation expense for fiscal 2020 and 2021, and six months ended July 31, 2021 includes $32.7 million, $103.8 million, and $0.3 million, respectively, of compensation expense related to secondary stock sales described in Note 16 to our consolidated financial statements included elsewhere in this prospectus.
Which makes the numbers not as bad as they seem on first glance.
> Stock-based compensation expense for fiscal 2020 and 2021, and six months ended July 31, 2021 includes $32.7 million, $103.8 million, and $0.3 million, respectively, of compensation expense related to secondary stock sales described in Note 16 to our consolidated financial statements included elsewhere in this prospectus.
Which makes the numbers not as bad as they seem on first glance.
Stock based compensation is compensation at the expense of current shareholders. It’s not free money.
True, but sometimes you have a big lump of early employees become liquid at the same time. That’s a not a recurring event, which is important when deciding how viable the business is.
Absolutely agreed, but events like one-off secondaries can somewhat distort the numbers in that they put costs that should be amortized over many in years into a single quarter. You see similar at big cos 6mos after IPO when everything vests.
It does not affect free cash flow or strain the resources of already available to the company.
Stock holders existing and new participate in the success of failure of the company, different from say vendor who needs to be paid no matter what.
it is far worse to be spending 100m in cash to get say 50m in new revenue (if the customers don't stay long enough) as this requires new cash to be infused to keep growing.
Stock holders existing and new participate in the success of failure of the company, different from say vendor who needs to be paid no matter what.
it is far worse to be spending 100m in cash to get say 50m in new revenue (if the customers don't stay long enough) as this requires new cash to be infused to keep growing.
They have explicitly opted to embrace unrestrained capital-seeking's amorality:
https://www.theregister.com/2019/10/16/gitlab_employees_gagg...
I don't really expect the market to care much about this one way or the other, but I do.
(Their competition, Microsoft/GitHub, famously embraces government/military custom, even supplying services to those operating concentration camps.)
This seems to establish a norm for the industry; one of the many reasons I am not a participant.
https://www.theregister.com/2019/10/16/gitlab_employees_gagg...
I don't really expect the market to care much about this one way or the other, but I do.
(Their competition, Microsoft/GitHub, famously embraces government/military custom, even supplying services to those operating concentration camps.)
This seems to establish a norm for the industry; one of the many reasons I am not a participant.
Surprised to see them IPO, IMO their best chance for their biggest valuation was to sell to AWS or GCP after they realize losing GitHub to MS/Azure was a major competitive disadvantage.
From their financials they've raised 415M total and are still making a loss that's widening for what looks like is only 3,632 customers (ARR>5k), i.e. 114k raised per base customer.
They'll likely have a successful exit but not very optimistic about their future given they have to compete with ubiquity and deep pockets of GitHub/MS and going IPO makes an acquisition target less likely. Given they have formidable and dominant competition with GitHub who's been executing on all cylinders I'll be steering clear of this IPO.
From their financials they've raised 415M total and are still making a loss that's widening for what looks like is only 3,632 customers (ARR>5k), i.e. 114k raised per base customer.
They'll likely have a successful exit but not very optimistic about their future given they have to compete with ubiquity and deep pockets of GitHub/MS and going IPO makes an acquisition target less likely. Given they have formidable and dominant competition with GitHub who's been executing on all cylinders I'll be steering clear of this IPO.
Last valuation was $6 billion, they initially wanted to go public in November of 2020 but because of COVID they delayed it.
Doesn't sound cheap to me for a company who isn't profitable yet...
(Microsoft payed 7,5 billion for GitHub and I think we can all agree that GitLab isn't used as much so nearly the same valuations seems a bit high too me)
Doesn't sound cheap to me for a company who isn't profitable yet...
(Microsoft payed 7,5 billion for GitHub and I think we can all agree that GitLab isn't used as much so nearly the same valuations seems a bit high too me)
Well, we have to ask ourselves two things:
1. What would GitHub actually be valued at now? It's possible that all valuations have risen.
2. What does GitLab provide that GitHub doesn't? We went with it for our on-site Git hosting because of a lot of features, but also because we were able to engage their dev team and add support for some of our software to their product (above the non-free tier) so that we can do 2fa git-over-ssh using our own OTP software and API. Definitely couldn't get that with Gitlab.
On the other hand, GitLab suffers from "not the best" syndrome; GitHub is the best, and everyone everywhere supports it. GitLab is not the best, so support for it is extremely limited across the board. At this point, I'm surprised if we find software that natively supports Gitlab integration beyond just "pull a repository using a key or password".
1. What would GitHub actually be valued at now? It's possible that all valuations have risen.
2. What does GitLab provide that GitHub doesn't? We went with it for our on-site Git hosting because of a lot of features, but also because we were able to engage their dev team and add support for some of our software to their product (above the non-free tier) so that we can do 2fa git-over-ssh using our own OTP software and API. Definitely couldn't get that with Gitlab.
On the other hand, GitLab suffers from "not the best" syndrome; GitHub is the best, and everyone everywhere supports it. GitLab is not the best, so support for it is extremely limited across the board. At this point, I'm surprised if we find software that natively supports Gitlab integration beyond just "pull a repository using a key or password".
GitHub wasn't profitable either when MS aquired it.
it was about the same ARR than gitlab is right now.
Now if your talking about brand and positioning that's another matter.
Now if your talking about brand and positioning that's another matter.
What's your source for the ARR comparison, out of interest? I'm of a different impression, and believe GitHub's ARR was actually quite a bit higher than GitLab at the point Microsoft executed that deal.
Do you think the GitHub or GitLab brand is stronger, today?
Do you think the GitHub or GitLab brand is stronger, today?
Timing of the CFO joining is interesting to me. From the S-1, Brian Robins joined GitLab in October 2020, so the desire to go public may have been there but an IPO is an enormous amount of work and I can imagine goes much better with an experienced CFO at the helm who has done it before. Therefore, "because of COVID" sounds like a contributing factor certainly, but may not be the whole story.
IIRC they had announced they weren't going to IPO in 2020 several months prior to that change. So I wouldn't assume they just didn't realize the work involved until October. Maybe they post-poned the IPO earlier in the year because they decided they wanted to find the right person for the job.
Tech valuations have doubled over the last four years.
The simplest heuristic is price/sales ratios.
Money losing companies that are doubling their revenue are currently going for nosebleed ps ratios of 40-100, which equates to $5-$13b market cap.
The simplest heuristic is price/sales ratios.
Money losing companies that are doubling their revenue are currently going for nosebleed ps ratios of 40-100, which equates to $5-$13b market cap.
this is why the companies in the last year before IPO go like crazy all the way in burning cash on customer acquisition and sales expansion. All the issues stemming from that are left to be dealt with by the post-IPO bug holders.
One of my favorite company with the true remote/open culture.
GitHub is yet to match the features GitLab provides. - Especially small but interesting features such as Group / Sub-group, much mature SDK/API, Better CI, and Web based Folder creation.
Competition is healthy, it brings in more benefits for end users.
GitHub is yet to match the features GitLab provides. - Especially small but interesting features such as Group / Sub-group, much mature SDK/API, Better CI, and Web based Folder creation.
Competition is healthy, it brings in more benefits for end users.
Personally, I think Gitlab needs to match with features of Github and its reliability.
Curious what are some of the top features GH has which GL doesn’t?
Based on free Github:
Github Check Runs API Github Applications Security scanning, vulnerability alerting Packages Registry that's reliable
The kind of integrations that Github offers for pull requests in general is miles away from Gitlab. Some of the things I mentioned above are possible in Gitlab but only on the highest tier and still then the UI integration isn't a great.
Github Check Runs API Github Applications Security scanning, vulnerability alerting Packages Registry that's reliable
The kind of integrations that Github offers for pull requests in general is miles away from Gitlab. Some of the things I mentioned above are possible in Gitlab but only on the highest tier and still then the UI integration isn't a great.
Does anybody actually embrace Gitlab fully?
Anybody I've seen uses it for git, and at most CI/CD on top. But who else (other than gitlab themselves) uses all of their stuff.
They're pushing really hard for that with their "the devops platform" thing, etc.
Anybody I've seen uses it for git, and at most CI/CD on top. But who else (other than gitlab themselves) uses all of their stuff.
They're pushing really hard for that with their "the devops platform" thing, etc.
I manage two teams and we use it for "everything" and have as part of our team values to use Gitlab fully.
We are on premium, the ultimate features would be an easier way to replace Jira but we manage with epics, milestones and iterations.
We are on premium, the ultimate features would be an easier way to replace Jira but we manage with epics, milestones and iterations.
Maybe not all the stuff, but I have seen many use Gitlab's docker & package registries, I think Gitlab's merge request discussions are miles ahead of Github's (threads without line discussions, can compare versions, etc), the test result integration is okay, we do use the issue boards a lot. We kinda use the deployments, but only for review apps. Merge trains are great too. There might be more cool stuff, that I either don't know about or have no use for, but in general they do provide some great stuff. (Not that Gitlab doesn't also have bad stuff.)
Does anyone know how Gitlab went from being a Ducth BV to a US Inc?
I see all of the founder's shares and options are owned by Rients.org BV and would love to know a bit more about the structure.
Seems like EU companies eventually become American and I would love to know how :)
I see all of the founder's shares and options are owned by Rients.org BV and would love to know a bit more about the structure.
Seems like EU companies eventually become American and I would love to know how :)
We did that in 2014. The process is straight forward and is called a Delaware flip (if I remember correctly): you setup a C-Corp in the US and then do a share flip for all share holders in the EU company to the same percentage in the US Corp. this will make the shareholders of the original company stock holders of the US one and the original company becomes a wholly owned subsidiary of the US one (or can be folded if no liabilities are left and no need for it exists)
Super. Would be very interested to know if this is possible with a Spanish company. From hearsay, Spain is supposed to be way harder than Netherlands or UK.
Thanks!
Thanks!
We have two classes of authorized common stock, Class A common stock and Class B common stock. The rights of the holders of Class A common stock and Class B common stock are identical, except with respect to voting and conversion rights. Each share of Class A common stock is entitled to one vote per share. Each share of Class B common stock is entitled to 10 votes per share and is convertible into one share of Class A common stock.
So who gets to be CEO for Life? Sid Sijbrandij?
So who gets to be CEO for Life? Sid Sijbrandij?
Congrats to the Gitlab team! Very happy on-premise Gitlab user, for both our relatively small scale SAAS and our digital agency. Our growth mirrored Gitlab's, so we started with the basic git hosting + issue tracker, and have added CI and other features in our workflow as time went by. Nice thing to know is that we've upgraded our instance for over the last 5 years and never had to do a backup/reinstall, which shows something about the general software quality.
The big issue we have with GitLab is the pricing. Ultimate is literally five (!!!) times more than premium. And there are only a couple of features that we want from ultimate.
There are also some asinine divisions w.r.t. what goes in Premium vs. Ultimate.
For example, Premium allows us to configure our CI system to ingest Coverity scans, but only Ultimate lets us actually view them in the GUI. What the hell, guys?
We're not paying for Ultimate, though, unless they give us a sweetheart deal in perpetuity, but it's still kind of ridiculous.
That said, they do tend to trickle features down, moving them from higher tiers to lower tiers, or lower tiers to the free tier, so maybe in a few versions we'll get that support for no extra cost.
For example, Premium allows us to configure our CI system to ingest Coverity scans, but only Ultimate lets us actually view them in the GUI. What the hell, guys?
We're not paying for Ultimate, though, unless they give us a sweetheart deal in perpetuity, but it's still kind of ridiculous.
That said, they do tend to trickle features down, moving them from higher tiers to lower tiers, or lower tiers to the free tier, so maybe in a few versions we'll get that support for no extra cost.
yeah ... I can't give Gitlab my money. We are ready to pay but the licensing model is just incompatible with our org. Very sad, I like the product very much but we are forced to keep coasting on the free version.
Also, pay only per year, instead of per month. So if you even want to get started you better be ready to fork over $1200 per developer immediately.
I can say a lot of bad things about Atlassian, but their price/benefit ratio is outstanding.
I can say a lot of bad things about Atlassian, but their price/benefit ratio is outstanding.
Do we have any idea when the stock will be available?
> Our business has experienced rapid growth. We generated revenue of $81.2 million and $152.2 million in fiscal 2020 and 2021, respectively, representing growth of 87%. We generated revenue of $63.9 million and $108.1 million for the six months ended July 31, 2020 and July 31, 2021, respectively, representing year over year growth of 69%. During this period, we continued to invest in growing our business to capitalize on our market opportunity. Our net loss was $130.7 million, $192.2 million, and $69.0 million in fiscal 2020, fiscal 2021, and the six months ended July 31, 2021, respectively.
Another buy in my books after calling CloudFlare [0] and DigitalOcean [1]. Looking forward to the listing of 'GTLB'.
[0] https://news.ycombinator.com/item?id=20707306
[1] https://news.ycombinator.com/item?id=26262799
Another buy in my books after calling CloudFlare [0] and DigitalOcean [1]. Looking forward to the listing of 'GTLB'.
[0] https://news.ycombinator.com/item?id=20707306
[1] https://news.ycombinator.com/item?id=26262799
Buy at what price? The revenue numbers are nice but not stellar to me. Quite a big spend, the path to real earnings could be really hard.
I’m a bit concerned that they have to compete against Microsoft/Github and their engineering/marketing/sales might. In your view why do you think they will be able to coexist long term?
Slightly meta but: Has anyone done an analysis of how well companies, who have their S-1 posted on HN, perform?
I'm curious what other HN users think of Gitlab's pricing?
I was considering Gitlab when pitching a new platform for my org but the value really didn't seem to be there when compared to Atlassian/Microsoft.
I was considering Gitlab when pitching a new platform for my org but the value really didn't seem to be there when compared to Atlassian/Microsoft.
Congrats Sytse.
18.9% shares, not bad. Had a chat with him a few year ago at the gitlab booth at Fosdem.
Somewhere around 2014 Sytse asked my former coworker to become gitlab’s first employee, working on Ruby code. Completely understand the request, as he’s an excellent DevOps engineer and fine colleague. He declined to opt for a more secure job position ....
Somewhere around 2014 Sytse asked my former coworker to become gitlab’s first employee, working on Ruby code. Completely understand the request, as he’s an excellent DevOps engineer and fine colleague. He declined to opt for a more secure job position ....
FWIW as the first engineer he might have gotten 1% of the stock, which would be worth about $6M. If he's really that good, there is a decent chance his more secure job has paid that much in 7 years, especially if it was with a FAANG company.
No way it is 6M. That is too low. I could have got that by joining stripe a few years back while enjoying high salary.
No company in NL pays FAANG salaries. My former coworker‘s rate as external consultant is around €120/h.
He’s a super nice person.
I would have killed to get some of this equity. Where can a regular investor buy these shares pre-IPO? I sat on ZenEquity for a while and saw nothing.
Gitlab CI pipelines also validation errors in the Pipeline editor but when you then run it's all good. Super confusing these errors which aren't errors issues. Such a time sink
I wonder if this could be considered as a pseudo index fund of the general tech sector as they essentially exist to serve tech-oriented companies.
Congratulations Gitlab employees! I am super happy for you all! Well deserved!
I'm not sure why people support Gitlab when the user experience is so much worse. It's a complete mess of a product with so many bugs as to be nigh unusable.
I am bullish!
[deleted]
What a shame
yeah it's a real shame for the folks with equity to finally have liquidity.
I'm not really seeing what's shameful about a public exit. They're a great company with an amazing product. This is good for GitLab.
I'm not really seeing what's shameful about a public exit. They're a great company with an amazing product. This is good for GitLab.
It is good for GitLab, what a shame for GitLab's users
complete nonsense and FUD.
I would argue that private equity has had a longer deleterious effect on product development, and also some IPOs have turned out disastrous, but it isn't a hard and fast rule to say that a company, once it goes public, automatically turns against its userbase.
I would argue that private equity has had a longer deleterious effect on product development, and also some IPOs have turned out disastrous, but it isn't a hard and fast rule to say that a company, once it goes public, automatically turns against its userbase.
It's only a matter of time before I move to sourcehut I think.
I paid for it recently. So far it's been a mixed bag for me. The core works as intended, but little annoyances can add up.
I love that the design is small and light, but almost none of the languages is use are supported by Pygments for highlighting so someone browsing the code may find it off putting (GitLab I can use gitattributes to select a different but compatible Rouge highlighter). I like that NixOS is a first-class compatible image, but GitLab offered more in build options (run certain tasks only on tags, run this job on a cron, etc.). I love that I can push any markup I want to the ‘README’ of a project, but I wouldn't have to if Markdown wasn't the only option (MD's so limiting without admonitions, definition lists, block titles, ToC, etc.). Project discovery has a lot to be desired, but at least it doesn’t have gamification like “stargazers”.
I love that the design is small and light, but almost none of the languages is use are supported by Pygments for highlighting so someone browsing the code may find it off putting (GitLab I can use gitattributes to select a different but compatible Rouge highlighter). I like that NixOS is a first-class compatible image, but GitLab offered more in build options (run certain tasks only on tags, run this job on a cron, etc.). I love that I can push any markup I want to the ‘README’ of a project, but I wouldn't have to if Markdown wasn't the only option (MD's so limiting without admonitions, definition lists, block titles, ToC, etc.). Project discovery has a lot to be desired, but at least it doesn’t have gamification like “stargazers”.
> almost none of the languages is use are supported by Pygments for highlighting
What languages are those? Pygments supports a lot of languages[1].
[1]: https://pygments.org/languages/
What languages are those? Pygments supports a lot of languages[1].
[1]: https://pygments.org/languages/
Why?
> what a shame for GitLab's users
Can you please elaborate about this?
Can you please elaborate about this?
In my opinion public exit has been twisted 180 degrees. The reason for a company going public is to raise capital that individuals do not have to expand the business - build new factories, hire or whatever. After all there is much more money distributed in the public than few individuals have and in exchange you get shares in the company.
I don't think GitLab is in need of that, what a lot of companies are doing now when they go public is just a method of 'cashing out'. When you have a great product as a private company your income comes from the users and you tailor and improve your product for their needs. When you go public in the above sense you're cashing out and suddenly the users shift to a product and shareholders are now what you cater for while trying to milk your 'users' as much as possible without them quitting.
I don't think GitLab is in need of that, what a lot of companies are doing now when they go public is just a method of 'cashing out'. When you have a great product as a private company your income comes from the users and you tailor and improve your product for their needs. When you go public in the above sense you're cashing out and suddenly the users shift to a product and shareholders are now what you cater for while trying to milk your 'users' as much as possible without them quitting.
I disagree with this characterisation.
Gitlab is losing money. They do need the capital.
While it's true sometimes shareholder interests can lead to the users getting screwed, that's a very short term and dangerous game to play. It's the equivalent of killing the Golden Goose. Companies that play that game may find themselves out of business in short order. They're opening opportunities for the competition.
Gitlab is losing money. They do need the capital.
While it's true sometimes shareholder interests can lead to the users getting screwed, that's a very short term and dangerous game to play. It's the equivalent of killing the Golden Goose. Companies that play that game may find themselves out of business in short order. They're opening opportunities for the competition.
> public exit
That's the exact opposite of what is happening.
That's the exact opposite of what is happening.
Yea it would be much better if only a small select group of elites were allowed to invest in companies.
Sorry for off-topic but notice how long this page is and yet how fast it loads. Why is it so hard to pull off elsewhere on the Web.
It's not hard. This is a .gov website and as such isn't plagued with a million external tracking and advertising/marketing scripts. It is also completely static.
Because it is a static document
So what? Most, or at least a lot of, Web documents are pretty much static, but they don't load nearly as fast.
(static, except for the tracking scripts and ads :))
(static, except for the tracking scripts and ads :))
No, they are not. Most of the content on the web is dynamic, based on things like your authentication, geolocation, time, and other things
Ironically, the 5-6 images on the page are really poorly optimized, making the total payload of the page probably 3-4 times as big as it could be.
I m in one of the companies they quoted as case study. The lies are so horrible I hesitate to do something: they fucked us completely replacing a wonderful github/teamcity combo, it crashes all the time, features are so amateurish (vs teamcity especially) that we're struggling just to do basic things.
I dont know what to do, but public investors should stay away: the product is not ready for people to pay for it. It's years behind the competition.
I dont know what to do, but public investors should stay away: the product is not ready for people to pay for it. It's years behind the competition.
Counterpoint: we've moved to GitLab internally (from SVN, granted), and while GitHub would have been easier because it's far more widely supported in tooling and integrations, GitLab has been great for us so far.
I would have preferred to switch to GitHub if we had an internal hosted GitHub Enterprise kind of situation, but so far Gitlab is doing fine for us.
It could be a matter of scale, though; perhaps for larger teams, larger repositories, or pre-existing Git-based MR/CI workflows, it's a dumpster fire, but that's not us so we can't speak to it.
Who knows though, maybe in a few years I'll regret writing this comment.
I would have preferred to switch to GitHub if we had an internal hosted GitHub Enterprise kind of situation, but so far Gitlab is doing fine for us.
It could be a matter of scale, though; perhaps for larger teams, larger repositories, or pre-existing Git-based MR/CI workflows, it's a dumpster fire, but that's not us so we can't speak to it.
Who knows though, maybe in a few years I'll regret writing this comment.
Honestly sounds like an implementation issue. I've run multiple Gitlab instances and I've used some more, and "crashes all the time" isn't a thing that just happens. Most features work fine, core ones even more so, some of the newer ones are clearly not polished enough but mostly function.
It's literally years in front of the competition ( GitHub and BitBucket).
It's literally years in front of the competition ( GitHub and BitBucket).
How many thousands repos do you have ? We are 10k+ users with many many more repos scattered around the world.
But the thing I ll say is the git part is satisfactory. It's the CI part we are livid about.
It's not "years in front of the competition" if you think of Teamcity. Github focus on what it does right.
But the thing I ll say is the git part is satisfactory. It's the CI part we are livid about.
It's not "years in front of the competition" if you think of Teamcity. Github focus on what it does right.
I'd say 5-6k users, and the number of repos is easily between there and 10k on the biggest Gitlab instance I've used. The CI/CD part works well, including for complex multi-project dynamic pipelines. We don't have crashes, ever.
> It's not "years in front of the competition" if you think of Teamcity. Github focus on what it does right.
The competition for me is the all-in-one solutions like Github and Bitbucket. If you have to deploy, maintain and sometimes pay for an extra CI/CD solution, either something is wrong or you have very very specific requirements. What is it that TeamCity does better than Gitlab CI/CD?
> It's not "years in front of the competition" if you think of Teamcity. Github focus on what it does right.
The competition for me is the all-in-one solutions like Github and Bitbucket. If you have to deploy, maintain and sometimes pay for an extra CI/CD solution, either something is wrong or you have very very specific requirements. What is it that TeamCity does better than Gitlab CI/CD?
I was gonna write a long list of doleances but you know what, Ill give it a chance after all. We re still learning it, we ll figure it out I guess, and if it's cheaper, well, it s more money for shareholders.
> it crashes all the time, features are so amateurish (vs teamcity especially) that we're struggling just to do basic things.
Do you have an on-prem instance? What sort of features does teamcity have that are not there in Gitlab CI?
Teams in my org are currently switching from Gerrit/Jenkins combos to Gitlab and I have been pretty pleased so far. I do wish there was a nicer way to experiment with different CI configurations from within the browser to prevent a bunch of pointless commits messing with your config YAML; but, otherwise I have been pretty happy with the flexibility.
Do you have an on-prem instance? What sort of features does teamcity have that are not there in Gitlab CI?
Teams in my org are currently switching from Gerrit/Jenkins combos to Gitlab and I have been pretty pleased so far. I do wish there was a nicer way to experiment with different CI configurations from within the browser to prevent a bunch of pointless commits messing with your config YAML; but, otherwise I have been pretty happy with the flexibility.
Well gitlab has all the features of teamcity on paper: it can run a remote script and build any random thing.
But why do we need so much work to write the script ? Why is the reporting so bad on test failure, why building complex dependency chains running in parallel and in sequence doesnt work ? Why do we need to touch the repo to change the build descriptor?
It's just not as fun to use, immediate, beautiful, and productive. It's thrown on top of the git part, half assed.
But why do we need so much work to write the script ? Why is the reporting so bad on test failure, why building complex dependency chains running in parallel and in sequence doesnt work ? Why do we need to touch the repo to change the build descriptor?
It's just not as fun to use, immediate, beautiful, and productive. It's thrown on top of the git part, half assed.
I'm from another company quoted in a case study and can say the contrary overall.
It does require work to properly scale for a few thousand of people if you run it yourself but it provides a lot of values for our developers to get their work done and require less maintenance than other SCM/CI systems we had to maintain in the past.
It does require work to properly scale for a few thousand of people if you run it yourself but it provides a lot of values for our developers to get their work done and require less maintenance than other SCM/CI systems we had to maintain in the past.
Are you one of these developers? Our management speak the same way of our infinite suffering during the migration ;)
You may betray yourself: developer dont maintain the CI system, they use it. And while I may accept it's now easier to maintain, why not, it's because it does less of what we need, possibly ?
You may betray yourself: developer dont maintain the CI system, they use it. And while I may accept it's now easier to maintain, why not, it's because it does less of what we need, possibly ?
If you are looking for a self-hosted git system, I highly recommend Gitea. Very lightweight and an order of magnitude easier to install and maintain. I am super impressed.
Gitea has a ton of issues, sadly. We self-hosted an instance where we had a number of mirrors and whatnot to have redundant copies of third-party dependencies. The server would deadlock, mirror tasks would time out and then couldn't be restarted, etc.
We filed an issue (or maybe two) and the developers were... eh. A bit rude, to be honest. Dismissive that it was really an issue, where restarting and deleting/re-configuring was a massive PITA.
Therefore, I can't really rec Gitea myself. I wish something like it existed though. That's for sure. Gitlab is just too bloated for my taste and our needs.
We filed an issue (or maybe two) and the developers were... eh. A bit rude, to be honest. Dismissive that it was really an issue, where restarting and deleting/re-configuring was a massive PITA.
Therefore, I can't really rec Gitea myself. I wish something like it existed though. That's for sure. Gitlab is just too bloated for my taste and our needs.
I've ran it for years and never had a deadlock. How big were your code bases, how many users?.. idk if that is even the reason why
Large, and the deadlock was only a few times but the stalled and unresumable mirrors were rampant.
We were mirroring the linux kernel and maybe 40-50 different repositories. Two users.
We were mirroring the linux kernel and maybe 40-50 different repositories. Two users.
Could you link the issues please? Planning to use Gitea with a lot of mirrored repos.
Our recent growth may not be indicative of our future growth, and we may not be able to sustain our revenue growth rate in the future. Our growth also makes it difficult to evaluate our future prospects and may increase the risk that we will not be successful.
I don't know why I thought Gitlab was completely private, but...welp, see ya later Gitlab. I'm looking forward to see what revenue you can squeeze out of customers from afar, without me on the platform.
I don't know why I thought Gitlab was completely private, but...welp, see ya later Gitlab. I'm looking forward to see what revenue you can squeeze out of customers from afar, without me on the platform.
Every S-1 in existence says that. Why people always share this excerpt when an S-1 is listed here in HN?
Just look back at any S-1 post and there's always somebody who shares it. Why? Do they really think they are illuminating someone else with the most boiler-plate phrase in the existence of S-1 filings?
Just look back at any S-1 post and there's always somebody who shares it. Why? Do they really think they are illuminating someone else with the most boiler-plate phrase in the existence of S-1 filings?
Even if they go broke and get taken over by a completely evil group tomorrow they will have left behind a very nice open source project.
Pretty much every S1 ever has similar language. Do you refuse to use any public company products?
This verbiage is present in basically every S-1 and quarterly filing, if not verbatim, then very close.
Most financial filings are filled with cover your ass statements like this.
Correct. The Robinhood disclosures were a fun read with Dogecoin trades (meme coin) being a large portion of their revenue.
What does completely private mean? Do you mean bootstrapped?
Yeah, not VC-funded. Stupid mistake on my part given the industry we're in
They're literally a YC company: https://www.ycombinator.com/companies/gitlab
Gitlab, I believe, informs the common strategy behind most other source-available ycombinator enterprise startups: the buyer-based open-core model [4]
Congratulations Gitlab. You're far from a copycat and deserve all the success for relentless execution and radical transparency, if nothing else [5]
[0] https://www.youtube-nocookie.com/embed/gOp4lKSCulI
[1] https://www.youtube-nocookie.com/embed/vCiLMLC2Rhs
[2] https://www.youtube-nocookie.com/embed/uUwmlJfim6U
[3] https://www.youtube-nocookie.com/embed/XcqloQezOUg
[4] https://www.heavybit.com/library/video/commercial-open-sourc...
[5] https://about.gitlab.com/handbook/values/