
GitLab Isn’t Really Open-Source - thefilmore
https://akr.am/blog/posts/gitlab-isnt-really-open-source
======
amingilani
There's honestly nothing new here. GitLab calls itself open core because only
the Community Edition (CE) is open-source and the Enterprise Edition is
source-available.

Anyone, after five minutes of looking at GitLab.com, knows this. They aren't
hiding it and it's already incredibly public.

They've even publicly talk about their 100+ user-relevant rule for features
that decides what CE doesn't get [1]

I don't understand what compelled the author to write this but GitLab CE
_really_ is open-source. Stop the FUD.

[1]: news.ycombinator.com/item?id=10923838

~~~
ktpsns
Furthermore, Gitlab has a brilliant documentation which makes very clear which
features are available in which version of the program. This distinction goes
even into the documentation of the (JSON) API.

What is advertised as open source is really open source, you can browse it
yourself. Find it at [https://gitlab.com/gitlab-org/gitlab-
ce](https://gitlab.com/gitlab-org/gitlab-ce) \-- btw, this is a ~3GB
repository, afaik you won't be able to host such a large repository at
github.com for free. With self-hosted gitlab, you can do this without any
hazzle.

~~~
dalore
Also the issues are all on public and anyone can comment and see what the devs
are saying about it.

------
dpedu
Even if every last byte of Gitlab and the bits behind it aren't OSS, it is
lightyears ahead of GitHub in terms of source availability. And while I
suspect the gap will only grow, I'd love for Microsoft to make me wrong.

~~~
draw_down
Exactly, which is what makes the "Microsoft LOVES open source!!!!" angle of
this acquisition so strange. If they love open-source so much why did they
acquire the closed-source service?

~~~
bdcravens
Because most of the open source world is more than happy to use that closed-
source service.

~~~
TAForObvReasons
Including Linux, which originally used the proprietary BitKeeper VCS system
before Torvalds wrote git.

~~~
tazjin
The Github repository for the kernel is a mirror of the actual kernel.org
repository.

The kernel does not use a Github-style workflow, either.

~~~
cma
He's not talking about them using Github as his example, he's talking about
them using Bitkeeper in the past.

------
benatkin
Here's how you get the instructions to install the open source version of
GitLab on Ubuntu:

\- Google "install gitlab ubuntu"

\- Click the first link

\- Choose Ubuntu

\- Notice that it says _ee_ in the command and think, oh, that's enterprise
edition, I want the open source edition: sudo
EXTERNAL_URL="[http://gitlab.example.com"](http://gitlab.example.com") apt-get
install gitlab-ee

\- Look around and finally find the link "CE or EE"

\- Read "If you're interested in using GitLab, we recommend you download and
install GitLab Enterprise Edition" and shake your head

\- Scroll to the bottom

\- Note that you fit into the category "If you only want to download open
source software Community Edition is the best choice" and think, maybe I'm one
of those "open source zealots" I've been hearing about

\- Click "Install GitLab Community Edition"

~~~
Improvotter
This is because the Enterprise Edition includes the Community Edition. If you
don't have a license, it'll use the EE as the CE version. This only makes it
easier for new people to get started. It also has the benefit that if you want
to switch, you don't have to set the entire thing back up.

Info: [https://about.gitlab.com/installation/ce-or-
ee/?distro=ubunt...](https://about.gitlab.com/installation/ce-or-
ee/?distro=ubuntu)

~~~
ljm
Why call it Enterprise Edition or EE everywhere when you have to write
documentation about the reason for that naming and the intricacies around the
licensing? And then explain that the unlicensed EE is actually CE which is
just the MIT licensed code and the other stuff is not under that license? No
one's going to expect that, they're going to think they're on a trial.

It sounds like a shady marketing ploy considering you could provide `sudo apt
install gitlab-ce` in addition to `sudo apt install gitlab-ee` (or even just
have `sudo apt install gitlab`). This isn't making it easier, it's just
shifting the burden onto the user and hoping they'll pay up because they got a
nerfed 'enterprise' install.

------
luka-birsa
I've been a user of gitlab for 4yrs+. Its a great tool and a nice alternative
to github for all us crazy "i want to have code on-prem" folks.

That being said gitlab ce and its relationship to ee is more and more
complicated. What started out at missing select features is now full out
armaggedon of lacking features. See latest releases and youll see that all the
cool stuff is comming out only to ee.

Whats even worse, the pricing is insane - some nice features are in the
extreme tier that costs insane ammounts od money.

There was a time when we considered dropping all other tools and moving to
gitlab. Now were actually migrating to jira for issue tracking. We're
considering jenkins as alternative to gitlab ci. And if we see the rift
growing too large, we'll move to phabricator (kindof sad we didnt go that
direction 4yrs back).

~~~
brianwawok
We went Gitlab to Bitbucket + Jira. Quite a bit more power, for less money
(even after paying for cloud testers).

~~~
jbergstroem
I think the Atlassian stack "wins" in the ~200-500 users range for enterprise
companies but price doubles if you want the "cloud edition" (read: run on more
than one vm). I asked for a few quotes of the gitlab EEU (ultimate) edition
and found prices competitive.

~~~
marcinkuzminski
You should check out RhodeCode as well. It integrates with
Redmine/Jira/Jenkins/TeamCity etc quite well, and it's suited to work for
teams of 100-1000+ with enterprise feature focus

------
ng12
> Both versions have their sources published on GitLab with the former having
> an MIT license and the latter a proprietary one which requires a paid
> subscription with GitLab.

So, it is open source? Doesn't this fall under the adage of "free as in free
speech, not as in free beer?"

~~~
zelphirkalt
Please don't confuse Open Source and Free Software. Open Source' ideals are
not "free as in free speech, not as in free beer?". That is something of Free
Software. Open Source does not care about the Free Software ideals. Except for
that one thing, that source code shall be available.

~~~
amyjess
The Open Source Definition [0] cares about more than just "that source code
shall be available". Among other things, it says "The license must allow
modifications and derived works" and "The license must not restrict anyone
from making use of the program in a specific field of endeavor".

In fact, the OSD is nearly identical to the Debian Free Software Guidelines
[1].

[0] [https://opensource.org/osd](https://opensource.org/osd)

[1]
[https://www.debian.org/social_contract#guidelines](https://www.debian.org/social_contract#guidelines)

------
jordigh
"Open core" is just plain ol' proprietary software. Mac OS X is "open core" in
the very literal sense that kernel and core are synonyms. It's really no big
innovation to be selling secret sauce on top of free software; Android is also
"open core" as is Matlab. Nowadays literally almost all proprietary software
has bits of weakly-licensed free software in it such as curl or React.

I've never been very impressed by GitLab's claims of openness. The only
difference seems to be that you can get most of the useful things of GitLab as
free software whereas Darwin, Linux, or LAPACK+FFTW are not the most
attractive parts of macOS, Android, or Matlab.

Call me when you manage to make a business without forcing any kind of EULA
whatsoever on your customers. That will be the real innovation.

~~~
pythonaut_16
I strongly disagree.

GitLab is open core because I can run and use the software in a meaningful way
under open source licenses.

MacOs is substantially different because I cannot take their open source
kernel and run a functioning version of MacOs

~~~
jordigh
Well, you used to be able to do that with macOS, but I think they stopped that
from happening in the last few years.

[https://en.wikipedia.org/wiki/Darwin_(operating_system)#Open...](https://en.wikipedia.org/wiki/Darwin_\(operating_system\)#OpenDarwin)

Gitlab may one day also decide that their core is too large and too useful to
let everyone play with it too.

Also, you're not strongly disagreeing with me. I said the same thing, the only
difference is that you can get most (but not all) of the useful things from
whatever GitLab currently considers its core to be.

~~~
innerspirit
Google took the same approach with Android, releasing non-OSS versions of
their OSS apps, and not updating the OSS ones anymore.

------
nightfly
Projects that follow the "open core" model bother me when they gate useful
features behind their paid version like Gitlab does. My organization would
benefit from the "Rebase merge requests before merge" and "Use fast-forward
merges when possible" features quite a bit, and we are an in educational
environment with lots of volunteers so using the Enterprise edition isn't
viable at all. These features aren't technically difficult to implement, but
even if we wrote open source versions of them we'd have to carry our own
internal fork of Gitlab since there is no chance upstream would accept them
since they've already decided they don't /want/ those features in the
"community" edition.

~~~
dpark
> _Projects that follow the "open core" model bother me when they gate useful
> features behind their paid version like Gitlab does._

I understand that criticism, but what else would you gate _except_ useful
features? The entire point of this style of sales is to enable a "freemium"
model with highly valuable features locked behind the pay-gate.

~~~
tonyarkles
In the parent's defense, the two features listed aren't really what I think of
when I think of "enterprise" features. I think more of things like SAML and
Active Directory integration, auditing, etc.

~~~
dpark
Sure, but that's essentially a branding criticism (labeling them "enterprise"
features) rather than a criticism of the "open core" model.

~~~
dnomad
This isn't really the "open core" model if the core is not actually open. GP
would like to contribute these features themselves to the open core but GitLab
likely would not allow it.

~~~
dpark
I don't agree with this assessment. Open Source does not require that the
maintainers will allow you to push changes upstream that they don't like. Is
AOSP not open source? Chromium? Atom? Linux? Linus rejects a lot of stuff.

Now, it may be poor stewardship if valuable changes are rejected, but Open
Source is about your freedom with the code, not the willingness of the project
maintainers to commit your pet features.

------
Kostic
I cannot disagree more. The open source core is very featureful for its price,
it's easy enough to host on premise and UX is very good.

Granted, the paid version has some nice features and there were some problems
in the past when people wanted to integrate features found in the paid version
to the open core but that's the price of living in current times. Money is
still needed to create and maintain something.

Maybe one day when we start living in a Star Trek society.

~~~
sytse
Thanks! The article asked "what chunk of GitLab will be considered “core” in
the future?". We try to detail this on
[https://about.gitlab.com/stewardship/#what-features-are-
paid...](https://about.gitlab.com/stewardship/#what-features-are-paid-only)
"All stages of the DevOps lifecycle is available in GitLab CE"

~~~
__manuels__
You are right, looks like the author did not even try to make any enquiries...

------
skywhopper
I don't really agree with the premise here. Gitlab is getting lots of new
users because of the Github/MS deal but if those users cared about how open-
source their git host was, they would not have been using Github. And the
value that Github and Gitlab.com provide have nothing to do with their source
code availability. They both provide a relatively trustworthy community
resource on which to share your code without having to run your own public
server.

Yes, Gitlab has generated goodwill by having an open-source version of their
product, and lots of people have tried it out for self-hosted needs. And so
they are the natural first place people will flock to. But the main reason
people are moving to Gitlab.com is because it provides an easy and open place
to host source code that remains (for now) independent from the tech
oligopolists.

------
greenhatman
Phabricator is 100% open source.

[https://www.phacility.com/phabricator/](https://www.phacility.com/phabricator/)

------
cjoy
In general I have sympathy for the free core + pay for enterprise features
approach. Seems like a fair model. Where it starts to fall apart for me, is
when basic quality of life features like a usable code review (do not trigger
a notification for every line I comment) are tagged as “enterprise features”.

------
vignesh_m
Whoa, those are some pretty big features I assumed were "core".Static pages,
fast-forward merges, Git hooks - aren't these core reasons to use a git
website instead of just git+remote

------
teraflop
Flagged as clickbait. "Gitlab Has Both Open-source And Closed-source Versions"
would be more accurate, but that's not as attention-grabbing a headline, is
it?

------
shazow
Like most things, "Open Source" is relative and spans a gradient.

It can be open but undocumented, it can be open but with closed components, it
can be open but broken, it can be open but closed to outside contributors, and
so on.

The most important question is whether it's forkable?

If X decided to go against its community, how painful would it be to fork X
and for the community to continue without the maintainer's support?

Is GitLab more open source than GitHub? Absolutely.

If I committed substantial resources integrating with "the GitLab way of doing
things" and then GitLab pulled the rug on me, would I be able to retain my
investment by forking off the product? For most things, yes.

I'm all for GitLab becoming even more open source, but they deserve the
accolades they've gotten so far.

------
rdtsc
> GitLab has two version of its software - GitLab Community Edition, the open-
> source version, and GitLab Enterprise Edition.

I think the context is the comparison with Github. So where is the Github open
source community edition with MIT licensing?

> The question then is - what chunk of GitLab will be considered “core” in the
> future?

None of the additional enterprise features seem to be core features so it's
just one core then? Maybe the author is not a native English speaker so it's
not clear what a "core" is.

~~~
tomcatfish
Believe the posters asking how we know that they won't shrink the feature set
in the future in comparison to the existing codebase by introducing updates or
quality-of-life improvements in the Enterprise version and not in the open
version

------
colemickens
It seems that most of the discussion has been around GitLab and then
Gogs/Gitea. I hope folks also give attention to other, possibly less-discussed
code collaboration platforms that have arguably more open development than
GitLab here.

For example, I believe Fedora is developed via Pagure, which also importantly
supports "remote" pull requests.
([https://pagure.io/pagure](https://pagure.io/pagure)) (Fedora's instance:
[https://src.fedoraproject.org/](https://src.fedoraproject.org/))

There's also Kallithea, but I haven't looked at it much. ([https://kallithea-
scm.org/](https://kallithea-scm.org/))

------
n4r9
I think I understand why this article was written, but earlier today I looked
up GitLab on Wikipedia and feel like I came away with a more comprehensive
understanding of GitLab's structure along with its history and motivations and
with less reading time to boot.

------
rburhum
GitLab open sources most of their core source. They never said they were 100%
- and even this concept is crazy.

At some point you have to realize that they need to have scalable business
model, and this is what they have chosen to do. Good for them, it is working.

------
ramshorns
It depends what you care about. Some would say it doesn't matter if the server
software is free and open source, so long as you can use the service without
running any proprietary software yourself. And GitLab is pretty good in that
regard, with the website's JavaScript under a free license.

[https://www.gnu.org/software/repo-criteria-
evaluation.html](https://www.gnu.org/software/repo-criteria-evaluation.html)

------
neuromantik8086
This isn't really that surprising when you see it as part of a general trend
of open source software being used to achieve vendor lock-in [1].

[1] [http://www.dr-chuck.com/csev-blog/2014/09/how-to-achieve-
ven...](http://www.dr-chuck.com/csev-blog/2014/09/how-to-achieve-vendor-lock-
in-with-a-legit-open-source-license-affero-gpl/)

------
watwut
Maybe, when we want comfortable hosting with all cool features one would wish
in one place for free, just maybe, it is impossible to have it forever.
Because the company and investors will run out of money one day, because we
are not paying enough to host our stuff.

Maybe google re-opens google code, but that wont be free open source either.

------
dosshell
> Rebase merge requests before merge

> Approve Merge Requests

What!? This is not true. You can both rebase and approve merge requests with
with Gitlab ce. You can even force semi-linear history. The webpage must be
outdated - or did i misunderstood something?

Source: I do it every day.

------
duxup
I look forward to the next panic that sends folks fleeing back to sourceforge.

------
naikrovek
I've heard good things about
this:[https://github.com/gogs/gogs](https://github.com/gogs/gogs)

I heard those good things here, iirc.

------
zantana
This rush to Gitlab reminds me of the forecasted mass reddit exodus to voat in
during the AMA/Ellen Pao crisis.

------
jph
GitLab LICENSE file: [https://gitlab.com/gitlab-org/gitlab-
ee/blob/master/LICENSE](https://gitlab.com/gitlab-org/gitlab-
ee/blob/master/LICENSE)

The way I read it, GitLab is open source in three senses:

1) GitLab core is MIT

2) GitLab enterprise edition is all published code

3) The GitLab EE license specifically gives the user permission to modify code
and publish patches within the broad EE license.

------
amyjess
> Furthermore, the free version running on GitLab.com is the Enterprise
> Edition. This means that if you wish to move from their hosted service to
> your own one, you would be losing several features and would even have to
> pay to import your projects based on the above list.

Just because GitLab.com runs EE doesn't mean all EE features are made
available to all users. Most if not all EE-only features are behind a paywall
on GitLab.com; you still have to pay to use them even if you don't self-host.

------
ianamartin
This kind of sort-of open source needs a word. Openium source or something.
You get the basics under open source with all that implies. And if you want
the premium features, that's also there in a sort-of open source way.

~~~
zokier
Open core is pretty well-established phrase

[https://en.wikipedia.org/wiki/Open_core](https://en.wikipedia.org/wiki/Open_core)

------
akerro
Author doesnt understand concepts of opensource, dual-licensing, copy-left and
copy-right. Nothing to see here.

------
TylerJewell
Disclaimer - I am CEO of WSO2, a pure open source company. We philosophically
oppose open core business models.

The author is speaking to the differences between the open core and open
source business models. I've been writing increasingly about the differences
between these models on my Medium blog about WSO2's growth story, our thoughts
on the MULE acquisition by CRM (another open core vendor), and our open source
business model.

WSO2 is a pure open source business model and we believe that it's more
honest, efficient, and scalable. Also, if executed in the right manner, there
is no risk from IP exploitation. We have been able to demonstrate that as we
are growing on an ARR basis faster than MULE with an equal customer net dollar
retention with negative churn, while getting to cash flow positive operations.

Our biggest rationale on why this is the case is that our internal teams do
not compromise productivity by perpetually wrestling with where the “for
free/for pay” line must be drawn. It is expensive for an enterprise vendor to
determine the best model of where for-fee options reside. Not only does the
vendor have to develop a strategy, but they must communicate this to all their
employees and then justify it to the open market. This is evidenced in this
thread and in the many HN threads for Gitlab - their management team has to
invest time and energy into explaining the philosophy that was used to
establish the line. It's rarely intuitive, so some non-zero effort goes into
that education internally and externally.

These costs are passed along to customers and require significantly higher
forms of capital from investors. This line does not stay static, either. The
nature of open source is that is erodes and impedes upon the areas where a
vendor is selling their proprietary extensions. This means the “for free/for
pay” line must be periodically rethought. This is a continual process, and
this is time where inefficiencies are introduced.

In the pure open source model, we just tell our developers to design and
build. And we can focus on a single pricing solution of value in and around
that overall platform. It saves us a lot of emotional capital, too, because
people get very committed on where they think the free / for pay line must be
drawn.

Finally, it lets us be more up front with customers. They know that our sales
reps have nothing to gain by suggesting one tech stack over another. Customers
can use the entire stack before they talk to us and so if they are really
engaged, then we are engaged for a value added subscription for all of the
right reasons, and we don't have to lengthen the sales cycle while they try to
decide which route they want to take - open source or proprietary.

[1] [https://blog.usejournal.com/wso2s-growth-story-and-why-
open-...](https://blog.usejournal.com/wso2s-growth-story-and-why-open-source-
is-the-only-way-to-solve-your-integration-challenges-32a72b173e0a)

[2] [https://blog.usejournal.com/salesforces-acquisition-of-
mules...](https://blog.usejournal.com/salesforces-acquisition-of-mulesoft-is-
a-triumph-for-investors-disaster-for-open-source-2e5252005860)

[3] [https://blog.usejournal.com/wso2s-open-source-business-
model...](https://blog.usejournal.com/wso2s-open-source-business-
model-3ffea58feb8b)

------
mankash666
GitLab or ANY company has no obligation to give away it's work under liberal
OSS terms. GitLab is NOT a charity, the hypocritical expectation of OSS while
still expecting silicon-valley style exorbitant compensation for being an
employee is clearly at odds, companies can only afford such salaries if they
eke out handsome profits. Ergo, if you expect a good salary for your work,
prepare to pay for good products.

RedHat is the ONLY company managing a reasonable revenue stream while being
fully open source. If you like/love GitLab/GitHub, you'll want them to thrive
financially, and there's no clearer path to financial stability than charging
for close source software, as proven by decades of enterprise and consumer
facing companies.

~~~
ModernMech
> RedHat is the ONLY company managing a reasonable revenue stream while being
> fully open source

For their size. There are other open source projects that are actually
profitable. They're just not billion dollar companies. e.g. ghost.org

~~~
mankash666
Ghost is NOT a for-profit company, you can't compare them to companies whose
mission is profit. Unless you're implying the pursuit of profit to be
unacceptable, this is an apples to oranges comparison

~~~
ModernMech
> you can't compare them to companies whose mission is profit.

Why not? They're a non-profit, sure, but that doesn't make them a charity.
Like Redhat, they also don't have an obligation to give anything away for
free. They just have an obligation to make sure at the end of the day, there's
no money left over in the form of profit.

And yet, they manage to not only generate revenue on an open source project,
they make enough to keep the company afloat.

That's not to say their model would work for gitlab or github. Ghost works
because they're small. But the point I'm trying to make is there is a model
demonstrated by Ghost and others that allows for small fully open source
project to support itself, while not relying on a closed core.

~~~
mankash666
I don't see the logic here. Ghost's mission is to stay independent and afloat,
and GitHub/Gitlab's to make the most money they can. These are indeed
different and oftentimes opposing mission statements. The fact they all make
software is co-incidental.

My thesis stands - as a for-profit entity intent on maximizing profits and
net-worth, empirically open source hasn't provided a vehicle to achieve those
goals. At best, it allows a company to stay afloat, but it doesn't in any way
guarantee maximizing net worth and profit of a company.

So, every-time you pith open-source as a viable alternative, you're confusing
the mission statement. It isn't to stay afloat, it is to maximize wealth

~~~
ModernMech
> My thesis stands - as a for-profit entity intent..

No, you've changed your original position, which was "RedHat is the ONLY
company managing a reasonable revenue stream while being fully open source."
You capitalized "ONLY" to emphasize it. I challenged that statement, and
you've conceded with this carve out: "At best, it allows a company to stay
afloat, but it doesn't in any way guarantee maximizing net worth and profit of
a company." which is a statement I agree with.

So while you say your original thesis stands, we've somehow arrived at a point
where we both agree. Open source for a profit-seeking company _hasn 't_
delivered. But you can still make a company with open source -- it's just not
going to be able to maximize revenue like a closed-source competitor could.
But I think that goes to show people write code for more reasons than profit.

------
stealthmodeclan
So it's not financially viable to run such companies without trick like these.

If our financial system does not allow for companies like Github/Gitlab who
provided positive value to society at large to sustain then perhaps the
finanical system is to blame.

About Github/Gitlab employees, I can provide them housing, food, and some soft
benefits. Can they work for free so that Github/Gitlab become sustainable?

Why government can't bless those companies to survive forever?

The major problem in the world is that evil players like Microsoft have all
money to do anything they want and positive contributor to society like Github
can't earn money.

~~~
x0x0
The acquisition was the almost inevitable outcome of decisions that github
alone made:

\- comping employees with options and/or RSUs;

\- taking $350m of VC money.

~~~
stealthmodeclan
Had they not made those decisions, would they've managed to attract
developers, pay bills and keep their lights on?

Do the founders wanted billions or a big impact on the world?

Today, they've sold their customers to an evil tech empire.

------
jacksmith21006
GitLab has been this fantastic secret and now with MS buying GitHub so many
people are coming over worry it will mess it up.

------
iddan
Stop the clickbait

------
syshum
And how much of GitHub is Open???

~~~
pythonaut_16
More than you'd expect, as they've open sourced and contributed to a number of
open source projects based on their development of Github.com

~~~
syshum
Github is a perfect match for MS, both of them are hostile to the idea of Free
Software

They open source tools for devs, things like Library's, Frameworks, IDE's etc.
Never end products.

They oppose the ethics of Free Software, Open source for them is a way to get
free labor

