[HN Gopher] Gitlab S-1
___________________________________________________________________
Gitlab S-1
Author : laminarflow
Score : 611 points
Date : 2021-09-17 17:19 UTC (5 hours ago)
(HTM) web link (www.sec.gov)
(TXT) w3m dump (www.sec.gov)
| anthony_r wrote:
| 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.
| enlyth wrote:
| Because it is a static document
| anthony_r wrote:
| 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 :))
| enlyth wrote:
| No, they are not. Most of the content on the web is
| dynamic, based on things like your authentication,
| geolocation, time, and other things
| bool3max wrote:
| 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.
| lftl wrote:
| 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.
| priansh wrote:
| 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.
| statictype wrote:
| MongoDB and Twilio have both done reasonably well haven't they?
|
| Which developer tools have not done well?
| HideousKojima wrote:
| Docker is the main one I can think of that has flopped
| financially despite being widely use.
| riffic wrote:
| Docker has never gone public.
|
| https://www.crunchbase.com/organization/docker
| ncphil wrote:
| ... 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.
| foolfoolz wrote:
| twilio is not a developer tool. twilio is a communications
| company that has great developer outreach
| vmception wrote:
| with the clever "ask your developer" billboard campaign
| rsync wrote:
| "... 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.
| camjohnson26 wrote:
| Atlassian too
| spullara wrote:
| Like Atlassian? (Now at a $100B valuation on the public market)
| lawrencevillain wrote:
| 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.
| TylerJewell wrote:
| I write extensively about developer businesses and markets:
| https://tylerjewell.substack.com/p/developer-led-landscape-2...
| moneywoes wrote:
| What private companies do you have an eye on?
| [deleted]
| wefarrell wrote:
| I'd expect M&A since their competitors are owned by larger
| companies with a suite of developer productivity offerings.
| dubcanada wrote:
| 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.
| jstsch wrote:
| 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.
| sjtindell wrote:
| 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.
| alberth wrote:
| 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.
| greghendershott wrote:
| 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.
| b9a2cab5 wrote:
| 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.
| anonymoustrolol wrote:
| 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.
| mikysco wrote:
| 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.
| danielmarkbruce wrote:
| 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.
| dfee wrote:
| Isn't your second sentence just a truism on the first sentence?
|
| profit = revenue - costs
| beeneuf wrote:
| 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.
| OJFord wrote:
| First sentence: 'I realise many ... profit < 0'
|
| Second sentence: 'Seems scary ... profit < -revenue'
| alberth wrote:
| Maybe a better way of saying what I meant is, gitlab is
| losing more than 2x their total generated. That's what seems
| scary.
| joering2 wrote:
| 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]
| jpollock wrote:
| he means losses > revenue, in other words costs > 2xrevenue.
| joelbluminator wrote:
| Yes and seeing the loss grow like that yearly is not a good
| look. Otherwise the product is really good.
| mason55 wrote:
| 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.
| RC_ITR wrote:
| 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).
| b9a2cab5 wrote:
| 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!)
| jppope wrote:
| this is actually quite surprising to me given what their
| product is...
| adamrezich wrote:
| 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.
| fnordsensei wrote:
| 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?
| stefan_ wrote:
| 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.
| HWR_14 wrote:
| Are you being sarcastic or not? And what are the explanations
| you've heard?
| stefan_ wrote:
| 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.
| amelius wrote:
| Sounds a lot like:
|
| https://en.wikipedia.org/wiki/Predatory_pricing
|
| And is illegal in some jurisdictions and frowned upon in
| others.
| NovemberWhiskey wrote:
| No? The point is just that revenue for subscription
| models recurs whereas build cost does not (handwave).
| amelius wrote:
| Yes? There are operational costs involved as well. It's
| not like a company fires half of their team after the
| product is launched.
| manquer wrote:
| 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.
| stefan_ wrote:
| 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.
| gigatexal wrote:
| 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.
| gigatexal wrote:
| 1.61x of costs not revenue. I was dividing the expenses from
| year to year.
| bpodgursky wrote:
| _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.
| sjatkins wrote:
| 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.
| codegeek wrote:
| 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.
| HWR_14 wrote:
| 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.
| lucasverra wrote:
| 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.
| junon wrote:
| 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.
| ignoramous wrote:
| 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]
|
| [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/
| INTPenis wrote:
| 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.
| reilly3000 wrote:
| 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!
| sillysaurusx wrote:
| 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.
| crazy_horse wrote:
| 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
| klik99 wrote:
| 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"
| tln wrote:
| GitHub seems to care about user experience even though
| they're winning though.
| sillysaurusx wrote:
| 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.
| bevdecloud wrote:
| 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.
| [deleted]
| benatkin wrote:
| 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.
| chx wrote:
| Who can edit that page? https://git.drupalcode.org/
| tyingq wrote:
| The owners/maintainers listed here probably:
|
| https://git.drupalcode.org/project/drupal/-/project_members
| benatkin wrote:
| Wrong page. Means to add drupal to that wiki page in my
| comment, since it's missing.
| tyingq wrote:
| 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.
| yibg wrote:
| 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.
| ModernMech wrote:
| 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.
| james-skemp wrote:
| In addition to the above, GitLab Pages continues to be easier
| to setup and use (on GitLab.com) than GitHub Pages.
| oweiler wrote:
| Except Github Actions is leaps and bounds above Gitlab CI.
| ModernMech wrote:
| 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.
| tyingq wrote:
| >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.
| tempest_ wrote:
| Really?
|
| I have consistently heard the opposite.
|
| Actions has more polish but is not as feature rich is what
| I have heard.
| dmurray wrote:
| 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
| dcchambers wrote:
| 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.
| ModernMech wrote:
| I'm the opposite actually. I do all my dev on Gitlab, and
| mirror on Github for the exposure.
| jupp0r wrote:
| 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.
| base698 wrote:
| To me it was very compelling before GitHub actions and only
| slightly compelling now.
| eftokay83 wrote:
| Mind to share a "quick link" to the mentioned documents?
| sm4rk0 wrote:
| https://about.gitlab.com/handbook/
| dcchambers wrote:
| 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
| rvz wrote:
| > 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
| joelbluminator wrote:
| 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.
| flafla2 wrote:
| 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?
| nix23 wrote:
| Why the down-votes? ....ahh humans :)
| bussierem wrote:
| 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.
| [deleted]
| m4tthumphrey wrote:
| Do we have any idea when the stock will be available?
| jenny91 wrote:
| 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.
| base698 wrote:
| 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.
| deepbluev7 wrote:
| 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.)
| marc__1 wrote:
| 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"
| sm4rk0 wrote:
| What happens if USD is no more in 2030?
| marc__1 wrote:
| "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."
| nexuist wrote:
| Maybe they're counting on inflation ;)
| LewisVerstappen wrote:
| > 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)
| digianarchist wrote:
| A lot of those companies are fully remote*
|
| _*Timezones and working locations restricted._
| sam0x17 wrote:
| > 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.
| lastofthemojito wrote:
| 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...
| LewisVerstappen wrote:
| Interesting, thanks for the link.
|
| Median salary seems to be $170k according to Levels.fyi ->
| https://www.levels.fyi/company/GitLab/salaries/Software-
| Engi...
| zndr wrote:
| You can actually see their salary calculator here
| https://about.gitlab.com/handbook/total-
| rewards/compensation...
| yunohn wrote:
| Are you able to actually use the calculator? You've
| linked the documentation page for it, but the actual tool
| seems restricted.
| mikeyouse wrote:
| 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...
| Animats wrote:
| _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?
| easton wrote:
| 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.
| rickosborne wrote:
| 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.)
| nawgz wrote:
| 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.
| shortstuffsushi wrote:
| > 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
| nawgz wrote:
| 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
| include: - project: 'public-tools/gitlab-
| extensions' ref: master file:
| '/.gitlab/ci/Docker-build.gitlab-ci.yml'
|
| Then of course that file does the things to run a `docker
| build` script with secrets passed as build args etc
| wdb wrote:
| 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.
| nawgz wrote:
| 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.
| nonameiguess wrote:
| 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.
| nonameiguess wrote:
| 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.
| tyingq wrote:
| 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.
| the_jeremy wrote:
| 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.
| marc__1 wrote:
| _> 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%.
| brianwawok wrote:
| That average is across all price points though right, not
| 100k+ customers? That seems a very apples to oranges
| comparison.
| marc__1 wrote:
| 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.
| pid-1 wrote:
| 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.
| Mavvie wrote:
| 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.
| josteink wrote:
| > 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.
| easton wrote:
| 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.
| mayurpipaliya wrote:
| 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.
| eljimmy wrote:
| 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.
| Wronnay wrote:
| 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)
| nzealand wrote:
| 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.
| trhway wrote:
| 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.
| nixgeek wrote:
| 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.
| bink wrote:
| 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.
| fcantournet wrote:
| 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.
| nixgeek wrote:
| 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?
| danudey wrote:
| 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".
| [deleted]
| rhacker wrote:
| 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.
| snicker7 wrote:
| 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.
| danudey wrote:
| 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.
| zmmmmm wrote:
| 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.
| mythz wrote:
| 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.
| jcdavis wrote:
| 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.
| TradingPlaces wrote:
| Stock based compensation is compensation at the expense of
| current shareholders. It's not free money.
| fshbbdssbbgdd wrote:
| 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.
| jcdavis wrote:
| 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.
| manquer wrote:
| 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.
| whalesalad wrote:
| 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.
| junon wrote:
| 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.
| kasbah wrote:
| Could you link the issues please? Planning to use Gitea with
| a lot of mirrored repos.
| S5yDyAk3XoQH5 wrote:
| 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
| junon wrote:
| 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.
| JohnWhigham wrote:
| _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.
| MattGaiser wrote:
| Most financial filings are filled with cover your ass
| statements like this.
| throw03172019 wrote:
| Correct. The Robinhood disclosures were a fun read with
| Dogecoin trades (meme coin) being a large portion of their
| revenue.
| bradstewart wrote:
| Pretty much every S1 ever has similar language. Do you refuse
| to use any public company products?
| dec0dedab0de wrote:
| 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.
| kuresov wrote:
| This verbiage is present in basically every S-1 and quarterly
| filing, if not verbatim, then very close.
| whoisjuan wrote:
| 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?
| spullara wrote:
| What does completely private mean? Do you mean bootstrapped?
| JohnWhigham wrote:
| Yeah, not VC-funded. Stupid mistake on my part given the
| industry we're in
| mikepurvis wrote:
| They're literally a YC company:
| https://www.ycombinator.com/companies/gitlab
| secondaryacct wrote:
| 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.
| danudey wrote:
| 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.
| sofixa wrote:
| 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).
| kickopotomus wrote:
| > 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.
| birdyrooster wrote:
| Congratulations Gitlab employees! I am super happy for you all!
| Well deserved!
| unixhero wrote:
| I am bullish!
| the-dude wrote:
| Congrats Sytse.
| smartbit wrote:
| 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 fellow worker 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 ....
| merrvk wrote:
| What a shame
| riffic wrote:
| 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.
| ithinkso wrote:
| It is good for GitLab, what a shame for GitLab's users
| whateveracct wrote:
| It's only a matter of time before I move to sourcehut I
| think.
| toastal wrote:
| 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".
| jorams wrote:
| > 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/
| bink wrote:
| Why?
| eloff wrote:
| Why?
| ithinkso wrote:
| rvz asked me to elaborate on it in a sibling comment
| rvz wrote:
| > what a shame for GitLab's users
|
| Can you please elaborate about this?
| ithinkso wrote:
| 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.
| eloff wrote:
| 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.
| riffic wrote:
| 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.
| svnpenn wrote:
| > public exit
|
| That's the exact opposite of what is happening.
| kcb wrote:
| Yea it would be much better if only a small select group of
| elites were allowed to invest in companies.
___________________________________________________________________
(page generated 2021-09-17 23:00 UTC)