Gitlab is one of the pioneers of "remote-first" [0] and "building in public" [1], to the extent of sometimes even live-streaming CEO meetings [2] and sales pitches [3]
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]
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.
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.
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.
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.
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”
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.
> 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?
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
> 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.
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.
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.
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)
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.
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.
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 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.
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.
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.
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
Ah, yeah...sorry. There is a history tab where you can see the users that last updated it. Though the page appears to be untouched for a couple of years, so that may not pan out.
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.
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.
> 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.
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.
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.
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.
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.
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%.
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.
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.
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
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.
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:
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>"
When you need to debug, the output of
yarn config list
is pretty concise and helpful. Be aware there can be local per-config folder so if you have trouble in a specific project you should issue that command there and check for incorrect registry settings etc. I also suggest you fully commit to yarn or npm, they are definitely different enough to be awkward to combine.
> 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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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).
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...).
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.
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.
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).
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!)
>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).
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.
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.
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.
> 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)
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:
> 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 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.
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.
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.
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.
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.
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 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.
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.
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"
"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."
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.
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.
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.
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)
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".
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.
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.
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?
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.
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.
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.)
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.
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.
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.
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.
> 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'.
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?
Most likely because their comment just sounds like them encouraging people to buy the stock (saying 'I called these other stocks and they did well, and now I'm buying this stock'). Whether they meant to or not, it comes off that way.
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 ....
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.
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'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 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 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”.
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.
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.
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.
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.
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).
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?
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.
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.
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'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.
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 ?
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.
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.
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?
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/