I've been a long-time Github user and believer and vaguely followed Gitlab since their beginnings. Much as I admired their company and business, I had a lot of problems with their UI, UX and scattered focus.
Then very recently I've had to use Gitlab for a variety of new projects. And just... wow, it has come a long way.
There is an incredible amount of tooling and features, native to Gitlab. It's actually scary, and in some places even gets messy (feature overload). But a lot of it is useful stuff Github really should be offering. Things like more metadata on projects, subprojects. A very in-depth permission system (invite users with read-only access, issue-only access; membership expiration, ...). Branch protection integrated into various features.
Native CI! That's the big one. Travis is terrible. I used Gitlab CI to deploy one of my most recent project and ... it's been great. Was very simple to configure, felt a lot less magic and constrained than Travis, and it's very well integrated into Gitlab.
All this to say that I'm just about converted. Unfortunately, I have my 10+ year old profile on Github which includes membership to various projects and orgs, but I'm now pretty definitely using both platforms.
Edit: Here's my Github profile so people know I mean business when I'm praising Gitlab. https://github.com/jleclanche
>"I've been a long-time Github user and believer and vaguely followed Gitlab since their beginnings. Much as I admired their company and business, I had a lot of problems with their UI, UX and scattered focus."
I had a similar experience where we had gitlab in a previous job(recent past.)
The scattered focus seemed to be manifest for me anyway in their documentation. Finding documentation often involved going down a rabbit hole of user issues rather than looking in the official documentation. Additionally I found a lot of the documentation seemed incomplete and read more like internal notes than anything else. The contrast being github which has very polished and thorough documentation.
Thoroughness? Accuracy? Here's an example. Someone attempting to upgrade their omnibus package installed instance will likely find the following resource:
This above page states "We encourage everyone to run the latest stable release", we contains an embedded link. And when you follow that link it returns a 404 with a cutesy error page! See for yourself:
Further none of those pages explains how to pass in a specific version of the omnibus package to satisfy the upgrade process in the even that the latest version fails because the upgrade version differential is not supported.
It was really frustrating. And this is but one small example of course. But I think this is typical.
Thanks for the examples. I've asked someone to look into this. And we'll consider setting up a service to scan for 404s in our docs to prevent this in the future.
I always find myself being bounced around different pages in your docs to find information about the same topic, and often also have to get bounced to your blog posts. It's hard to know when I've got all the info.
There are so many different places containing parts of the docs about your CI, for example.
Thanks, I recognize what you mean, blog post content that is not in the docs. I'll bring this up with the docs team and we'll try to get better at this by coping the blog post to the docs and linking the blog to the docs for the most up to date content.
I use all three, and I still like GitHub. It works well, and it's incredibly well supported in the wider ecosystem of services - every CI product, bug tracker, comms product and analytics tool you can think of integrates with Github. Plus, for most large-ish projects, the web UI isn't where anyone spends much time so it doesn't really matter.
I'm intimately familiar with GitHub's UI from both my OSS work and previous employers. I know GitLab can do everything GitHub can do (and more!) but it infuriates me how long it takes me to figure out how to do things I can do in my sleep on GitHub's web UI.
I don't think it's just a familiarity thing; I've been using it for months and still haven't adjusted. Gitlab's UI/UX has gotten better by leaps and bounds, and I prefer it to BitBucket, but it still feels like it has a ways to go.
Well, because it's cheap, I have literally no issues or problems with it, it has all the features I need, integrates with everything, and is the most popular repository of open source code.
When I hear "Github has better integration" I think "You need better integration because half of Gitlab's features are provided by third parties on Github".
I don't care about the integrations on Gitlab because it already has everything I need, plus they ship new features at a rate of more than one per decade.
I use GitLab exclusively these days. GitHub annoys me because I can't turn off PRs for mirror repositories, so I end up either having to sync or to manually tell people to take their PR and redo it on GitLab.
Mostly because of the "hub" part. It used to be the place where everyone else was. Up until the Microsoft buyout when people started jumping ship in droves.
I find both Gitlab and Github have plenty of focus on the dev (Github more so). It just so happens that Github has developed a lot of tooling for orgs and projects since.
Obviously, this comes down to opinion, but honestly: yes. In the case of GitHub, the point where I reached that conclusion was when they added built-in enforcement of code review workflows. A feature which I seem to recall they copied more-or-less directly from GitLab...
(And I'm not saying it's wrong for everyone. But diversity is nice...)
I'm not sure I follow. Do you think improving in other areas means the focus is no longer on the dev?
Github, when it came out, was the only platform that even had proper profile pages for developers. They coined the whole "social coding" thing. I find that whenever I interact with other people on the site, I actively look at their profiles, their contributions, etc.
An example of a recent-ish feature they added which IMO is a good example of "focus on the dev": Comment authors are tagged as "Owner", "Member", "Contributor" and "First-time contributor" in comment streams.
I'm not sure I follow. Do you think improving in other areas means the focus is no longer on the dev?
Yes. There are always trade-offs, especially when you're adding user-facing features as slowly as GitHub [1]. The author tags are one of very few that focus on individual developers. About the only other one I can think of is the option to curate the repositories that appear on your profile page (welcome, but took years of asking...)
[1] Which isn't, in itself, a bad thing -- stability is good, and GitHub's launch feature set turns out to be a pretty good match for what I want)
No, it became atrocious. The world moved on and SourceForge did not, which is why superior offerings arrived.
And to your first "question", no. It had them in almost exactly the same incarnation as modern sites, but with a UX design language rooted (fatally) in the "best practices" of the web at the time. Unlike all the crazy things you'd have to do around FTP to get it to act like DropBox, SourceForge had the mentioned features built in from the start.
It doesn't really win GitHub any prizes to pretend otherwise, so I'm not sure why the pushback against simple facts.
The enforcement of those code review workflows is set up on a per-repository basis. So e.g. if you get access to <someorg>/repo you need to go through that, but not in <yourfork>/repo.
I guess in some sense you could say it's a focus on organizations, but on the other hand it's a glaring omission of a feature that you could have implemented with a pre-receive hook years before either GitLab or GitHub had it, so it would be strange if they didn't add it.
:/ This feels like a 100% reaction to the GitHub acquisition by VCs not understanding the market. I'll bet the inbound to them was nuts the weeks following the new. Good on Sid for fleecing the VCs though how GitLab ever supports that valuation is beyond me.
> Good on Sid for fleecing the VCs though how GitLab ever supports that valuation is beyond me.
Good on the VCs who have deep connections to Google, Amazon, SalesForce, SAP, Oracle, Apple, etc. to make some serious money by selling GitLab to them at some point.
I am very critical of VCs, but when it comes to a market for selling software development tools, you have a limitless balance sheet out there (easily in the $200B market range).
Investors who clearly "not understanding the [software development] market" include:
> Good on the VCs who have deep connections to Google, Amazon, SalesForce, SAP, Oracle, Apple, etc. to make some serious money by selling GitLab to them at some point.
All of these companies have their own internal version control, and its highly doubtful that any of them would switch over to a third-party service.
There's a few people confusing the purchase of software and the purchase of a software company. Sorry for not being more clear.
I'm specifically talking about the fact that all of those companies have massive amounts of cash that they could buy the company and it would create an ROI from the profit it generates.
This. I've never used any of their products but I've always found their marketing to be spot on. They perfectly positioned themselves as a 3rd option to GitHub and BitBucket. With the GitHub acquisition and Atlassian's stock on fire right now, they were in the perfect position to go for an insane valuation.
There'll be more about what made the VCs invest in the live stream tomorrow (10 AM PT / 1pm ET / 5pm UTC). You can register at https://about.gitlab.com/webcast/whats-next-for-gitlab/ but the tl;dr is that the VCs have been following GitLab's progress and metrics for a while now and it was not a kneejerk reaction (even though I get that the timing might make it feel like that).
Is there anyway to register for the live stream without giving up my work email? I'd like to listen but don't feel like I should be giving away my company contact info.
Hope they put a lot of it (money) in their server infrastructure and better management of incident handling on gitlab.com. Thinks can break or get slow (sure) but their competitor (github) is in comparison rock solid. I cannot even count the 503 or git downtimes on gitlab.com
I hope they look on a lot of worse case scenarios like e.g. an upgrade breaks things, DB issues etc. and look how big big cloud installations are doing this stuff (staged updates, roll backs etc.)
We are heavily focusing on performance improvements - both in the product (so that features run better)[1] and in our GitLab.com infrastructure team (so that GitLab.com runs more reliably)[2]. Thank you for sharing your thoughts candidly.
I'll just say that gitlab.com, in my experience, has been much faster than it used to be the past few weeks. Things now don't take forever, which is a good thing. It's still slower than Github, but the improvement (due to the GCP migration?) is quite visible. Keep moving forward :)
Yay! Thanks for sharing the positive experience. We know .com performance is something we need to improve and as mentioned in the comment above, are working super hard to get there.
Seconded. I moved to Gitlab because of pricing issues, and initially it felt sluggish to the point where I considered moving back to Github or Bitbucket (although the latter felt slow too). This is no longer the case. Things still feel sluggish, but not egregiously so.
We actually spoke to this topic in our Series C announcement last year. If we pay the same (rather than by some measure of PPP) in every location, we are effectively discouraging applications from people who happen to be in more expensive areas. By making it about the cost of living, we make sure everyone is taken care of based on living needs. That said, we have an awesome chief culture officer who is leading efforts to make sure our comp calculator is fair and encourages people to apply.
This system fails badly when people move between cheap and expensive cities over the course of their lives, and might need to build savings at expensive city levels when living in a cheap city.
Why not just pay everyone at the expensive city level? If you were hiring a true consultant rather than an employee or a full-time "contractor," you would pay them solely based on value delivered and the defensibility of their pricing given GitLab's business needs. Their cost of living wouldn't matter.
For employees at an all remote company, I don't see why their cost of living should matter any more than that. And applicants in expensive cities would not be dissuaded.
Additionally, the calculator's attempt to handle cost of living fails to address hot markets outside the US (hello from Montreal), treats many countries as way more homogeneous in cost of living than they really are, and gives a seemingly quite inadequate 17% adjustment for contractors. That doesn't cover legal and accounting fees, paid time off of various types, the cost and limitations in health insurance coverage attainable by one-person companies, normally employer-side retirement contributions, etc.
I also find this methodology for paying engineers concerning.
It’s been a while since I last played with it, but I recall finding the results from gitlab’s publicly accessible regional salary calculator producing some pretty absurd results in the Bay Area.
I live 45 minutes from San Jose, and expect remuneration at levels commensurate with my title and experience for the Bay Area in general, as should anyone dealing with cost of living issues here. The gitlab calculator however thinks I should earn 35k less, which feels like a punishment for trying to live somewhere commutable that I can, you know, actually afford to buy a house large enough for a normal family.
If I live in commute range of the same location, why pay me 35 grand less? Should I apologise for my less desirable zip code?
Ah that’s interesting, certainly assuages some of my concerns with this approach, and would obviously allow almost all Bay Area employees to claim the SF salary range.
Arguably the calculator should be configured to just select the maximum permissible salary range inside the permitted radius based on a home zip code, given that presumably everyone who accepts a job offer at gitlab will do this manually anyway. You’d be foolish not to.
It’s still troubling how ‘wrong’ the numbers look for various regions I’m familiar with though.
I can't find their calculator currently, but last time I looked they treated all of Japan as Tokyo. It's kind of funny because although one could quibble about the salary range they give for Tokyo, if I compare it to the salary that someone would make in rural Japan (where I live), it's at least twice as much.
They've got their formula and I think it's probably fair to say that they aren't paying at the top end of the range in expensive markets. Also by scaling on cost of living, they are getting mismatches with the local market -- both up and down. But it's a formula that's intended to be transparent. As much as they say publicly that they want to be competitive in every market, the reality is that a formula will never be able to achieve that.
I quite like their system. As a developer, I can look at what they are offering and decide before I apply if they are going to be in the ballpark I'm looking at. Not everybody has to work at Gitlab. Gitlab also doesn't have to hire all the best developers in every market -- their strategy is to hire around the world. SV is the most expensive market in the world -- in many cases by 1-2 binary orders of magnitude. Remote only companies don't have to pay those prices and I don't see why they should. That Gitlab even tries to hire in expensive markets is interesting to me. I'm not really sure what value they are getting from it.
I know in the US (and especially SV) there is a feeling that expensive markets attract the best talent. In my experience this isn't really true. In my experience expensive markets attract more people, but the range of ability and experience is about the same. So you may have more great developers in absolute numbers, but your chance of hiring them (especially if you are on a budget) is not any higher at all (and in many cases quite a bit lower).
I should note, in closing, that I may be strange: I don't care at all what anyone else makes in the company. I only care if people pay me what I want to be paid. If someone else makes more, then good for them. If they make less, then that's too bad. But I don't personally care either way.
> If I live in commute range of the same location, why pay me 35 grand less?
If you are doing location-based pay at all, you can't really apply his rule because very large areas are connected by within-commute-distance links such that if you never distinguished places within commute distance by pay you'd essentially eliminate location-based-pay other than across high-friction borders or places that are (either in fact or at least for transit purposes) isolated islands.
A fair counterpoint, but if the methodology creates results that do not reflect market reality, it’s arguably not fit for purpose. I do think that much of that can be mitigated with more sensible “region” factors, but that would greatly increase the complexity of the process. Setting remuneration fairly is a hard problem, but this is arguably not a great solution either.
"Additionally, the calculator's attempt to handle cost of living fails to address hot markets outside the US (hello from Montreal), treats many countries as way more homogeneous in cost of living than they really are, and gives a seemingly quite inadequate 17% adjustment for contractors. That doesn't cover legal and accounting fees, paid time off of various types, the cost and limitations in health insurance coverage attainable by one-person companies, normally employer-side retirement contributions, etc."
I, personally, did not know about the way we treat intl comp on the calculator because I do not work in people ops. I found it useful new information.
Thank you. I understand. I know PR is difficult and I really value the candor. I am very concerned personally about what Gitlab represents for my industry, but if you are all willing to speak directly to challenges on it that goes a very long way. I hope you can understand also why people have these concerns.
It seems to me that the reverse of your policy would be best for the world. If you free people to move, they can choose community, friends, family, politics over being tied to a single geographic location where most of the activity is. This would help with availability of technologists in many disadvantaged locales, and would provide an influx of taxable income and consumer spending locally. This should have the ultimate effect of improving economic conditions in depressed areas, and when that happens you can actually come back and reduce everyone's wages across all locales because the economy is healthier and more robust. It works out for the owners too in the end, if they take a long enough view.
I guess it depends on your perspective whether this is the case. With the current policy, if the implementation works, GitLab employees should be free to move anywhere without sacrificing anything in terms of living conditions. If you live somewhere with low costs of living, you can move to your community in an area with higher costs of living, without noticing in the amount of things you can purchase. The same holds true when you move to an area with lower costs of living, but of course, you'd get paid less.
No problem at all and glad you find the candor useful. It is one of our company values to be transparent :-).
I also hear you in your concern. There is a flip side perspective to what you are saying as well where someone might be forced to uproot from their home which happens to be in a more expensive area because they would save so much elsewhere. But regardless of the specific arguments, what I have truly learned here in this thread is that we should continue the conversation in the community. I am going to sync up with the people ops org and suggest that we share our rationale in more detail in the near future and/or also incorporate the good points that were raised.
I do think it is amazing that GitLab brings these conversations to the fore because opacity has been the norm for way too long around comp and we need to change that as an industry and community.
For me, in this case, the specific arguments are exactly what matters. If your company claims a solid economic rationale they should provide one. I'm not sure how it's possible you've had this policy this long and can't come out swinging on this topic. Claiming fairness vaguely is not enough to gain goodwill. It's easy to assume greed and desire for control over employees in this remuneration policy, and I'm quite happy to make that argument if your company needs that feedback. You probably don't want people like me in your company, because I am annoying, but I do have a lot of diverse experience and an abiding concern for the health of my company and coworkers. If this policy doesn't reflect a deep level of antipathy about contributors (currently) high wages, and if the company would reverse this policy in considerance, people like me would be in the door tomorrow - thousands of us. You recently hired someone I love and deeply respect professionally, so I hope your company plans to take good care of them. They deserve it, and you do to. Everyone deserves it, especially if they can make it in the door in this new economy. I'm arguing for you too, you personally, if you can see that. End "brain-drain" in USA (and its associated economic spheres).
> If we pay the same (rather than by some measure of PPP) in every location, we are effectively discouraging applications from people who happen to be in more expensive areas.
If you do location-based pay, you are even more strongly discouraging applications from people in less expensive areas, especially if you don't adjust salaries for relocations after someone is employed, since someone in a less-expensive area who might consider working for you is encouraged to delay their application, seek employment that will let them wlive in a more expensive area, and then apply to GitLab (and, if you don't do post-enployment location-based adjustments, then move back to the cheap area.)
> efforts to make sure our comp calculator is fair and encourages people to apply.
As long as you pay people differently for the same work based on where they live when they apply, your comp calculator will not be fair.
To the extent that place of residency at time of application correlates with status in any protected class, it also seems to be a pretty open and shut unlawful discrimination by disparate impact case waiting to be filed, too.
That means that as someone working at GitLab, my current wage is competitive compared to local companies, + I get all of the perks of remote work, working on open source, developer tooling, etc, and all of this will still be the case if I were to move elsewhere.
The exact amount of money deposited into my account each month would go up or down, but my lifestyle would stay roughly the same.
I know I’d make a lot more money if I lived in, say, the Bay Area, and if I made that same amount of money pretty much anywhere else I could live like a king, but I honestly don’t care. I quite like my decidedly not-king-like life today, and I love that with GitLab, I can have this same life and job wherever I choose to live.
I’m currently living in the Netherlands, but am planning to move to Mexico in a few years to be closer to my fiancée’s family. If all goes well, GitLab will travel there with us, and while my compensation will see a decrease, our life style won’t.
GitLab’s compensation philosophy is one of competing with the local market, instead of putting a fixed price on the value I or anyone else provides to the company, and that’s totally fine by me. If it wasn’t for GitLab, I’d probably be working at one of those local companies, so aren’t I still better off? For the company, it means that it/we can hire great people wherever they may be on earth, without being limited to the subset of great people who also happen to or want to live in the specific city the company happens to be based in.
This may come as a surprise to some, but there are some amazing engineers out there who have zero interest in living in the Bay Area, and who don’t particularly care about maximizing their yearly take home pay, as long as they make enough money to provide for themselves and their family, and can live in whatever city or country or continent that they prefer. The map on our team page is a testament to that: https://about.gitlab.com/team/ (mobile-friendly: https://gitlab-com.gitlab.io/teampage-map/)
FWIW, I know of colleagues who have moved to locations with both lower and higher cost of living compared to the location they were hired in, and I’ve never heard about requests to move being rejected.
I did not know companies actually do this. I would never work for a different salary than my peers (based on location). In my small "virtual" company, most of my colleagues live and work in Wisconsin (US). I live in Hawaii, where the expenses are much higher, but I would never dream of asking for more money, and I would be laughed out of the room (virtually!). Years ago, when I was an officer in the Air Force, we all had the same salary, but the government did provide Housing Allowances. This is similar, but not the same thing. A unit of salary is for a unit of work, and I do not believe this should vary by geography. If their workers choose to live in SF vs Oklahoma or Buffalo, then they pay the price. I realize that I have less "real" wages than the rest of my team in Milwaukee or Green Bay, but Maui has its compensating benefits.
I agree, and I think that military housing allowances (which are adjusted for CoL) also have the additional justification that (generally speaking) you don't get to choose where you are stationed. As a service member, the military tells you where to go and you go, so it makes a certain amount of sense that you're then paid enough to live there.
As a software developer in the civilian world, my physical location has nothing to do with my work, so it makes no sense for my compensation to be based on my location.
I don't understand this rational at all. If a developer in SF is worth x dollars to you, why are they suddenly worth less if they move to a lower CoL area? If you're paying salaries that are livable in a high CoL area, you aren't discouraging people living there, you're freeing people to move wherever they want.
I'm a Silicon Valley based dev who really wishes he could move far, far away from here without taking a huge pay cut, so I'm obviously biased. That said, in my view as an employee, the value I create for the company isn't based on my physical location, so why should my salary be?
The market for remote work isn't geographically constrained, so it doesn't make sense to make pay offers as if you were hiring in specific geographically constrained markets rather than the unconstrained remote work market.
As the devils advocate: Why not? The competition for that employee is largely local offers, remote is a small part of the overall market. Plus many other companies hiring for remote do local adjustments too, they just aren't public about it.
This all sounds weird for me to say because I certainly want devs to get paid, but this is the reality of the situation
Agreed. Though I can imagine some companies reasonably applying constraints in certain areas: working hours overlap, travel costs, and (especially where they don't do the fraudulent "honest this person whom we treat daily like an employee is not one" contractor lie) compliance costs and obligations.
That may indirectly imply some geographical constraints which could affect the shape labor market and the resulting supply/demand math leading to a salary. But it's definitely not what most companies do in their cost of living adjustments.
It's a negotiation, right? And at least some of the cards are known, such as an admittedly noisy estimate of what people will accept as a salary.
Basically the company shares in your lowered living costs if you are somewhere cheap. Hopefully they won't eat the whole savings, something should be left for both parties.
I was interested in working at GitLab a couple years ago but the salary calculator changed my mind. It lumped all the cities in Oregon together which gave some weird results depending on which city you live in. I can't imagine how wonky the data gets internationally, and it seems like the fairness of your salary would depend on the accuracy and granularity of the data GitLab has for your particular region.
> but it's one of those things that we can't just vote on and change the whole company salary structure.
I know you alone can’t do anything about this, but the longer this painful task is put off, the more difficult will be to rectify as Gitlab grows (more people = greater labor cost expense increase when the problem is addressed).
Just looking at Germany: the salary calculator assumes everything outside a select few cities is costing the same. I sincerely hope they don't use that calculator to make the actual calculations for candidates but spend the effort to calculate an actual number for the location, otherwise that's entire areas that are just laughably inaccurate. E.g. Stuttgart, according to some numbers the city with the second-highest average rent in the country is not in a special case and thus assumed to be in the cheapest class. Let's estimate CoL 30 % higher than Berlin, 10 % less compensation.
I really don't find it convincing. If you pay as much as your competitors, why would talents in expensive areas would be discouraged to apply to your company and go to your competitors?
If you're assuming that big city people would feel bad because the small city people get paid more in terms of cost of living, then I'd say that's a bad assumption. People living in any city should know its pros and cons, why is it up to you to decide that the cost of living is the metric?
There's serious room for improvement in the salary calculator, calculator to account for growing metro areas, and I think most of this comes from trying to rely on numbeo for your rent indexes. Eg. Why in the world doesn't Portland OR have its own rent index vs rest of OR?
The 'Hot Markets' adjustment should also take a wider account for cities / towns / suburbs that are probably also booming. For example, I'm in the PDX metro area, but on the WA side of the river. My housing costs have gone up 41% to 2.5 years thanks to the booming housing market here, but the current gitlab calculation doesn't account for it thanks to the combined factor of being in the metro area but not in the right city/state, combined with the fact that the big growing metro area doesn't have it's own rent index.
Of course, this could be smoothed over and fixed as part of the hiring process, but it would be nice to know up front that you were using up to date data in your attempts to pay market rate salaries.
So high COLA areas typically already have better schools, utilities, and public services, but you reward employees living in those areas with higher pay because it would be unfair to pay them the same as people in lower COLA areas? Why would anyone choose to work for you if they don't live in a high COLA area?
That's probably usually true but as an SF resident, I can tell you the schools, utilities, and public services aren't what I would call world class here :p. Wish this was more like New York that way hehe.
Hi folks - appreciate the discussion here. Our ceo put down his thoughts in the GitLab handbook about our policy to pay local rates - https://about.gitlab.com/handbook/people-operations/global-c.... Do check it out. Doesn’t mean the calculator is perfect but speaks to the universal comp vs localized.
Ok, so maybe people in high cost of living areas aren't discouraged when the salary scales with their cost of living. But doesn't that effectively bias gitlab against those candidates because they have to pay them more? At some point there are unavoidable incentives that crop up as a result of the asymmetry.
so by his words, it means that if I live in a third world country but I work as hard as my peer in SF I'm going to get paid less by a unit of work? even tho we both are equally good and working as hard?
The reason why I think GitLab has been massively overvalued and why GitLab will ultimately fail is because it is storming head on into becoming a stale company.
Normally a startup is innovating in one vertical, disrupting the market with new ideas or technology which enables users and the company itself to profit of those innovations. This continues normally until the startup has become number one in that vertical. Then it must defend its spot against other newcomers who want to disrupt. Part of the defence is diversification, use the capital to disrupt in other places as well. This has been the natural progression of every successful business I know. At some point that company is so big though, competing in so many verticals that it becomes stale. It stops innovating and is constantly on the defence. Only innovation comes through acquisition which is often just a way to defend your spot by buying early.
GitLab is sort of not even trying to become number one in one vertical. Like the CEO said in his interview, GitLab already competes in 9 different verticals (JIRA, Jenkins, GitHub, NewRelic, Artifactory, etc.) and they are not near the top anywhere yet. They are going to become stale before even reaching a single peak in any industry. So far they have not innovated anything yet. Their only innovation is "free private repos" and "cramming 9 different domains into one product", which is nothing more than a pricing strategy and a lack of focus and not an innovation. It's painful to watch. Their business model looks like their products: an absolute mess.
The CI is pretty but it's definitely not a polished product, e.g. the job progress indicators are unreliable on most pages, the "retry" functionality for failed jobs periodically does nothing which forces developers to touch their branch with a push to trigger a rebuild, the horribly named "tags" feature is a source of constant confusion for developers new to gitlab who are trying to trigger jobs based on git tags only to discover that "tags" in gitlab-ci have literally no relationship to "tags" in the sense of tagging a git commit. It's also impossible to do something as simple as trigger a job only for tagged commits on a specific branch or skip certain steps in the pipeline based on what happens at job run time. I like many other aspects of gitlab but the CI is definitely less than ideal.
> The CI is pretty but it's definitely not a polished product, e.g. the job progress indicators are unreliable on most pages,
I agree with this, they need to do a better job of updated those circular indicators.
> the "retry" functionality for failed jobs periodically does nothing which forces developers to touch their branch with a push to trigger a rebuild,
Not sure when you last used their CI, but I've never experienced this issue.
> the horribly named "tags" feature is a source of constant confusion for developers new to gitlab who are trying to trigger jobs based on git tags only to discover that "tags" in gitlab-ci have literally no relationship to "tags" in the sense of tagging a git commit.
A tag created through the GitLab web GUI is directly connected to `git tag`
> It's also impossible to do something as simple as trigger a job only for tagged commits on a specific branch or skip certain steps in the pipeline based on what happens at job run time. I like many other aspects of gitlab but the CI is definitely less than ideal.
> A tag created through the GitLab web GUI is directly connected to `git tag`
It appears you may be suffering from the same confusion (or perhaps you're not aware of the feature), I'm talking specifically about gitlab-ci tags
https://docs.gitlab.com/ee/ci/yaml/#tags
That has nothing to do with git tags, but one could be forgiven for believing that's the case when the documentation exacerbates this confusion. From the docs you just linked
> only defines the names of branches and tags for which the job will run
"tags" in that sentence has nothing to do with git tags but is actually referencing a gitlab-specific job tagging feature. It's very confusing.
> I think you should refer to the manual.
I have. The tools provided are not sufficient to accomplish the examples I have described. I'm happy to be proven wrong because it'd actually be quite useful to me. Can you direct me to how I might trigger a job only on tagged commits pushed to the master branch?
As far as when/except/only etc, they are not able to introspect on variables or conditions within the context of the job runner, they can only react to gitlab-specific signals like the success or failure of other jobs, I can't do something like "build, run unit tests, run eslint, run flow type checker, deploy but only if nothing else failed, except eslint which is only a soft requirement but not a deployment blocker". Any failure in one job is a failure for all jobs unless you make it explicitly the inverse which still doesn't give you intelligent control over the jobs.
> > It's also impossible to do something as simple as trigger a job only for tagged commits on a specific branch or skip certain steps in the pipeline based on what happens at job run time...
> I think you should refer to the manual.
GP is correct - there is no way to do it. Workarounds posted on multiple issues simply don't work. Official docs are vague on the matter, but the fact is, GitLab doesn't support this common scenario. And a few others either while we're at it... Like allowing me to schedule a manual job for when dependencies finish. I have to wait every time and it's annoying as hell.
While I also like to consider myself above pricing, it is worth noting that innovation with pricing is perhaps the most important part in building a great business.
Arguably Google Search's success is more to do with their revenue innovations than their algorithms.
I started using GitLab a week ago. Only because they offer free private repos. GitLab feels unpolished and I encountered so many small UI bugs. If they said they are three people and just founded their startup, ok, sure. But Series D, at a $1B valuation? I guess their priorities lie somewhere else.
As a now-more-active user of Gitlab (cf. my other comment in this post): I think you should prioritize cleaning up your project management tooling UI.
The project sidebar is a mess. Full of stuff most projects most likely don't use (I bet the "Operations" and "Registry" sections are used by <1% of projects).
Stuff that is conceptually duplicated. And also there's yet another "Settings" sub-section.
The CI UI could use some reorganization as well. It still takes me several clicks to get to the current running build log from the project homepage.
Your UI has improved a lot since the old days. I'm glad you found the right balance between "carbon-copying github" and "having your own completely unique identity". I hope you can focus more on UI and UX though. Especially with a featureset the size of Gitlab, retaining a good UI becomes harder, even more so as the ways people use your product differ more and more.
Thanks for the feedback @scrollaway. I appreciate that fact you recognize we have made a lot of improvements and that there is a challenge in scaling and keeping the user experience consistent.
"Stuff that is conceptually duplicated. And also there's yet another "Settings" sub-section."
I am curious to learn more about what you feel is duplicated in the sidebar? The 'settings'in the sidebar is specific to the project you are currently viewing. The 'settings' in your avatar drop-down is specific to you. Are there other duplications?
"The CI UI could use some reorganization as well. It still takes me several clicks to get to the current running build log from the project homepage."
We agree! We have an epic to prioritize UI/UX improvements for CI/CD. It is still being updated but you can view it here: https://gitlab.com/groups/gitlab-org/-/epics/295. I would love to hear any more specific area you think we should concentrate on.
The most jarring duplication I keep encountering is `Sidebar => Settings => CI/CD` vs. `Sidebar => CI/CD`. I understand they don't do the same thing, but the way it's presented, the sidebar is already the settings.
Registry should probably be under Operations, too? All in all there's a lot of stuff in the sidebars and it's very hard to find my way through them, especially the bits I don't often use.
Not gp, but: you have a marvelous security system, but GitLab Pages does not use it. For an installation containing private/protected projects, this severely limits the use of Pages.
For example, it is not possible to use Pages to build documentation that should only be available to project members. Everything published to Pages is available to the public.
Thanks! I see you also contributed this as an issue https://gitlab.com/gitlab-org/gitlab-ce/issues/33422 and we plan to make this in the next 4-7 releases. Many of our users have a self-managed installation that is behind the firewall so for them this is less relevant. But we understand the urgency. And of course it would be even quicker if someone can contribute this functionality.
I've been following that one for a long time. Someone started a contribution for it (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18589) and there's a GitLab person that appears to be very responsive, so it's going to land eventually.
Once that lands, it would be amazing to have a way to leverage CI + pages + auth to provide docs for external users. For years, I've been looking for a way to host authenticated, infrequently used docs. There are no options. Static sites on self-hosted, authenticated GitLab Pages would be perfect if I didn't have to pay for every user.
Possibly. For our use case (300 users, 900 projects), it makes Pages a non-starter. And the upside would be to move almost all technical documentation from SharePoint to GitLab, which would make the platform significantly more sticky than it is today.
I use gitlab every day. When we get a large MR gitlab is almost unusable. You need to add pagination instead of auto-closing file diffs. The page gets so slow to the point that there are multiple seconds of lag time when you type or do any action. Sure it's not a great idea to have huge MRs but sometimes it happens. And when it does it makes me want to not use this product
Making it possible to find an image in the registry. Can't sort by date. Have to go (slowly) paging through hundreds to find them. No automatic culling. It's a nightmare. And you must surely be accruing many TB of images people don't need anymore.
Congrats to the GitLab team! They and a few other companies lately have shown fantastic customer and revenue numbers around an open source product. (I mean, a $1B+ valuation is cool, but the underlying customer metrics are way more important because that’s what it’s all based on.) This is an important step toward increasing the % of all software that is open source.
Calling Joseph Jacks to give some data here... (I know some other names of companies with tremendous numbers but don’t recall which are public info, so I don’t want to risk it.)
+1 to the "I mean, a $1B+ valuation is cool, but the underlying customer metrics are way more important because that’s what it’s all based on." I've been super impressed working with Sid that his eye is always on the prize and he pushes us to work towards making our users and customers happy rather than go after any vanity metrics. It's ironic but this is novel in the valley now :p.
> As Sijbrandij stressed, while most people still look at GitLab as a GitHub and Bitbucket competitor [...] GitLab wants to be far more than that. It now offers products in nine categories
So basically, instead of being a GitHub competitor, it is now an Atlassian competitor.
Atlassian is indeed broader then just BitBucket and a better comparison. GitLab does a broader offering than Atlassian by including things like packaging, monitoring, and security. And GitLab is a single application instead of a suite of tools with different data models.
The offering in most categories is already good enough (for our little startup in Amsterdam), and we're still on the free tier! We only have to use a single integrated SaaS offering which fits almost all of our needs. The CI/CD is far beyond "good enough": it is fantastic, especially with runners on EC2 auto-scaling. Congrats on closing this round Sytse!
Be careful when considering the market share of these vendors based on anecdotal SaaS experience. A large portion of their revenue comes from their enterprise editions which are hosted in-house. We're seeing significant growth by GitLab in this area with our enterprise clients.
I previously worked at GitLab, and I can confirm this is the point that I find most commenters on HN miss. GitLab's web platform, at the moment, is essentially a marketing expense to get people to use GitLab and push it into their day jobs.
I saw somewhere MongoDB claimed like near universal usage in fortune 100s or 500s, meaning Mongo was used at all these big, successful companies.
GitLab is that...it's mongodb to GitHub PostgreSQL. GitHub isn't "cool" anymore but it powers the world. GitLab is "cool" to some, but ultimately it's software sugar.
I use GitLab for all my side projects. I personally love the integrated CI/CD. But there's one thing that I absolutely hate and is their hierarchy model for repos. In GitHub, repos are first class citizens. For some reason, I feel that in GitLab you get a diluted repo experience.
I think I would abandon GitLab altogether if Microsoft ever makes private repos free.
Thanks for the feedback. I’m a Product Manager for Create (Git, merge requests etc) at GitLab. Why do you think the repository part of the project isn’t clear enough? What would make GitLab’s repo capabilities less diluted for you? I want to make sure using Git with GitLab is great.
Thanks for the feedback. I'm a Solutions Architect at GitLab.
You can certainly maintain a flat line of repos in GL just like GH. But as you scale and need to group projects by context (customer facing, webapps, bizapps, security, etc), hierarchies (ie. GL groups) provide some added benefits esp around access rights and inheritance of settings -- and the 1st class citizen child projects get things implicitly! Curious how you are using hierarchies in a way that doesn't feel right. Happy to help!
I have wanted to and tried to like GitLab. I can't. Everything about it is less than half baked, most of all their CI stuff. It's hard to see them having line of sight to a $1B valuation when they can't do the basics and are trying to recreate the terrible monolithic systems of years gone by. That's not a world I want to live in ever again...
Likewise. Our team just transitioned from trello + github + jenkins to only gitlab. It's definitely missing a few things, but having all our development workflow in one place has been amazing.
Not sure its worth 1bn, but I am excited to see whats next. Github has been resting on its laurels for some time.
I'm sorry to hear that. We value iteration over perfection and so that can be jarring sometimes. I am surprised to hear about the CI experience though. Did you try the Auto DevOps pipeline or just CI generally? Would love to help out if you are open. Twitter.com/pritianka DM me!
To add on, we are actively working on balancing how we deliver new and deep solutions, CI in particular is an area where we want to provide better solutions for more complex problems (as well as address some of the challenges like hung builds or other issues people are running into.) You can read about our vision for CI here: https://about.gitlab.com/direction/verify/
I'd also be up for a chat sometime if you'd like to talk about some of the issues that are impacting you and what we might be able to do to help. twitter.com/j4lenn
Really sorry to hear you've had that experience. I'm the PM for CI and we're really proud of how our CI product in particular has been rated by industry analysts, and how we've maintained interoperability, though of course that doesn't speak to where you've struggled with our solution. If you'd like to chat about it sometime I'd definitely be up for it.
My company uses GitLab and I think the CI is fantastic, especially compared to Jenkins, Travis, Circle, etc. It's very easy to setup, incorporated into the rest of our workflows, intuitive, reliable, powerful. I have a few complaints but i see they are on the upcoming roadmap.
Right now sales people at GitHub are trying to convert our $200 grandfathered plan into a $2000 one per month at no avail because we can just move over to Gitlab and get same or better service. I’m thankful for Gitlab’s existence and am just watching this unfold popcorn at hand. I bet I can probably cut that $200 bill into a $0 if I asked Gitlab now after their big fundraise.
As Jack Welch says, strive to be #1 or #2 in your industry, seems gitlab is well positioned to make a run at this, and given the price tag Github set for this type of product in the devtool space, 1.1 seems very respectable. Nice work Gitlab CEO, good luck! :)
To people who have used GitLab: is there any way in which GitLab is not just an incremental improvement over GitHub? Or is there something I'm missing? (Genuine question; not trolling).
Thanks for asking. One of our big goals is to address the awareness-gap about the GitLab offering.
So instead of a version control system that lets people try out different integrations, GitLab provides an opinionated (yet flexible with key integrations and the option to opt out of anything you don't want) way to run the entire software development and deployment lifecycle. You can start with planning your issues, then you create the code (usually in your editor of choice but there's a web IDE that makes quick fixes much faster in GitLab), then you store your code with our version control. Using the GitLab CI you can set up automated jobs that include all kinds of tests (we provide the Auto DevOps pipeline for a set of best practices to automatically do tests and security scans and also provide Prometheus metrics without you having to do a thing). Then comes the CD part, followed by monitoring via Prometheus and tracing with Jaeger. You can deploy the code to k8s clusters directly on GitLab making k8s a lot more accessible to developers and then run it on any cloud. Our GKE integration is pretty dope. I personally am working on bringing similar serverless functionality to the product soon as well. This is by no means an exhaustive list but I covered the main aspects from my perspective. You can learn more here - https://about.gitlab.com/features/
I'm not that familiar with Github but the workflow for creating issues, trying branches to that issue, and tying pull requests to an issue was very good and really helped me get started with Gitlab. I also appreciated the build server which is very integrated into that workflow. I tried creating my own project on Github but couldn't really figure out how to tie a pull request or a branch to an issue. I'm sure it's possible but with Gitlab it was immediately obvious how to do it and almost hard to avoid it.
I spent a lot of time with Gitlab Auto DevOps but never really got it off the ground. I think I could make it work now but that Git + Gitlab + Docker + Kubernetes was just too much to learn in one go. It certainly didn't help that I started out with Amazon EKS instead of the recommended Google Cloud option.
In the future I would like see them add a hosted Maven repository (but I don't think that's in the stars) and if they are feeling adventurous I would like to see them explore visualizing the execution of multi-stage Dockerfiles as process pipelines the way they visualize .gitlab-ci.yml files today.
Perhaps these very subjective impressions from someone who doesn't have a lot of prior experience with either product will give you an idea of how these products differ. ;-)
I personally couldn't really name one but it is many small incremental improvements adding up to something bigger.
When a place I used to work at mandated a switch away from GitHub to GitLab I was a bit annoyed and saw it as penny pinching, going for the cheaper but crappier option, but since using it daily for a while I am a convert. I have my own installs of the free version running in some places now as well, and I find that pretty painless.
Their CI tool is nice as well, dead easy to get started with.
Agreed, for me this is a killer feature. Being able to just download the gitlab-runner executable (1 file) on mac/windows/linux and register a private runner - even on gitlab.com - and the simple configuration of CI builds, with the deep integration of CI results in the whole gitlab experience (commit browser, merge requests ("merge if CI succeeds", etc)) is best of class.
Edit: I'm not usually bothered by downvotes but I'm curious about what kind of agenda whoever downvoted this has.
I wonder if that means they'll finally create a dark theme which has been on the request list for years and has been pushed from releases time and time again.
While I'm a huge GitLab fan since June 4th, but one thing that concerns me greatly, which hopefully will be resolved with this extra money, is the huge number of growing issues.
What's even more scary herein is, that some issues/feature request get put on the back-burner because "there's bigger problems to solve" or "more valueable features to build"
$1.1 Billion? That too much, even Github hasn't reached profitability yet inspite of being the most popular Code hosting site. Gitlab can never reach the level of popularity that Github has. Then how are they valuing it at the price point? Some of Khoslas investment lately are so off, for instance the 'Hyperloop' transport Inc.
GitLab is pretty awesome. I switched for many of my projects over the last few months and I'm most enjoying the time tracking functionality. Very simple, yet very powerful. It's nice to be able to estimate or track time using commit messages or a command line helper tool like gtt.
I wonder how well they explain to their employees how this can wipe out their upside. Venture Deals by Brad Feld is a great read to help understand why this is potentially a dangerous situation to be in: https://www.amazon.com/Venture-Deals-Smarter-Lawyer-Capitali...
Okay, are we starting migrating to another hosted Git service right now or do we wait for them to start behaving shady and eventually selling out? Asking for a friend.
Great news! For Kitspace [1] I am currently working on re-purposing GitLab for electronics projects. It's good to see that "upstream" is getting more financial support.
I believe GitLab being open source is going to save me a ton of time and it could do this in other areas as well. I always thought GitHub could have been a much more remarkable product if it had been open source given its community. Let's make it happen with GitLab.
Came to the comments to complain about GitLab not having language stats on a repo landing page, as I thought that was the #1 missing feature. Very pleased to see it was added three months ago!
Surprised it took this long, this is one of the first things I look at when considering contributing to a repo: Am I proficient in it's primary lang(s)?
So you've done a complete analysis of how much effort that would take and the loss of reliability inherent in rewrites versus the potential gains at scale?
No, it is not because of Ruby. It is either about not prioritizing performance in their development process or lacking the skills to write fast software. The Gitlab team would probably write a slow application in Go too.
It's mostly due to them not paying developers enough and also having a cavalier attitude about engineering concerns. Their free product is a loss leader designed to sell you their B2B and it doesn't need to be great it just needs to be used. As with the rest of their philosophy the less they spend and can get away with the better for them. From their perspective.
Then very recently I've had to use Gitlab for a variety of new projects. And just... wow, it has come a long way.
There is an incredible amount of tooling and features, native to Gitlab. It's actually scary, and in some places even gets messy (feature overload). But a lot of it is useful stuff Github really should be offering. Things like more metadata on projects, subprojects. A very in-depth permission system (invite users with read-only access, issue-only access; membership expiration, ...). Branch protection integrated into various features.
Native CI! That's the big one. Travis is terrible. I used Gitlab CI to deploy one of my most recent project and ... it's been great. Was very simple to configure, felt a lot less magic and constrained than Travis, and it's very well integrated into Gitlab.
All this to say that I'm just about converted. Unfortunately, I have my 10+ year old profile on Github which includes membership to various projects and orgs, but I'm now pretty definitely using both platforms.
Edit: Here's my Github profile so people know I mean business when I'm praising Gitlab. https://github.com/jleclanche