2020: It has been an amazing ride but all journeys come to an end. Joining the Google family will allow us to offer our customers much better experience while retaining our independence. We are developers at heart and this is why we want to give developers the source control tools they deserve!
Independence: since we took financing we need to have a liquidity event; to maintain independence we want to become a public company rather than be acquired.
At any rate, even if it happens, GitLab CE is open source, which can't be said for some of their competition.
From what I can tell 5 out of 7 board seats are owned by VCs and it's very unlikely the founders retain majority shares given their 5 rounds of funding. So I doubt it's their call to make in any way.
I can promise you they are already in talks with at least one large company. You know those phones started ringing when Microsoft bought Github. I'm not ready to believe that Goldman Sachs is now a principles over profit kind of company.
If one takes GitLab's communication entirely at face value, one might consider there is some kind of 'principled' thing going on here, but I suggest that 'it's just a business' and that GitLab isn't some shiny example of much, other than a well run entity.
All of the 'everyone can do this' language in their communications, is just that, communications, it has a cognitive resonance with words such as 'equality' which appeal to some (well, all of us in a way) - but it's marketing.
The are what they are because it works for those involved, and also makes them money. Many boring business without fancy communications provide immense surpluses to the world.
Which means Gitlab would likely cease to exist as a standalone product but rather be integrated into GCP or the like (similar to Gemnasium and Gitorious after Gitlab acquired them)
GitLab employee, thank you for your kind words, and I also couldn't agree more! We're currently all at our company-wide conference [1], and legit every single employee is passionate about transparency (and also very happy to work here). Definitely not something I've experienced at the other companies I've worked for.
I can't speak for gitlab, but there is a strategy to not competing with higher salaries, even if you can afford it in some cases.
You aren't necessarily losing the top talent because not all the top talent cares only about the money. And by not offering the highest salaries, you are naturally selecting for employees that care more about the culture and work/life balance than having the highest possible salaries.
So if you do hiring right, you are more likely to get employees that stick around rather than jump ship for the first offer of a 10% pay raise.
"you are naturally selecting for employees that care more about the culture and work/life balance than having the highest possible salaries"
This is not quite true.
You're 'selecting' for all of the things that come along with offering lower salaries, which usually means losing the best talent.
All things being equal, it's rational for even a 'good staffer' to go to Google (or whatever).
And of course, the company saves money by paying people less.
I'm doubtful that there's any correlation between 'lower pay and commitment' once you normalize for talent.
If this is true, they could equally pay people more and get the same or better results.
Corporations speak in their self interest, and other people's interests to the extent it serves their own. If a company is paying less, it's probably because they can get away with it for one reason or another.
Not true at all. Money isn't everything. Culture and value mean a huge amount to me as an employee. I'd take 60k less a year or more based on culture and value.
The last time I worked at a company where “money isn’t everything” with a focus on culture instead it was because they ended up getting bought out by a private firm where most eventually got laid off. Money talks, bullshit walks first and foremost while culture is what ensures those with competitive skill set and high salaries don’t jump ship for 10 percent more, but you still have to pay your employees well. You can’t pay your bills or afford your hobbies outside work with culture.
As a person from a third world country, I don't think paying local rates makes sense for an employee.
I worked in both Vietnam and Bay Area. The salary difference is ~10x. In Bay Area, I easily save $100K or more per year (earning >~$300K a year). Even earning a top local rates in Vietnam would have a hard time accumulating $100K in savings. I could go back to Vietnam now and earn like $5K USD a month top.
Living in a country with lower cost of living often means lower quality of school, safety, health, and etc.
If I work remotely for gitlab, I'd immediately move to Bay Area or maybe Seattle to increase my savings.
But, well, it saves gitlab money. So, it makes sense for Gitlab to make this decision. It's not good for employees though.
> Is working for Gitlab remotely in Vietnam on a localised salary as good or better than most local job opportunities?
I think Gitlab aims to pay top rates on the local market if I'm not wrong.
What I'm saying is that, even with the top rate in Vietnam, it's still small compared to being an average engineer in Bay Area in terms of saving performance.
I'd highly recommend doing an internal, anonymous, survey to see if employees are happy with their compensation. Literally every GitLab employee I've talked to is extremely unsatisfied and tends to agree with the sentiment about being underpaid relative to other companies for those not in SF, and a very common theme I've heard is being heavily low balled when reaching the offer stage. Somewhat anecdotal but still more so than other software companies willing to pay market rates, also worth noting I am not a GitLab employee just a very common theme when chatting with them. Something is obviously wrong with your "compensation calculator" if the general sentiment is this widespread.
Salaries at GitLab were increased (at least for engineers) towards the end of 2018. This meant that at least my salary went from so-so to something I am actually really happy about (this was combined with some other adjustments, such as my experience level), and something that is hard to beat here in The Netherlands.
In other words, the opinion will vary from person to person.
GitLab employee here, who have you been talking to? Because that has 100% not been my experience working here. I live in a pretty middle-tier area, and I was offered a salary that was pretty much on-par with I was making at the company I worked for locally. My draw to GitLab wasn't the idea that I'd be making a SF level salary, it was (primarily, for me) the ability to work remotely. I couldn't really care less that I'm getting paid less than my colleagues in SF, because the ability to get paid the same amount that I would at a local company while working remotely was already worth it.
IBM, Atlassian, CA, GitHub, Microsoft, Micro Focus, Perforce, to name a few. Even if you believe GitLab's 100,000 number, Atlassian claims more than that and they're a public company so less likely to fudge the numbers.
I imagine that the on-prem and public versions are completely different beasts to operate.
It's quite the engineering feat that they reached the current scale with the same codebase! I believe maintaining one shared codebase will be expensive in the long run: locally you want simplicity, SaaS you want scalability, micro-services and all that.
It's better than GitHub in almost every way. And yet GitHub is more popular both in open-source and enterprise. And in enterprise we are usually left with unholy combination of GitHub and JIRA because GitHub project management is a joke and they haven't done anything useful in that space for years.
But for some reason pushing for anything other than GitHub is always an uphill battle. And the web interface GitHub offers isn't any good either; I can't use it without OctoTree (amazing stuff BTW, works with GH and GL! Kudos!). So what does GitHub really offer that makes it so popular? A friendly name? A cute OctoCat?
And GL leads the way and GH copies their features some years down the line and GL fights and GH is still more successful.
A lot of the development ecosystem had integrations with Github, and haven't yet done so with Gitlab. Additionally, network effects matter, especially when if you add collaborators to your repo it's almost a given that they have a Github account.
I assume you're talking about CI? Not much more than that. But that only works in the most trivial cases. One repository, simple tests. I spent tons of time over the years always tweaking this and that to make whatever CI system we were using somehow work with GitHub. Lot's of setup, lots of trouble.
Last time I tried switching to it it was slow as molasses on the command line. Easily several times slower than GitHub. So I went back to GitHub. I still have a GitLab account, but I only keep my dotfiles there.
I keep hearing they've improved performance, and maybe they did, but that's also what I heard last time I tried it, so now I'm kind of reluctant to give it another try. Unlike before, now it doesn't just have to be "as fast", for me to switch to it, it has to be noticeably faster. Feature-wise it's easily on par already, but performance is also an important feature, and I don't think codebase being primarily in Ruby inspires a lot of confidence, especially if scale is growing. You're basically running it at 1/10-1/30th the speed it could run if a proper language were used.
The Omnibus package is very painless and internally uses Chef to apply configuration changes and data migrations. I maintained a (small) instance for a few years and never ran into any issues, all you need to do is upgrade the package through APT/yum etc.
There's also support for zero-downtime upgrades [1] but I haven't tried it yet.
I am not a GitLab user, so I'm not speaking from personal experience, but I've read more than a few comments here on HN that GitLab stability and performance is worse than GH. For a mission critical system like source control, stability and performance are more important than any other features.
GitLab employee, this is somewhat of a drawback to how transparent we are about our issues. I know this might seem like I'm just trying to PR spin it, but it's a real phenomenon. We post about any little problem we have, and 99% percent of our Issues are public, so it probably seems like we have a lot of downtime and problems because of how often we talk about them
Unfortunately the perception was earned a few years ago created not by running “more openly” but real user experience and breaking people of that experience over several months is a long uphill battle for GitLab. I’m involved with a large group of Python developers that echos the same feeling, even though generally speaking many of us find GitLab (performance and reliability aside) a better and more comprehensive product.
I’d guess this was a consequence of a strategy decision that went against the plan (probably an expectation mismatch with users). I think the large part of the problem is the public GitLab instance is (was?) the beta environment, so a lot of issues popped up constantly while people were evaluating the options. In our group we are all volunteers, so when downtime impacts the little time we can dedicate (push code, review, deploy) it’s a fairly big deal.
Our python group (pyslackers.com) runs in the open as much as we can, so for us we went where the exposure and ease to be involved is (Github), even though from a raw feature perspective we liked what we had on GitLab when it worked.
That's definitely fair, and warrented. We haven't really had the resources for (relatively) long to put into performance when we were still in early stages. However we've constantly been improving that, to the point where I truly doubt you'd find that we suffer disproportionately from performance issues more than any competitor.
Before I worked here, I was on a team that evaluated different devops tools, and I felt the same apprehension about the uptime. But we eventually chose gitlab, and the only real downtime we experienced was during the 2017 outage. And we liked having the option to switch to self-hosted if it became too much of an issue
There’s a pretty vocal group that favors GitLab, I campaigned for it internally at a few companies as well - having so much of the tooling in once place is pretty nice. It’s obvious that GitLab is making quick improvements consistently.
The project boards are better than most others, the CI is phenomenal, and I have noticed the review process is being worked on.
Keep up the good work, we need options in the space!
It is because GitHub employs a marketing strategy like Microsoft about selling something based on relationships but not product quality. They wine, dine and give kickbacks to those with the power to sign a multi-year contract.
Things that make me not use gitlab (some of them are super shallow, stupid and relatively unfounded):
1. They used to use Azure, so even though I know Azure is actually an awesome cloud platform, I get this mental image of "Microsoft MVPs" constructing gitlab using VBScript macros because I come from the M$ era.
2. the very public data loss that happened a few years ago, that sounded like a mess, gives the lasting impression that repos are not lasting if they are in gitlab.
3. I never knew gitlab didn't just look like bitbucket, which I hate. In fact, I never would have looked at all if I wasn't writing this response, so I guess to get me they would have to lead with "Nothing like bitbucket!!"
4. I've spent so much time in github, that anything even slightly different pisses me off.
5. The logo looks like firefox porygon edition. GitLab is such a cool name, it could have a better logo, like the word "Git" followed by a chemistry beaker / "potion" thing.
6. The only marketing that would ever work on me would be "has an interface identical to github, does all the things github does, plus these 30 other things". Most of their marketing leads with the "30 other things", so I click away before I bother to read it.
7. If GitLab or anyone tried to do something innovative like writing an extended version of git that adds comments and pull requests to the underlying CLI, and bakes them into the repo itself in some way so we can just stay in CLI world all day, I'd be absolutely onboard, but no one does that for some reason even though that would be a huge differentiator. A similar strategy worked for Heroku if you think about it.
8. Every single open source project I use or contribute to uses github. If GitLab were to, say, add a github integration that lets me work with all the github repos I care about, but using Gitlab's UI, I would be intrigued.
> 8. Every single open source project I use or contribute to uses github. If GitLab were to, say, add a github integration that lets me work with all the github repos I care about, but using Gitlab's UI, I would be intrigued.
Depending on what you consider "work with github repos" here, you can import then as emily said above, and setup a push mirror, so whatever you do on gitlab is pushed back to Your fork on GitHub, so you can do PRs there.
The way to interact between the two without this sort of functionality would be if both agreeded in some sort of federation access. I don't see GitHub allowing that anytime soon, as that would reduce their lock-in effect.
Yeah mirroring is relatively easy. What I want is full and continuous synchronization of everything -- comments, PRs, etc. You could do it with a combination of the Github API and a web spider, at least with public repos.
Yeah importing doesn't do it for me though. I know I'm not going to be able to get any people to go to my repos if they are on Gitlab. But if I could use Gitlab as the UI, that would be cool, and might be the start of something that would get me to eventually host things on Gitlab.
Yeah that's fair, and we're pretty aware that we don't have e.g. the social functions that GitHub has. Your comment has sparked some internal discussion though, a full integration would be interesting.
On that note, legally, I don't think there is anything preventing you from automatically mirroring all MIT-licensed repos as well and pulling in some organic search engine traffic that way. Don't know if that also applies to the comments, pull requests, etc., but it's an intriguing move and definitely one I'd consider as long as there is a sane way of allowing the relevant users verify their ownership of a repo via GitHub API if they wish to "claim" the corresponding automatic gitlab repo.
It's a for profit company, but they still not only give away the source code, but offer a great deal of hosted functionality for free.
So contributing helps the community whether your contribution also helps the company or not.
Seems kind of like asking "Why would you give money to the Red Cross? They have employees that get paid a salary for running it."
If it's a good cause and you benefit from it, I certainly wouldn't avoid supporting it simply because someone else might profit indirectly from my contribution.
You contribute something you need. The deal is that you benefit from the change yourself. Upstream gets your change for free, but will (hopefully) continue maintaining it. (If they don't take the feature in it doesn't matter they got it for free ...)
"Around going public we want to become the most popular SaaS solution for private repositories (a complete product that is free forever is competitive since network effects are smaller for private repositories than for public ones)."
I honestly believe that whoever wrote this probably has a way of looking at it that is not "buy expensive, sell cheap, make it up on volume" but... oh well, seems to be working for the ride-sharing companies.
The linked strategy page says they are aiming for a liquidity event by 2020.
Of any tech company, GitLab seems like the most ripe for a conversion to an ESOP, which is often accompanied by a liquidity event for early investors. GitLab seem to be already operating as an employee-centered business, so from the outside looking in, conversion to an ESOP might be quite compatible with their existing culture.
EDIT: When you convert to an ESOP, you often work with an investment bank (such as https://www.awcfund.com/). As I understand, the investment bank provides a loan to a new tax-exempt foundation, which uses the cash to buy the stock from early investors; this foundation then repays the investment bank from revenue. These sorts of investors specialize in ESOP deals and they see the foundation which owns them money as less risky investments since ESOPs can grow faster than similar public for-profit companies since: (a) they are employee owned, and (b) because of the ESOP's tax-exempt status.
I don’t understand how this would work. Investors own the majority of Gitlab. Wouldn’t becoming a public company in 2020 be a much better return for them that making it employee owned?
76 comments
[ 2.5 ms ] story [ 138 ms ] threadIndependence: since we took financing we need to have a liquidity event; to maintain independence we want to become a public company rather than be acquired.
At any rate, even if it happens, GitLab CE is open source, which can't be said for some of their competition.
All of the 'everyone can do this' language in their communications, is just that, communications, it has a cognitive resonance with words such as 'equality' which appeal to some (well, all of us in a way) - but it's marketing.
The are what they are because it works for those involved, and also makes them money. Many boring business without fancy communications provide immense surpluses to the world.
I don't doubt this is their honest preference, but these are words, part of a communications strategy.
Since it's fairly clearly a business, they have 'a price', surely, moreover, the outside impetus may force their hand.
I guess MS will roll out something similar on Github + Azure sometime in the future.
Their handbook is a fantastic resource for distributed companies (but also for non-distributed companies).
https://about.gitlab.com/handbook/
e.g. here is how they do CEO shadowing:
https://about.gitlab.com/handbook/ceo/shadow/
[1] https://about.gitlab.com/company/culture/contribute/
Are they profitable? If not, they aren't inspiring me
The goal is to go public by November 18, 2020. You can read all about it here: https://about.gitlab.com/company/strategy/
We have an MR open to mention our long term profitability target for Q4FY25 here: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...
You aren't necessarily losing the top talent because not all the top talent cares only about the money. And by not offering the highest salaries, you are naturally selecting for employees that care more about the culture and work/life balance than having the highest possible salaries.
So if you do hiring right, you are more likely to get employees that stick around rather than jump ship for the first offer of a 10% pay raise.
This is not quite true.
You're 'selecting' for all of the things that come along with offering lower salaries, which usually means losing the best talent.
All things being equal, it's rational for even a 'good staffer' to go to Google (or whatever).
And of course, the company saves money by paying people less.
I'm doubtful that there's any correlation between 'lower pay and commitment' once you normalize for talent.
If this is true, they could equally pay people more and get the same or better results.
Corporations speak in their self interest, and other people's interests to the extent it serves their own. If a company is paying less, it's probably because they can get away with it for one reason or another.
If you mean we pay local rates please see https://about.gitlab.com/2019/02/28/why-we-pay-local-rates/
I worked in both Vietnam and Bay Area. The salary difference is ~10x. In Bay Area, I easily save $100K or more per year (earning >~$300K a year). Even earning a top local rates in Vietnam would have a hard time accumulating $100K in savings. I could go back to Vietnam now and earn like $5K USD a month top.
Living in a country with lower cost of living often means lower quality of school, safety, health, and etc.
If I work remotely for gitlab, I'd immediately move to Bay Area or maybe Seattle to increase my savings.
But, well, it saves gitlab money. So, it makes sense for Gitlab to make this decision. It's not good for employees though.
If so, isn't it still good for the employees?
I think Gitlab aims to pay top rates on the local market if I'm not wrong.
What I'm saying is that, even with the top rate in Vietnam, it's still small compared to being an average engineer in Bay Area in terms of saving performance.
In other words, the opinion will vary from person to person.
[citation needed]
It's quite the engineering feat that they reached the current scale with the same codebase! I believe maintaining one shared codebase will be expensive in the long run: locally you want simplicity, SaaS you want scalability, micro-services and all that.
This allows us to scale GitLab.com and with our Unix packages and Charts it is still easy to install.
It's better than GitHub in almost every way. And yet GitHub is more popular both in open-source and enterprise. And in enterprise we are usually left with unholy combination of GitHub and JIRA because GitHub project management is a joke and they haven't done anything useful in that space for years.
But for some reason pushing for anything other than GitHub is always an uphill battle. And the web interface GitHub offers isn't any good either; I can't use it without OctoTree (amazing stuff BTW, works with GH and GL! Kudos!). So what does GitHub really offer that makes it so popular? A friendly name? A cute OctoCat?
And GL leads the way and GH copies their features some years down the line and GL fights and GH is still more successful.
I think this is sad.
I keep hearing they've improved performance, and maybe they did, but that's also what I heard last time I tried it, so now I'm kind of reluctant to give it another try. Unlike before, now it doesn't just have to be "as fast", for me to switch to it, it has to be noticeably faster. Feature-wise it's easily on par already, but performance is also an important feature, and I don't think codebase being primarily in Ruby inspires a lot of confidence, especially if scale is growing. You're basically running it at 1/10-1/30th the speed it could run if a proper language were used.
No idea what gitlab.com is like, we picked gitlab because we could self-host.
There's also support for zero-downtime upgrades [1] but I haven't tried it yet.
[1] https://docs.gitlab.com/ee/update/#upgrading-without-downtim...
I’d guess this was a consequence of a strategy decision that went against the plan (probably an expectation mismatch with users). I think the large part of the problem is the public GitLab instance is (was?) the beta environment, so a lot of issues popped up constantly while people were evaluating the options. In our group we are all volunteers, so when downtime impacts the little time we can dedicate (push code, review, deploy) it’s a fairly big deal.
Our python group (pyslackers.com) runs in the open as much as we can, so for us we went where the exposure and ease to be involved is (Github), even though from a raw feature perspective we liked what we had on GitLab when it worked.
Before I worked here, I was on a team that evaluated different devops tools, and I felt the same apprehension about the uptime. But we eventually chose gitlab, and the only real downtime we experienced was during the 2017 outage. And we liked having the option to switch to self-hosted if it became too much of an issue
The project boards are better than most others, the CI is phenomenal, and I have noticed the review process is being worked on.
Keep up the good work, we need options in the space!
1. They used to use Azure, so even though I know Azure is actually an awesome cloud platform, I get this mental image of "Microsoft MVPs" constructing gitlab using VBScript macros because I come from the M$ era.
2. the very public data loss that happened a few years ago, that sounded like a mess, gives the lasting impression that repos are not lasting if they are in gitlab.
3. I never knew gitlab didn't just look like bitbucket, which I hate. In fact, I never would have looked at all if I wasn't writing this response, so I guess to get me they would have to lead with "Nothing like bitbucket!!"
4. I've spent so much time in github, that anything even slightly different pisses me off.
5. The logo looks like firefox porygon edition. GitLab is such a cool name, it could have a better logo, like the word "Git" followed by a chemistry beaker / "potion" thing.
6. The only marketing that would ever work on me would be "has an interface identical to github, does all the things github does, plus these 30 other things". Most of their marketing leads with the "30 other things", so I click away before I bother to read it.
7. If GitLab or anyone tried to do something innovative like writing an extended version of git that adds comments and pull requests to the underlying CLI, and bakes them into the repo itself in some way so we can just stay in CLI world all day, I'd be absolutely onboard, but no one does that for some reason even though that would be a huge differentiator. A similar strategy worked for Heroku if you think about it.
8. Every single open source project I use or contribute to uses github. If GitLab were to, say, add a github integration that lets me work with all the github repos I care about, but using Gitlab's UI, I would be intrigued.
This does exist: https://docs.gitlab.com/ee/user/project/import/github.html#m...
The way to interact between the two without this sort of functionality would be if both agreeded in some sort of federation access. I don't see GitHub allowing that anytime soon, as that would reduce their lock-in effect.
We have an epic for Distributed Merge Requests: https://gitlab.com/groups/gitlab-org/-/epics/260 and an issue to discuss ideas about Federated GitLab: https://gitlab.com/gitlab-org/gitlab-ee/issues/6468
I'm curious about what motivates you such as improving a tool that you use everyday or code quality?
So contributing helps the community whether your contribution also helps the company or not.
Seems kind of like asking "Why would you give money to the Red Cross? They have employees that get paid a salary for running it."
If it's a good cause and you benefit from it, I certainly wouldn't avoid supporting it simply because someone else might profit indirectly from my contribution.
I honestly believe that whoever wrote this probably has a way of looking at it that is not "buy expensive, sell cheap, make it up on volume" but... oh well, seems to be working for the ride-sharing companies.
Of any tech company, GitLab seems like the most ripe for a conversion to an ESOP, which is often accompanied by a liquidity event for early investors. GitLab seem to be already operating as an employee-centered business, so from the outside looking in, conversion to an ESOP might be quite compatible with their existing culture.
EDIT: When you convert to an ESOP, you often work with an investment bank (such as https://www.awcfund.com/). As I understand, the investment bank provides a loan to a new tax-exempt foundation, which uses the cash to buy the stock from early investors; this foundation then repays the investment bank from revenue. These sorts of investors specialize in ESOP deals and they see the foundation which owns them money as less risky investments since ESOPs can grow faster than similar public for-profit companies since: (a) they are employee owned, and (b) because of the ESOP's tax-exempt status.
Nice try, but that's called dogfooding.