Hopefully now they will realize that they should run on a colo rather than be wholly on the cloud... and hire for that expertise (their previous attempt to do so was a bit amateurish, which is understandable ).
Nothing blows money faster than unlimited storage and unlimited bandwidth when you're not charging for it...
And before you down vote me, realize that github, their main competitor, runs on a colo for this very same reason.
No matter how much revenue you get from paid accounts, and selling on-prem installs, the free service popularity which fuels the paid revenue will outpace it for the forseable future. Trying to reign in those cost, isn't a bad ( or hard ) thing.
Yes, this is true to an extent. But price is one of many factors that go into GitHub's design decisions for infrastructure planning. (I used to work on the Git Infrastructure team at GitHub, which is responsible for exactly this.) Nor is it the _first_ consideration. Price is important (obviously) but only after performance and resiliency.
Putting repositories on bare metal on-premises makes sense for GitHub's architecture. They run git itself, which is happiest packbuilding with as many IOPS as it can manage. But they've also built out a number of custom performance monitoring and load balancing applications, and any single Git repository is replicated across a number of servers using spokes, their custom Git load balancing system. They run on-premises because they've done a detailed analysis of their needs and hired a staff of developers and infrastructure experts to deliver it. And as a result, they're the world's largest Git hosting provider.
But you _can_ be perfectly happy in the cloud.
Visual Studio Team Services hosts its Git repositories in Azure. Since VSTS didn't start out hosting Git repositories, but Git repository management was added _after_ it already had a cloud-first architecture, it didn't make sense to host repositories on-disk. (Nor would relying on Git for Windows have been performant five years ago.) Instead, VSTS built out custom Git server implementation to take advantage of storing repositories in SQL Azure and Azure Blob Storage. And this implementation scales up to the needs of Microsoft's customers - both external and internal - who are hosting the world's largest Git repositories.
So I think that you can be happy on-premises _or_ in the cloud. I think it comes back 100% to your point that you need to hire for that expertise.
Visual Studio Team Services surely doesn't pay list price for their bandwidth on Azure. It's the same company! Azure is the colo!
You seem to assume running a colo means having some bearded Linux admin on staff that runs all the applications with init.d on bare metal. Not so, kubernetes is a thing. They wisely haven't chained themselves to any of the critical proprietary Azure lockins.
It was definitely not one of my better worded comments :)
colo == renting space/cooling/power from a datacenter provider to run your own servers.
on-prem == on premise installs/support
They have two revenue models, SaaS and Selling you support [1]. Giltlab has a "loss leader strategy" like many online businesses. The difference is that in this case, their free plan will grow so exponentially fast, it will become a huge cost center.
Also, to add to my simplistic post above, colo wasn't meant to only imply Gitlab having to run everything, for example, they could go with a managed provider, and have them run the network/hardware site of things. This is also still substantially less expensive than the cloud, when your biggest bills will be storage and bandwidth ( which of course, is my assumption ). From their tech postings, it seems their problem domain doesn't allow them to utilize s3 or any other other massive scale distributed storage, so they have been primarily utilizing block storage.[2][3]
He's talking about where GitLab should run their services from. He meant GitLab should purchase hardware and move into a colo rather than run off of cloud services.
I believe he means that the "SaaS option" is run in the cloud by GitLab itself, which is probably very expensive given that the nature of the service is both storage and network-intensive. If GitLab operated their own datacenter(s) it could be considerably less expensive.
Colocated hosting refers to a kind of hosting where Gitlab puts their own hardware inside of a data center. They primarily pay the data center for physical space (also called rackspace), bandwidth and power but they don't pay for the the server itself since the physical hardware belongs to you.
Dedicated hosting is similar to colocated hosting with the only difference being the physical server is rented to you by the data center. This is different from cloud hosting because unlike cloud hosting, with dedicated servers you are the only customer using the physical server that is located in the data center.
An off-shoot of dedicated hosting is a VPS (virtual private server.) VPS can be seen as a mix of cloud and dedicated in that the physical server's resources are split between x customers but each customer has their own virtual machine with root access.
I have been thinking about whether GitLab should opt for the M version Xeons when they finally get their servers so they can upgrade to 128GB TSV LR-DIMMs in the future.
It feels to me like GitLab might be shooting themselves in the foot by spreading their resources too thin, too quickly.
They have the very grand ambition to take over the entire devops toolchain from source control to deployment, and some parts of the toolchain can certainly benefit from the tight vertical integration that GitLab provides, and when everything just works the product does end up providing a very streamlined user experience.
However, this also means that their monolithic toolchain has to be able to out-compete best-of-class specialized tools in every part of the chain, and every part of the chain where they fail to do so could end up as a potential dealbreaker for a large subset of their user base.
I've used GitLab.com for a few projects, and in general I've found the various aspects of their product sorely lacking in terms of overall polish, performance, and capability compared to excellent specialized products like GitHub for VCS, CircleCI for CI/CD, and Pivotal Tracker for project tracking/planning, etc.
Also, the fact that they're trying to take over the entire toolchain means that just about everybody else in the devops space sees them as a direct competitor, so until they grow to become an 80-pound gorrila that nobody can ignore in at least 1 part of the toolchain, very few other companies building devops tooling will willingly integrate with their product, which makes them even less attractive for users with specific/more advanced needs that their product alone can't meet.
With all that said, I really appreciate their dedication to open-source and am personally rooting for their success, but I can't help but shake the feeling that they're fighting a losing battle. DevOps tooling is simply too diverse, complex, and opinionated a field for any 1 company to dominate from end-to-end. Focusing resources to become the best tool for the job in 1 area and using that leverage to foster an open-ecosystem around that product seems like a much more viable long term strategy (though that could certainly prove to be difficult if you're trying to become the best tool for VCS, due to how entrenched GitHub is in terms of developer mindshare).
We are very afraid of spreading ourselves too thin too. Recently we've been encouraged by how GitLab CI is doing, it is winning developers gitlab-ci-is-the-most-popular-next-generation-ci-system and industry analysts over https://about.gitlab.com/2017/09/27/gitlab-leader-continuous...
I think what makes GitLab different is that more than 1800 people contributed to it to increase the depth. Our team members are focussed on increasing the breath. From https://about.gitlab.com/strategy/
"We realize our competitors have started earlier and have more capital. Because we started later we need a more compelling product that covers the complete scope, that is integrated out of the box, and that is cloud native. Because we have less capital, we need to build that as a community. Therefore it is important to share and ship our vision for the product. The people that have the most knowledge have to prioritize breadth over depth since only they can add new functionality. Making the functionality more comprehensive requires less coordination than making the initial minimal feature. Shipping functionality that is incomplete to expand the scope sometimes goes against our instincts. However leading the way is needed to allow others to see our path and contribute. With others contributing, we'll iterate faster to improve and polish functionality over time. So when in doubt, the rule of thumb is breadth over depth, so everyone can contribute."
I don't see how GitHub will ever be dethroned due to the mind share and market share of Open Source projects. It is a simple process to move to GitLab BUT all the developer tools for many projects relies on GitHub.
When I get a package in Racket or R they normally come from github automatically.
>It is a simple process to move to GitLab BUT all the developer tools for many projects relies on GitHub.
There are few faster ways for someone to ensure I cross their product off my list of things I consider production-ready than to do this.
Everything is relative and it isn't always a cardinal sin to tie some parts of ones product to github, but it's a common non-decision and overall I consider it a clear sign that the product developer lacks foresight. If they are short-sighted enough to design their system in a way that it will break if github goes away and supports no substitute workflow, I have to wonder what else they might be short-sighted enough to do.
> There are few faster ways for someone to ensure I cross their product off my list of things I consider production-ready than to do this.
Care to explain? You don't use Python or other languages where the libraries are built off code that is on github???? You want it hidden into some strange package management system that is closed to developers?
Python is not using Github as a package management system. Python keeps it's packages on Pypi, which is a simpler and more specific product than Github, and seems to have a higher average uptime as a result.
More importantly, the Pypi project is open source, which means I can set up a Pypi server inside my company to host private and/or critical packages and configure it to go upstream for anything I request but don't have locally.
The Python strategy is a considered strategy that provides acceptable business continuity options.
I don't give a shit where you store your source code, that's /your/ business continuity problem.
- Um maybe I am stupid but you can't simply just post things on Pypi and have contributors involved pypi is a final step????
If you have any contributors you have it on github (normally) or any other git you want and then push it to pypi. THis is why any major library of Python is developed on Github.
I actually don't use github for anything except my public open source code, but almost every single Python library is on github and then pushed to pypi as a final step.
Does the new round going to help with reliability problems? I use GitHub ~90% of time and I can't recall any downtime, while for GitLab it's very often to see it being unavailable.
I find the service great but it's really frustrating to see it being down so often.
I haven't experienced any downtime with their public service - which I think is great for hosting private repos (as others have mentioned). I actually prefer it to bitbucket.
In other professional experiences, hosting our own instances of Gitlab was a great solution. Setup/updates were easy and we had the piece of mind knowing that we were in control of the maintaining uptime. I was very impressed by how simple it was to their implement CI service as well.
Just this past friday their fully automated CI devops whatever deployed an old major version to some parts of their infrastructure, the entire website was 500 for an hour and git pushes were barking up Ruby stacktraces.
GitLab.com is not deployed using any automated CI software, instead it's deployed using https://gitlab.com/gitlab-org/takeoff. The problem here was an incorrect version set in Chef, resulting in it deploying an old version to the cluster.
All the more reason to host your own instance! However, I understand if others prefer not to go this route and thus use an alternative version control solution.
I stopped using Github for private repos for three years. I get them for free from Bitbucket and Gitlab. So, I think the actual contender to Gitlab is Bitbucket and not Github.
However, Bitbucket feels a bit more organized and mature (the UI). What I also like: Bitbucket has the real Trello integrated which is great. I still like Gitlab, it's always good to have competition.
+1 this would be really nice. Currently we can choose between "latest activity" or "browse files". Adding an option for "issue board" (and "list of issues") would be great.
My non-tech colleagues get pretty lost when they go to the project's home page and see either files or a list of commits.
For open source projects, but it appears to me that the enterprise projects are more BitBucket. This is just my experience, but I can't see how GitHub even competes with Enterprise Support that comes from BitBucket.
Hm perhaps. Without any knowledge or info whatsoever, I'd think that Bitbucket and Github are close for enterprise too just because of how big Github is. And then Bitbucket obviously has the experience and integrations that Atlassian provides to be competitive. Still feels like the edge would go to Github Enterprise in terms of popularity and revenue if I had to pick one.
I'm also partially basing this on Atlassian's public company market cap and revenue. I believe Atlassian does close to $65M a month in revenue (they did $58M/month in the quarter ending in June)[0]. GitHub I believe does around $15M/month in revenue nowadays[1][2]. They both lose some money. I actually believe around the same amount, $4-7M a month. Jira, Confluence, and potentially something else have to take the bulk of Atlassian's earnings.
Gitlab keeps raising money at pretty high valuations so I'm probably underestimating the industry as a whole anyway and missing some info.
Really happy for GitLab and wish you guys all the best (and luck).
We've been using Gitlab for all our company's development, however, one major issue that is pushing us to switch over to GitHub is the fact that GitLab goes down almost every other day (or sometimes every day) due to deployments. Although during this often the site remains available, when CI is not executed or triggers are not performed, it is still extremely disruptive. I really hope that you prioritise having disruption-free deployments.
Thanks for your comment. Self hosted GitLab has been very reliable but GitLab.com's availability has been far below par.
It is our nr. 1 focus to improve this. Deployments should not cause disruptions. Over the last few months we solved the speed of GitLab.com. Availability is next.
Firstly, I'm really happy to see Gitlab growing and desperately want to see it succeed. We need an open-source alternative, and the organisational transparency within the company is also wonderful. However...
> we solved the speed of GitLab.com
I'm currently browsing a repo tree and each page is taking 5+ seconds to load (I am literally browsing HN while waiting for pages to open). This is a common experience. Please please don't get complacent. Not yet.
We're hoping to complete this by the end of the year. Once it's done, we'll be able to end our reliance on NFS, which should greatly improve performance and uptime on GitLab.com and other large GitLab instances. In fact, we're already seeing some big performance payoffs as we bring services online.
> Please please don't get complacent. Not yet.
I can confirm that this is not the case. We're focused and working really hard to improve performance and we're also working hard to improve our metrics, so that we can target optimizations where we can gain greatest benefit.
It's also worth pointing out that routinely experiencing 5+ second render times on browsing a repo homepage is outside our 99th percentile latencies for that route. I'd be interesting in digging into it further. Would you mind creating an issue in https://gitlab.com/gitlab-org/gitaly/issues/new (mark it as confidential if you wish) and ping me `@andrewn`.
The 5+ second delay is a little above the average (I'm rarely frustrated enough to actually go off and get distracted by HN while I wait), but notable delays on loading repo trees are definitely common, if not usually quite so high.
Thanks, I wanted to indicate our primary focus moved from the speed to the availability. But you're very right that there is still much to improve. We're not happy until every page is fast.
Specifically about the repo tree page load:
1. I'll share this comment with our VP of Eng
2. We're working on Gitaly to make git calls faster.
3. We're working on a multifile editor to make browsing faster.
Quick question: for my side project I currently pay money monthly for both Cloud9 and GitHub, but I am very open to switching tools. One of the things I love about storing code in the cloud and manipulating code in the cloud is that absolutely nothing needs to touch my local machine, which means I'm free to use (almost) whatever machine I want with (almost) any browser or (almost) any platform I want. It also means switching costs are next to nil, since I don't have to worry about if it runs on a Mac or Windows or what native tooling I have.
However, a big problem I've discovered with Cloud9 is that it doesn't run on iOS and there are seemingly no plans to make that happen. I'm beginning to transfer over a lot of my work to an iPad, and with the incredible power offered by modern iOS systems, not supporting the platform seems a huge miss.
I see in your slides you're working on a web IDE for GitLab, and in some of the comments on the open issue, iOS is mentioned. Can you answer if mobile platforms like iOS are really in the roadmap?
As a paid customer, I'd switch in a heartbeat if I could use the same IDE on my Mac, PC, and iPad.
I'm using Cloud9 and Bitbucket. I was thinking just the other day how I would love to ditch my main rig for an iPad. Researching this some it looks like Duet or Puffin Browser gets Cloud9 mostly working.
I do use Duet, but it's just an app to make an iPad a second monitor, it doesn't allow me to take it with me and leave my Mac at home.
I'm not really understanding why anyone would build a web IDE in 2017 without iPad support. Web IDEs targeting x86 platforms are already plentiful and mature, and people on x86 platforms tend to ignore them for more traditional desktop IDEs because their computer can already run all of the code or containers they might need. But those don't really exist on an iPad, which I'd think is the ideal target for a cloud IDE.
On wages: the lowest pay they offer in London Ontario is higher than my current salary, & I've been given a 10k raise over the course of the past two years. Figured I'd mention seeing people going as far as getting into the topic of minimum wage. Slippery slope
Canadians are criminally underpaid. I made significantly more than many full-time employees (I'd wager the majority) on more than half of my internships. Adjusted for rent and cost of living.
I do love London, Ontario though. Beautiful place even if it's too homogenous and quiet outside of around Western university.
> GitLab says that it plans to use it to add “new functionality for packaging, releasing, configuring and monitoring software.”
I can't wait for GitLab to offer hosting. They already do such a good job with their CI containers. It will be amazing when I can host my code, run my tests, and deploy my app all on the same service.
My team utilized Gitlabs on premise offerings and it's always been a good experience to use. They are adding new features at a modest pace and their support people have always been helpful.
I really need to try them out for my personal projects but I haven't had the chance.
What I'm most surprised by in this thread is the toxicness. As of right now there are only two threads that I can see, one that is slamming Gitlab's salaries and one that is slamming their reliability.
Gitlab is building something nearly completely in the open, and doing it quite well in my opinion. They're the best open source reference for how to ship on premises software I've seen, and I frequently refer people to them as an example. You may not like their compensation structure, but they have certainly been quite transparent.
If we want to see more companies build around open source and bring transparency, a small touch of forgiveness is probably worthwhile. I'm a little disappointed in the HN community.
(I'm not affiliated with gitlab other than being a customer.)
> What I'm most surprised by in this thread is the toxicness. As of right now there are only two threads that I can see, one that is slamming Gitlab's salaries and one that is slamming their reliability.
After many year on the internet, it's not that surprising. It's best summed up as, "Haters gonna hate.".
The jabs at the cloud offerring's reliability are valid. That includes both uptime and the horrendous data loss event they had earlier this year. I don't recall anything major after though not knowing about internals, can't tell if they learned from it or have just gotten lucky.
As a CE user I love GitLab. It does what it says on the tin and for the most part I don't have to think about it. The UI changes every other release are bit haphazard but not enough for me to truly care.
I've always thought that slamming their open comp policy is hilarious. They're one of the most open companies about how they handle comp and the result is they get insulted for it. I'm not saying I agree with the formulas (in particular the non-NYC COLA adjustments are out of whack) or the general approach, but to say they're worse than the voodoo guesswork that goes into figuring out how much a company is going to pay you is disingenuous. Especially if it's after a number of interviews only to find out they're going to low ball you.
At least in GitLab's case I know, at the current comp levels, I'd never work there or even interview there. And that's beyond fair for the worker. Plus it seems to be working fine because they've got a bunch of people that are happy to work there.
> The jabs at the cloud offerring's reliability are valid. That includes both uptime and the horrendous data loss event they had earlier this year. I don't recall anything major after though not knowing about internals, can't tell if they learned from it or have just gotten lucky.
I regularly slam them about their reliability on Twitter, but I keep using them, because I love how integrated the product is. I really have no complaints about either gitlab.com or the EE version, which I pushed that we migrate to at work.
If they can reduce the service problems, it'll be a great service.
> I've always thought that slamming their open comp policy is hilarious. They're one of the most open companies about how they handle comp and the result is they get insulted for it.
Well, they openly discriminate based on zipcode. It's their right as a business but it runs counter to the internet age remote-work utopia everyone wants. Kudos to them for even running a remote-work business, though. We need more of them.
A possible interpretation is that Gitlab chooses to not pay for top-tier distributed systems talent and will thus never reach the service quality they want.
Used to be a fan, but the change in licensing is worrying me. We started with the enterprise edition, which was the top tier at the time. Since then another tier has been added above and another one is in the works.
The road map is not encouraging, unless you are on premium or ultimate editions. And the license costs at least five times as much.
Also the road map shows a very Oracle-esque thinking, that only the big guys need advanced features and they are willing to pay what it takes.
I hope they find a better way, like scaling of the features rather than the features themselves.
Reluctant to place more eggs in our GitLab basket.
What "toxicness"? I don't see any in this comments section? Did HN delete most of it or did the community down vote those entries into oblivion? Due to a few comments in here I did some digging on the compensation they calculate publicly. Honestly, I can actually see why they are getting negative feedback from it. Paying people 221k in San Fran for the same job they would pay max 102k for in Minnesota, regardless of the city, seems quite unfair. Minneapolis is actually quite expensive. Why not pay for the value a developer provides independent of location? Plus, if someone moves to a less expensive location, they lower the pay. Looking at all their compensation rules, I would never feel secure about knowing how much I might be paid month to month. It seems they can make new rules as they go along. Might they want to reduce my pay if my average monthly grocery bill goes down after learning to cook?
It has been heavily downvoted now. When I commented, almost all of the discussion was on two threads that are now either removed or really far down the page.
These "_______ raises $__MM Series _ round" posts always end up like this. They are essentially rah-rah-hooray posts with little or no technical content. HN has always been down on blatant marketing and that's what these posts feel like.
I think you would have been seeing a completely different discussion if the post was "GitLab launches _______".
Anecdotally, I've seen this same sort of phenomenon play out in plenty of other discussions. The worst ones are typically conversations about JS frameworks, iOS vs Android, messaging apps with "private" chat features (Telegram/Signal/etc), and battles about Gitlab/Github. For some reason these subjects seem to create an open invitation for haters of all stripes to list their grievances about the product under discussion.
I used to think it was mostly astroturfing -- and there may be some of that on occasion -- but lately I've come to understand this phenomenon as a "feature" of humanity's tribal nature, much like sports team preferences.
(Edit: that's not to say that fair criticism of a product is a bad thing. It can be healthy! But these conversations often go beyond balanced criticism, at least from my perspective.)
Full disclosure, my wife is a gitLabber. Gitlab is uncomfortably transparent with how they compensate their employees. Given their remote policy and openness regarding compensation, no one is surprised with their pay and everyone can take it or leave it, which you can view https://about.gitlab.com/handbook/people-operations/global-c...
If you are a developer / professional living in a rural area and don't want to move or have a commute, I'm certain you'd find gitLab both lucrative and a fun place to work.
If they were consequent about paying less or more depending on where you live, they would also charge their customers less or more depending on where they live.
I'd imagine, like most companies, they charge their customers based-on willingness to pay related to market forces and the value they deliver.
While the argument you're making is sound, I'd challenge you to think of it this way: gitLab wants the best talent, no matter where they live. If they happen to live in a high cost area, vs someone that lives in a low cost area, both uniquely qualified, would it make sense to make sure two qualified candidates get approximately the same buying power's worth of compensation? Companies already adjust base pay based on your location, Google, for example.
It also takes a bit of the good versus bad negotiator penalty out of the equation, which provides a level of fairness that doesn't exist in most companies.
> they charge their customers based-on willingness to pay related to market forces and the value they deliver.
So do I, that's why I don't work for a company that says "well you life in a low-cost area, so you need to charge us less".
Their policy is transparent, and it is take-it-or-leave-it. I think the salary gripes you're hearing from many commenters is that they are leaving it, when they'd very much like to work for Gitlab, as it's a company I personally like.
However, what they're doing will either get them developers in the most highly-paid areas (where their salaries are actually competitive) or lower-paid developers that are actually not the best their local market has to offer (because the best developers are already employed elsewhere for higher pay). So, in essence, what they're doing is limiting their top-tier prospects to people who live in high-cost areas.
As another commenter said at some point, living in the Valley has such high cost because there are benefits to it. Developers in SF can find a job more or less the minute they walk out of the door of one company, and that's something that's expensive. I don't have the same luxury, and Gitlab says "well, since you aren't paying for the privilege of job liquidity, we'll give you a lot less money".
You should work for whatever you can negotiate; and you are worth what someone is willing to pay you.
That being said, in order to align with their values of transparency, they shared an algorithm that makes sense. It's not the only way to do it, but it's transparent and doesn't seem unreasonable.
Startups are about alignment to the big picture and long-term. I'd imagine that's why they don't change equity based on location. However, The free market being what it is, some will take it and others won't.
If people are willing to work for them, then they are in fact paying the "market rate" - a meaningless term in itself. Anyone who doesn't want to work for GitLab can easily work somewhere else. Let them decide for themselves.
> Anyone who doesn't want to work for GitLab can easily work somewhere else.
That's certainly true. But as a GitLab user, I want to make sure they're hiring the best candidates to work on the product. Is that an unreasonable thing to want?
Ok but that's a different topic. I also think you want the best product, regardless of how that's done. Asking for the best candidates is a rather indirect way to get there and I'm sure they understand their business better than anyone here.
I think they understand their business well, but I'm not sure if they understand market salaries well, given that our culture is notoriously opaque about salaries and one would hope that senior leadership at GitLab is not in the habit of applying to individual-contributor jobs at other companies to get a sense of what offers look like. That means that hearing people complain about their pay bands is probably one of the only good ways for them to get information about whether they're significantly below market or not - as I mentioned in another comment, I just didn't bother applying to GitLab because they were so far below what I could get elsewhere, so they have no information from their normal HR process that I even exist, let alone what a competitive salary for me would be. Once they have that information, then yes, I trust them to make decisions that are good for their business (I wanted to work there, after all!), but I still think that it's appropriate for users to express opinions if we think they're making poor decisions.
Their CEO is very active here on HN so I'd assume they do know all the feedback, but the bigger goal here is the business itself which seems to be doing well (as evidenced by this new round) so they are probably meeting all of their talent needs.
Flawed? Where was minimum wage discussed? That's a completely separate topic that has no bearing here.
Any argument depends on context and in this case, none of the GitLab employees are facing minimum wage, working in hard labor conditions, or facing removal of their last chance at employment. The reality is that they're paid a very transparent amount without much negotiation hassle and they can easily choose to work elsewhere if they want to.
I wouldn't be in favor of increasing the minimum wage if I knew that most of the workforce could easily find a better paying job elsewhere if they weren't happy with the compensation. This is clearly not the case for the general population but probably mostly true for the type of profiles gitlab wants to hire.
Furthermore while I can believe that gitlab's salaries are below the average I doubt they're below any reasonable proposal for minimum wage. If software developer salaries start dipping below what we consider fair I think the most efficient solution would be unionizing to raise the salaries for the profession at large.
Quite frankly I find it a bit obscene to conflate both these issues.
If their salaries are too low, then they should struggle to hire and it'd be their own damn fault. The calculator salaries are lower for my area than what I see, so they should fail to hire here if they are truly that low.
What does this comment even mean? If their employees do not like the compensation package they should negotiate better or leave. Have you worked there? Do you know what the total compensation package is or are you just knowledgeable about base salary?
Negotiate if you want better comp. Nobody in this industry is a McDonald's/Walmart wage slave. Nobody is putting a gun to anyone's head and forcing them to work for GitLab.
GitLab has an exclusively remote workforce that is globally distributed. They put their compensation guidelines up on their wiki for the world to see and readily acknowledge that they adjust salaries for cost-of-living. It’s not a huge problem for them, I suppose, because they are willing to hire workers in lower-cost areas where tech jobs at well-known companies are relatively scarce.
Personally, this goes against my hiring philosophy and as a remote manager at another company, I insist on remote salaries for my team that match Bay Area salaries. I make up the difference by getting pick-of-the-litter hires that I wouldn’t have a chance of getting if I was going up against the Facebook/Google/Netflixes for a local SFBA hire.
I don’t know if GitLab employees have much recourse individually or collectively. It will probably take a market change to get them to adjust.
I have no beef with them and would have considered them more seriously during my last move but their comp is close to $100K less than what I can get working remote for many other SFBA startups.
That's a good thing though, paying with regards to market rate - it's what SF has to do, given how cost of living there is exorbitant and even with the high wages there unaffordable.
I (American) interviewed a Gitlab while earning "SF money" from Argentina. During the phone screen, they told me if I chose to live in SF, they would pay me $121k, but if I wanted to continue to live in Argentina, I would take a massive pay cut $70k. Not to mention, ARG is have massive currency inflation, so each month I would work there, my pay would drop 1-2%.
For remote workers, the job market is actually pretty small. Many of the "remote only" companies (Buffer, Gitlab, RainforestQA, etc) pay based on how expensive of a lifestyle the employee chooses to have.
One remote company I interviewed at mentioned how one of their SF employees moved in with their parents and how they talked about cutting his salary significantly because of his cheaper lifestyle.
I live in Uruguay and I don't earn "SF money", a 70k paycheck would be huge here (and in Argentina as well).
And to avoid the currency inflation you should of course choose to earn in U.S. dollars, or negotiate to be tied to the regular - currently bi-annual in Uruguay - pay increases in countries with inflation (which usually lag inflation and are a bad deal, but offer some buffer to it).
My $0.02 your pay should not be based on how much you spend. If your co-worker chooses to buy an expensive car or live in an expensive city, then they should not get paid more than the guy that lives with his parents because he wants to save money.
Unfortunately that's how it works for companies today - they know they can pay less depending on where you live (even within the same country, like SF vs Midwest US).
It's because it's a market; there is less demand in non-hub / smaller places. Think about the same thing for houses - should you pay SF house prices living in the midwest?
but that logic breaks down when if you factor in competition from other remote companies.
The moment one remote company offers an SF rate compensation outside of SF, then the job candidate's market rate is an SF rate.
I totally understand if a company doesn't have the budget for talent and looks to exclusively hire in non-hub / smaller places in order to keep costs low. But I hate when a company says: we understand you have an SF rate offer and we would normally compete with that if you lived in SF, but, sorry, our excel spreadsheet says we can only lowball you.
Rainforest QA co-founder here; We actually now pay percentile of local equivalent, which is fairer if you want to compare apples-to-apples when looking for work without moving. We found that places like LA, with our previous structure, we just couldn't hire - LA actually has a better $ / living cost ratio for developers than SF! Meanwhile in other places, we'd be 95-100% percentile.
Anyway; compensation is really hard to get right and keep everyone happy, you do your best, but haters-gonna-hate.
p.s. also we're not remote only - we have some great SF engineers - but 90% of our eng is remote; we just want the best people regardless of location :)
I think everyone's financial situation is different. I agree with you that if you try to cater compensation by a hire's lifestyle choices, then it does get really hard to keep everyone happy.
IMHO, living in SF is a choice, especially at a remote company. Just like buying a Tesla or choosing to live in your car instead of renting an apartment is also a choice.
I don't think companies should pay one employee less because they choose to have a cheaper lifestyle than the employees that buy Teslas or live in San Francisco.
I think employees should be paid fairly (which works both ways) based on where they live; if we can pay you above the local average for your role and you don't want to move, then we're an attractive offer.
JW, but how do you think about taxes? Would an American living in Denmark earn more than a Danish living in Denmark, because the American has much higher tax liability?
Or maybe the American doesn't report the income to Denmark so has very low taxes compared to a danish or American-based co-workers since they qualify for FEIE?
Does the married American with the marriage tax breaks get paid more or less than a single American?
I would not feel right lying to them about my location. I currently changed countries every 1-2 months so maybe I could of worked something out for them to pay me in USD, but they also said they wanted to pay me in local currency.
> Have you worked there? Do you know what the total compensation package is or are you just knowledgeable about base salary?
This is pretty rude given that you're the one who's not knowledgeable here. GitLab is extremely public about salary - if you go any job application page they'll tell you what the pay bands are. There is very limited room for negotiation, on purpose.
I agree that nobody is forced to work for GitLab. I completely skipped them over in my last job hunt because their pay bands were much lower than anything else I could find, even though I would have enjoyed the job. I have a friend who did the same. I think that's unfortunate for GitLab / the world and wish they would raise their pay so they can attract candidates who are getting higher offers elsewhere, so they can build a better service.
This is a very different sort of complaint from wage slavery, so I'm not sure why you brought that up.
> Have you worked there? Do you know what the total compensation package is or are you just knowledgeable about base salary?
There have been multiple threads about this. Some being hundreds of comments related to Gitlab's salaries, which they and some people who work there are pretty public about. I could try to find the threads on HN, but they shouldn't be too hard to find yourself.
Yeah, I think it depends on the area. I'm out in Denver and the compensation for an average senior developer seems to be on par with what some salary websites tell me but it's definitely way below what I currently get paid (and below what I've been paid for the past 3ish years).
It's a little low for Minnesota in the US, in my opinion. I could definitely get a little higher than that in the Twin Cities but I think being able to work remotely is a perk that people are willing to take a small pay cut for
While I won't comment on the raw salary numbers, I am curious about how long you feel it should take someone to graduate from "new to the position" to "learning the position"? Because it seems like if that time period is less than two years, you'll be underpaying your long term employees vs. a new hire of equivalent skill, which seems like a not good thing.
Also your Experience Factor Worksheet is private, whether or not you care.
Chicago is really low... the calculator returns ~$50k for a position that would pay 85 or 90 around here. I imagine they mostly target european employees? I know salaries tend to be much lower in the EU.
I think the issue is that they don't adjust for what the market is offering, they just take a standard NYC salary and adjust it depending on your city's rent.
So if your city has a better market-salary:rent ratio than NYC, their salaries are not competitive.
Conversely, they pay pretty well in Lisbon, since the rent is actually quite high compared to the pittance that software developers earn (which is why long commutes are common).
as an American remote worker that interviewed there from Argentina, it was really frustrating for them to tell me they wanted to pay me $50k less because I choose to live in a cheaper city. Even though I was currently making market rate SF money.
They had the budget for me if I lived in SF, but they stuck with their lowball offer.
It’s about fairness. Would it be fair if a SF hire had a lower wage (after expenses) than an argentinian hire? No. So Gitlab tries to optimize for every employee having the same disposable wage, no matter where they live.
It is not a fair system. Thats like saying, "well, Frank bought a BMW and owns a house, so he gets to get paid more." They chose to live in an expensive city and have an expensive life style.
If a hire lived with their parents in SF, does that mean they get paid less than their coworker that rents an apartment?
This reminds me of a recruiter telling me 'people don't work here for the money, they work here for the opportunity, and it's more than enough to live on' when asking for market rate salary. Big tech company, you can probably guess which.
As a senior dev with 5-ish years of experience in NYC, GitLab's calculator for "Developer" is offering me a $144,106-$157,207 base pay, plus stock options (because they are options I'm giving them an expected value of 0; I could value them more accurately if they were public about shares outstanding but they aren't). If I max out the sliders and call myself a lead, that goes up to $183,408. https://about.gitlab.com/jobs/developer/
For comparison, Etsy gave me an offer earlier this year that was $185K, and came out literally in the week they had layoffs, and Google gave me an offer earlier this year that added up to about $215K (base + 15% bonus + RSUs which have an obvious nonzero cash value), with an expectation of year-over-year growth. (The actual job I accepted was higher than either of these.)
I think GitLab's numbers make sense in several markets but not in NYC and probably not in SFBA either. To be fair to them, there's no good reason to pay someone market rates for those cities when they're hiring a remote workforce, but the fact remains that they're significantly under market and probably losing out on good candidates as a result.
Sorry but I think its wrong to compare Gitlab to Google, even Etsy tbh.
Its obvious that Google can offer high salaries. Same with Etsy, while its nowhere near Googles level, I feel like Gitlab's cashflow is nowhere near Etsy's cashflow either.
I checked for London and I can say that Gitlab seems to be giving out a low to average salary at best. Which is not bad considering that you can be working remotely from your home etc etc, and get maybe more shares in a startup like Gitlab.
But ye all and all I feel the OP is a bit right that since they got a better funding they should be looking at accumulating their salaries to go up for their devs that have been getting bellow market rates.
Yeah, I don't expect GitLab to reach Google salaries, but I do think that the data point is useful for knowing how much they are below Google. (Note also that this was an unnegotiated offer; I tried negotiating, evidently not very well, and only got Google to budge about $5K. I'd imagine the legendary Google offers are the ones you get if you are in a position to get Google into a bidding war for you with another comparably-profitable company, and I certainly don't think those can be called "market rate".)
I do expect them to reach Etsy - they had been facing serious investor pressure at that point and laid off a lot of people in a lot of departments including the CEO and CTO, and had not reported a profit for several quarters (they reported one this year after the layoffs). They laid off their summer interns two weeks before the summer, leaving the poor college kids scrambling to find another internship. That's not a company with enough cashflow to make significantly-higher-than-market offers.
And yeah, the comment above (as I read it) was in comparison to GitLab raising a significant funding round.
Actually, there is a good reason to pay SF or NYC salaries to remotes - you get the remote people who're good enough that they can live anywhere and still command a premium salary. I moved to Boulder, Co because I knew that I'd never work here - only in SF or NYC, so I get better quality of life without a meaningful drop in compensation (I'd make more if I picked the right company in NY or SF, but I'm making what many of my friends in NY do, so I'm fine with that.
For India, they have just two areas: Mumbai and Anywhere else. I am living in Gurgaon(near New Delhi) and it is as expensive as Mumbai in terms of renting an apartment. So Mumbai(0.227) and elsewhere(0.103) is not fair. I guess they don't have much data for elsewhere.
I appreciate them being transparent about this. But the calculator suggested salary was too low for me to consider applying :(
Gitlab is a remote company and yet location plays into salary. I get that they need to do this to be competitive but still a 1.263x multiplier for San Francisco vs my 0.466x for TN. Seems like the smart play is to briefly live in SF, secure the >2x salary and then move.
Also, kudos on them for this calculator - very transparent!
But the calculator is based on rent not cost-of-living. For example rent may be 6% lower in Zürich than in Geneva but Groceries are more than 12% more expensive. [1]
With the difference in salary between 'rest of England' and 'London' you could probably afford to rent a very modest one bedroom flat in London while living elsewhere and still earn more.
> Are you also planning to pay your employees market rates now?
This is a defamatory statement and surprisingly not done anonymously. So, maybe you present us the full story, otherwise it's hard to believe that all employees of Gitlab are underpaid and that one person like you knows salaries of all employees there.
> WordPress founder Matt Mullenweg is joining the company’s board.
I suspect this has more to do with Akismet than WordPress. They are using Akismet to filter spam issues, but it seems to have a problem with false positives after making edits.
This is interesting because the two companies are very similar, with Automaticc being a few steps ahead in several areas: distributed workforce, developer first, size / stage of the company.
It helps to have someone who has solved the very problems you'll be facing.
Nothing blows money faster than unlimited storage and unlimited bandwidth when you're not charging for it...
And before you down vote me, realize that github, their main competitor, runs on a colo for this very same reason.
No matter how much revenue you get from paid accounts, and selling on-prem installs, the free service popularity which fuels the paid revenue will outpace it for the forseable future. Trying to reign in those cost, isn't a bad ( or hard ) thing.