GitLab acquires Gitter, will open-source the code | Hacker News Reader

GitLab acquires Gitter, will open-source the code

venturebeat.com

Somewhat off topic, but I was once very interested in working for GitLab. According to their compensation calculator, though, I'd be making less than half what I make now (also working remotely). They ding me for living in a comparatively low cost area.

I'm surprised they are able to attract talent to achieve what they have done so far. It makes me worry somewhat about my future prospects in an increasingly globalized talent pool.

I had an interesting interview with one of their recruiters in which within the first 5 minutes I was asked to agree to compensation below what their calculator (which was a part of the job posting) indicated was their pay scale for my location and that position. I was told my resume wouldn't be passed to an engineering lead until I had (in writing) agreed to the lower salary range. Liiike why even...

Edit: Didn't intend to make a scene or put anyone on blast here. Just thought the calculator was a little silly. Thanks for the responses gitlab staff.

Hi Matt, I am the recruiter at GL, I've reviewed your case, and I wanted to follow up personally. I'd like to address your concern and explain our process. Since the time of your interview, we have changed the process of discussing compensation within the first 15 minutes of a conversation to the end of a phone call. We understand it's uncomfortable and sometimes awkward to talk pay when you've just met someone. Hopefully this improvement will prevent misunderstandings in the future. Secondly, we never would ask you to agree to something that is below the calculators suggestion, however your expectations based on Level, Experience, or Location may differ from the recruiter or hiring managers' assessments. We do talk about compensation early and upfront with every candidate, because we use it to guide our offers. I'm very sorry that your experience was less than ideal, and I apologize for any miscommunication that happened as a result! We are always striving to improve our process so any more details/feedback you'd like to share about your specific situation would be appreciated so our PeopleOps team can ensure this mistake isn't repeated.

I'm not sure this really addresses the issue? Personally I actually would appreciate the upfront salary discussion as it could potentially save a lot of wasted time.

It seems to me the issue is more there was a difference in expectations between what the candidate perceived was their situation and what the recruiter believed. This is of course not uncommon, however from the sounds of it the candidate was not given an opportunity to reason their position. It could be that GitLab is simply not offering competitive renumeration based on what the candidate believed they could achieve in the same market. It could also be that GitLab undervalued the particular skill sets of the candidate. Of course the opposite may also be true.

Clearly there were differences in opinions, however by asking the candidate to sign an agreement to a specific salary based on no discussion is only going to cause issues for everyone. Either the candidate agrees, goes through the interview and decides "it's not worth it, and now there's no flexibility", they disagree and a potentially good candidate is immediately lost or they agree, take the job and feel like they are not being fairly compensated, which can have all sorts of consequences.

This is usually why the discussion happens at the end of an interview process, after the candidate has had the opportunity to demonstrate their skills and experience. Then if there is still a perception of a mismatch this can be reasoned with respect to what has previously been discussed.

> Secondly, we never would ask you to agree to something that is below the calculators suggestion, however your expectations based on Level, Experience, or Location may differ from the recruiter or hiring managers' assessments.

The candidate has clearly stated they were offered less than what the calculator suggested. It was your recruiters opinion that they did not meet the parameters entered into the calculator, however clearly the candidate believed that they did. In this case the recruiter must judge the cause of the disparity through discussion with the candidate and set expectations in terms of the results of this discussion. Again, simply telling a candidate "this is our opinion, you must agree to it" is not going to benefit anyone.

Just to be clear: the calculator takes Level, Experience, and Location into account. If the candidate and recruiter arrive at different numbers while typing into the calculator, then there is apparently miscommunication about one or more of those factors. But being asked to agree to something that is lower than what comes out of the calculator is just not something we do at GitLab. If it came across that way then something got lost in the communication.

Matt, since I deal with the comp calculator every now and then, if you'd like to provide more specifics of your situation, can you please email me on ernst@gitlab.com ?

I want to second this, we should never ask people to agree to something below the calculator. But of course the applicant and the interviewer might disagree about the appropriate title and experience factor for a candidate.

We have to decline 200 applicants a week at GitLab. We realize that interviewing is very stressful. We send a survey afterwards to get a net promoter score. The current average is 4.2 out of 5 for people that did not sign with us. Most applicants don't fill out the survey, we're not sure how that influences results.

You are saying most people don't do the survey and I think also most would think it matters how they rate the company for their own future prospects. 4.2 is actually pretty low considering this.

If you're actually calculating an NPS, the non-respondents should be considered detractors for a more accurate rating. Happy to talk more if you're interested (have done a lot of this as a user researcher).

Your calculator would probably need to be updated? I just tried it out and the difference between the locations Mumbai and Bangalore, the latter is close to 2.5x less than Mumbai (0.08 vs 0.20).

Your data-source for this is very clearly wrong.. any income/cost-of-living report for India will show that the cost of living is the same for these 2 cities.

Just FYI.

Holy crap, you've just done your company - or if you are an external recruiter, your client - a huge disservice by posting this reply. You've done nothing to assuage future candidates' concerns. You've merely confirmed that your compensation offers, and likely the entire hiring process, is driven by undesirable corporate metrics. This makes GitLab sounds seem like a company that only knows how to regurgitate HR 101 tactics. No thanks.

GitLab, diversify/improve your recruitment strategy. Why you only have "the recruiter", aka a single person heading your recruitment, rather than a group of competent personnel, is concerning. Your public image is of a medium-sized company which is already established, not a tiny startup outfit wherein all hires rely on a sole (apparently inadequate) person vetting each potential employee.

Since the first part of your comment is addressed to Sasha I'll let her reply to it, but to address the second part:

There are multiple people involved in the hiring process here at GitLab, specifically several people who handle phone screens and resumes. The responsibility of vetting doesn't rest solely on one person and is actually a pretty collaborative process in my experience. As an example, I was able to vet every single candidate's resume myself for roles I was involved in hiring for.

With all due respect, the parent to my comment - an apparent employee at GitLab - said "I am the recruiter at GL". "The recruiter", not "a recruiter" How else is that to be interpreted? With whom does the candidate discuss compensation? This one single recruiter, or the manager of the team with whom the employee would be placed? Why does GitLab have a "recruiter", rather than an "HR employee" or "hiring manager"? The term "recruiter" generally means an external non-employee who is financially compensated for each new hire brought on board. "HR" or "hiring managers" are company employees, given a flat salary irrespective of the number or quality of hires. Which do you have?

Either way, the parent comment is full of language that raises red flags to competent developers. Personally, my first thought is "oh hell no!". It's possible that their comment is not representative of the company's effective policies, but when one perceives this kind of reply as an official stance of the company's standpoint, it is difficult to retract.

> With all due respect, the parent to my comment - an apparent employee at GitLab - said "I am the recruiter at GL". "The recruiter", not "a recruiter" How else is that to be interpreted?

The way I understood it, at least, was 'the recruiter who handled the interview with "matthewvincent"'. Doesn't imply that there are, or are not, other recruiters at gitlab.

And if so, at least to me it seems honest for said recruiter to come forwards personally, instead of some feel-good mumbo-jumbo from the PR department.

Speaking from the candidate's perspective, I tend to avoid companies where money is discussed upfront. I want to be able to demonstrate the value I can add, and then have a negotiation about remuneration based on that value.

Bluntly, yes, it does put the candidate in a much stronger negotiating position but, hey, if you really want to hire good people then I'm afraid it's hard cheese. Conversely talking about remuneration upfront puts the candidate on the back foot because there's substantially less of a basis for convincing negotiation, so it really becomes about cutting costs for the company.

Unless you absolutely have to - sometimes you might not have any other option, and you shouldn't let pride blind you to that reality when you're facing it - I'd always recommend you avoid working for anyone where you've had to discuss money first.

The discussion of compensation is an extremely simple concept: you wait for the candidate to bring it up, and you discuss it only at that point in time. The interviewer should never bring up compensation before the candidate does, unless the potential employee is so shy that they are waiting for the employer to do so first. The moment an employer tries to pre-emptively bring up the topic of money before it makes sense, it shows their true colors - they care far too much about the money rather than the talent they are hiring.

It really is that basic. When the company cares more about the money than what the employee can bring, they've shown their company cares more about their internal politics then they do about their future success. Simple as that.

I don't understand. Why does Location matter? Does it matter if have 10 kids, or a lease on a Porsche, or 2 alimonies, or live in a McMansion, or my kid has cancer? Are those factors relevant? What makes Location special?

Because not all jobs are remote, so local jobs make up for a considerable amount of the job pool. For this reason, it's easier to get another job at your current location, so that's the competition the employer is faced with. If you live in an expensive area they're not paying you more to help you, they're paying you more to be more competitive with other companies in your area.

This line of argument is ridiculous. Are software companies pricing their computer programs based on location? Do folks in Ohio get to pay less than folks in New York?

What if you hire a great remote developer who lives in San-Jose, then she moves to Kentucky 6 months later, and their contribution is still the same. Why should their pay be adjusted?

GitLab has made a big deal about working remotely; I thought that's what they did. https://about.gitlab.com/2015/04/08/the-remote-manifesto/

> not all jobs are remote

GitLab claims to be "Remote Only": https://about.gitlab.com/jobs/

It does not matter how big you are on equal opportunities, work and compensation, when you can use your (cherrypicked) metrics to point your fingers at the market regarding salary discrimination, it would be irresponsible not to do so. Put it another way, if it was legal to discriminate against <underprivileged group> companies would be all over it.

PS it is not about GitLab, I like their service (even better than GitHub) and it is great they are transparent about compensations. IMO if they were to eliminate location from their calculator they could get the cream of a very big talent pool.

Especially for remote position when you can live wherever you can imagine.

This response is quite in the style of the Yelp/TripAdvisor response to a negative review. A thin veneer of consolation around an attempt to save face.

It looks like a perfectly reasonable response to me. What face is there to save? The fact that this was brought up "within the first five minutes" is far better than "after a plethora of interviews".

I had an interview with Parsely a few years back. Took over 3 weeks of back & forth before they rejected me with a reason that should have been squashed the first hour of the interview.

Agreed, the underlying process is still there.

> Since the time of your interview, we have changed the process of discussing compensation within the first 15 minutes of a conversation to the end of a phone call.

Cynical read: We discovered people are more likely to compromise on the salary if they've already committed their time to the interview.

Sorry this happened to you, I’ve brought it up with our PeopleOps team and we’re looking into it. Something like this absolutely shouldn’t be happening.

If you have any more information you can share, it'd be great if you could send it to peopleops at gitlab.com.

That all sounds kinda weird and sketchy, like the recruiter had a strange hidden motive.

be nice this is my first comment in Hacker News :D

Interestingly issues gets noticed here!, there was a posting yesterday about FB hiring issue.

Agreed. I actually had a good time interviewing with them. I'm not sure if it was normal, but it was essentially a 2 week email thread with a few GitLab devs asking me to explain various architectural parts of their system. I had fun diving into their system and getting to know it, including a few of their Go projects like workhorse, but I stopped the process after being told I couldn't ask for more than $60,000 for the position. Cool company, but the pay is just too low.

I feel a little bad contributing to such a very off-topic thread, but...

I'm familiar with how compensation is determined at Mozilla, and we use something similar but with different inputs. GitLab seems to be using rents as their determiner with New York as a baseline, which means way underpaying people in most markets. If they adjusted those numbers by the average percentage of income applied to rent (I believe a readily available number) then the numbers might be more reasonable.

At Mozilla we have a smaller number of regions, I think it's each nation plus three tiers in the U.S.: Bay Area/New York, Chicago/Seattle (not sure what all is in this bucket), and the rest of the country. Then we get data from some company that provides us with market rates for different given titles. We target salaries at the top 25th percentile (not a 25% bump like GitLab).

So given a title, people's compensation is figured as somewhere between 0.8x and 1.2x that market rate, depending where you are in your career. Each level bump is about 1.2x the previous level. So typically you might enter a Senior Engineer role at maybe 0.85x the compensation, and as you grow into the role you get to 1.0, and as you are approaching the next level you get into the 1.1s.

I think it's a pretty fair process. Especially internationally you can't relate salaries to each other well given different labor laws and taxes. Assuming our input numbers are right, our compensation is by definition competitive across markets – though in practice all sorts of weird things can happen over an employment history, like when a person moves.

All that said, it's clear we get a better value from people in cheaper markets, even while those people in practice also get a better value in terms of compensation. So far that hasn't been met with any adjustment in compensation, but instead some acknowledgement of the dynamic during recruitment.

I'm also turned off by remote companies that do the same. I work remote and moved to a very low-cost area. That doesn't mean I want a massive pay cut.

I guess if you are a remote friendly employer, you'd want to avoid both cutting yourself off from talent that happens to live in a high-cost area and getting completely overrun by applications from low-cost areas. And that could be reason enough even before applying the most obvious rule of acquisition, "don't pay more than you need".

But yeah, the outcome, remoters from Cheaptown effectively subsidizing their coworkers from Glitter City is incredibly ugly. One should at least hope that the decisionmaking processes at the employer do not completely isolate the one deciding on a hire from the cost difference, so that flyover guy could at least enjoy an increased chance of getting the job.

"From each according to his ability, to each according to his need" is a bad principle to run both countries and companies.

Why should we run countries like companies?

That was never said, we obviously shouldn't.

Finding something that applies to both (Or in this case something that works in neither, which makes it even clearer) is not the same as treating both as requiring the same solutions.

What is the advantage to the company in hiring remote workers then?

You want your cake and to eat it too?

Access to talent in locations where there aren't offices + access to talent who only work remotely.

So you seem to think a Bay Area company should pay it's remote workers Bay Area money. That'd be lovely, but we should explore what it infers. Let's assume that Gitlab will open a Mumbai office in a month's time. Would you expect the people there to get typical Mumbai wages, or typical Bay Area wages?

Assuming you don't think it's Bay Area wages (because that's crazy), why do you think going to an office in your location means you ought to be paid a lot less?

Some of us get Bay Area salary in hyderabad and bangalore. Why should we not get bay area salary when we deliver the same or better. I have no control over my cost of living but i do control what i will work for. No matter where.

Getting the best staff and not having to provide an office?

Not having to deal with operating a physical office (beyond the bare minimum necessary to e.g. be served with a subpoena)?

Using the GitLab calculator: If you are a developer in Medellín you are paid 3x less than if you are living in the Bay Area. If you are a customer in Medellín you pay the same as a customer in the Bay Area. In this case, "cost of living"[0] only applies to employees and not customers, which in my opinion says a lot about how much the company values their staff.

I appreciate the openness from GitLab on this matter though, they're pretty up-front about it so if you don't like it don't apply.

[0] When the word "cost of living" is mentioned but it's not reflected in the price for final users then you know you're about to get fucked.

Senior Backend Engineer shows 85-95k in Chicago, which is below average. It shows 45-55k for Fayetteville -- most junior guys/gals start around 75k in Fayetteville at mediocre companies.

Yeah, similar for me. In my geo it shows ~87-98K, but if I moved to San Francisco it is ~173-189K. Which seems foolish. They should incentivize people to move to the lower costs geos, not penalize them.

And the listed salary for my geo is about 2/3 to 3/4 of my current base pay before any bonuses. The idea of the company sounds good, but the pay is a deal breaker for me. I wouldn't like feeling like I'm providing the company more value but because the person lives in San Francisco they get twice as much pay. Maybe that is me being petty?

They're not trying to incentivize people to move to SF; they're trying to maintain a competitive hold on the market of talent which is already there, as the realities of our current climate are that many of the highest-talent candidates are to be found in that pool.

If they're ok with people working remotely, they'd do much better to pay everyone as if they lived in a very expensive area, and attract all the people who don't want to give up a lot of the flexibility of a large paycheck but would love to be able to save even more of it by living somewhere cheaper.

(Their calculator also seems somewhat bonkers (on the extremely low side) compared to the local market where I live. It seems based on a somewhat-arbitrary, quick-and-dirty-wild-guess estimate formula vs what real, on-the-ground competitor companies in those areas are paying.)

EDIT: there seems to be a small trend emerging where every company I've seen with fully-public payscales/pay calculators wildly comes in below what I'm currently making, and what I've heard from local competitors. And I'm not in SF. Wonder if there's some causality there, though it's still just a handful.

Also it's amusing to get a downvote for offering up the info that Gitlab would want me to take a pretty substantial ~30% haircut in base pay based on where I live. What would be attractive to me would be "we'll give you 80% of your current take-home, but you get to live wherever you want," but this is basically the opposite.

I get $45k - $48k which would actually be about a 50% pay rise for me. UK wages outside of London really do suck.

So you could get double your pay by moving from Chicago to San Francisco, or multiply by 6 if you move from Fayetteville to San Francisco.

Seems backwards to have such a large incentive to live somewhere more expensive.

Unfortunately, this is the common practice - offer salaries adjusted for the local market. I could keep my current job and move to an office 1500km closer to my parents, but my salary would be slashed in half, because market. But it's pretty funny for remote workers: what if you get hired in SF, but then move to Fayetteville without telling anyone?

As long as you keep paying taxes in CA, I imagine this is not an uncommon practice.

Yep, this seems to be a major flaw in their compensation calculator. If you don't live in a high rent, hot bed, you end up with a compensation package that is very (i.e. laughably) low.

A lead (maximum seniority), with high (maximum) experience, in Fayetteville, AR makes less than most junior developers (60k-68k)...

I used a cost of living calculator[1] and compared it to theirs. Found the numbers don't match up. Just matched Nashville vs SF and the low end of Nashville was higher than the low end of SF (-3000 SF dollars) but the high end of Nashville was lower than the high end of SF (+3000 SF dollars).

[1] I've found this calculator to be decently accurate http://www.bankrate.com/calculators/savings/moving-cost-of-l...

Simple solution. Don't work there. If they can attract talent at that price then good for them.

Same deal in Sacramento; it'd be more cost-effective (even factoring in time and cost of transportation) to just commute to the Bay Area, which quite a few people already do.

The concept of the calculator is very strong, but I don't think they've implemented it well.

It seems obvious to me that they should be paying relatively more to people in cheap locations than expensive ones. That saves Gitlab money, biases their hiring to people in cheaper areas, incentivizes people to move to cheaper areas, helps cool down the overheated housing markets in expensive areas.

I can see drawbacks to paying a strict flat amount regardless of local cost of living; some adjustments probably make sense. But Gitlab seems to be doing the opposite. I don't get it.

The problem with GitLab's calculator is that it's simply... too ambitious. They try to calculate the salary for pretty much every somewhat major city in the world and it's simply impossible. You can't capture the details of so many different local economies.

For example, when I lived in England, the difference between rent for a room in a shared house outside city center and a 1 bedroom apartment in the city center was usually at most 100% (excluding the very top and very bottom of the ranges). Meanwhile in Lithuania, where I live at the moment, the difference is about 6 times. You can't capture this in a calculator with such broad coverage.

Approach by mozilla (https://news.ycombinator.com/item?id=13881004) seems much more reasonable to me, to be honest.

They're not really able to attract much talent. Look through the LinkedIn of some of the GitLab people. A lot of them are very junior (this is the first "real job" for one guy I looked up), and they, rather clearly, have an amateur leadership team, as exhibited by their recent spectacular failures, their underwhelming commentary on remote team management, their naive idealistic implementation of "radical transparency", and their grossly inadequate compensation calculator.

Most likely, one of their founders is technically adept, there are a small number of other experienced people onboard because they incidentally live in areas where the compensation calculator doesn't screw them, and most others are riding on those coattails.

GitLab is really a sad story of lost potential. Most of the time, you can't fix these kinds of problems, because they start at the top and flow down (and you usually can't replace the top). A well-engineered GitLab alternative would be welcome.

That's one hell of a pessimistic view if I've ever seen one.

What I see is an brilliantly managed company despite having a globally distributed team, which has a great pace of development, which is carving a nice market share in an extremely tough market (developers) and against a fierce competitor (Github), let alone the other multibillion company backed Bitbucket.

And their radical transparency, as you put it, is a fascinating thing in and of itself. If anything it makes me feel intimate with the company. Hard to put it in words, maybe because I was a rather early adopter but if you follow them closely it's a like you're there on their board with spectator mode on. That's some invaluable experience for HN crowd.

Are we even talking about the same company?!

Is the company "brilliantly managed" because they still exist? What is an example of this management brilliance? At this point, all the company has proven is that it is able to convince investors to give it money. I see a bloated company with over 100 underpaid junior-level engineers putting out subpar software.

The radical transparency may be a fun experiment and it may provide a lot of interesting data to parse, but it's not a good way to run a real company. It screams of impractical idealism. A lot of companies are bad, but GitLab wants to make sure that you know they're bad from a distance. In theory this is all great and nice. In practice, it hurts the company in both commerce and recruiting.

The truth is probably somewhere in the middle.

How do you get "brilliantly managed company" when they just had a massive data loss? How can you say that honestly?

Is there a strong correlation between company management and ops practice?

Especially for small companies, I'd hope so. If management isn't even aware that they've got data backup issues, they're missing valuable information, yeah?

My boss makes sure I backup stuff...and we're not taking on millions of dollars in funding and customers.

Not sure I entirely agree but I do feel GitLab is caught up now in the hyper-growth circle like every other startup :/ If the enterprise angle does not work out, there is no backup plan. They compete against GitHub and Atlassian in this space and can only grow so much (but VCs was never ending growth).

I can't be bothered to bother that GitLab has junior people, even to the extend that it's the first "real job" for some of them. We hire people for their first "real job" all the time -- someone has to!

Of course, the problem is not that some people are junior. The problem is that most people are junior, because, ironically, unless you live in one of the most expensive cities on the planet, their compensation is not commensurate with what an experienced developer can make in any first-world market.

When you have an inexperienced crew running your tech, you get a lot of very preventable issues, which sometimes approach apocalyptic scale (like GitLab's February data loss). That's fine for some businesses, but it shouldn't be fine for something as important as GitLab.

Are there evidence that the founders are not willing to learn or something like that.

Just the fact that they've been around a long time now, and are still like they are.

Um ok. What's actually wrong with the product? Why is it not "well-engineered"? All the things you said could be true, yet their product is amazing. I haven't used it, but I like what I'm seeing.

So what if a smart experienced developer (their CTO) is able to get good prices on what he/she wants done through remote work? The point you're making is negativity for no reason without evidence on how it's not working, i.e. what's wrong with their product.

It doesn't take much investigation to start seeing problems, or to see major lapses in engineering from both a concrete (e.g., bugs) and a process (e.g., data loss) perspective. The data loss event that made it clear that GitLab a) never tested its backups b) didn't have a real monitoring/alarming system to inform its employees when things broke c) did not have processes enforcing clear separation between production environments and d) did not know how to configure a PostgreSQL cluster, among many other basic flaws, is just one recent example. The postmortem for that event included the accidental disclosure of a serious DoS exploit, itself the symptom of poor engineering practice (hard-deleting all content flagged as spam, making it impossible to redeem erroneously targeted content; a user could maliciously trigger such deletes with minor effort), which was live on the site until a couple of hours after that disclosure was discussed on HN. As I understand the ticket explaining this, the entire spam cleanup system was shut off until they could teach it not to hard delete anymore. Many other junior-level mistakes are regularly discovered and discussed, both on their bug tracker and elsewhere.

Other than that, GitLab is a beast to install and navigate and it requires a lot of resources. Rails is slow. The UI is weird (frequently end up not finding the repo I want due to the way the "trending" tab works). There are other issues. I'm not a GitLab contributor so I don't really have more technical detail, I just use it sometimes.

It seems like you're just assuming they're a great company with a well-engineered product because you like the corporate image they project.

I don't know of anything about them that makes either themselves or their product "amazing". It is somewhat usable, which is good; I'm not trying to besmirch the earnest efforts of people to make something that works, and indeed there are some uses for something like GitLab. That doesn't mean that GitLab is "amazing" or that their product is flawless or even good.

The most exciting thing about GitLab to me is remotely distributed teams, which I usually love seeing, but I think they've gone about it all wrong.

Shouldn't you use the software before calling it amazing?

Your reflexive defense isn't any more useful than extreme criticism.

I didn't say it was amazing. Perhaps you are the one being reflexive.

I wrote:

"All the things you said could be true, yet their product [could be] amazing."

Grammatically, it's called "elliptical." I then immediately say: "I haven't used it, but I like what I'm seeing"--so what I meant should be quite obvious.

What value are you adding with your criticism of what--in my case--at least has a question:

"What's actually wrong with the product? Why is it not 'well-engineered'?"

My point was extremely clear--his post needed to have evidence of how their processes results in bad product. And I asked that as a question--perhaps you know? Something tells me you even do (perhaps you're a Gitlab user), yet you're choosing to take an unproductive meta route of criticizing my partial criticism with no actual goal. What do you expect to accomplish with that?

I presume you got stuck on one word ("amazing"), made up your mind and didn't read the rest. My bad, i could have been more clear. However, the essence of what I was saying was straightforward, but you chose to see the forrest instead of the trees. A common reason people take that route is because there is something else you wished to express, but didn't--perhaps you have real experience with gitlab in one way or another that resonates more with the person's viewpoint I replied to. I'm not saying he's wrong--I just would like to hear the full reasoning behind that perspective.

I'd love to hear what that actual perspective is. Gitlab is an interesting product I haven't spent much time reviewing until today. Maybe you can provide the evidence to back up the original poster's point??

You can find out if their product is amazing by creating an account and using the software. It takes ten minutes, less time than it takes for you to type up that post. The original poster shouldn't have to explain to you how good the software is when you can try it. If you haven't used it his criticisms of the product aren't going to be useful to you anyway.

I haven't used it, but I like what I'm seeing

If you're just talking about what you're seeing, you have the same vantage point as everyone else and the original poster made a number of obvious and valid criticisms - data loss is one, they are selling software and a service.

It probably is trolling on my part, but as harsh as the original poster's words were, he's got some points.

I'm happy this comes up in every thread about gitlab, and that they appear to read them. I'm hoping one day someone on the team says "you know, they're right, we should do something about this."

Just to throw my example in, they would want to pay me at least 20% less than what I currently make -- and I'm already a 100% remote employee working for a financially stable startup. What they offer is simply not even close to market value -- yet they claim it is. In this case it's the D.C. area.

This has been discussed quite a bit on HN in the past with the general sentiment that their calculator is very off from the market in the US.

In reading all these responses about the low GitLab pay calculator, does anyone have any good tips on how to underpay and still hire talent. It's pretty incredible to me.

I've worked in several jobs where I've thought, "If I'm going to have to put up with this BS, they're going to have to pay me a lot more". And the funny thing is, often times they are willing to pay you more if you ask. So there have been times in my career where I've been miserable pretty much exactly because I decided to work in a really stressful environment while accepting a large salary.

As I get older, I'm not really that interested in putting up with the BS. So if I work in an environment without the BS, or if I have a boss who is willing to shield me from the BS, I'm very happy to pay for it.

Actually, there are tons of things I'll pay for. Remote working on a team that knows how to do it and respects remote workers? That's a big discount. A work process that allows me to work effectively in a different timezone or with flexible hours? Another discount. Guarantee that the work I'm doing will be released with a free software license? HUGE discount (really, huge). Working with interesting and talented people? Yep, discount. No inventions agreement? DISCOUNT.

You get the picture. Hell, I'll do a fair amount of work for free if you tick all the boxes. I'm nowhere near alone in this.

Edit: grammar... :-P

At what point do you discount your skills so much that you can't afford to save for kid's education, retirements savings, etc, though.

In looking at those GitLab pay scales, it's a pretty SEVERE pay cut for all but the most junior people. I'm not sure I'd be comfortable with a 50% pay cut to do "something cool".

From Wikipedia: The U.S. Census Bureau reported in September 2016 that real median household income was $55,775 in 2015.

If you scroll down to education and look at the chart for education, you will see that the median household income for someone with a bachelor's degree is $68,728. With a professional degree (like a P.Eng) it's up to $100K.

Can you afford to save for your kid's education, retirement savings, etc on the median household income in the US? That depends a lot on your lifestyle. It certainly is possible.

I'm not going to tell you what's good for you. I'm just saying that there are people (myself included) who can live comfortably on less and who value things other than money when accepting a job. I was simply answering the question that was asked: How is it possible to hire quality people while paying below market rate? By making it worth the reduction in pay. Whether or not Gitlab succeeds in doing this, I have no idea.

Hire entry level and train them. Have a kick ass culture so they want to stay. Preposterous I know. I've seen it once. In reality, job hoppers are the minority I've found.

Is a lot of their workforce remote? Because I imagine that would influence the lack of job-hopping.

It's really hard. I haven't found a way to do it successfully yet. I think a lot of it depends on the "coolness" factor. Also interested to hear from anyone who has done it successfully.

The trouble with this kind of calculator is that it fails to take into account the global opportunities that the higher end of the talent distribution has. Salaries to retain highly skilled people in cheap locations don't have as large a discount; not only does the salary need to compete against other employers in the area, it also needs to compete against moving to a better market.

Top end salaries will still be discounted, naturally, because the costs in high cost areas are real. But not every scales like housing.

Yeah, the calculator seems to cause some weird things.

Living in Seattle, WA, the salary range I used topped out at ~$120k. However, 30 miles south in Tacoma it tops out at at ~$80k. Moving to Dallas would move the top of the range to ~$105k (Hot Market Adjustment?! but not Seattle?!).

Values I used (I rounded the salary up too): * Lead * Above Average Experience * United States * Dallas, Seattle and Tacoma.

I'm looking to move to the Dallas area (from Tacoma) and my rent will likely end up being less in Dallas (at least 20%).

I also had an interview at Gitlab, and I was dinged for being from a smaller market. I thought the interview itself was very nice, straight forward, and friendly.

One thing that I thought was strange was the quiz/test at the end of each interview. I get that you want to make sure that the candidate has an adequate skill level, but I have a lot of open-source projects (hosted in GL), and I am (one of many people) horrible at live quizzes. Mostly because of nerves, being in an interview is stressful enough. The fact that I had to take a 30-45min quiz instead of going over my own code is not ideal. I just don't believe in standardized testing being a good measure to someone's ability. But, I really thought they were nice about it, and I wish them luck.

It also comes back with half of my current salary, for a senior with a lot of experience. I know what you mean about future prospects.

This is quite common they like to brand themselves as startup and remote company with all their slimy tactics to pay their employees below market rate. I've had their team deny the proof that the salary expectation I asked for is with-in the normal range even if they are a remote company and a startup.

Nobody should be paid as low as 50-60k per annum when they expect people to perform same as someone paid 90-120k. Here are some of the links where I raised this point as well:

https://news.ycombinator.com/item?id=13549948 https://news.ycombinator.com/item?id=10924957

This link suggests their average salaries to be 115k but their calculator is just for people who they'd like to scam into paying below par.

https://www.indeed.com/salaries/Gitlab-Salaries

Mmm, that is pretty far off. If I understand correctly you're a developer intern in Orlando. In most countries interns are paid less than juniors. Maybe that is not the case in the US currently?

BTW Our compensation principles can be found at https://about.gitlab.com/handbook/people-operations/global-c...

Definitely not an intern anymore ;)

Edit: and yeah, I've read a lot about your company including that link. I understand your approach, it just excludes me.

I must have found a different person, sorry. Can you please email ernst@gitlab.com with your case? If the calculator is so far off we would love to add that data point. The most heard criticism seems to be that for low rent parts of the US the calculator is too low. Before our last change the biggest problem was that for hot cities (Phoenix and Austin) it was too low, we now fixed that.

I'm in Phoenix, and it still seems a bit low.. about 16-20k off at lead with high experience... seeing roles around $130k locally. One of the sites like glassdoor is seeing an average around your top.

For U.S. it may be best to establish a floor, and for most cities don't go below that... Remote work in the U.S. tends to be closer to 65-75% of Northern California pay, from what I've seen. Often more than local rates, but harder to come by the jobs.

No, you found the right person, it's just dated information :) I was an intern ~2 years ago.

Seriously? BTW! I just checked the calculator again and the time I was offered a job, there was no calculator then. The calculator pretty much offers the same amount that I asked for but still Gitlab decided to waste by time by saying we expect to pay 70-80k max. The range is clearly 115-120k and I don't think you understand the concept of remote teams when this range can be quite different than US which I explained to your HR as well.

How can anyone verify where I live? What if I say I live in SF just don't wanna meet up personally?

Assuming you are a law-abiding citizen such information would be critical for tax withholding.

Hi Egor, we rely on team members telling the truth about where they live and when they move. In SF we sometimes meet up so that would be slightly harder to pull off. But all of our physical get togethers are optional so you can probably keep this going for a while.

It was a general question to all companies, because geosalary seems to be popular. Always wondered how it works, and how it can be abused.

Also: we, digital nomads, don't have any base. I honestly have no answer to "where do you live"

We had one person before that didn't have a base. He was registered in Estonia as a digital citizen and company. We opted to use that. But we'll look at this on a case by case basis.

They have developers from poorer countries like Eastern Europe where your twice less is twice more than local market.

You vastly underestimate situation in Eastern Europe. It's fairly easily for software engineer to move to Europe, so local companies still have to compete with that.

Anyway I've looked at my homecity in Ukraine and salaries proposed are around 80-90th percentile (~$50k for senior developer).

The thing is there's no reason for a person to hold onto Gitlab. Once you get some remote experience there're a lot of companies who provide EU/US salaries even if you happen to live in Eastern Europe.

> The thing is there's no reason for a person to hold onto Gitlab

This is the one area, I'm quite interested in seeing how things play out, from a human resources point of view. Since GitLab is so transparent, it'll be interesting to see, if they publish any information on employee turnover in the future. Or any mitigation strategies they may develop, to help retain high value employees.

how can i get a remote work?

Yeah I'm really surprised that they don't do something similar to https://buffer.com/salary or stackoverflow.

I applied to Gitlab, but then I noticed the calculator. London is below market rate. In Warsaw is half what Google pays.

Every next move by Gitlab makes them grow in my eyes, personaly. Few weeks ago I started using it as my main "portfolio", it's not much but I really like their way of thinking, openness and providing services. Their whole eco-system is looking really interesting right now, and I hope they will continue to advance and grow.

Edits: typos, wrote from phone.

They definitely have a very interesting strategy, one that is well suited to their target market (= programmers). They're probably the most open company I've seen. Still, I can't justify moving off GitHub, for now. Gitlab has some growing left to do, especially on the SaaS part.

Still, good luck to them :-)

"Gitlab has some growing left to do, especially on the SaaS part."

Some people (say, big companies) think exactly the opposite because they are after an on-prem solution, and for that Gitlab kicks Github's ass.

GitHub offers on-prem as well. Of course it's not open source and not potentially free like GitLab https://enterprise.github.com/features

$250/user/year, blocks of 10, min 10

Ouch. If you run your own servers already it's financially worth hosting your own gitlab at the minimum price point.

I expect it will be the big orgs who don't move due to integration costs.

Let's be honest, does anyone pay full price beyond 10 users? If there's anything I've learned it's that the word "enterprise" means "negotiable." I suspect they put that out there so they have a place to start without the costly interaction of emails coming in saying "how much for x people."

I like Github's UI slightly better (though it's been about a year since I've tried Gitlab)... the recent db issue has me concerned though.

That said, I think it's always worth considering using a tool because of their options for the open-source community... github, travis-ci etc have changed the way a lot of people work. GitLab might be what I reach for for self-hosting, but more likely to try the community/open edition first.

Using VSO (VisualStudio.com) for hosting at work, and some of the integration parts are very nice... Though no idea what a private TFS instance costs.

I use Gitlab and the DB issue only affected me in regards to CI, and I believe this is true to anyone that was affected at all.

They did a manual Backup before meddling with stuff so they only lost data from a really small timeframe.

CI downtime, on the other hand, is troublesome. I love using Gitlab CI and it didn't take me more than a few minutes to manually deploy what I had to, but I decided I need most of my CI to be controlled by me.

The end result is a simple refactor of my test and deploy specs to their own rake tasks (Could be Bash scriots or whatever) and I'll have Gitlab run a simple gle command, if it goes down I run the command manually...

Now some eventual downtime is not such a deal breaker anymore, and I continue having private repos and CI (Awesome CI) for even the smallest (And private) projects I work on... Not a bad deal if I do say so myself.

Why? Github enterprise offers exactly that. An "On premises" Github.

Gitlab Enterprise pricing starts at $39/user whereas Github Enterprise pricing starts at $250/user so from that perspective Gitlab kicks ass.

where did you see GHE asks for $250/user? seems the most expensive package is $21 [1].

[1] https://github.com/pricing

Having never used GitLab, what do you mean by growing from a SaaS perspective?

Performance of repos on GitLab.com https://about.gitlab.com/gitlab-com/

We hear you and agree, GitLab.com is too slow. We're working on multiple things to improve it https://gitlab.com/gitlab-com/infrastructure/issues/947 GitLab 9.1 will have lots of performance improvements for database queries. The GItaly team is working hard to move git commands to the fileservers to reduce latency, that will happen in about a month from now.

Idea: put the performance plots from tickets on https://arewefastyet.gitlab.com

Mozilla does this to great effect:

http://www.arewefastyet.com/

https://areweslimyet.com/

http://www.arewewebyet.org/

As a thought for the performance diagnosis part of things, if your network switches have the option to enable NetFlow (also known as IPFIX), it can be extremely useful.

It does need to be paired with something that can capture and display the NetFlow data well. But with that, you can literally see what data is going where in your network, accurate to the byte. And with a good visualisation solution, you have the data historically too, so you can (easily) match things up time wise.

eg a developer writes a bad query which pulls 1/2 the database over the network to the front end server for filtering results there, instead of filtering them in the database. You can see that on the network fairly easily, and let the developer self-educate (if given access to the tools). ;)

As an aside, the gold standard used to be a commercial product called "NetFlow Tracker". It was amazing (fond memories), but the company behind it (Fluke Networks) didn't seem to know anything about software sales. So, it's now discontinued. :(

Hopefully there's a modern version of that somewhere. :)

We're working very hard on making GitLab.com much faster. Right now, it's measurably (and more importantly: measured [0]) faster than it was a month ago.

If you would like to follow progress you can dive into it all here [1]. One of the spearpoints is Gitaly, which should significantly improve git access.

[0]: http://monitor.gitlab.net/dashboard/db/fleet-overview?from=n...

[1]: https://gitlab.com/gitlab-com/infrastructure/issues/947

Thanks for the confidence in our approach :D Being open and honest about everything is super important to our company culture. We definitely have some great stuff in the pipeline for the next few months.

I started a new project recently, and put it on Gitlab instead of GitHub. I'm very pleased so far, and have been finding reasons to justify encouraging others to move projects there as well.

I'm very glad to hear that. What are the reasons that you think will encourage others?

The biggest thing I think would encourage more projects to move is improving discoverability. On Github, I can very easily search for new projects to contribute to, and their Explore page [1] is very nice. Gitlab's, on the other hand, doesn't seem to have a way to browse by category like Github.

For everything else, I like Gitlab a lot -- it seems to have the best integration of tools of any code host.

[1]: https://github.com/explore

I completely agree. Actually, I think Github could do a better job with discovery too. The Explore page is a decent start, but why don't I get personalized recommendations for new projects?

Yes, that would be nice -- look at the languages my code is written in or the categories my code is, it makes sense to suggest new projects based on that.

First and foremost for me are protected branches. For everywhere I've worked, giving someone commit access to the main repository means giving them the ability to rewrite history on the release branch as well. GitLab solves that nicely by allowing committers to append only to protected branches by default.

I'm also warming to the idea of treating CI as "pipelines", and find myself thinking of tooling more in that way.

GitHub has that too, I noticed the other day. I still think Gitlab is much better, and use it by default for everything new, but fair's fair :P

I love the integrated CI, though, and the use cases it enables. I love that I can just make a pipeline that lints, tests and compiles my code and then, if all of those pass, ends with deploying it to production.

There are many more Gitlab features I like a lot, and the fact that they're all integrated is icing on the cake.

It took forever for GitHub to get protected branches. It was quite frustrating. Glad they finally have it though.

Cool, thanks for that. As others noted GitHub recently also introduced protected branches. As for CI pipeline we got some great multiproject functionality coming in a few months https://gitlab.com/gitlab-org/gitlab-ce/issues/22558#note_25...

I recently setup a small personal project on Gitlab as well. I've been very impressed. I was able to setup a private repo, with a CI setup that builds my code and runs my tests every time i push a commit.. all on their servers. For free.

Thanks for using as part of your main portfolio Philip! Can I ask what else is in there?

Does that include neglecting to create or test their backups?

edit: would prefer to delete this because it's not especially constructive...

Can't we be realistic about companies instead of getting wild eyed? You don't have any reservations about recent events?

Have you actualy used Gitlab? I can't say they are becoming bloated, because they services are of high quality? Have you tried their CI/CD? Github is stagnating. Yeah, they are industry standard, but competition is best thing that can happen to them and users.

I haven't seen them promoting that hard as you describe.

I wrote my comment of the pure satisfaction with their services and my use case. So stop being ignorant and be civilized and at least argument what you say. What happened to them month ago was an accident that could happen to many others, but the difference was that they were 100% open about it, with others you may won't even know shit is happening.

Nobody forces you to use anything.

Edit: And now you edit and delete 90% of comment, nice.

Imo github has the much better user interface. I wouldn't say gl became bloated, but it is not easy to navigate around. At one point, I think, it is necessary to 'rethink' the UI, i.e. to arrange the parts into one consistent beautiful whole.

(My comment excludes the CI part)

That is true. GitHub really got it with the UI, and it was so easy to get used to. Later on, I was thinking I was having slight problems with GL's interface because I was so used to GitHub, but after some time spending on GitLab, I think they really could rethink the UI.

Have you actualy used Gitlab? I can't say they are becoming bloated, because they services are of high quality? Have you tried their CI/CD? Github is stagnatingn. Yeah, they are industry standard, but competition is best thing that can happen to them and users.

I have. I've installed Gitlab and Mattermost on my own server. Gitlab is great but I found Slack was a better product (over Mattermost). Have you tried installing it?

I created a Gitlab account and was planning on using it over Github but their recent data loss scared me off. Is that unreasonable? It worries me just as much to see them buying a company a month after that. Is slowing down unreasonable?

I want to use Gitlab. I like their open approach, but if people just praise them without being objective about it it doesn't benefit any of us. I might just be a selfish and/or entitled user but you'll forgive me for wanting Gitlab to be good. Don't you?

I found Slack was a better product (over Mattermost). Have you tried installing it?

No, please tell me how you installed a Slack server! (j/k, but it's also kind of the point: GitLab wins on-prem)

Hi @aaron-lebo,

Mattermost team here, would welcome any feedback on how we could improve.

Here's a demo of Mattermost features vs Slack as FYI: https://www.youtube.com/watch?v=AKqHWqrAgpk

Hey, thanks.

I had some confusion with the install. It seems the Docker install is favored, but not using a lot of Docker stuff I went with the gitlab-omnibus install on Ubuntu 16.10.

It worked but I didn't feel especially comfortable with it, there were a number of steps. That's vague enough be useless and it could have just been my own ignorance. What is the suggested install if that isn't too basic of a question?

I also had issues with it not liking users sending rather large files but I believe that's an odd use case.

I would use it again but the simplicity of Slack (no setup and no management) won out for now.

What happens to Mattermost? They even touched on this ...

"What about Mattermost, how is this different?

Gitter was built to be used in the open. We’ve always seen Gitter as a network, or a place where people can come to connect to one another. Team collaboration, whilst possible, has never been a core aspect of the Gitter experience.

Mattermost is a powerful, integrated messaging product for team collaboration - we will continue to ship and recommend using Mattermost for internal team communication."

Thanks, that's good.

They surely have the best intentions. Hopefully one product doesn't take priority over the other and/or they can prevent cannibalization. There's definite overlap.

Mattermost is developed by another team https://about.mattermost.com/company/ that is separate from the GitLab/Gitter team. So I think both will continue to grow without affecting each other.

Up until this week I was in love with Gitlab. We've been using it at work for over a year as our main repo, code review tool and CI (tried self-hosted first, then moved to gitlab.com).

However, the service (gitlab.com) is constantly having issues, most of them not reported on their status page or on their twitter status account. For the last week it's been practically unusable, to the point where our whole dev team combined has wasted almost a hundred hours just re-trying builds and deployment jobs. Yesterday we tried, unsuccessfully, moving to the new AWS tools (CodeCommit, CodeBuild and CodePipeline), and today we just moved back to Bitbucket + CircleCI (we use RoR if you are wondering).

Unfortunately today I couldn't seriously recommend gitlab.com to anyone needing a reliable hosted repo + CI solution (maybe self-hosted works better though, YMMV).

Regardless, I have a deep respect for what Gitlab as a company has done so far. After looking into repo + CI options I've realized that they've created probably the best all-in-one platform out there, at least their vision/concept. Wish them the best and hope to use their service again in the near future once they have their stuff together.

Hi Nico, I'm sorry that you suffered our unreliability this week. We do try to update @gitlabstatus for everything that we see happening, no matter how small. We're determined to make GitLab.com a reliable platform, but we realize we still have a long way to go.

Thank you. I'm still a big fan of Gitlab and the vision you guys have. You've built an amazing organization and you'll definitely keep doing great things. Look forward to using your platform again in the future :)

Thanks Nico, glad to hear that you'll give us another chance.

You mentioned that you tried and failed to move onto the AWS developer tools. What problems or issues did you run into?

    > However, the service (gitlab.com) is constantly having issues, most of
    > them not reported on their status page or on their twitter status account. 
    > For the last week it's been practically unusable, to the point where our
    > whole dev team combined has wasted almost a hundred hours just re-trying
    > builds and deployment jobs.

Do you happen to have some examples of these problems? I recall there are some known problems with CI runners getting stuck, but I'm wondering if you were running into other problems as well.

Those are exactly the problems we were running into. Our pipelines ran 3 consecutive stages (lint, test, deploy). Because every push and every merge triggers a pipeline, and because every stage runs a job, almost anytime we did anything on gitlab.com something (or everything) would get stuck. This slowed our dev/deploy process to a crawl, to the point where we spent all of Monday pretty much just checking, waiting for, or retrying jobs. Sometimes we would merge a branch and an hour later none of the jobs in the pipeline had even started (had status created or pending). Yesterday (Tuesday) things were still pretty much the same. Today we just moved on.

Jobs getting stuck might not seem like a big deal, but when every dev on the team needs to manually check every 5 minutes to make sure things are running and retrying everything, while clients are waiting on a hotfix, bugfix or a new feature that we promised we would ship by a certain deadline, then the issue becomes critical.

Out of curiosity, why did you move from self-hosted to gitlab.com? I run self-hosted and I've been quite happy with it.

Cloud anything just seems like begging for this kind of problem.

Great question :) We are a small team so we prefer focusing on writing code than managing our infrastructure.

Keeping even just one server secure and up to date is no small task. Additionally, in this particular case, given Gitlab pushes changes pretty often, we wanted to have access to the latest stuff without having to update the self-hosted instance every time (with the added risk of screwing up in the process). I guess there's a trade off for everything.

Did you consider GitLab's githost.io?

GitHost seems incredibly expensive. For $150/mo for their most basic plan I could easily rent a basic dedicated server or VPS from for $10-40/mo. In my experience this takes about a 1 day investment up front then 1 hour/mo (basically just update the box or replace a failing drive once in a while) to maintain indefinitely if you keep it behind LAN/VPN. It's a fairly small time investment with a big reward for security, privacy and stability in my experience. Then you have control of backups too, which seems like a pretty good thing to me given the recent GitLab fiasco.

I've been having the very same experience and were also seriously considering moving off of gitlab at this point. It's a shame but the amount of hours lost are starting to become entirely unjustifiable.

@sytse - this is huge. You can move the YC internal slack to gitter as well ;)

But seriously - people are willing to throw money for an enterprise gitter - especially after https://medium.freecodecamp.com/so-yeah-we-tried-slack-and-w...

Look at the number of people begging Discord to take money from them - https://feedback.discordapp.com/forums/326712-discord-dream-...

gitter always had search working - discord just got it recently.

Thanks Sandeep. We assume that it is easier to charge money to enterprises than open source communities. If we see strong adoption and feature requests from the enterprise we'll consider adopting an open-core model and charging for it. For now the adoption is mainly from open source communities and we think of our costs as a marketing expense.

Do you know of any enterprises using Gitter?

No - because, like discord, gitter makes it a point to make privacy very hard to set up. This is fairly deliberate and is the reason why enterprises have a hard time adopting it.

Sandeep, it's interesting that you view it that way, but it was never our intention to deliberately make privacy hard. When creating a new room, you can choose to make it public, private and optionally allow anyone from your GitHub org to join your private room. See http://imgur.com/jIb8EKA

It's definitely true that the product focus on Gitter has always been more on public rooms. That's because the focus of our company has always been on the network of public communities, rather than enterprise features, which we feel are well represented in the market by other great products like Slack, Mattermost, etc.

(Background: I'm CTO/Cofounder at Gitter)

I completely understand and respect that. It was not a complaint - but cognizance that you had a certain philosophy in mind.

Forget slack - look at hipchat which has far simpler privacy controls. The ability to create an organization (NOT linked to GitHub), per channel permissions is all that's needed. Hipchat makes this dead simple.

Lots of different people will have different requirements - some people will need Active Directory even, but essentially the only two things needed for enterprise messaging is permissions and search.

Additionally, would love to hear your feedback on what you think we could change in Gitter to make privacy easier and less frictionless.

Can you explain how Discord makes privacy hard to set up? Servers by default are private (No one can join or even see the server unless they are invited to it). You can disable people's ability to create invites with a 3 clicks.

(disclaimer: work at Discord & fishing for feedback about how we can make this easier)

So, this is related to another comment I made. We are not hosting our own. We want to throw money at discord bringing in enterprise like features in its hosted version.

I linked to a ticket - if you follow that trail, there are many more.

Why not use Mattermost for something like this? We ship it with GitLab Omnibus and it's open core.

https://about.mattermost.com/

EDIT: Previously said open source, open core is the correct term.

It's the gitlab vs github stand - self hosted vs hosted saas.

Gitlab is incredible... but I really cant host right now. Same for mattermost.

I do believe that the ability to run a fairly large hosted system at scale and with incredible performance is what the gitter guys bring to the table.

Mattermost is open core and not open source.

> people are willing to throw money for an enterprise gitter

Isn't that just Slack?

The point of the first link is that free Gitter is already better than free Slack, so companies would be willing pay to have guaranteed support/uptime/etc from Gitter.

"Next piece of wow: we will be open sourcing all of the Gitter"

The Gitlab folks really know how to do it. It is of course the rational approach to it, but still, that's a bold move.

For us it was natural to open the source code, we prefer to work that way. All our source code is publicly viewable and most of it is open source.

This just makes me hope you guys buy more things.

Ha! Any suggestions? ;)

A cross platform GUI git client that doesn't suck!

This is a pretty great idea. For what I often deal with, the GitHub desktop client is okay (though obviously tied to GitHub), but then I was sad to also realize they don't offer it on Linux. (Maybe they assume Linux nerds don't need GUIs?)

I tried Tower when it was in beta for Windows, but the cost is too steep to justify it for me. But it seemed to be a lot more full featured than the GitHub client which isn't good for more than basic commits. And again, no Linux there either.

I'd definitely go for a solid, open source git client, and it's obviously very relevant to GitLab's business.

Spend that money porting GitUp.co to multiple platforms instead. The only git GUI I've used that doesn't suck. Might be lacking in features though 8)

> Any suggestions?

Seriously, SublimeText, which is $70 closed-source.

Less seriously, macOS and iLife. I'd be ok to pay €200/year/user for an OS of that quality, as long as it's open-source.

I'd personally (not speaking on behalf of the company) love to acquire Sublime, but it's probably too expensive at this point. I'm pretty sad to see Atom eclipse Sublime so much recently, Sublime is so much faster and change is hard :( If only it were open source.

https://typora.io/ (a WYSIWYG Markdown editor)

waffle.io

I doubt CA will let it go. Now poaching Homeyer might be possible. ;)

> All our source code is publicly viewable

Not all of it. version.gitlab.com is one of GitLab's closed source IPs.

Yeah, unfortunately that's because we made a mistake, here's the relevant issue if you want more info (PDF because it's a private repo so I can't link directly to it unfortunately):

https://drive.google.com/file/d/0ByoIqX0IDB5scWpJT0JKTHQtTG8...

We do want to open source it when we can.

I reopened the issue.

Do we know what protocol Gitter runs on top of?

Gitter uses a proprietary websocket protocol built on top of the Bayeux protocol: https://docs.cometd.org/current/reference/

More details can be found on the developer site: https://developer.gitter.im/docs/faye-endpoint

We also have an open-source IRC bridge: https://github.com/gitterHQ/irc-bridge

I prefer matterbridge :) Supports more than IRC, and supports multiple gateways at once: https://github.com/42wim/matterbridge/

Depending on the availability of a Bayeux client for Golang, it looks like something that could be integrated quite easily.

I don't know how Gitter support in matterbridge is implemented but it is great! Do try it out. I've been running a three-way discord+gitter+irc gateway for a long time.

And there is a matrix.org/gitter bridge already in use by riot.im

Protocol? I kind of assumed things like Slack, Gitter, etc. were just using websockets that communicate with their backend.

Slack is built on top of IRC. Presumably Gitter is as well

Slack is definitely not built on top of IRC. There is, however, an IRC interface to Slack.

Not on top of IRC. Just similar in that they are both chat like

> Slack is built on top of IRC

Source? First time I hear that, and it seems unlikely, since they have quite a few features that don't fit nicely in stock IRC.

I’m not sure there are any Slack features that don’t fit into stock IRC v3. Basically everything they do is already supported or a draft. (Now just everyone has to implement it)

Any source on that. I don't think it follows any protocols at all. Just implements it's own thing.

I think open sourcing here just shows that the code is irrelevant and is not the money maker. I guarantee you nobody is moving off slack because gitter is "open source". People might move to gitter because is it integrated into gitlab self-hosted though (this is what will happen and mattermost will be phased out despite what they say).

Does anyone have an insight into the differences between Slack, Mattermost, and Gitter? I have only ever used Slack before but it seems like Gitlab is already heavily invested with Mattermost. That makes me wonder what the future looks like for both Mattermost and Gitter. Are they different enough that they can both coexist without hurting either product or is one of them destined to be folded into the other in hopes of taking on Slack more directly?

Gitter is targeted at providing a public channel around a project, Mattermost is more Slack-like for team-internal organisation (with multiple channels, user management etc)

Thanks - haven't heard of Gitter, came to the comments to ask about the potential impact to Mattermost. Sounds like there's room for these two to coexist within GitLab.

They mention those in http://blog.gitter.im/2017/03/15/gitter-gitlab-acquisition/

Mattermost is for self-hosted communication. E.g. automated deploy to your cloud account, etc.: https://www.youtube.com/watch?v=AKqHWqrAgpk&t=83s

Here's a blog post on differences with Mattermost and Slack: https://www.mattermost.org/what-slack-might-learn-from-its-o...

We chose gitter over slack as an open core company. I close leads, hire engineers, and run our team chat all on one platform. (We supplement this with hangouts) . The idea that all of my activity and communications can happen on one platform is pretty appealing. We also don't need many features (aside from better search please!)

Confirmed on Twitter: https://twitter.com/gitchat/status/842058103571001344

Link to the live post: http://blog.gitter.im/2017/03/15/gitter-gitlab-acquisition/

Looks like they will open source the whole thing. I'd be very interested in learning how much Gitlab paid for this acquisition.

I'm sorry but we don't comment on acquisitions prices. Being transparent about it is not common in the industry and us doing this by default might make future acquisitions harder since the company being acquired might not like it. Also see https://about.gitlab.com/handbook/general-guidelines/ "Most things are public unless there is a reason not to. Not public by default are: financial and legal information"

..because financials is something people hope a company to be more open. It takes quite alot of courage to honestly reveal all the salaries. Then you wouldn't need a calculator anymore. So probably you should consider when you are acquiring talent, talent may set the price based on their own needs and have a right to negotiate. You shouldn't first of all, build an annoyingly outdated calculator and give it to HR to reject good talent and rely on community to mess up when the decision to build that calculator was mostly to serve company's own purpose. (which probably why its more biased to downpaying employees)

I think even public companies often disclose the prices though, especially for major ones. This being said, I have been thinking about the GitLab IPO, including things like fixing Reg FD for a while now.

> I think even public companies often disclose the prices though,

"Even public companies"? Public companies are required to report a lot of financial information publicly that non-public companies are neither required to report nor in the habit of reporting.

The point is there probably won't be much problem in disclosing this info and they will likely have to do so after they IPO anyway.

This is pretty weird to me:

> What about Mattermost, how is this different?

> Gitter was built to be used in the open. We’ve always seen Gitter as a network, or a place where people can come to connect to one another. Team collaboration, whilst possible, has never been a core aspect of the Gitter experience.

> Mattermost is a powerful, integrated messaging product for team collaboration - we will continue to ship and recommend using Mattermost for internal team communication.

Surely GitLab would be better off investing fully into a single chat-platform? The road to making Gitter good for internal team communication is not particularly long or windy.

When it's going to be open sourced then we could finally implement a proper matrix.org bridge. Currently all messages are relayed through a special gitter user called matrixbot

matrix-appservice-gitter actually supports 'puppeting' already - letting you log in as your own user. But native Matrix support for Gitter would be incredible!

This appears more like a acqui-hire. Also, since mattermost is bundled as part of GitLab, it makes me wonder why they didn't acquire mattermost instead.

This is good though because mattermost is open-source only on paper. They refuse to integrate important features even when people contribute code (to protect their commercial version).

Third, people see GitLab as GitHub competitor. But really it competes with Atlassian.

Hi @simplehuman, Mattermost team here, thanks for the mention.

First, we love GitLab. While we'd be flattered with an offer to join them, Mattermost has its own mission and motivation (https://www.mattermost.org/why-we-made-mattermost-an-open-so...)

Second, regarding community contributions, we have an open and transparent process for proposing, discussing and vetting contributions before a pull request is made (https://docs.mattermost.com/developer/contribution-guide.htm...).

When people don't follow the guidelines, and when they work hard to contribute something before engaging with the broader community--especially when it totally works but can't be officially accepted--we feel terrible.

Recent example: https://github.com/mattermost/platform/pull/5718 Previous related example: https://github.com/mattermost/platform/pull/2718

You can follow the links there to go into detailed, heated discussions around this in our own Mattermost instance.

In our manifesto, we lay out the purpose of the open source Mattermost Team Edition, and about the commercial Enterprise Edition (https://www.mattermost.org/manifesto/), and--at least in my mind--our decisions are based on scope (What purpose does X serve? Where should it belong, if at all)?

Our contribution guidelines are in our docs, they're in our developer docs, they're displayed to contributors before they can submit a merge request, and yet with the size of our community, we still have mistakes and awkward threads.

I hope we can do better here. If anyone would like to discuss, you're welcome to join our community server: https://pre-release.mattermost.com/

Third, yes, agree, GitLab is certainly competing with Atlassian, and winning a lot.

I hope this spurns more OSS communities to move to gitter. As much as I enjoy slack, limits on features like search and invites creates a friction that I think a service like gitter can help solve.

Personally the fragmentation of these random chat services does little to make me want to get involved in project chat discussions.

I wish project maintainers would stick to a network like freenode and just occupy a channel there dedicated to the project. I'm already set-up to take part in discussions there, I don't need to use a web browser etc.

Totally agree with this. Having to join 10+ Slack-like groups to collaborate on open source projects is unrealistic for me. As a result, I don't frequent some projects' chats and stick to bug trackers/mailing lists -- as a result of that I miss out on a lot of the camaraderie that comes with contributing to open source. I've missed out on a few conversations where decisions were made too. Being in multiple groups on these services is a huge pain point for me, whereas being on multiple IRC servers in multiple channels is far less invasive to my time and computer resources ;D. I'm not necessarily advocating that everyone use IRC for everything, but it seems like a lot of us had standardized on IRC for OSS before most of these services came along.
Also I'm salty that most of these Slack-like services have no ignore feature/minimal moderation tools which are both things I've leaned on heavily when working with communities. That's probably a rant for another day, but it's related to why I really dislike using some of these things.

This might just be my perception, but it seems like most people I come across in this field were on IRC at some point.

>most of these Slack-like services have no ignore feature/minimal moderation tools

This is what pushed me away from using Slack with a group of gamers I admin for. I can understand Slack's desire to stick to the workplace and how that leads to "if you need to /ignore a co-worker your company has problems implementing /ignore in Slack can't fix." And I can understand Mattermost wanting to become the opensource/on-prem analog of that. But it really falls apart when you try to use that kind of system with users that don't know you, aren't on your payroll or have issues with rules - like open source developers, or gamers.

My group eventually switched to Discord for, among other things, its amazing ACL-style permissions system, frictionless inviting and unlimited history (iirc, getting history with the first tier of paid Slack would have cost us ~11k USD/year?). It's not perfect - I really hope their bot API gets some love, and of course the ability to host your own server would be nice (though I understand some of the catch-22's there) - but I like it a LOT and I keep encountering new groups of people with Discord servers where I can just idle using one client. This is MUCH more IRC-like experience than I ever got with Slack (for instance, switching between or getting/setting notification alert levels on several different servers is much more ergonomic on Discord than on Slack).

I've not used Gitter a whole lot - just a couple of times when I had a question for some project that had one - but my impression is that it leans more towards "chat with strangers about $topic" (like Discord) and less towards "chat with colleagues about work" (like Slack). In that respect, I'd lay a small amount of money that Gitter does have an /ignore command, among other tools that you miss from IRC.

s/spurns/spurs/

Not trying to be snarky. Maybe it was a typo, but non-English speakers might not immediately get from that to the correct word.

I'm a member of a Gitter for a smart mirror project. It's been a fun way to connect with other fans of the project and the maintainers. Feels like a smart move.

Thanks Brad, glad to hear you like the move.

This seems like a good match.

I've been helping some early coders in the FreeCodeCamp Gitter and have been impressed with the quality of the app for a company with little capital. They have done a lot with short resources.

It would be better in my opinion for small Slack communities to transition to Gitter since Slack has said they do not plan to support large scale free communities in the long term.

edit; typo

Thank you Dangeranger! FreeCodeCamp is an incredible community and we've been glad to be able to support them in doing the amazing work that they're doing. Hopefully this announcement will help them go from strength to strength!

That is awesome news. I have been using Gitlab for the last year. I switched over my personal projects and 3 organizations I was advicing from GitHub. They won me with their data centers in Asia and Europe. GitHub is extremely slow in Asia and they do not want to change.

i was just hating on GitLab here a few days ago so i will take the opportunity to say this is really cool on a bunch of levels.

I love Gitlab but sadly, quite a lot of services that offer free accounts for open source projects (TravisCI comes to mind), generally don't integrate with Gitlab

It's one of the few reasons why I am still using Github :( .

I'm in a similar situation. I have a Gitlab account and am fine using it for personal projects but it's challenging to convince existing projects to move their repositories over. I'll start considering gitlab.com more seriously after the performance improvements mentioned in another thread here are rolled out.

I would prefer if Gitlab CI was a separate product but there probably isn't a lot of benefit for Gitlab to do that. If you want to have Gitlab CI job results displayed in your Github branches you could try this test service:

https://github.com/avtar/docker-push-ref-gitlab

> I love Gitlab but sadly, quite a lot of services that offer free accounts for open source projects (TravisCI comes to mind)

Isn't there a "but sadly I don't love its CI" missing from the middle of this? Why is Travis the problem?

Gitlab has its own CI. Are you sure you need Travis? Especially if you're the owner of project and can make a switch. Imo all open source programs should make the switch. Gitlab stands better for the community that github does.

I've yet to find something I needed that wasn't supported - or that there wasn't a better option available that did support it.

TravisCI for instance, is easily replaced in all of my projects with Gitlab's integrated CI.

I feel this way too. Not specifically about travis but about providing github integration as the only option Git is supposed to be distributed! How hard is it to ask people to provide a git url and tell them to push events to a webhook?

Generally I have the opinion that the CI of gitlab is much more powerful because of real Docker usage (and also works on private repos for free). Speaking about the gitlab CI... why is there no status or statistics page about it on status.gitlab.com and why is a new build pending over 30 minutes currently (now) ?

You can find some public monitoring regarding CI on GitLab.com here [0].

I agree that we should have some status on CI as well, made an issue [1].

[0]: http://monitor.gitlab.net/dashboard/db/ci

[1]: https://gitlab.com/gitlab-com/infrastructure/issues/1360

Wow that gitlab monitor on [0] looks really great. Thanks! Can I ask which software that is? :)

It's Grafana [0], backed by Prometheus [1].

[0]: https://grafana.com/

[1]: https://prometheus.io/

Travis has supported Docker Container based builds for quite a while now.

Let us know what projects you miss seeing integrated with GitLab and we'll try our best to convince them, help them in any way to make sure it happens!

As other point out, you should be able to use GitLab CI instead of Travis, they configure very similarly. That said, I'd welcome them integrating fully with us as well.

I've used Gitlab CI before and I do like it, but TravisCI allowed for some granular control that Gitlab CI does not have (or that I am doing wrong) - for example, ability to run specific tests in case of pull/merge requests (TrasisCI has an environment variable for it).

As for other projects - the most important one for me was clubhouse.io (Gitlab Issues is great but just not as good as clubhouse.io)

> I've used Gitlab CI before and I do like it, but TravisCI allowed for some granular control that Gitlab CI does not have (or that I am doing wrong) - for example, ability to run specific tests in case of pull/merge requests (TrasisCI has an environment variable for it).

Ah interesting! You can't do this now with GitLab, but we're working on supporting merge requests as special cases [0].

> As for other projects - the most important one for me was clubhouse.io (Gitlab Issues is great but just not as good as clubhouse.io)

Clubhouse sure looks nice! GitLab Issues is getting better every release and in 9.0 (March 22nd), we have some big changes for Issue Boards.

I've asked our PM on Issues (Victor) to check out Clubhouse and hopefully we can convince them to integrate with us in some way.

[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/23902

GitLab CI and gitlab-multi-runner is nice and all (really!) but Travis CI provides (free) OS X runners, which is mandatory for some projects.

Maybe we can then fix all the UI-bugs in gitter which pissed me on so often.

I really like Gitlab and this acquiring.

When I firsted started as a developer, I don't know how people do thing in real production. I don't know how real company build real software.

Nowsaday, with all open source thing from real company that acquire/shutdown I can finally learn a lots from them.

Recently Stajoy open source everything, now Gitter is next. I'm sure I will learn a lot by consume the real code that run on production.

Thank you Gitlab/Gitter.

Discussion at: https://gitter.im/gitterHQ/gitter

The goal seems to be to have the code open sourced by this June, with all history included.

Stack details here: https://stackshare.io/gitter/gitter

Hah, nice. Love it, love it that a whole business can run on free/open source and selling hosting/support.

What the heck is Gitter? A public chat service? Sounds like adding yet a new way for people to bug you about things that don't work, but without the controlled discussion of opening a proper Issue. As a developer or maintainer, what value does this bring to a project?

It ties chats to Github repos/issues. I've never had any luck with clicking on one. IRC is much more useful in my opinion. I suppose they could make it work in some fashion, but opening an issue should suffice...

Think about your favorite github repo, or even just a very specific one, and there is always a few people talking about this repo: https://gitter.im/rails/rails

Url changed from http://blog.gitter.im/p/7e1c7194-347e-47f1-84d1-8149de853e03..., which disappeared.

Thanks Daniel, sorry for circulating a draft post early.

I hope the search in gitter-chanels gets better now, cause of open-sourcing it. There are good infos and tips hidden. Maybe tags or upvotes would solve this.

Have used gitter a few times. I've heard it lacks moderator tolls from the channel owners a few times. OpenAI has their channel there too.

The blog post is now up: http://blog.gitter.im/

Would be interesting to know how much they paid

So the race to acquire the next team dev solution heats up. Slack + github + trello equivalent

From what I've read so far, I get the impression, Gitter was purchased solely for marketing value. And in a lot of ways, is quite ingenious. I would suspect, 80% if not more of the discussions that occurs on Gitter, revolves around repos that are hosted on GitHub.

By tapping into those conversations, they'll probably be better able to identify GitHub pain points and provide subtle hints and nudges, for Gitter users to consider GitLab.com

So somewhat eerily, my Gitter GitHub public repo authorization token shows that it was accessed within the past 2 days, despite my not having logged in to any Gitter pages in months. http://imgur.com/a/aABi8

next, I hope to see some "content" offer attached to gitlab's ecosystem, for instance a strong collaboration with stackoverflow/OSQA

Gitter has been working on a content system called Topics. https://gitter.im/gitterHQ/topics. It's still in Beta, but Q&A and structured content is definitely something that - in addition to chat - we think is important.

(edit: typo)

That's really awesome! Does it run like a mailing list system? One of the #1 pain points in running FOSS projects is creating and managing a mailing list, with archive browsing that doesn't look atrocious.

very interesting, the UI throws me off though, for instance are topics somehow correlated to the channels I have open (i.e. the list on the left)? Can I access Topics from the desktop client?

Looking forward to updates, thanks!

I guess you can remove OSQA from that list. It's now abandoned, with no new commits and the developers strongly encouraging to use their commercial offering...

I'm currently in the processor of migrating an OSQA site to AskBot, which seems currently maintained.

too bad, thanks for the heads up

Can mods fix the link please, it's currently 404.

Blog post seems to be taken down. Here's a cached version. http://webcache.googleusercontent.com/search?q=cache:XWzfaAJ...

The page appears to have been taken down.

Google cache: https://webcache.googleusercontent.com/search?q=cache:XWzfaA...

The blog post appears to have been deleted. There's also nothing on the Github blog. Maybe they released the post sooner that they had wanted to?

Perhaps this was a premature disclosure of the acquisition? Is an 8-K filing required for privately held companies?

But yea, one of my favorite topics is the NDA.

Sure thing.

Looks like the Gitlab v. Github battle rages on.

Solidly great business decision, well done.

`git pull gitter`

More like `git merge gitter` :)

great news!

great news

This leads to 404. Their official blog says nothing about it (http://blog.gitter.im/) and Twitter also says nothing about it (https://twitter.com/gitchat).

Here's a cached copy, http://webcache.googleusercontent.com/search?q=cache:XWzfaAJ...

It's up now at http://blog.gitter.im/2017/03/15/gitter-gitlab-acquisition/

I just read it a couple of minutes ago, maybe the announcement was posted early?

Probably. Who ever did push the "Publish" button is probably biting his nails :)

Luckily GitLab can't get too angry about someone pressing the wrong button...

Probably. There are grammar errors (or at least one) in the cached copy that was linked elsewhere.

Congrats to the gitter team, you guys are awesome and have a way (far far superior) product than slack.

thought gitter is part of github, what an ignorance.

Reply on news.ycombinator.com