
Gitlab features that are moving to open source - markdog12
https://about.gitlab.com/blog/2020/03/30/new-features-to-core/
======
ddevault
Since there are GitLab insiders in this thread, a question: has GitLab ever
discussed the possibility of simply making Enterprise Edition _actually_ open
source/free software, all at once, and simply continuing to charge for it like
you already do? You can sell free/open-source software, and you already offer
things like paid support in your pricing model.

~~~
sytse
Thanks for asking Drew and congrats the rapid progress on sourcehut.

Yes, we actually started by making making Enterprise Edition actually open
source. When we announced there would be a proprietary part of GitLab people
mentioned that Wordpress plugins where able to make it work with an open
source license. It was a comment on
[https://about.gitlab.com/releases/2013/08/22/introducing-
git...](https://about.gitlab.com/releases/2013/08/22/introducing-
gitlab-6-0-enterprise-edition/) but the comments there seem to have
disappeared. So instead of making it proprietary we licensed it with an open
source license but without offering a download, you had to pay to get access
to the source code (this is similar to the Wordpress plugins and also not
unlike Red Hat Enterprise Linux updates).

We were afraid that people would put up a mirror with the paid code, this
didn't happen. But our customers told us that it was hard to justify paying
for open source code, they got lots of questions from their managers. So we
switched to making the additional features proprietary.

We tried charging for support but it is hard to make enough margin to be able
to invest in the things we wanted (scalability, security, library upgrades,
easy of use, etc.). People tended to cancel after they didn't use support for
a year. I believe that most companies charging only for support are tempted to
make the product harder to use to increase the need for support. More about
the business models we tried can be found on
[https://about.gitlab.com/blog/2018/11/09/monetizing-and-
bein...](https://about.gitlab.com/blog/2018/11/09/monetizing-and-being-open-
source/)

~~~
ddevault
Thanks for the detailed answer! I'm glad to hear that some thought has gone
into this. For a direct comaprison of SourceHut's financial model with GitLab,
see:

[https://sourcehut.org/blog/2019-10-23-srht-puts-users-
first/](https://sourcehut.org/blog/2019-10-23-srht-puts-users-first/)

Though it's definitely _easier_ to go with the GitLab approach to
monetization, I pointed out a lot of problems that these incentives set up.
I'm not sure how you're going to avoid some of these problems. That being
said, I imagine that it would be extremely difficult GitLab to change course
so sharply at this point in its life.

To be clear, I recognize that GitLab EE, as a source-available distribution,
is a measurable improvement over GitLab's closed-source offerings. I think
GitLab is a valuable tool and an ecosystem without it is poorer than an
ecosystem with (though, an ecosystem without SourceForge would be nice...). I
hope that you guys are able to balance your incentives and stick around to
provide a good service to the community, and I hope you keep it up with
merging EE features into CE.

~~~
kikoreis
I am not sure I had ever read Gitlab's rationale for its business model
outlined in this detail anywhere, and I found it fascinatingly similar to our
own. I wanted to share that Canonical's 15-year experiment in business models
has lead to similar conclusions: if you want to scale, you need to 1) to make
it very clear why your customers should pay, and 2)take into account that
buyers in general are less sophisticated in their decision making than we
would hope for. I think the general move to freemium/open core models is
recognition that other models are very high-risk.

I can't tell you how many times I have heard from a suit and tie buyer that
they can't justify paying [that much] for open source, and even when you can
answer that question in a compelling way, the message is diminished along the
way to procurement. And that's erosion of margin.

You're right that there is an inherent conflict in freemium between the free
version's feature set and the paid-for version, but that just means you need
to weigh your options carefully along the way, and ideally come up with some
simple to understand strategies/rules of thumb that your team can use when
deciding where the products need to go.

Note also that it's not like other less controversial models aren't without
conflicts of their own. For instance, support models set up a conflict with
the quality of the product, because high quality, "It Just Works" products
don't help users value support highly -- yes, even when the users are Fortune
100s, amazingly. Similarly, SAAS models are naturally incentivized to make the
software complex, undocumented, hard to install and challenging to operate,
lest the value proposition of the paid offering becomes convenience only,
which is very hard to capture margin with for relatively low-volume B2B
products.

In the end, I guess I'm saying that Gitlab's approach isn't necessarily
easier; it's just much less risky and therefore scales much better.

~~~
izacus
Yeah, one of the important lessons here is: Buyers just aren't rational. Even
multi-billion companies are driven by manager egos and biases and they will
make dumb decisions based on prejudices.

Unfortunately, the Oracle/IBM marketing of "Opensource is trash" has proven to
be very sticky so selling OSS to Enterprises companies can be a hugely uphill
battle when managers think that OSS products are inherently low quality in
comparison to highlghy priced "brand name" stuff. Giving them away for free
with paid support is very contraproductive when your purchaser has this line
of thinking - they just percieve this as "this product is so bad they need to
give it away for free".

~~~
ddevault
Note that I explicitly pointed out that you don't have to give it away for
free - you can charge people for the source code _and_ use a free/open source
software license at the same time. It does prevent you from charging a
subscription fee (or at least makes it ineffective), but you can also deny
them access to updates unless they pay up. Sure, someone could stick the code
online somewhere else, but now customers would have to trust some random third
party to forward the legitimate code to them, and this third party has to
compete with your established marketing funnel.

------
Freak_NL
Gitlab is really great for companies who wish to self-host their tools, and as
a source code repository it is great at the free tier. But for small companies
who might wish to migrate their issue tracking to Gitlab as well the pricing
of the paid tiers is prohibitively expensive.

What would really help me is a self-hosted pricing tier that includes things
like epics and roadmap management, for something like $2/user/month. No need
for support, just a way to contribute to the product without breaking the
bank. After all, we're already self-hosting the software, so without support
exceeding that of the free tier it wouldn't cost Gitlab a thing, but it would
allow smaller companies to support Gitlab financially.

~~~
foepys
You pay your employees thousands per month and rent an office for several
hundreds per month. Most people here seem to buy absolutely overpriced Mac
Book Pros for $3000. When you cannot pay $4 or $19 per month extra for each
employee to be more productive, you have problems beyond that.

This "everything must be free" mentality is driving me crazy. And yes,
$2/month/user is still ranging in the "free" region, even $4 is ludicrously
cheap when you are even a minute more productive each day. Somebody has to pay
Gitlab's employees and VC money wont do this indefinitely.

~~~
Freak_NL
You seem to be well aware of the financial resources at my disposal and the
salaries paid at my company. Do we have a data leak?

Besides, epics and roadmaps pushes the price to $19/user/month, which we can't
afford. $4/user/month might be possible, but the epics and roadmap features
are a must have at that point.

~~~
KaoruAoiShiho
Do you guys want to chip in and create something like an open source version
of Instagantt for Asana, but "Epics/Roadmaps for Gitlab".

I think something like $3000 one time payment should be enough to clone the
feature from scratch.

~~~
base698
This exists in Gitlab already.

------
xrd
Gitlab CE is just amazing. It's hard to fathom going back to GitHub (and I
wrote a book for O'Reilly about the GitHub API). The tight integration with CI
rather than using external services is amazing.

~~~
rattray
Have you tried Github Actions? (I haven't, just want to calibrate).

~~~
nhumrich
Github actions is nowhere near as polished/mature ad gitlab ci. Github actions
feels more like a "hack blocks together" than a true pipeline.

~~~
gitgud
Github actions is confusing and has a steep learning curve, but the
flexibility of using Docker makes it fast and reliable to _hack_ together
workflows.

~~~
xrd
Are you suggesting gitlab ci isn't docker? All my pipelines are some docker
variant. I'm not sure if you are just suggesting actions was done the right
way with docker, but that's nothing special with gitlab ci. Can you clarify?
You can even use your own docker repository with gitlab, though I'm unsure if
that's something that only comes with EE (I haven't needed it yet, I just keep
all my extras in the gitlab ci yaml file).

~~~
gitgud
> _" Are you suggesting gitlab ci isn't docker?"_

Sorry, I'm honestly not familiar with Gitlab CI. I was just originally
mentioning how the use of Docker in Github Actions allowed for amazing
flexibility, which I thought was cool.

What makes Gitlab CI a better or more polished API than Github Actions? At
first glance they look very similar

------
zmmmmm
Gitlab as both a product and a company continues to amaze me with the quality
and value of what they create and give to the community.

~~~
mekster
Have they started hiring shills? These reactions defer greatly from what I had
seen a year ago for bad designs and high load.

~~~
zmmmmm
No relationship to Gitlab. But do work for an organisation that uses it very
heavily and gets entirely by with the open source version (plus various
scripts that use the API to fill in some of the gaps).

------
chrisseaton
I had no idea there were any closed-source features - I thought Gitlab was a
passionately completely open-source company. They even open-source their
arguments between their legal counsel and their developers!

~~~
rpaik
Please see my response above. Enterprise Edition(EE) code is open to everyone
and wider community members have also been contributing to EE.

~~~
ddevault
This code might not be closed source, but it's definitely not open source -
please be careful about your language. It's source available. Open source
software is software which meets the open source definition:
[https://opensource.org/osd](https://opensource.org/osd)

If GitLab truly cares about open source (and I believe you do), you should be
protecting the term from misuse.

~~~
sytse
I totally agree we shouldn't call it open source if we mean proprietary and
source available. We changed the classification of our company from open
source to open core a while ago
[https://about.gitlab.com/blog/2016/07/20/gitlab-is-open-
core...](https://about.gitlab.com/blog/2016/07/20/gitlab-is-open-core-github-
is-closed-source/) Sorry for the inconsistency in this thread.

~~~
ddevault
Thanks, "open core" is a classification I would agree with for GitLab. Cheers!

------
nmaludy
Bummed that Pull Mirroring isn't on the list. I really want to use GitLab for
CI/CD, but we dont want to store our code there exclusively. Instead we use a
series of scripts to work around this problem. Would be great if the core
platform just supported this.

~~~
davidcorbin
This. Pull mirroring is a must before my team would considering using it.

------
mgbmtl
I'm really excited by the availability of the helpdesk feature. It will help
our FOSS project reduce the number of mailing lists we have (such as the
security@ or some other public-facing lists).

~~~
sytse
Awesome! Getting your support emails converted into issues so you can work on
them as a team tends to make it much clearer who is handling what.

------
veeralpatel979
Will these features be available in gitlab.com for free users as well?

~~~
sytse
Yes, free users with private repos have the same functionality as is in the
Core edition of GitLab self-managed, the open source feature set. Free users
using a public repo additionally get all proprietary features.

------
mch82
Nice set of features! I’m especially excited about the package managers.

------
laktak
Will it be possible to customize these features?

I'd like to turn off Kubernetes integration for example.

------
apple4ever
That's great! Changes I'd really like to see:

Down to starter: epics, roadmaps, HA, Free Guest users Down to premium: SAST,
Dependency Scanning, DAST, Vulnerability Management

------
jbk
This is really cool.

I just wished they had moved Scoped Labels to Free too.

And I would love that the SAST framework goes to Free too and kept have the
security scanners Premium. That would allow to have basic code coverage
directly in Free, without the complex static analyzers, which would be
reserved for premium...

~~~
jamesh-gl
Hi there!

GitLab Product Manager here. You can generate code coverage reports today and
use the generated value to populate a project badge value
([https://docs.gitlab.com/ee/ci/pipelines/settings.html#test-c...](https://docs.gitlab.com/ee/ci/pipelines/settings.html#test-
coverage-report-badge)) or publish the
report([https://about.gitlab.com/blog/2016/11/03/publish-code-
covera...](https://about.gitlab.com/blog/2016/11/03/publish-code-coverage-
report-with-gitlab-pages/)).

We understand these are not the only use cases for code coverage and really
just scratch the surface. We are working on the next set of features to build
this category out further and would appreciate any input you might have on the
issues there([https://gitlab.com/groups/gitlab-
org/-/epics/100](https://gitlab.com/groups/gitlab-org/-/epics/100)).

Thanks!

-James H Product Manager - Testing

------
deckar01
I am a GitLab contributor. I have been fighting for years for them to explain
why basic features were getting shoehorned into paid tiers. This is years too
late, and it falls short of addressing the source of the issue. The people who
are making these decisions seem to have an incentive to restrict features to
paid tiers. It's a business, I get it, but they are taking basic features that
the community could implement, and locking them away in a paid tier. Sometimes
a front-end only change, all the data is already available, marked as a paid
feature. I used to constantly come across features I needed that had landed in
a paid tier where I could write a grease monkey script to do it in a few lines
of code, so I would post it as a snippet to illustrate how ridiculous it was.

~~~
rpaik
First of all, thanks for being a GitLab contributor. Could you share other
features you're concerned about? (If you have a link to issues that'd be
great)

~~~
deckar01
Description change history just landed as a paid feature.

[https://gitlab.com/gitlab-
org/gitlab/-/issues/10103#note_152...](https://gitlab.com/gitlab-
org/gitlab/-/issues/10103#note_152161361)

Repository push mirroring is available in CE, but pull mirroring is a paid
feature.

[https://gitlab.com/gitlab-
org/gitlab/-/issues/19095#note_272...](https://gitlab.com/gitlab-
org/gitlab/-/issues/19095#note_272839987)

------
weitzj
I am using GitLab in my work environment and I really try to embrace it. But
some features one just expects from a basic Jenkins setup are either missing
or weirdly implemented and feel like duct-taped into GitLab.

Take for example:

\- Code coverage reports:

You can have one absolute number to get your total coverage. To get the number
you have to provide a Regex deep down on the main project settings. This Regex
has to match some log output of your CI job in order to be picked up, e.g
“Total 87%”.

Why can’t GitLab collect cobertura Test reports for example?

\- Unit Test Results:

Collecting JUnit test results is disabled by default, since there is a warning
about a performance issue when collecting them
[https://docs.gitlab.com/ee/ci/junit_test_reports.html#enabli...](https://docs.gitlab.com/ee/ci/junit_test_reports.html#enabling-
the-feature)

\- collecting multiple artifacts as HTML pages:

to circumvent the above downsides, you can get creative, and generate HTML
websites of the Unit test and Coverage reports themselves and publish them
somewhere. An ideal place would be GitLab pages.

But you are only allowed to have one publish job for GitLab Pages. And this
publish job has to have a special name so it is recognized for publishing
GitLab Pages. The artifacts you want to publish have to be in a special named
folder in order to publish them. So you fallback to some hackery by using
“mv,mkdir”

[https://about.gitlab.com/blog/2016/04/07/gitlab-pages-
setup/...](https://about.gitlab.com/blog/2016/04/07/gitlab-pages-setup/#add-
gitlab-ci)

These were some examples which I find not that exotic for a CI setup and I
know from previous experience that Jenkins handles all these with ease. To
circumvent this shortcoming, we introduced SonarQube.

I feel that people often are drawn to a shiny, small GitLab CI yaml and are
happy to get started so fast. But again having Jenkinsfiles with shared
libraries, which you can program in Java and Groovy, is superior to the next
yaml include/extend you are going to add.

My 2cents are that:

If you are a solo developer or a small company Gitlab might be fine for you.
When your company is larger and you want to be able to share knowledge using
shared libraries, have a streamlined CI setup with GitLab includes from
multiple departments, GitLab gets tough.

How could one be confident to use for example their 1-click deployment
(autodevops) Feature if the implementation of CI basics like collecting test
results and coverage reports have this weird taste to it?

I wish these features will get better and please don’t take this too harsh. My
tone might sound worse than it is.

~~~
jamesh-gl
Hi there!

GitLab Product Manager here. I really appreciate the feedback on those
features and it helps inform some upcoming work to make them better. The team
is currently working on improvements to JUnit parsing
([https://gitlab.com/groups/gitlab-
org/-/epics/2854](https://gitlab.com/groups/gitlab-org/-/epics/2854)) so we
can enable those Junit reports by default.

We are also working on the next set of code coverage features to build this
category out further and would appreciate any input you might have on the
issues there as we're prioritizing and scheduling for the next few milestones
([https://gitlab.com/groups/gitlab-
org/-/epics/100](https://gitlab.com/groups/gitlab-org/-/epics/100)).

Thanks!

-James H Product Manager - Testing

------
2ion
All not very relevant. They keep the core business features (like merge
request approval) carefully out of the OSS edition. And they haven't fixed the
pricing for their premium offering either.

~~~
lxn
Relevant is subjective. Merge request approval is not something a single
contributor needs for example.

You can still get it by paying for it. In the end GitLab is a business,
someone needs to pay something. As developer who runs a GitLab server for
personal projects I don't miss any paid features.

~~~
Carpetsmoker
Rather makes sense, because for many open source projects with a single or
handful or contributors it's not a very important feature, but for larger
teams (i.e. companies) it is, which ensures they pay their fair share while
still keeping the product available for free for most of us.

~~~
m4rtink
Still, having _any_ features that are propritary and thus off-limits to
contributors does not create a good community atmosphere.

Say as an example that Debian, which has a big user of GitLab wanted this
feature, so the Debian project contributors create all the patches & submit
them for inclusion in the open source part of GitLab. Normally, a project
would welcome any (presumably) well written patches like this. But with open
core project this creates an instant conflict of interest.

Either GitLab takes such patches, loosing their proprietary edition exclusive
feature & possibly even compatibility with their closed source implementation
of it. Or they reject the patches, presumably loosing a lot of goodwill with
the community and forcing Debian to maintain those patches for ever in their
own fork of GitLab.

All in all, I don't see open core companies like something to invest ones
contributor time to due to this & more importantly like something to use and
make you open source project to depend on.

~~~
Carpetsmoker
The alternative is GitLab not being able to hire developers to actually build
GitLab since the "kindly ask to please pay"-model doesn't really work very
well.

"The community" is often vastly overrated anyway IMHO. Patches are always
good, of course, but people who actually consistently invest time in a project
are exceedingly rare. You can't build a product based on sporadic patches.
Besides, a lot of the time "the community" is just users (people with no
contributions) complaining you're not doing stuff right.

Unless you have a viable (preferable proven) model that allows GitLab to hire
developers _and_ keep everything 100% open source, it seems to me this is the
best and most balanced option. To the best of my knowledge, such a model
doesn't really exist.

I continue to be surprised at the hesitancy (or even outright hostility)
whenever someone tries to make an economically viable open source product,
which usually involves things not being 100% open source because turns out,
that's the only way to make things viable. "90% open source" is a hell of a
lot better than 0% open source in my book.

~~~
cycloptic
The oldest viable and proven business model where you can keep 100% open
source, is to sell support contracts and warranties. This model is harder for
your average SaaS company to pull off but provides much better ROI if you can
actually do it.

~~~
Carpetsmoker
It only works well if you have a decent amount of large enterprise customers
(like RedHat); I don't think it will work out well for GitLab, which is mostly
aimed at small-to-medium businesses. I don't think it's viable for most
projects (otherwise they would be using it).

Even if it is viable, you're usually leaving a lot of money on the table, and
even Red Hat – the poster child of this model – does stuff like releasing
updates to paying customers first.

~~~
cycloptic
You are always leaving money on the table. The choice of business model is
only a decision of whose table you are going to leave it on. The downsides of
the open core model have already been mentioned here. I am not suggesting that
GitLab change their business model, I don't have any opinion about what they
should do. But I will say that releasing updates to paying customers first is
still consistent with being 100% open source, as long as those updates are
still released to them under an open source license.

