Gitlab S-1(sec.gov) |
Gitlab S-1(sec.gov) |
I was considering Gitlab when pitching a new platform for my org but the value really didn't seem to be there when compared to Atlassian/Microsoft.
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 ....
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.
(static, except for the tracking scripts and ads :))
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.
We filed an issue (or maybe two) and the developers were... eh. A bit rude, to be honest. Dismissive that it was really an issue, where restarting and deleting/re-configuring was a massive PITA.
Therefore, I can't really rec Gitea myself. I wish something like it existed though. That's for sure. Gitlab is just too bloated for my taste and our needs.
I 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.
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?
It's literally years in front of the competition ( GitHub and BitBucket).
But the thing I ll say is the git part is satisfactory. It's the CI part we are livid about.
It's not "years in front of the competition" if you think of Teamcity. Github focus on what it does right.
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.
But why do we need so much work to write the script ? Why is the reporting so bad on test failure, why building complex dependency chains running in parallel and in sequence doesnt work ? Why do we need to touch the repo to change the build descriptor?
It's just not as fun to use, immediate, beautiful, and productive. It's thrown on top of the git part, half assed.
I 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.
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.
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 ?
We were mirroring the linux kernel and maybe 40-50 different repositories. Two users.
> 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 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 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”.
What languages are those? Pygments supports a lot of languages[1].
Can you please elaborate about this?
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.
Gitlab is losing money. They do need the capital.
While it's true sometimes shareholder interests can lead to the users getting screwed, that's a very short term and dangerous game to play. It's the equivalent of killing the Golden Goose. Companies that play that game may find themselves out of business in short order. They're opening opportunities for the competition.
Gitlab, 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...
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.
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.
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.
But certainly there will be pressure on them and on all others, as US companies start to hire globally, and offer more-or-less US wages.
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.
You can workaround it by pressing the right arrow at the end of the text.
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.
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
It's interesting to see that GitLab has adopted dual-class common stock structure, though I'm certainly not surprised. Some people and organizations (including some investment firms and stock exchanges) are not fans of multi-class equity structures, but I'm not sure that this fact would have any significant negative impact on GitLab's IPO. At least, these popular 10:1 or slightly less popular 20:1 voting schemes are not as aggressive as Palantir's three-class stock structure, where Class F (just three founders - out of five!) would hold practically 50% of the total voting power.
One strange thing that I've noticed while browsing through this S-1 document, though, is the lack of mention of GitLab's co-founder (Dmitriy Zaporozhets) in the stockholders table (p. 148). I would expect him to hold about the same ownership of the Class B shares as the other co-founder Sytse Sijbrandij holds, but definitely more than 5%, which requires a disclosure there. I'm not sure how to interpret the absence of his name.
It's 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.
REVENUE:
2021: $152m (loss of $192m)
2020: $81m (loss of $130m)
EDIT: reworded for clarity.
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)
Which developer tools have not done well?
DDOG, PD, DOCN, FSLY, NET, TWLO, MDB, TEAM, etc
All of those are doing great, and there are probably like 50 more.
But yes, agreed.
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.
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"
1. https://www.iqt.org/portfolio?&search=gitlab&taxonomy=&tax_i...
> Stock-based compensation expense for fiscal 2020 and 2021, and six months ended July 31, 2021 includes $32.7 million, $103.8 million, and $0.3 million, respectively, of compensation expense related to secondary stock sales described in Note 16 to our consolidated financial statements included elsewhere in this prospectus.
Which makes the numbers not as bad as they seem on first glance.
Stock 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.
https://www.theregister.com/2019/10/16/gitlab_employees_gagg...
I don't really expect the market to care much about this one way or the other, but I do.
(Their competition, Microsoft/GitHub, famously embraces government/military custom, even supplying services to those operating concentration camps.)
This seems to establish a norm for the industry; one of the many reasons I am not a participant.
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.
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)
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.
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.
We are on premium, the ultimate features would be an easier way to replace Jira but we manage with epics, milestones and iterations.
I see all of the founder's shares and options are owned by Rients.org BV and would love to know a bit more about the structure.
Seems like EU companies eventually become American and I would love to know how :)
Thanks!
So who gets to be CEO for Life? Sid Sijbrandij?
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.
I can say a lot of bad things about Atlassian, but their price/benefit ratio is outstanding.
Another buy in my books after calling CloudFlare [0] and DigitalOcean [1]. Looking forward to the listing of 'GTLB'.
Note: I've preferred Gitlab, for exactly this reason
> 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.
"Akshually" that was Coinbase [0]. Although maybe not, because they did a direct listing so not strictly an IPO. Matt Levine talks about both these points in his Feb 25th 2021 Money Stuff newsletter.
[0] https://www.sec.gov/Archives/edgar/data/1679788/000162828021... "Address not applicable"
Indeed, interesting question. I’d expect that a S1 would clarify Dmitriy Zaporozhets position & role.
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.
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.
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%.
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.
Having all those things in the same place does wonders for my sanity.
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.
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
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.
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.
> 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.)
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.
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.
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 fact Gitlab are recognizing a loss at IPO could have been predicted at the company's inception.
The bronze plan (4/user/mo) was burned and moved into premium (19/user/mo). If you have any sort of moderately active company, going back to free tier is really not an option (the feature reduction would be simply too much, plus a lot of previous ci/cd work would be binned).
[0] https://about.gitlab.com/blog/2021/01/26/new-gitlab-product-...
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.
profit = revenue - costs
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.
Second sentence: 'Seems scary ... profit < -revenue'
They have to take customers while they can.
If you're the best at your language/library/framework you'll always find better compensation than a company that normalizes compensation by locale.
There's plenty of top tier talent in cities across North America and Europe who can find remote employment at companies paying bay area rates.
Median salary seems to be $170k according to Levels.fyi -> https://www.levels.fyi/company/GitLab/salaries/Software-Engi...
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 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.
*Timezones and working locations restricted.
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".
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.
Now if your talking about brand and positioning that's another matter.
Do you think the GitHub or GitLab brand is stronger, today?
Github Check Runs API Github Applications Security scanning, vulnerability alerting Packages Registry that's reliable
The kind of integrations that Github offers for pull requests in general is miles away from Gitlab. Some of the things I mentioned above are possible in Gitlab but only on the highest tier and still then the UI integration isn't a great.
I would rather have less notifications, they distract me too much.
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'
I was just trying to emphasize that for the highest paying cohort, retention is best class.
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.
I have consistently heard the opposite.
Actions has more polish but is not as feature rich is what I have heard.
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.
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.
Here are the commands I suggest you run to authenticate your local machine to GitLab:
yarn config set "@example:registry" "https://gitlab.example.com/api/v4/packages/npm/"
yarn config set //gitlab.example.com/api/v4/packages/npm/:_authToken "<your PAT here>"
yarn config set //gitlab.example.com/api/v4/projects/:_authToken "<your PAT here>"
yarn config list
I 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.
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.
The end-user of (most of) their products are developers.
Are you trying to claim that AWS is not for developers because the end users who visit website hosted on AWS are not developers?
Their products are built to be used by developers.
As an analogy, AWS’s customer is Netflix. Not the end user who is watching a movie that streams out of an EC2 instance.
(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)
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).
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).
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.
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.
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.
https://about.gitlab.com/handbook/total-rewards/compensation...
It is far less true for consumer/SMB mid market products as cost of leaving there is not high.
https://en.wikipedia.org/wiki/Predatory_pricing
And is illegal in some jurisdictions and frowned upon in others.
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.
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.
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.
And that's why we can't have nice things in for-profit software nowadays.
There are alternatives with less features if you don't need them all.
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 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.
Not an uncommon VC/PE strategy. Wait two years and see what happens.
not one of my complaints has ever been addressed. my last complaint was ghosted after i pointed out that they should actually read my lengthy analysis instead of giving a worthless canned response.
still waiting for reply since Jan 4.
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?
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.