
GitLab Direction - jmilloy
https://about.gitlab.com/direction/
======
whitepoplar
GitLab is like the average kid in class that everybody makes fun of for
constantly asking questions, but the joke's on them because "a little bit of
slope makes up for a lot of y-intercept." While GitLab may have warts, I feel
that they're very earnestly working to make the product better, bit by bit,
day by day, and will one day surpass GitHub.

~~~
sytse
Thanks! Incremental progress in the form of iteration is one of our core
values
[https://about.gitlab.com/handbook/values/#iteration](https://about.gitlab.com/handbook/values/#iteration)

~~~
tempaccount777
I have some questions to ask of you.

1\. Why does gitlab have so many tiers? It would be better if you guys could
repackage the features into fewer categories.

2\. Why is the Gitlab UI so ugly? IMO, bitbucket and github are leaps and
bounds ahead of you guys when it comes to design.

3\. Can we get a dark mode for us night owls?

4\. Finally, the morality question, You guys proudly associate yourselves with
open-source and get help from loads of opensource devs, yet you greedily
restrict simple features like epics, burndown charts, roadmaps, configurable
issue boards etc. from the core/free categories. Looks like your key core goal
is to make money... how are you any different from microsoft or google?

~~~
brandonwamboldt
1\. They only have four tiers (four equivalent tiers for hosted and on-premise
technically). This is quite reasonable, as they need to provide flexibility
for their customers. They are quite clear about which tiers provide which
features.

2\. This is purely subjective. I quite like the design, both more than GitHub
and Bitbucket. They do have a UX team, and they conduct regular user tests.
They've also made a lot of improvements and continue to make improvements, but
design will always be subjective. You CANNOT please everyone

3\. I suggest putting a thumbs up for [https://gitlab.com/gitlab-org/gitlab-
ce/issues/18596](https://gitlab.com/gitlab-org/gitlab-ce/issues/18596), but
ultimately it does create additional work for the UX team so I don't know if
they'll end up doing it or not. You could try a user style, e.g.
[https://userstyles.org/styles/125366/gitlab-simple-
dark](https://userstyles.org/styles/125366/gitlab-simple-dark)

4\. GitLab is a company and needs to make money to continue employing
developers to continue developing their product. Open source devs volunteer
their time on GitLab CE, not any of the closed source features, and GitLab has
open sourced enterprise features in the past if the demand is high. Also,
there is nothing wrong with comparing them to Microsoft, as Microsoft has
thousands of open source projects and is quite the open source contributor.

I'd flip #4 on it's head. They aren't greedily restricting features, they are
generously open sourcing features and giving them away for free. As a
business, they have no obligation to do so.

~~~
tyldum
When my company subscribed there was only a community and enterprise tier. Now
this has become the starter edition and I feel we are losing a lot of value.
We are 200 employees, but only 10 developers using the advanced features. We
really want to make GitLab our hub (GitOps and all), however the the cost of
going beyond starter edition is mind blowing (x5). So if we are to embrace
GitLab further we must abandon the idea of letting the whole company use
GitLab freely and limit it to devs only.

Being small doesn't mean that we are not in need if advanced features, we just
have a smaller scale.

Also as our initial tier was the top tier, and now is the bottom one, I fear
GitLab will fence off future functionality with even more tiers at random.

Further, the tiers creates some artificial barriers where we several times
feel the some of the new features we receive are just barely functioning and
are just there to entice you to upgrade to the next tier.

We are all in all very happy with GitLab, however we are no longer pushing it
as a central hub for the company.

~~~
manigandham
You pay 200 employees but don't want to spend $19/user/month on software for a
company hub? That's not really a small company, and this seems like a
budgeting problem if money is that tight.

You can also try running multiple installations with a separate dev-only
instance with more features. Also have you tried contacting Gitlab to
negotiate? A few emails can go a long way.

~~~
bigtunacan
I would say 200 employees is fairly small company; and depending on the line
of business it is certainly small enough that profit margins and thus spending
may need to be closely watched.

If you consider that the OP has only 10 out of 200 users that need the
advanced features, but has to purchase the advanced features for all 200 users
for anyone to use those features that is $45,600 a year.

Now if it were possible for example to have a mixed licensing model; buy 10
Premium licenses for the users who need it and 190 Starter licenses for
everyone else then that is $11,400 a year. That is a difference of $34,200 a
year so it may be the difference between being able to hire another employee
or not.

~~~
manigandham
As stated, they can run separate instances, or spend 5 minutes contacting
GitLab to negotiate.

200 employees is not small, that is considered a medium sized business.
Millions of companies around the world never get past single-digits. With
payroll extending into 10s of millions, $35k sounds rather trivial if it
really is powering the company hub and the value that brings.

~~~
bigtunacan
"200 employees is not small, that is considered a medium sized business"

I'm just curious what your basis for that is? To go with some kind of
standardization on the term "small business" I would say the safest definition
(within the US) would be to follow the SBA guidelines that define a small
business. Depending on the industry a small business is defined by the SBA as
a maximum of anywhere from 100 to 1500 employees. So it is not cut and dry
that this is or is not a small business; industry and also potentially
revenues in millions of dollars would need to be known to determine absolutely
if it by definition a small business.

------
dstick
Thanks for sharing this! The transparancy of GitLab is amazing for people like
me who have no experience nor contacts in larger companies. The handbook is a
joy to read!

I discovered GitLab when researching CI/CD workflow and thanks to your tight
integrations had one setup within 24 hours.

Add to that the fact that 3 fellow Dutchies are the founders which inspired me
to apply our own Security startup to YC19 and all I can say is: keep it up!
You’re an inspiration :-)

The only bit of constructive criticism I have is that the Epic ‘feature’ being
locked behind the highest subscription is a bit weird. I’d love to be able to
create an epic for our first release version but can’t. If that feature could
drop a tier, that would be... epic ;-)

------
Spidler
What I'm missing is a different security model than the current `If an
endpoint can push to gitlab, it is trusted and can execute code server-side`.

There is no (current) way to enforce a 2fa step in order to push to a
repository, and while you can technically implement them, that doesn't mean
much, due to the nature of `git push`.

What I want is a 2fa-enabled review boundary between "commit" and "execute",
which currently isn't possible.

Protected branches can be unprotected without an auth step.

There's nothing on the server-side that signs `gitlab` generated merge-commits
in the commit graph, so no way to distinguish them from other merges.

There's no security boundary to change the deployment details, or to modify
the deployment pipeline to run from a different branch.

Basically, I'd want a way to ensure that there's an authenticated hand-off
between "commit" and "deploy" steps on the chain.

Also, it'd be nifty if one could get gitlab to maintain a version number,
increasing with every merge request merged, in order to get smooth tagged
builds when MR's are used.

~~~
jramsay
Hi Spidler, I'm a Product Manager at GitLab. Thanks for the feedback. Solid
security protecting deployment is very important.

In GitLab 10.7 we added branch unprotecting restrictions that can be managed
through the API to restrict who can modify protected branch rules
[https://docs.gitlab.com/ee/api/protected_branches.html#prote...](https://docs.gitlab.com/ee/api/protected_branches.html#protect-
repository-branches), and we'll be adding a UI to manage this soon too. I
created [https://gitlab.com/gitlab-org/gitlab-
ce/issues/49513](https://gitlab.com/gitlab-org/gitlab-ce/issues/49513) to add
an auth step for changing protected branches as well.

I'm interested to know more about the version number improvement you suggest
too. There are a few similar proposals like automated tagging on merge
[https://gitlab.com/gitlab-org/gitlab-
ce/issues/22363](https://gitlab.com/gitlab-org/gitlab-ce/issues/22363).

------
dom96
GitLab is a great service, not perfect but a good alternative to GitHub. I
actually use Gitter far more than GitLab these days, GitLab acquired them a
while back and I'm really disappointed to see it reduced to stagnation. The
product hasn't improved at all since the acquisition, you can argue that it's
"finished" and it is 90% there. There are rough edges that make it more
annoying to use than Telegram, Slack, etc. The primary one being how they
handle notifications on their Android app. It's annoying me every day that
this has been effectively broken for years now.

Maybe some of the GitLab guys that hang around here can answer my concerns.
Why are you guys neglecting Gitter?

~~~
MadLittleMods
Heya, I'm the current Gitter developer and was working on Gitter before the
acquisition.

After the acquisition, Gitter did stagnate with no movement as we settled into
our new GitLab roles and responsibilities but since May, we have been actively
shipping things again. Changelog: [https://gitlab.com/gitlab-
org/gitter/webapp/blob/develop/CHA...](https://gitlab.com/gitlab-
org/gitter/webapp/blob/develop/CHANGELOG.md). Catching up from the break in
development, a lot of work so far has been technical debt. We do have more
user-facing changes in mind like removing the disruptive large embeds
([https://gitlab.com/gitlab-
org/gitter/webapp/issues/714#note_...](https://gitlab.com/gitlab-
org/gitter/webapp/issues/714#note_88039992)), improving search
([https://gitlab.com/gitlab-
org/gitter/webapp/issues/1925](https://gitlab.com/gitlab-
org/gitter/webapp/issues/1925)), and decoupling unreads from emails
([https://gitlab.com/gitlab-
org/gitter/webapp/issues/1205](https://gitlab.com/gitlab-
org/gitter/webapp/issues/1205)).

One of the goals this quarter is to open source the Android/iOS apps,
[https://about.gitlab.com/okrs/2018-q3/](https://about.gitlab.com/okrs/2018-q3/)
but there isn't a plan to keep improving them with new features. We are
focusing on fixing the rough edges of the webapp and are happy to review your
Merge Requests for any project.

By Android notifications being broken, I assume you probably mean our double-
buzz avoidance, [https://gitlab.com/gitlab-
org/gitter/webapp/issues/1846](https://gitlab.com/gitlab-
org/gitter/webapp/issues/1846), but please make sure your particular issue is
tracked, [https://gitlab.com/gitlab-
org/gitter/webapp/issues?scope=all...](https://gitlab.com/gitlab-
org/gitter/webapp/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name\[\]=android&label_name\[\]=notifications)

~~~
dom96
Hey, thanks for responding.

> By Android notifications being broken, I assume you probably mean our
> double-buzz avoidance, [https://gitlab.com/gitlab-
> org/gitter/webapp/issues/1846](https://gitlab.com/gitlab-
> org/gitter/webapp/issues/1846)

That does indeed look like the issue I am experiencing. We've got a setup
where our IRC channel is relayed to/from Gitter so I am usually on IRC instead
of Gitter web. But this means that I need to manually discard mentions on
Gitter web, otherwise I get a notification that is super long containing all
my mentions. This means I cannot easily see what was said to me at the time of
the notification.

------
nathan_f77
A few years ago I really wanted to join GitHub as a software engineer. I was
living in San Francisco and visited their office for some events, and I
thought it would be an awesome place to work. I tried reaching out to a few
people who worked there, but I could never get my foot in the door.

There were a lot of things I would have loved to build at GitHub, and they
were all the same things that GitLab is doing now. I felt that there was so
much potential to build things like CI, DevOps, and eventually a PaaS to
compete with Heroku. I really think they should have acquired something like
TravisCI or CircleCI and made that part of their platform, but it seems like
they haven't really done anything significant in the last 5 years.

I'm a very happy user of GitLab now, and the product is awesome. But I don't
think I would ever join the company. First of all, they don't pay competitive
salaries for remote workers (cost-of-living adjustments). I also don't think
they have a very good company culture, and to be honest, it still feels a bit
sketchy that they ripped off GitHub and undercut them on pricing. But I'm sure
I'll get over that eventually.

~~~
fqb
Could you elaborate about the salaries for remote workers? I'm a frontend
developer in southern Europe and I'd love to work for Gitlab because I love
the product.

~~~
nathan_f77
I don't have any first-hand experience, and I'm sure there are exceptions.
I've heard that GitLab will pay around $80k for a remote software engineer in
a country with a low cost-of-living. That engineer could be earning
$150k-$250k at a different company (e.g. Basecamp, GitHub, etc.)

I realize that $80k is a lot of money for Europe/UK/Asia/South America/rest of
the US. But if you're a top engineer, you could double or triple your income
by working for a different company (or as a consultant.)

I should mention that I don't have any problem with GitLab's compensation, and
I think it's actually pretty fair. But fair doesn't really matter. A top
engineer will just go to the company that pays more. I'm sure GitLab has a lot
of great engineers, but just based on their compensation, I'm pretty sure it's
not one of the best engineering teams in the world.

Here's a few references/articles/job boards:

* [https://news.ycombinator.com/item?id=10924957](https://news.ycombinator.com/item?id=10924957)

* [https://dev.to/sam_ferree/why-i-think-cost-of-living-pay-for...](https://dev.to/sam_ferree/why-i-think-cost-of-living-pay-for-remote-workers-is-bs-5b68) (see some of the comments in there)

* [https://m.signalvnoise.com/basecamp-doesnt-employ-anyone-in-...](https://m.signalvnoise.com/basecamp-doesnt-employ-anyone-in-san-francisco-but-now-we-pay-everyone-as-though-all-did-3ee87013cfc2)

* [https://weworkremotely.com](https://weworkremotely.com)

* [https://remoteok.io](https://remoteok.io)

~~~
maccard
They have a calculator [0]

The same job, with the same experience is paid less than half what it is in SF
in the UK. That's not really very enticing.

[https://about.gitlab.com/job-
families/engineering/developer/...](https://about.gitlab.com/job-
families/engineering/developer/#compensation)

~~~
kabes
I don't know how they came to that calculator. But it seems that someone in
Ethiopia would earn $20k more than someone in the Netherlands (outside of
Amsterdam)

------
tfha
If you want to compete with GitHub for open source projects you are going to
need a 'releases' page that's similar (at least in function) to github's.

I would like to see that prioritized more, I think it's more important for
many projects looking to switch than many of the other features listed here

~~~
NickBusey
I just link to the project tags page, since the only tags we have are
releases, this works great.

~~~
tfha
There are no download statistics for that though

------
sciurus
There may be many things you can fault GitLab for, but dreaming big isn't one.

E.G. not many companies would have "becoming a platform-as-a-service" just
casually dropped in their roadmap.

[https://gitlab.com/gitlab-org/gitlab-
ce/issues/32820](https://gitlab.com/gitlab-org/gitlab-ce/issues/32820)

------
KeitIG
People tends to compare GitLab to Github, to me it seems more they compete
with VSTS or Atlassian.

CI, project management (epics and roadmaps), monitoring...

Github introduces really few features but seems to make them right, or really
limited, but never “bad”.

Gitlab on the opposite, works more with super-fast and open iterations,
without hesitating to roll-back if it just doesn’t work.

------
abuldauskas
One of my major pain points with GitLab was its API. The lack of coherent API
design ultimately made me lose hope in the product. For example I think it
still lacks an ability to create threads on MRs. Until recently it wasn't
possible to approve any MRs either, for 10+ versions of the product and 4+
versions of the api, but adding emoji was... The disjointed API made it nearly
impossible to create quality tooling on top of GitLab, ultimately forcing us
away from the product. It left a poor taste in my mouth, with a sense that
there was no rhyme or reason to the direction of the platform, unfortunately.

~~~
sytse
Are the APIs you need added now or are there ones still missing? Anything we
can improve in the API organization?

------
ephimetheus
Triggering pipelines only in merge request is what we’ve really really been
hoping for for quite while. Still seems pretty far out unfortunately...

~~~
lloeki
If you use the GitLab convention of naming your branches from the issue (like
it does when creating a MR straight from the issue), the MR branches will be
named /^\d+-/ so you can add a only: clause to .gitlab-ci.yml steps matching
that.

~~~
Drdrdrq
Probably a different issue, but one of my greatest gripes with CI is that I
can't limit steps to (for example) master branch AND having a tag. It seems
such a basic requirement, but is unfortunately not possible via .gitlab-
ci.yml.

------
dogweather
I find GitLab's upgrade tiers oddly chosen and quirkily implemented:

* The features don't seem to follow the costs of running them. I.e., they're economically inefficient. This makes GitLab less competitive. E.g., Some features held back for higher paying customers feel arbitrary in the sense that it's a marketing decision, not an ops/cost decision.

* Permanent nag text and nag links - annoying.

------
AFNobody
GitLab should, frankly, focus on performance/ux/bug-fix releases every other
release. And probably for the next 2-3 releases to get some of the warts under
control.

This constant push for project management features, frankly, is at the expense
of the core product. I'd rather use a combination of GitHub and JIRA over
Gitlab.

~~~
sytse
What is the nr. 1 performance/ux/bugfix you would like to see?

BTW This month we shipped 35 performance improvements
[https://gitlab.com/groups/gitlab-
org/-/merge_requests?scope=...](https://gitlab.com/groups/gitlab-
org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name%5B%5D=performance&milestone_title=11.1)
and there were 141 bugs closed in the release of this month
[https://gitlab.com/groups/gitlab-
org/-/issues?scope=all&utf8...](https://gitlab.com/groups/gitlab-
org/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=11.1&label_name\[\]=bug)

~~~
omeid2
I have a feeling that many people who constantly ask for "fixes" are the kind
of people who want to "fix them all", by rewriting without understanding that
it is a never ending cycle. Don't pay attention to them. Just do your thing.

Gitlab has provided the much needed competition with real impact (consider
Github boards, for example) and you have a company that can pay many people a
living. That is more than good enough.

~~~
sytse
Thank you very much for the encouragement, I appreciate it after significant
commenting today while flying from Mexico to San Francisco. You can rest
assured we'll keep working on our vision
[https://about.gitlab.com/direction/product-
vision/](https://about.gitlab.com/direction/product-vision/)

The people that ask for fixes care about GitLab and are worth listening to.
There is an almost infinite demand for new features and we can't make them all
(even with more then 2000 open source contributors). But I've found that
Hacker News readers have great insights and we'll keep listening and adjusting
were we missed the mark.

GitLab as a company was born on Hacker News
[https://news.ycombinator.com/item?id=4428278](https://news.ycombinator.com/item?id=4428278)
and although the tone these days feels like different I hope it is a bond for
live.

~~~
Qwertie
I just wanted to add that I have been absolutely loving gitlab. Signed up in
2014 and use it pretty much daily.

One of the biggest problems I had was the speed of the web ui but since the
great github migration the speed increased massively and has stayed snappy.

Contributing code to GitLab has also been my favorite experience with open
source as not only were my changes looked at, Gitlab developers actually
helped me get things working and write better code.

~~~
sytse
Thanks so much for commenting, awesome to hear you're loving GitLab.

We made a lot of performance improvements, I'm glad you're benefitting from
them. On
[https://about.gitlab.com/handbook/engineering/performance/#p...](https://about.gitlab.com/handbook/engineering/performance/#past-
and-current-performance) you can see what we're measuring. The monitoring of
our biggest merge request
[https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-
sum...](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-
summary?orgId=1&var-base=sitespeed_io&var-path=default&var-
group=gitlab_com&var-page=_gitlab-org_gitlab-ce_merge_requests_9546&var-
browser=chrome&var-connectivity=native&var-
function=median&from=now-30d&to=now) shows of our fixes regressed and we're
looking into what is going wrong. Screenshot for people reading this in the
future:
[https://www.dropbox.com/s/nlriugkzknu2tl9/Screenshot%202018-...](https://www.dropbox.com/s/nlriugkzknu2tl9/Screenshot%202018-07-22%2022.15.42.png?dl=0)

There is a lot more work to do and we'll keep shipping performance
improvements in code and to our infrastructure. The tentative date for our
migration to GCP is next weekend.

I'm so glad to hear that contributing code to GitLab was a favorite
experience! Kudos to our merge request coaches who try to get every merge
request over the finish line with a high quality.

~~~
sytse
The migration to GCP is now scheduled for August 11. See
[https://docs.google.com/document/d/e/2PACX-1vSSnHIgZoKXt_HuT...](https://docs.google.com/document/d/e/2PACX-1vSSnHIgZoKXt_HuTgypvfqzLxh4GMzZ43JK7LrPMtd65M7YCPx1sY4lvj7l27O0Vs7B9KUGj1VFcidq/pub)

------
substring
Gitlabs security is absolutely horrific:

[https://www.cvedetails.com/vulnerability-
list/vendor_id-1307...](https://www.cvedetails.com/vulnerability-
list/vendor_id-13074/Gitlab.html)

~~~
sytse
None of these was out in the wild. We take pride in requesting CVE numbers to
aid our users in remediation. We think that identifying and promptly fixing
vulnerabilities is key to security.

------
apple4ever
I'd love much more work on Issues. I'd replace JIRA with it if I could, but
Issues is very feature poor (and we are a light JIRA use case).

------
coderesearch
EU GDPR compatibility would be a cool thing - I am sure that people have been
asking for that "long time enough" ago.

Also now that this software has left prototype status for long enough time -
why are you still using ruby?

Ruby is much too slow and bloated for production - there are only a few
companies out there that missed the right time to jump from the ruby-
prototype-bloat and have enough money to burn to just stick with it, but for a
project like gitlab this is a huge problem. Judging from the roadmap there
seem to be many bored developers with no good ideas about what to do next, so
maybe unbloating could be a good direction?

There must be at least one person in that team with a feeling for
architectural brilliance?

