Gitlab S-1 • Hacker News Board

Re: Gitlab S-1

#171

Post by manquer » Fri, Sep 17, 2021, 9:20 PM UTC

stefan_ wrote: post #126

HWR_14 wrote: post #116

Earlier quoted context omitted.

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.

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.

Re: Gitlab S-1

#172

Post by tempest_ » Fri, Sep 17, 2021, 9:24 PM UTC

oweiler wrote: post #159

ModernMech wrote: post #107

Earlier quoted context omitted.

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 feat…

Except Github Actions is leaps and bounds above Gitlab CI.

Really?

I have consistently heard the opposite.

Actions has more polish but is not as feature rich is what I have heard.

Re: Gitlab S-1

#173

Post by manquer » Fri, Sep 17, 2021, 9:25 PM UTC

TradingPlaces wrote: post #65

jcdavis wrote: post #59

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 t…

Stock based compensation is compensation at the expense of current shareholders. It’s not free money.

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.

Re: Gitlab S-1

#174

Post by jstsch » Fri, Sep 17, 2021, 9:32 PM UTC

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.

Re: Gitlab S-1

#175

Post by tyingq » Fri, Sep 17, 2021, 9:34 PM UTC

nonameiguess wrote: post #140

nonameiguess wrote: post #136

Earlier quoted context omitted.

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 t…

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 hap…

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.

Re: Gitlab S-1

#176

Post by benatkin » Fri, Sep 17, 2021, 9:34 PM UTC

tyingq wrote: post #147

chx wrote: post #96

Earlier quoted context omitted.

Who can edit that page? https://git.drupalcode.org/

The owners/maintainers listed here probably: https://git.drupalcode.org/project/drupal/-/project_members

Wrong page. Means to add drupal to that wiki page in my comment, since it's missing.

Re: Gitlab S-1

#177

Post by deepbluev7 » Fri, Sep 17, 2021, 9:35 PM UTC

jenny91 wrote: post #73

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.

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

Re: Gitlab S-1

#178

Post by tyingq » Fri, Sep 17, 2021, 9:37 PM UTC

benatkin wrote: post #176

tyingq wrote: post #147

Earlier quoted context omitted.

The owners/maintainers listed here probably: https://git.drupalcode.org/project/drupal/-/project_members

Wrong page. Means to add drupal to that wiki page in my comment, since it's missing.

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.

Re: Gitlab S-1

#179

Post by sillysaurusx » Fri, Sep 17, 2021, 9:43 PM UTC

reilly3000 wrote: post #167

INTPenis wrote: post #148

Earlier quoted context omitted.

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…

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.

Re: Gitlab S-1

#180

Post by crazy_horse » Fri, Sep 17, 2021, 9:55 PM UTC

sillysaurusx wrote: post #179

reilly3000 wrote: post #167

Earlier quoted context omitted.

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.

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