Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitLab Strategy

about.gitlab.com

Post reply on HN
Print view View original

51–60 of 77 posts

Re: GitLab Strategy

#51

Post by techntoke »

GreaterFool wrote: post #19

I feel bad for GitLab. It's better than GitHub in almost every way. And yet GitHub is more popular both in open-source and enterprise. And in enterprise we are usually left with unholy combination of GitHub and JIRA because GitHub project management is a joke and they haven't done anything useful in that space for years. But for some reason pushing for anything other than GitHub is always an uphill battle. And the we…

It is because GitHub employs a marketing strategy like Microsoft about selling something based on relationships but not product quality. They wine, dine and give kickbacks to those with the power to sign a multi-year contract.

Re: GitLab Strategy

#52

Post by techntoke »

sonnyblarney wrote: post #41
jjeaff wrote: post #25

Earlier quoted context omitted.

I can't speak for gitlab, but there is a strategy to not competing with higher salaries, even if you can afford it in some cases. You aren't necessarily losing the top talent because not all the top talent cares only about the money. And by not offering the highest salaries, you are naturally selecting for employees that care more about the culture and work/life balance than having the highest possible salaries. So i…

"you are naturally selecting for employees that care more about the culture and work/life balance than having the highest possible salaries" This is not quite true. You're 'selecting' for all of the things that come along with offering lower salaries, which usually means losing the best talent. All things being equal, it's rational for even a 'good staffer' to go to Google (or whatever). And of course, the company sa…

Not true at all. Money isn't everything. Culture and value mean a huge amount to me as an employee. I'd take 60k less a year or more based on culture and value.

Re: GitLab Strategy

#53

Post by techntoke »

ralph84 wrote: post #40
jjeaff wrote: post #29

Earlier quoted context omitted.

What other on premise lifecycle development solutions are there?

IBM, Atlassian, CA, GitHub, Microsoft, Micro Focus, Perforce, to name a few. Even if you believe GitLab's 100,000 number, Atlassian claims more than that and they're a public company so less likely to fudge the numbers.

Most of Atlassian customers are using their cloud solutions at this point.

Re: GitLab Strategy

#54

Post by techntoke »

simplyinfinity wrote: post #44
janee wrote: post #21

Earlier quoted context omitted.

Tbh Google would make a good fit considering the existing auto devops CI/CD integration with GCP. I guess MS will roll out something similar on Github + Azure sometime in the future.

Checkout azure pipelines + visual studio team services :)

GitLab has self-hosted and open source, and offers a lot more for free.

Re: GitLab Strategy

#55

Post by nerdwaller »

emilycook wrote: post #42
hn_throwaway_99 wrote: post #26

Earlier quoted context omitted.

I am not a GitLab user, so I'm not speaking from personal experience, but I've read more than a few comments here on HN that GitLab stability and performance is worse than GH. For a mission critical system like source control, stability and performance are more important than any other features.

GitLab employee, this is somewhat of a drawback to how transparent we are about our issues. I know this might seem like I'm just trying to PR spin it, but it's a real phenomenon. We post about any little problem we have, and 99% percent of our Issues are public, so it probably seems like we have a lot of downtime and problems because of how often we talk about them

Unfortunately the perception was earned a few years ago created not by running “more openly” but real user experience and breaking people of that experience over several months is a long uphill battle for GitLab. I’m involved with a large group of Python developers that echos the same feeling, even though generally speaking many of us find GitLab (performance and reliability aside) a better and more comprehensive product.

I’d guess this was a consequence of a strategy decision that went against the plan (probably an expectation mismatch with users). I think the large part of the problem is the public GitLab instance is (was?) the beta environment, so a lot of issues popped up constantly while people were evaluating the options. In our group we are all volunteers, so when downtime impacts the little time we can dedicate (push code, review, deploy) it’s a fairly big deal.

Our python group (pyslackers.com) runs in the open as much as we can, so for us we went where the exposure and ease to be involved is (Github), even though from a raw feature perspective we liked what we had on GitLab when it worked.

Re: GitLab Strategy

#56

Post by autotune »

sytse wrote: post #35
autotune wrote: post #5

Funnily enough paying their employees somewhat competitive market rate still isn’t on there.

What rate do you think is off? For example our rate for an intermediate developer in San Francisco is $160k a year and options. See https://about.gitlab.com/job-families/engineering/backend-en... If you mean we pay local rates please see https://about.gitlab.com/2019/02/28/why-we-pay-local-rates/

I'd highly recommend doing an internal, anonymous, survey to see if employees are happy with their compensation. Literally every GitLab employee I've talked to is extremely unsatisfied and tends to agree with the sentiment about being underpaid relative to other companies for those not in SF, and a very common theme I've heard is being heavily low balled when reaching the offer stage. Somewhat anecdotal but still more so than other software companies willing to pay market rates, also worth noting I am not a GitLab employee just a very common theme when chatting with them. Something is obviously wrong with your "compensation calculator" if the general sentiment is this widespread.

Re: GitLab Strategy

#57

Post by GreaterFool »

bdcravens wrote: post #20
GreaterFool wrote: post #19

I feel bad for GitLab. It's better than GitHub in almost every way. And yet GitHub is more popular both in open-source and enterprise. And in enterprise we are usually left with unholy combination of GitHub and JIRA because GitHub project management is a joke and they haven't done anything useful in that space for years. But for some reason pushing for anything other than GitHub is always an uphill battle. And the we…

A lot of the development ecosystem had integrations with Github, and haven't yet done so with Gitlab. Additionally, network effects matter, especially when if you add collaborators to your repo it's almost a given that they have a Github account.

I assume you're talking about CI? Not much more than that. But that only works in the most trivial cases. One repository, simple tests. I spent tons of time over the years always tweaking this and that to make whatever CI system we were using somehow work with GitHub. Lot's of setup, lots of trouble.

Re: GitLab Strategy

#58

Post by m0zg »

lttlrck wrote: post #39
m0zg wrote: post #24

Earlier quoted context omitted.

Last time I tried switching to it it was slow as molasses on the command line. Easily several times slower than GitHub. So I went back to GitHub. I still have a GitLab account, but I only keep my dotfiles there. I keep hearing they've improved performance, and maybe they did, but that's also what I heard last time I tried it, so now I'm kind of reluctant to give it another try. Unlike before, now it doesn't just have…

self-hosted on a $40 digital ocean droplet performance is practically speaking indistinguishable from Github. No idea what gitlab.com is like, we picked gitlab because we could self-host.

How is it maintenance-wise, BTW? How involved are the upgrades? I'm tempted to self-host, but don't want to go too far down the rabbit hole.

Re: GitLab Strategy

#59

Post by autotune »

techntoke wrote: post #52
sonnyblarney wrote: post #41

Earlier quoted context omitted.

"you are naturally selecting for employees that care more about the culture and work/life balance than having the highest possible salaries" This is not quite true. You're 'selecting' for all of the things that come along with offering lower salaries, which usually means losing the best talent. All things being equal, it's rational for even a 'good staffer' to go to Google (or whatever). And of course, the company sa…

Not true at all. Money isn't everything. Culture and value mean a huge amount to me as an employee. I'd take 60k less a year or more based on culture and value.

The last time I worked at a company where “money isn’t everything” with a focus on culture instead it was because they ended up getting bought out by a private firm where most eventually got laid off. Money talks, bullshit walks first and foremost while culture is what ensures those with competitive skill set and high salaries don’t jump ship for 10 percent more, but you still have to pay your employees well. You can’t pay your bills or afford your hobbies outside work with culture.

Re: GitLab Strategy

#60

Post by bdcravens »

GreaterFool wrote: post #57
bdcravens wrote: post #20

Earlier quoted context omitted.

A lot of the development ecosystem had integrations with Github, and haven't yet done so with Gitlab. Additionally, network effects matter, especially when if you add collaborators to your repo it's almost a given that they have a Github account.

I assume you're talking about CI? Not much more than that. But that only works in the most trivial cases. One repository, simple tests. I spent tons of time over the years always tweaking this and that to make whatever CI system we were using somehow work with GitHub. Lot's of setup, lots of trouble.

Not just CI. Various bug trackers, project management tools, static analysis tools, etc.
Post reply on HN