GitLab is like the average kid in class that everybody makes fun of for constantly asking questions, but the joke's on them because "a little bit of slope makes up for a lot of y-intercept." While GitLab may have warts, I feel that they're very earnestly working to make the product better, bit by bit, day by day, and will one day surpass GitHub.
1. Why does gitlab have so many tiers? It would be better if you guys could repackage the features into fewer categories.
2. Why is the Gitlab UI so ugly? IMO, bitbucket and github are leaps and bounds ahead of you guys when it comes to design.
3. Can we get a dark mode for us night owls?
4. Finally, the morality question, You guys proudly associate yourselves with open-source and get help from loads of opensource devs, yet you greedily restrict simple features like epics, burndown charts, roadmaps, configurable issue boards etc. from the core/free categories. Looks like your key core goal is to make money... how are you any different from microsoft or google?
1. They only have four tiers (four equivalent tiers for hosted and on-premise technically). This is quite reasonable, as they need to provide flexibility for their customers. They are quite clear about which tiers provide which features.
2. This is purely subjective. I quite like the design, both more than GitHub and Bitbucket. They do have a UX team, and they conduct regular user tests. They've also made a lot of improvements and continue to make improvements, but design will always be subjective. You CANNOT please everyone
4. GitLab is a company and needs to make money to continue employing developers to continue developing their product. Open source devs volunteer their time on GitLab CE, not any of the closed source features, and GitLab has open sourced enterprise features in the past if the demand is high. Also, there is nothing wrong with comparing them to Microsoft, as Microsoft has thousands of open source projects and is quite the open source contributor.
I'd flip #4 on it's head. They aren't greedily restricting features, they are generously open sourcing features and giving them away for free. As a business, they have no obligation to do so.
When my company subscribed there was only a community and enterprise tier.
Now this has become the starter edition and I feel we are losing a lot of value.
We are 200 employees, but only 10 developers using the advanced features. We really want to make GitLab our hub (GitOps and all), however the the cost of going beyond starter edition is mind blowing (x5).
So if we are to embrace GitLab further we must abandon the idea of letting the whole company use GitLab freely and limit it to devs only.
Being small doesn't mean that we are not in need if advanced features, we just have a smaller scale.
Also as our initial tier was the top tier, and now is the bottom one, I fear GitLab will fence off future functionality with even more tiers at random.
Further, the tiers creates some artificial barriers where we several times feel the some of the new features we receive are just barely functioning and are just there to entice you to upgrade to the next tier.
We are all in all very happy with GitLab, however we are no longer pushing it as a central hub for the company.
That one is exactly ours, too. We have 275 users in license, bought when GitLab Enterprise was the thing. We set up GitLab to help establish innersourcing (e.g. https://about.gitlab.com/2016/07/07/trends-version-control-i...), where all employees are users -- no exceptions. We run a GitLab introduction as part of onboarding of all employees, whether techies, marketing people or recruiters.
Our 275 users are an eclectic mix. There are a few projects that really pound the product, there are lots of internal playground repositories, and even a few non-technical documentation repositories. The requirements are scattered.
I think that that perhaps 25 of the 275 users have need for Ultimate Edition, but that is not possible, we'd have to pay $325.000 for the pleasure. And that is going nowhere.
An interesting question then is what do we do next? Perhaps our innersourcing strategy has to go, and each team will get to choose their own platform. People will chose what they know, and soon most will be on GitHub.
The 250 users who don't need Ultimate are using our GitLab-installation for entirely different things (different projects, different repositories, etc) than the 25 who do.
For example, our training academy keeps a bit of training material in asciidoc format, stored in GitLab, and available to everybody in the organization . GitLab Starter is fine for this need, and this is one reason why every employee has a GitLab license.
On the other hand we have a software project with 6-8 team members who could benefit from GitLab Ultimate. Their needs do not apply to the rest of the company, so we will not get 275 Ultimate licenses for this purpose.
We want (wanted) to have a single GitLab instance to rally around, where we could keep track of all sorts of projects across the company. We went for the Enterprise edition to make sure we could use it without limitations, but we're slowly realizing that it ain't so.
Also, some quick stats: 264 users with altogether 76 groups and 887 projects, adding 5-10 projects a week and 5-10 users a month. We managed to create the hub we wanted, but the hub we bought is no longer catering for our needs, and the hub we need is too expensive.
We're facing the same problem at my company, I heavily pushed towards switching to GitLab and am currently overseeing the process. While we can probably make due with CE, there are a few features that only the 10 to 15 developers in our 300+ employee company would actually use. I don't think that in the foreseeable future the price point of Ultimate will make it viable for us to go that route. Having every employee being able to use GitLab is essential to my idea of how GitLab can be of use to the company, but unless free guest users will also come at least to Gold tier, I think we will have to live with the limitation of CE rather than becoming paying customers. (Please don't get me wrong, I definitely value the product a lot, but I'm not making these decisions alone and I'm merely stating what I know to be the facts for our company. As a fan and developer who would like to use some advanced features I'm hoping that free guest users will come to the other tiers as well.)
IMHO, guest users should be free for everyone. Why should I use GitLab Ultimate instead of GitLab CE + JIRA + JIRA Service Desk and even BitBucket? If I have less than 10 contributors (ie: developers), I can self host Atlassian stuff for less than $100 / year and JIRA Service Desk lets me have unlimited customers for no additional cost.
GitLab's issue tracker and Wiki would be a perfect fit for me to support customers and non-contributors. I really think you should try to make that type of distinction. I would describe a "non-contributor" as someone that generates work for contributors. Ex: Customers submitting issues that a developer needs to fix.
I don't understand the reluctance to make guests free for everyone. If you're worried about existing licenses getting dropped in favor of free guests, you've got a big problem that's going to catch up with you eventually. People don't like paying for things they're not using.
If you think free guest users will encourage people to upgrade, I don't like that either. It's really frustrating to get locked out of features that would be useful to me just because I'm not a huge developer that can afford Ultimate licenses. I'd say that limiting my ability to develop good processes and workflows, as a tactic for "encouraging" me to upgrade, isn't going to leave me felling confident in my choice to use GitLab. Giving me the ability to scale up when I need it / can afford it will.
I want licensing that scales up with me, not licencing that I need to buy if I want to scale up. Get it? I'm already making a HUGE trade-off to move from CE to a paid license because I can't add contributors for free any more.
As a general observation, the way GitLab's cost scales up seems weird to me. If you plot the incremental cost of adding users to (ex:) JIRA, it looks like a hill that gets easier to climb as you add users. If you do the same for GitLab, it looks like a set of stairs (aka steps). Every time you jump tiers there's a huge pricing cliff you need to be able to climb. If the features I need to scale up (my business) are locked behind those pricing cliffs, I think it's risky to buy into that, isn't it?
I really like the way Microsoft does their licensing with Office 365. They let you arbitrarily assign licenses on a per user basis. For example, I can have one user on "Business Premium" and everyone else on "Business Essentials". Have you ever considered something similar?
I feel like I get really good value out of the Office 365 model. To use GitLab as an example, I "make do" with "Starter" because I don't want to bear the cost of an upgrade for every user. With Office 365 I'd simply buy a "Premium" license for myself and leave everyone else with "Starter" licenses.
I would also say that if you ever decide to allow arbitrary, per-user licenses, the first user should get a free Ultimate license. I've used GitLab for 2+ years and I have no idea what features are available in Ultimate. I pretty much live in CE / Starter. There's no way for me to discover the features I don't have.
I'd also be willing to buy short term licenses, if that were an option, which is another reason guest users being free for everyone might be a good idea. For example, if I'm working on a project for 1 month, it would be nice to be able to give a few people access as collaborators / contributors. However, I don't want to "kick them out" once the project is done, so a downgrade to a free guest user would make a lot of sense. As it is, there's no chance I'm buying licenses for anyone because it's annual only pricing and kicking them out when the project is done makes it seem like I don't want to support the project.
To add something positive, the GitLab (product) issue trackers are amazingly well run. I've never run into a problem with GitLab where I felt like it wasn't worth my time to create an issue for it.
You pay 200 employees but don't want to spend $19/user/month on software for a company hub? That's not really a small company, and this seems like a budgeting problem if money is that tight.
You can also try running multiple installations with a separate dev-only instance with more features. Also have you tried contacting Gitlab to negotiate? A few emails can go a long way.
I would say 200 employees is fairly small company; and depending on the line of business it is certainly small enough that profit margins and thus spending may need to be closely watched.
If you consider that the OP has only 10 out of 200 users that need the advanced features, but has to purchase the advanced features for all 200 users for anyone to use those features that is $45,600 a year.
Now if it were possible for example to have a mixed licensing model; buy 10 Premium licenses for the users who need it and 190 Starter licenses for everyone else then that is $11,400 a year. That is a difference of $34,200 a year so it may be the difference between being able to hire another employee or not.
As stated, they can run separate instances, or spend 5 minutes contacting GitLab to negotiate.
200 employees is not small, that is considered a medium sized business. Millions of companies around the world never get past single-digits. With payroll extending into 10s of millions, $35k sounds rather trivial if it really is powering the company hub and the value that brings.
"200 employees is not small, that is considered a medium sized business"
I'm just curious what your basis for that is? To go with some kind of standardization on the term "small business" I would say the safest definition (within the US) would be to follow the SBA guidelines that define a small business. Depending on the industry a small business is defined by the SBA as a maximum of anywhere from 100 to 1500 employees. So it is not cut and dry that this is or is not a small business; industry and also potentially revenues in millions of dollars would need to be known to determine absolutely if it by definition a small business.
"I fear GitLab will fence off future functionality with even more tiers at random" our goal when introducing the new tiers was to put new functionality in then, not to move existing functionality away. In the future we might move functionality between tiers to keep the grouping logical but we won't do that lightly let alone randomly.
New functionaly is made iteratively starting with the minimal viable change. But they should always function and additions should land in the same tier. If we missed the mark somewhere please let us know.
I think the problem for us is that not all users are equal.
To embrace devops/gitops I really want most of the company involved through our GitLab instance, but only a subset of the license seats would actually use the kubernetes features for instance.
Most of our users would not venture beyond the features of the community edition (except for the LDAP auth we use).
So while we enjoy GitLab and do some software development, we are not a software company. I think this is becoming all the more common.
I recognize this. Not every company with developers is a software develop company. Those 190 others that dont use the advanced features, what subset of functionality do they require?
Primarily logging in, filing issues and using the wikis. A few might be able to request changes by submitting a PR instead of issues.
We do need to have authentication and cannot simply mark all repos public either.
The 10 power users want to take advantage of the kubernetes and devops features - especially since we are a small team covering a lot if ground.
On the "Open Source" issue, they seem to be trying to keep a careful balance. They're doing the ideal thing and fully freeing a decent amount of stuff. But they have VC investors, so they have to pay them off with an exit sometime. And that fact on its own is the compromising thing that means they won't likely do just-enough to keep their own sustainable funding. They need to get profit not just pay all the team well.
I'd like to see them at least become a Benefit Corp or similar to trust more that they won't end up selling out in some worse way that goes against the Open Source values they largely but incompletely embrace.
> I feel that they're very earnestly working to make the product better, bit by bit, day by day, and will one day surpass GitHub.
It's assuming github doesn't do that as well.
As a paying github using, I can see they are improving my life a little bit more everyday.
Like, lately, they introduced automatic security checks on python project dependencies.
I'm glad gitlab exist. I feel safer, knowing I have a place to migrate to if MS screw up with gitup and no commercial replacement lives up to the task.
Just curious, what specifically you mean by "surpass Github"? I mean this with no snarky intention. I'm just wondering what tasks Gitlab doesn't perform as well as Github for you; unless you were referring to the social awareness that Github has.
GitLab is pretty impressive with the rate of features that gets shipped, but it does come at the cost of things not always been stable even though I think it's pretty impressive how stable it is considering the volume of changes being shipped.
That said I found a way to have it stable is to run GitLab on your own systems using their omnibus installer, and then upgrade around the 20th of each month before the next big release so you upgrade to a version with most of the patch versions instead of the latest bigger version.
Revenue? GitHub has been operating at a loss right up to the moment that MS bought them for over a thousand times what they had to start making annually to not run a loss.
No, I'm not. Both are business health indicators, with revenue being the more important one, since you can be sustainable without being profitable. However, when you operation on a _loss_ your revenue is not sufficient, and Github has been running a loss right up to when MS bought them.
While having no profit does not imply you have insufficient revenue, running your business at a loss absolutely does. So: wanting another company in the same space to have the same kind of revenue profile is extremely questionable; you want them to have a sustainable revenue model, and the ideally on top of that, be profitable.
I moved over a project from GitHub to GitLab recently - I wanted to try a competitor, and I wanted to take advantage of their CI/CD feature.
I've actually been very impressed. The UI is laggy at times, and they haven't mastered the UX/information architecture like Github has, but they have added a lot of other valuable features.
Sometimes the valedictorian or most popular kid is always going to be better, no matter how much "hard work" in involved. Sometimes it's friends (marketing) and good looks (good design) that get you there.
These are things that GitLab is losing on. Damn thing is so ugly from a layman's perspective, it's probably hard to figure out if they are technically superior because no one uses it.
Private repo offerings are a tough competitive space, too. Everyone knows who Atlassian is.
Thanks for sharing this! The transparancy of GitLab is amazing for people like me who have no experience nor contacts in larger companies. The handbook is a joy to read!
I discovered GitLab when researching CI/CD workflow and thanks to your tight integrations had one setup within 24 hours.
Add to that the fact that 3 fellow Dutchies are the founders which inspired me to apply our own Security startup to YC19 and all I can say is: keep it up! You’re an inspiration :-)
The only bit of constructive criticism I have is that the Epic ‘feature’ being locked behind the highest subscription is a bit weird. I’d love to be able to create an epic for our first release version but can’t. If that feature could drop a tier, that would be... epic ;-)
What I'm missing is a different security model than the current `If an endpoint can push to gitlab, it is trusted and can execute code server-side`.
There is no (current) way to enforce a 2fa step in order to push to a repository, and while you can technically implement them, that doesn't mean much, due to the nature of `git push`.
What I want is a 2fa-enabled review boundary between "commit" and "execute", which currently isn't possible.
Protected branches can be unprotected without an auth step.
There's nothing on the server-side that signs `gitlab` generated merge-commits in the commit graph, so no way to distinguish them from other merges.
There's no security boundary to change the deployment details, or to modify the deployment pipeline to run from a different branch.
Basically, I'd want a way to ensure that there's an authenticated hand-off between "commit" and "deploy" steps on the chain.
Also, it'd be nifty if one could get gitlab to maintain a version number, increasing with every merge request merged, in order to get smooth tagged builds when MR's are used.
GitLab is a great service, not perfect but a good alternative to GitHub. I actually use Gitter far more than GitLab these days, GitLab acquired them a while back and I'm really disappointed to see it reduced to stagnation. The product hasn't improved at all since the acquisition, you can argue that it's "finished" and it is 90% there. There are rough edges that make it more annoying to use than Telegram, Slack, etc. The primary one being how they handle notifications on their Android app. It's annoying me every day that this has been effectively broken for years now.
Maybe some of the GitLab guys that hang around here can answer my concerns. Why are you guys neglecting Gitter?
One of the goals this quarter is to open source the Android/iOS apps, https://about.gitlab.com/okrs/2018-q3/ but there isn't a plan to keep improving them with new features. We are focusing on fixing the rough edges of the webapp and are happy to review your Merge Requests for any project.
That does indeed look like the issue I am experiencing. We've got a setup where our IRC channel is relayed to/from Gitter so I am usually on IRC instead of Gitter web. But this means that I need to manually discard mentions on Gitter web, otherwise I get a notification that is super long containing all my mentions. This means I cannot easily see what was said to me at the time of the notification.
A few years ago I really wanted to join GitHub as a software engineer. I was living in San Francisco and visited their office for some events, and I thought it would be an awesome place to work. I tried reaching out to a few people who worked there, but I could never get my foot in the door.
There were a lot of things I would have loved to build at GitHub, and they were all the same things that GitLab is doing now. I felt that there was so much potential to build things like CI, DevOps, and eventually a PaaS to compete with Heroku. I really think they should have acquired something like TravisCI or CircleCI and made that part of their platform, but it seems like they haven't really done anything significant in the last 5 years.
I'm a very happy user of GitLab now, and the product is awesome. But I don't think I would ever join the company. First of all, they don't pay competitive salaries for remote workers (cost-of-living adjustments). I also don't think they have a very good company culture, and to be honest, it still feels a bit sketchy that they ripped off GitHub and undercut them on pricing. But I'm sure I'll get over that eventually.
> It still feels a bit sketchy that they ripped off GitHub and undercut them on pricing. But I'm sure I'll get over that eventually.
Isn't that a vital part of market economies functioning. I don't entirely agree with free markets, but IF we have this kind of system then this kind is absolutely crucial.
I could not agree more with you that Github should have acquired a CI tool and worked on PaaS. Big missed opportunity for them and for their customers. I do expect Azure to become well supported on Github at some point, but Github had the opportunity to build something truly awesome and cloud vendor neutral. Very sad and weird they sold out, but it is theoretically possible Microsoft will do a better job moving Github forward.
Gitlab seems fine but it's just not as smooth / good looking as Github. Github is one of the best websites ever made in my opinion. I do like the fact Gitlab is more aggressive in adding CI features. Maybe I'll check them out...
Hey Nathan, I'm very curious about what you mean by "I also don't think they have a very good company culture".
I've been at GitLab since early 2015 (employee #10), and the culture is one of the major reasons why I joined, and stayed. :)
Would you mind elaborating?
For anyone else reading along, our Handbook (https://about.gitlab.com/handbook/) covers our culture (and every other aspect of working here) very well.
Hi there, glad to hear that you enjoy working at GitLab!
My impression was just based on some things I've been hearing about compensation, and a couple of negative comments and articles.
I think the best way to explain it is that GitLab sounds like a more traditional place to work. Similar to companies in the UK, Europe, Canada, Australia, and New Zealand. It's very unlikely that I would accept a job in one of these countries for the same reasons. Software engineers are typically not paid very well and are treated more like "code monkeys" who report to their managers and don't have any self-direction.
I guess I've just been spoiled by Silicon Valley, so the rest of the world doesn't feel very competitive compared to some of these SV startups.
I also feel like you're painting companies outside Silicon Valley with a pretty broad brush.
There's nothing about a healthy engineering culture that makes it unique to Silicon Valley, and there are many, many companies in those regions you mention that would take significant issue with that generalization.
If you want to optimize for annual salary, Silicon Valley is probably the place to be, but if you want to optimize for happiness (however a developer may define that for themselves), it's just one of many potential places to go, and if you want to optimize for work/life balance, it's probably not even in the top 10.
Sorry yes, companies can have a healthy engineering culture anywhere in the world, even if they pay the local market rate.
It’s just my personal experience interviewing at a number of startups/companies in these countries, and from friends who work at them. I would really love to move to Toronto, but the salaries are just way too low. Hopefully I can find another way to move there.
I'll leave the subject of compensation to the threads dedicated to it, but 'software engineers [...] are treated more like "code monkeys" who report to their managers and don't have any self-direction' absolutely does not apply to GitLab. Have you had a chance to check out our values (https://about.gitlab.com/handbook/values/) or our section on making decisions (https://about.gitlab.com/handbook/leadership/#making-decisio...)? What you're describing is pretty much the opposite of how we actually work :)
Hello DouweM, I've been considering joining gitlab for a while! I have a couple of questions about how you guys make remote work run smoothly, can I reach out to you?
>a bit sketchy that they ripped off GitHub and undercut them on pricing.
Can you elaborate on that?
Because ripping off and competing against original developers is what open source specially allows. That's one of it's benefits of open source. If someone can improve and and do cheaper, they should do it. I don't see any moral implications.
Software business service business not manufacturing business. (at least 99%). If you are against ripping off, maybe put more restrictive license or go closed source. Then you can leverage accumulating IP from work you do.
GitHub isn't open-source, so while you're correct about what open source licenses allow, that's not really tangible to the complaint that they ripped off GitHub.
I see. It seems you are right. Github is closed source, Gitlab CE is open source, Gitlab EE is closed source.
Reframing the question:
Isn't ripping of and competing with the implementation of an idea is just normal business. Or is there something like gentleman rule where you should not copy business ideas as fast as you can?
The initial GitLab UI felt a lot like a direct copy from GitHub.
I'd consider "normal business" to be some combination of creating new benefits for your service that your competitors don't have and replicating the kinds of benefits they add, hopefully doing them better.
As an example: both GitHub and GitLab have recently launched features in the "security monitoring for your projects" space, but they're both independently good features. Had GitLab launched the feature and then GitHub just copied all the css/js and stood up a clone of it, I'd consider that to be highly questionable.
Could you elaborate about the salaries for remote workers? I'm a frontend developer in southern Europe and I'd love to work for Gitlab because I love the product.
The QoL adjustments seem less granular than needed in the UK. "Everywhere else in England" covers a wide range of living conditions/costs. Areas like York & Harrogate are far more expensive to live in than the not-all-that-far-away Grimsby & Hull, to give one of many possible examples. If you are going to change what you pay geographically, I would suggest you need more local variance to do it properly.
Several countries are on hiring stop currently, mainly those that you have listed. This is due to administrative reasons, as people from those countries work as contractors, as we have no entities there. In Europe we currently have an entity in NL, BE, UK and DE. Furthermore we have an Indian, Chinese and of course US entity.
I think leipert is saying that people from those countries only work as contractors, and that involves specific administrative problems/burden which Gitlab can't cope with at the moment.
@aissen this is a temporary roadblock for us. As we scale, we are working on a better payroll solution in these locations. We are hoping to remove some of these roadblocks in future entirely. We have already moved a few successfully, like Australia and Canada.
I think it comes down to their policy of adjusting to provide the same quality of life, which I disagree with for remote companies. Their London salaries are fine, but one of the main reasons for me working remotely would be to increase my quality of life by living more remotely but still earning a London-like salary. Otherwise you've moved away from many conveniences, will likely have to pay much more for travel, but will still have to live with the quality of housing you could afford in the city.
Yeah this is very much discouraging you from living in a low cost of living area. After all, compensation should be about the value of the work you're doing. Not the value of the money to you. If we experience high deflation, should my salary go down?!
They once had a online calculator where you put in your location (basically only SF, non-SF US, and outside US) and position but apparently they switched to another model that includes employee performance and other factors.
I don't have any first-hand experience, and I'm sure there are exceptions. I've heard that GitLab will pay around $80k for a remote software engineer in a country with a low cost-of-living. That engineer could be earning $150k-$250k at a different company (e.g. Basecamp, GitHub, etc.)
I realize that $80k is a lot of money for Europe/UK/Asia/South America/rest of the US. But if you're a top engineer, you could double or triple your income by working for a different company (or as a consultant.)
I should mention that I don't have any problem with GitLab's compensation, and I think it's actually pretty fair. But fair doesn't really matter. A top engineer will just go to the company that pays more. I'm sure GitLab has a lot of great engineers, but just based on their compensation, I'm pretty sure it's not one of the best engineering teams in the world.
I don't know how they came to that calculator. But it seems that someone in Ethiopia would earn $20k more than someone in the Netherlands (outside of Amsterdam)
There are other advantages of being a cheaper remote worker, cheaper than 'market rates'. One is that since you are cheaper, there may be less pressure on you to deliver at a certain speed. Which, in turn actually may allow you to work more carefully and over time deliver your work at a higher level of quality. This combination can lead to you being happier in the job and wanting to remain at it for longer and since you are cheaper your position is less at risk when your employer is going through restructuring.
That might be true sometimes, but I've also heard about some cases that are the exact opposite [1]. There are some software engineers making high six figures (e.g. > $600k including RSUs and bonuses), and the company respects them a lot more and values their output. These engineers aren't frantically cranking out code or working 12 hour days all the time. They're often doing very important work and have to be very careful.
And I've also heard about cases where lower pay means worse employers, higher expectations, and higher levels of stress, because the company doensn't value or respect the employee as much.
This is really interesting. I live in Czech away from Prague and made a joke on local dev meetup that "I will not work for 22k". Answer was "everyone here wishes to work for 22k".
I don't think anyone I know here makes anything close to 100k even in Prague.
I should investigate this bit more to get closer to SF salaries if possible.
22k USD is far too low for a good developer. I’ve met a few developers from Eastern European countries that charge $100+ USD per hour.
You will always be able to find work at ~$70 per hour if you join TopTal. It should be easy to book projects for 30 hours per week and earn $100k USD per year. (Or you can work 6 hours per week to make $22k, if that’s all you need.)
That’s still on the low end for web/mobile dev. Top developers will charge 2x or 3x that amount (but you won’t find that work on Toptal.)
Full-time salaries will be lower than contract work, but it shouldn’t be difficult to find a remote web/mobile development job that pays $80k. (And that’s still very low for a good developer.)
A top Engineer will go to a company which aligns with his personal and professional goals. With your example, no one would have created a startup and simply working for someone who pays more.
No, I'm talking about as a remote employee living in any country. It's true that most high paying software jobs require relocation, but there's some that don't.
I will address the concerns around compensation. I appreciate the comments and understand that working remotely is not valued the same by all and has its own unique challenges. However, the challenge of location influenced pay is not unique to remote companies. I worked at large, traditional companies for years who had different pay for team members in the Silicon Valley, and those in other offices. Of course, with team members in so many different locations, many without meaningful local compensation data, the challenge grows. We don't have it perfect at GitLab yet, but we continue to try to make it better. It's a complex topic, but I will add some thoughts to the discussion.
We do look at rent index as a factor within Compensation. It is not the only factor but it would be unfair not to take it into consideration. Afterall, there are not many locations in the world where $117,000 is considered low-income. (https://sanfrancisco.cbslocal.com/2018/06/26/hud-117000-low-...). I'm thrilled that we can provide team members with a meaningful career without forcing them to move to a high-cost area. I have often seen cases at other companies where we make a great offer to an out-of-area candidate. They think the compensation is amazing and jump on a plane to start their new job in the Silicon Valley only then realizing that they can't afford a home here and may need to get a roommate to pay the rent unless they live far enough away and endure a long commute. The big salary suddenly looks a lot smaller after seeing the cost of living.
However, it is not the only factor we look at and we are continuing to improve the model we have for compensation. We also set a minimum rent index so those very low cost areas are actually paid above market. We do this to ensure that the gaps are not too large. We also pay the market data for a region widely. If you're within a 90 min. commute of San Francisco, for example, you would still make the SF pay.
Where you see region broadly represented (like the example of "the rest of the UK), that is because the rent index across the region was less or equal to the minimum rent index set. When you see a location that you perceive to be a lower rent index, getting higher compensation, that could be because we also add a contractor factor in those locations where we are hiring as contractors, knowing that there are often additional expenses to cover as a contractor.
With that being said, we are constantly trying to get meaningful compensation data in various locations so we can rely more on the market data and less on the rent index. It is my intention that if we see that the market is changing with more remote companies, we will also adjust our benchmarks to be an accurate reflection of the market. I know that there will always be a company out there willing to pay more and that we will lose some talent because of that. I also know and have seen, that GitLab is able to attract and retain some of the best engineers I've seen (and I've seen some great engineers!) due to its product, culture, and all remote work life.
> If you're within a 90 min. commute of San Francisco, for example, you would still make the SF pay.
Is that anywhere near the calculation information? I didn't see it. This is very helpful if you are looking for people in the DC area, particularly Northern VA as you have the Rent Index as:
Washington DC - 0.780
Virginia - 0.488
Northern VA, even a bit further than your 90 min number, can still be on par with DC pricing.
One of my major pain points with GitLab was its API. The lack of coherent API design ultimately made me lose hope in the product. For example I think it still lacks an ability to create threads on MRs. Until recently it wasn't possible to approve any MRs either, for 10+ versions of the product and 4+ versions of the api, but adding emoji was... The disjointed API made it nearly impossible to create quality tooling on top of GitLab, ultimately forcing us away from the product. It left a poor taste in my mouth, with a sense that there was no rhyme or reason to the direction of the platform, unfortunately.
If you use the GitLab convention of naming your branches from the issue (like it does when creating a MR straight from the issue), the MR branches will be named /^\d+-/ so you can add a only: clause to .gitlab-ci.yml steps matching that.
Probably a different issue, but one of my greatest gripes with CI is that I can't limit steps to (for example) master branch AND having a tag. It seems such a basic requirement, but is unfortunately not possible via .gitlab-ci.yml.
I find GitLab's upgrade tiers oddly chosen and quirkily implemented:
* The features don't seem to follow the costs of running them. I.e., they're economically inefficient. This makes GitLab less competitive. E.g., Some features held back for higher paying customers feel arbitrary in the sense that it's a marketing decision, not an ops/cost decision.
GitLab should, frankly, focus on performance/ux/bug-fix releases every other release. And probably for the next 2-3 releases to get some of the warts under control.
This constant push for project management features, frankly, is at the expense of the core product. I'd rather use a combination of GitHub and JIRA over Gitlab.
I have a feeling that many people who constantly ask for "fixes" are the kind of people who want to "fix them all", by rewriting without understanding that it is a never ending cycle.
Don't pay attention to them. Just do your thing.
Gitlab has provided the much needed competition with real impact (consider Github boards, for example) and you have a company that can pay many people a living. That is more than good enough.
Thank you very much for the encouragement, I appreciate it after significant commenting today while flying from Mexico to San Francisco. You can rest assured we'll keep working on our vision https://about.gitlab.com/direction/product-vision/
The people that ask for fixes care about GitLab and are worth listening to. There is an almost infinite demand for new features and we can't make them all (even with more then 2000 open source contributors). But I've found that Hacker News readers have great insights and we'll keep listening and adjusting were we missed the mark.
I just wanted to add that I have been absolutely loving gitlab. Signed up in 2014 and use it pretty much daily.
One of the biggest problems I had was the speed of the web ui but since the great github migration the speed increased massively and has stayed snappy.
Contributing code to GitLab has also been my favorite experience with open source as not only were my changes looked at, Gitlab developers actually helped me get things working and write better code.
There is a lot more work to do and we'll keep shipping performance improvements in code and to our infrastructure. The tentative date for our migration to GCP is next weekend.
I'm so glad to hear that contributing code to GitLab was a favorite experience! Kudos to our merge request coaches who try to get every merge request over the finish line with a high quality.
I just want to let you know that I code just for hobby, super simplistic projects like notes app, javascrtipt utilities, personal blog on Jekyll etc, gitlab @ davchana, I absolutely love Gitlab, and have been using it since almost two years.
Before it I always had to find a free hosting, with lot of shaddy banner ads or unreliable systems. Gitlab.com free edition has everything I wish for, & occassionally I read & wander in gitlab.com issues repo just to see & be amazed on new improvements being made. Being a completely remote company is a cherry on top.. Great Work!!
They can also measure it live in the website, the median response time of API calls and so on.
Github has said this:
"We’re quite obsessed with performance. We want to make sure the site is always performant and continually fast. For a Rails app, github.com is a really, really quick site and we have a motto that “It’s not shipped until it’s fast.”"
https://medium.com/s-c-a-l-e/github-scaling-on-ruby-with-a-n...
They can create a performance measurement team, assign tickets based on what they find and prioritize them as part of ticket management. If something is too slow, then maybe it's time to refactor the underlying architecture or subsystem thats making things slow.
When glaring security issues sit open for a year, you need to understand GitLab is a problem for anyone who has regular security audits.
I am not asking for 100% redirection of resources to fix all the issues. I am suggesting they reprioritize resource allocation to lean more towards fixing issues that exist instead of new feature implementation.
It's not obvious to me that that's a glaring security issue. If the password were encrypted, then Gitlab would need to be able to decrypt it, so all you're gaining is a bit of security through obscurity. Which doesn't accomplish anything when it's a publicly documented feature of an open source project.
I'd agree that, depending on usage model, this isn't a major issue, in that if you symmetrically encrypt a password, you still need to store the key somewhere to do the decryption.
That said it is possible to improve the security of this kind of model, although there is a trade-off in availability. What can be done is that the decryption key (or a passphrase controlling access to it) is stored offline and manually input at application launch.
The downside is that if the application restarts it needs human intervention to be operational. the upside is that you reduce (but not eliminate) the risks of the credentials being compromised from that system.
They have both SaaS and self-hosting options which cost considerable amount of cash ($99/mo per user for the most expensive option) for any large scale deployment. They're earning plenty and they need to fix what is valuable to their customers.
It is blocking people from converting to paying customers because as soon as we see an issue like that we know it isn't viable because we'll get denied.
If you have not done so already please ask our support team if they have an alternative solution. I've heard of people dynamically loading secrets but I'm not sure it addresses your use case.
Merge request page load times. Sometimes it can take like 5s for a merge request page to load (and then another 5s for the comments), and that's noticeably more frustrating than github's snappy UI. 5s isn't world ending but it is obviously slow and frustrating.
Treat server responses taking over 100ms as failures and keep fixing that.
There isn't 1 thing that's wrong, it's the entire UI, every operation that feels like it has a lag. Using GitLab is like using an app via remote desktop. It's tiring.
I am not here to push any specific ticket. I just think GitLab should move in the direction of redirecting more resources to fixing the warts as a general policy decision.
Ultimately, I am not your customer and haven't been for a couple years so it is up to you.
I don't know about the performance and bugfix issues, but based on my experience with gitlab.com, I don't think it has a good UX design.
You see, there are many many best practices in the UX world, just like those in the programming world. And seems to me, GitLab is not following many of them.
For example, the width of the content area.
I've once read an article that trying to dig into that topic, and one opinion that article has brought up was that users eye should not move too far up and down and more importantly left to right. I deeply agreed with this because I found myself feel very tired after reading a width page.
The solution is of course to limit how width the content area is, according to many factors (front size for example).
Now if you look at the user's home (project list) page on the GitLab, you will found that the page and the list (which is the main content) has been designed to fill 100% width of the view point.
On the left side of the list, is the name and description of my projects, and on the right side is the counters + update date.
The information on both left and right side are significant, so I may have to scan it from time to time, and it's exhausting.
If you're thinking, "Oh it's just the user's home page, no big deal". No No No, the search result page is the same deal, same design language.
Now, if you take look GitHub, you will found that they're not only limited the width of their page, they've also limited the width of the project list by adding a sidebar on the page. Which makes me 10 times more comfortable when using it.
Also, since we're talking about project list already, let me also remind you that the front is also very important.
Currently on the project page, the project name text is bold'ed, and underneath it is the description text. Problem is that the size of both text is the same, which makes them muddled together when doing a quick eye scan. GitHub on the other hand, use white space, front size and color to differentiates those elements which makes their list far better.
I did a little re-design to the project list to clarify what I've meant.
And these just two examples, there are many of them. So please GitLab, design your web interface better. I'm currently mainly use your product now and I don't want to have many struggle with it :)
Thanks so much for the feedback, the UX team here at GitLab is always looking for ways to improve the user experience. It looks like someone else in this thread mentioned that you can choose between a fluid and fixed layout depending upon your preference. Some prefer a fixed width and others hate wasted screen space. We try our best to accommodate everyone.
Given that, we agree that this can be improved. We have an issue here discussing page-width, https://gitlab.com/gitlab-org/design.gitlab.com/issues/47. As you can see, in many cases we have decided that we should reduce the width in order to improve readability. I will add a link to your comment in the issue as further data on our user's preferences.
Also, we opened an issue with your suggestions for the project list page. Feel free to jump in and add any more thoughts you have there, feedback is always welcome. Here is a link: https://gitlab.com/gitlab-org/gitlab-ce/issues/49504
Thanks for your feedback around content width. Making GitLab accessible on all screen sizes is important to us given that there are many users out there using HD (720p) screens primarily. Our design indeed has fixed width portrait container enclosing the page body (with maximum size being 1200px) so here's how it looks on a large monitor at 100% zoom: https://i.imgur.com/lTqL6X8.png
Hence if the browser viewport width goes below 1200px, page body ends up taking full width. Although this screen resolution being still widely used, I've opened an issue to discuss this further here https://gitlab.com/gitlab-org/gitlab-ce/issues/49488
So, hi kushalpandya, jmiserez and svesselov (For some reason I cannot reply your comment)
Looks like you guys didn't understand what I just said: The problem is the UX design is NOT very good. I think you guys should re-think about how user will interact with your interface.
For example (since I discovered the 'fluid' setting): Even if a user have a super wide monitor, when the user turn on the fluid setting and maximized the browser, should they saw an interface like this: https://screenshotscdn.firefoxusercontent.com/images/324e117... ?
Also, from my point of view, 1200px is still too wide for that list. If you take look the version that I've modified, you will notice it's only about 400px wide, and with that width, I can scan every results on the page without moving my eyes too much.
The magic thing is, with 400px, YOU can also scan every results on the page without moving YOUR eyes too much, even your monitor is wider than mine. And THIS, my friend, is the so called compatibility. The goal here, is to provide the same level of user experience -- GOOD user experience, NOT to fill the whole width so the page look like the same in every resolutions.
Again, the key point here is NOT about just the width of the page, it's not a problem between 400px and 1200px and 100%, it's about how you guys think how users will feel about the UI -- Will user feel tired when using it? Can the UI effectively helping user to get what they want? etc.
If you have no idea, go checkout some list designs on https://dribbble.com/ (By the way, dribbble.com itself is very well designed, go learn from it)
Don't worry though, I'll keep using your product and patiently waiting for improvement :)
There already is an option to set this, at /profile/preferences:
Layout width
> GitLab can be set up to use different widths depending on your liking. Choose between the fixed (max. 1200px) and the fluid (100%) application layout.
I agree. Our team test drove gitlab earlier this year (as in, moving all repos over and using it for a month). We were hoping to consolidate a suite of products into one unified dev hub. )sadly, we found the general clunkyness and slowness a deal breaker for us. Lots of clicks to perform actions, each click requiring a short wait. Many features that applies to single projects don't apply to groups. We felt the core features were still very unfinished, especially when working with multiple repos. We looked at the roadmap and decided to move on.
Gitea has been very close to core Github Features IMO and Gogs (the original fork) has some neat other features separate from Github.
There is also Bitbucket which does integrate neatly into JIRA in my experience.
There is a lot of choice, Gitlab is great if you need a "everything in one box" solution for every problem or demand you might encounter during development.
Other Git-Webapps solve other problems or problem spaces.
None of these was out in the wild. We take pride in requesting CVE numbers to aid our users in remediation. We think that identifying and promptly fixing vulnerabilities is key to security.
Thank you for the feedback. One of our core values is transparency. Very few companies are as transparent as GitLab. We take our users' data security extremely seriously. Since total CVE count is only one metric to measure the security maturity of an organization, allow me to provide you with other metrics that may help you understand what we're doing on our users' behalf.
Over the last 7 months, we have been focusing on mitigating security vulnerabilities that highly impact our users, where at least 25% of our users are affected. Since then, we've been able to bring the mean-time-to-mitigation (MTTM) for new, high-impact vulnerabilities to less than 30 days, which is below industry average for security vulnerability mitigations. However, we are not done securing GitLab of course, and are also working on maturing the security vulnerability mitigation process. Here are some goals that we've achieved over the last 6 months:
1. Developed and put into place two separate security release processes - a monthly non-critical security release process, focusing on reducing security debt, and a critical release process (on demand, as needed) when there is a new vulnerability discovered that impacts a significant number of users. https://gitlab.com/gitlab-org/release/docs/blob/master/gener...
2. GitLab continues to work with security researchers from the HackerOne program to recognize and reward bounties for their contributions. We have plans in place to expand on the existing HackerOne program by the end of 2018. The HackerOne program has been effective in assisting us with scaling our work with security vulnerability mitigations, because we have a small security team at GitLab, currently. https://hackerone.com/gitlab
3. Our 2018 (and beyond) Security Vision and Hiring Plan includes growing GitLab's internal security team further, and we will be making security research hires, in order to accelerate the security vulnerability mitigation efforts that we are working on maturing. https://about.gitlab.com/handbook/engineering/security/
If you have any further questions, please feel free to contact us directly at security@gitlab.com
EU GDPR compatibility would be a cool thing - I am sure that people have been asking for that "long time enough" ago.
Also now that this software has left prototype status for long enough time - why are you still using ruby?
Ruby is much too slow and bloated for production - there are only a few companies out there that missed the right time to jump from the ruby-prototype-bloat and have enough money to burn to just stick with it, but for a project like gitlab this is a huge problem. Judging from the roadmap there seem to be many bored developers with no good ideas about what to do next, so maybe unbloating could be a good direction?
There must be at least one person in that team with a feeling for architectural brilliance?
