
The market figured out Gitlab’s secret - tosh
https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/
======
whalesalad
Every time github releases a feature this is the response. These posts are so
pathetic. I’m surprised that they continue to play this angle. It’s a very
polarizing way to address the community that will definitely continue to stir
up us vs them mentality between GitHub and Gitlab users.

~~~
frabbit
GitLab don't have to worry too much. Their uptime has been fine for us over
the course of several years. And it's good that GitLab is around, so that we
don't have to worry quite so much about Microsoft/GitHub messing around with
the code in international projects. They have a great history[1] of co-
operating with nefarious people. (And no, most people do not sign their
commits and watering hole attacks are an obvious worry).

1\.
[https://news.ycombinator.com/item?id=20645964](https://news.ycombinator.com/item?id=20645964)

~~~
ldoughty
I use Gitlab CE and I certainly prefer it to GitHub. The interface just makes
more sense to me as an operations-first guy. The CICD connections are great.

That said, I do SOME work in GitHub to stay familiar with it. And I've set up
web gonna to push to lambdas, but I would probably hate that process if I
wanted to clone a private repo and had to deal with the security there.

------
asadkn
For all the bashing GitLab gets, personally, I want GitLab to survive and keep
competing at some level with GitHub.

Should GitHub dominate the market and gobble up competition, we all know how
it goes for its parent company.

~~~
jvanderbot
As soon as gitlab sprung up, I got unlimited free repos and shortly after CI.

I'm happy with this competition.

~~~
m1sta_
Praise be to the teams that patron the second best and keep the first best on
their toes.

------
dessant
Some will continue to prefer a self-hosted GitLab instance over GitHub, but
requiring _at least_ 4GB of RAM [1] for a low traffic instance sounds like an
aberration. There should be better ways to manage memory consumption, and a
lean GitLab instance that we have full control over could still be their
selling point over GitHub.

[1]
[https://docs.gitlab.com/ce/install/requirements.html#memory](https://docs.gitlab.com/ce/install/requirements.html#memory)

~~~
sytse
We agree 4GB is too much. We put a team together to get the memory usage down
[https://about.gitlab.com/handbook/engineering/development/en...](https://about.gitlab.com/handbook/engineering/development/enablement/memory/)
They’re rolling Puma out as an application server on .com within weeks. After
that is successful we’ll make that the default. That should save a lot. After
that the memory team will keep improving it.

------
vemv
> Well, if you don’t believe that it’s better for a user, at least believe
> it’s more efficient for us, because we only have to release one application
> instead of two. Efficiency is in our values.

Wow, this is some terrible reasoning. Efficiency and cardinality are
orthogonal.

For a company of the size of Gitlab, releasing two apps instead of one
shouldn't be much of a burden.

Now two different concerns' uptime and performance are coupled.

No wonder that Gitlab has an infamous track record when it comes to response
times / uptime.

(more constructively: I'd point out that both end-users and GL developers
could have an equally unified experience while the concerns remained separate.
Good architecture makes it possible)

------
konschubert
What a strange post.

GitLab is under siege from GitHub.

The argument for GitLab has always been that they are more feature-rich, the
argument for GitHub has been that their uptime is >80% and their UX is
excellent.

If GitHub achieves feature parity, GitLab is dead.

~~~
tjoff
The arguments for gitlab are that they are open source and that self-hosting
isn't an afterthought.

We need more of both.

~~~
SEJeff
Unless you want their enterprise features. Gitlab is open core.

~~~
majkinetor
However, that core is REALLY BIG. I do not really miss any enterprise feature.
I ordered enterprise edition only to support it and I never installed it.

~~~
SEJeff
Well a lot of _enterprises_ care about things like user directories (LDAP) and
the extra access control. Just because you don't need enterprise features
doesn't mean that large enterprises (the target audience for Gitlab
Enterprise) don't!

I'm not saying it isn't great stuff, it really is, but "it is all open source"
is sort of a misnomer. It is open core.

I'm of the same opinion with Dave Neary on Open Core Software. He's a long
time contributor to the GNOME Desktop Environment:

[https://blogs.gnome.org/bolsh/2010/07/19/rotten-to-the-
open-...](https://blogs.gnome.org/bolsh/2010/07/19/rotten-to-the-open-core/)

~~~
majkinetor
You are right in general. Most open core tools do not let anything enterprise
like into community versions. However, Gitlab is somewhat different. For
example is that it lets you have LDAP/AD integration in core version. Compare
that to lets say Mattermost which doesn't.

And yes, I need enterprise stuff, I just don't need enterprise stuff currently
in Gitlab. Looks to me those stuff are created for really big teams and really
big multinational companies. My company is 1200+ employees big with IT having
around 70 people, and in that context I don't miss anything.

Futhermore, some enterprise features finish in core after some time. I have
never witnessed the opposite in Gitlab.

------
groundlogic
This seems like misdirection. Gitlab's largest problem is their record of
operational incompetence. This will take some time to recover from.
Personally, I won't use them for a least two more years, based on their data
loss incident two years ago.

I do wish them luck. Github/Microsoft should have a credible competitor.

------
comex
What a strange post. Considering the timing, it seems like it must have been
posted in response to GitHub's announcement of new CI/CD functionality (also
on the HN front page):

[https://github.blog/2019-08-08-github-actions-now-
supports-c...](https://github.blog/2019-08-08-github-actions-now-supports-ci-
cd/)

But if so, it's quite a backhanded response – the post itself only mentions
GitHub in passing.

~~~
wiremine
Not sure the down-line developer community is the audience for the post (or at
least, likely not the primary audience).

They took $100M in D round funding in last 2018 [1], so it's likely a victory
lap to validate their investment, and also a "see, you should buy us" post for
engineering managers buying their services.

And, that said, they aren't wrong. It's a solid model.

[1]
[https://about.gitlab.com/2018/09/19/announcing-100m-series-d...](https://about.gitlab.com/2018/09/19/announcing-100m-series-
d-funding/)

------
kareemm
GitLab is right.

I ran a company that was in the GitHub marketplace and was a partner. At the
GH partner day a few years ago they shared their view the world: their
thinking was that it was preferable for devs to be able to use “best in class”
tooling for CI, project management, etc, with gitHub’s version control at the
center.

GitHub contrasted this with the “one stop shop” approach where you get all
your Dev needs met with (presumably) inferior tools from a single vendor.

Because, the thinking went, how could one vendor do everything better than
many vendors? Especially if you have sets of vendors focused on one tool in
the Dev toolchain?

Between Projects, Actions, and CI/CD, it seems GItHub has indeed come around
to the one stop shop view of the developer toolchain.

I guess each of those only has to be good enough and not best in class. And
there are efficiencies to be gained for customers from an integrated approach.

------
tosh
I found the post interesting from a product-management angle.

The decision to fuse the two components (SCM and CI/CD) must have been quite a
leap of faith. Wasn't aware of this.

------
statictype
_GitLab will automatically detect where in your codebase that vulnerability
exists, update the dependency, and deliver it to your production environment._

Auto patching and deploying to production in an automated fashion sounds like
a terrible idea. Do people actually do this? Does it work for them?

------
deckar01
I think what GitLab really needs is what a lot of open source projects are
lacking: popular community forks. Their product development benefits from the
community's QA feedback, but there are no community forks (that I am aware of)
that are taking GitLab CE in directions that gitlab-org won't go. IO did this
for Node and everyone has benefitted.

I think GitHub's UX has caused new developers to lose true meaning of fork.
When software doesn't work the way you want it to, you fork it, and if other
people want it enough, they will merge it into their own forks and maybe some
day it will get adopted upstream.

~~~
sytse
We had companies forking GitLab instead of contributing upstream, they all
fell behind with upstream and couldn’t keep up to date anymore.

Any examples of things you see that we at GitLab Inc. are not open to?

~~~
deckar01
[https://gitlab.com/gitlab-org/gitlab-
ce/issues?state=opened&...](https://gitlab.com/gitlab-org/gitlab-
ce/issues?state=opened&author_username=deckar01)

As more of the feature development goes into EE, there is less of a need to
back port the latest changes. There are tons of workflow processes I would
love to more tightly integrate with GitLab, but not all of them would make
sense outside of my organization. Some of them can be hacked together with
bots, but some of them require extending the core functionality and would
probably require a fork.

> forking GitLab instead of contributing upstream

I think this is the problematic mindset. Meaningful contributions to upstream
will follow useful forks.

> they all fell behind with upstream and couldn’t keep up to date anymore.

Code churn doesn't just slow down forks, it slows down core development.

------
ken
> At the time I believed we needed to have tools that are composable and that
> could integrate with other tools, in line with the Unix philosophy. Kamil
> convinced me to think about the efficiencies of having a single application.

The Unix Philosophy is dead today, but I don't believe that's because of any
inherent flaw in the principle of "composability". It's that we no longer have
a good composition mechanism for the types of programs that people run.

In 1975 or 1985, you were running a command-line tool to process some data.
(That kind of sucked, but whatever, that's what we had.) The idea of being
able to pipe bytes from the output of one to the input of another is pure win.
Fewer steps, no temp files, see results as they are completed -- and the cost
is literally one character. No wonder it took off.

Today, the types of programs people run are native apps (which don't have an
obvious I/O mechanism, apart from the filesystem, if that) and web pages
(i.e., programs awkwardly split across my computer and some server in
Virginia, speaking an ad-hoc protocol). Making them talk to each other takes a
developer and a month.

I'd _love_ to be able to have a web app, a word processor, my contact list,
etc., talk to each other and easily and meaningfully pass data between them
(and I'm working on software to do just that -- see my bio). Why _can 't_ I
pipe my Facebook friends list straight to a spreadsheet, or a map?

They speak of the efficiencies of having a single application. It's more the
lack of an efficient standardized way to combine different applications. Back
when it was "type one character", the efficiency argument went the other way.
We need to get back to where sharing data with every other program is the
default.

~~~
DreamScatter
The Julia language can solve all those composability problems you are having,
much of the package ecosystem is very composable. It is currently focused on
scientific computing, but it is a full general purpose language.

------
alephnan
Amazon was not the first online bookstore, nor is Apple first to market with
their product features. Funny thing is, they made it sound like they pioneered
the idea of:

> Realizing the future of DevOps is a single application

Google already realized the value of coupling their version control to CI
years ago

------
luord
Seems like marketing speak, and weirdly self-congratulatory in a not entirely
correct way (reminds me of announcements made by Apple, in fact), but they're
not wrong.

------
Legogris
All else aside, I realized that if you add hosting and assume dogfooding,
GitLab's product is a platform made for building, configuring and running the
platform you're building, maintaining and configuring... It feels
Hofstadterian from several angles.

> Idera acquired Travis CI

This is disingenuous. That acquisition is not a validating example.

That aside, I don't feel a need to read in as much passive-aggressiveness as
everyone commenting does. It's a bit of rivalry, sure.

Resource-usage aside, I was happy self-hosting GitLab for years.

