GitLab Isn’t Really Open-Source
akr.am
akr.am
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
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 -- 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.
To counter all the comments throughout today claiming that GitLab is the bastion of Open Source. There's nothing wrong with GitLab or their "open core" business model, but a lot of posters today surrounding the GitHub acquisition have been misstating GitLab's OSS credentials.
GitLab did nothing wrong. But facts somethings need to be restated.
The kernel does not use a Github-style workflow, either.
From Wikipedia (https://en.wikipedia.org/wiki/BitKeeper):
"The decision made in 2002 to use BitKeeper for Linux kernel development was a controversial one. Some, including GNU Project founder Richard Stallman, expressed concern about proprietary tools being used on a flagship free project. While project leader Linus Torvalds and other core developers adopted BitKeeper, several key developers (including Linux veteran Alan Cox) refused to do so, citing the BitMover license, and voicing concern that the project was ceding some control to a proprietary developer."
Not that it matters to anyone, but I do remember I found it shocking news :)
BitKeeper is by that time open source under Apache 2.0 License:
EDIT: Why the downvote?
I specially looked in the dictionary what the translation of "mittlerweile" [de] means in English ("by that time"). Additionally I did not write "BitKeeper was by that time open source under Apache 2.0 License", but "BitKeeper is by that time open source under Apache 2.0 License", which to my understanding of English grammar means that I am writing about something that currently holds. Additionally the German word "mittlerweile" (which by my dictionary means "by that time", as I already remarked) has exactly the meaning that it was different in the past - and my language feeling says this also holds if "by that time" is used in a present tense sentence. Even if not: if I were to say that it was already open source in the past (when Linus Torvald decided to create Git), I would have used the simple past tense. Using a present tense sentence for such a formulation does not make sense with respect to my understanding of the English grammar.
Regardless, you haven't explained what your actual point was. BitKeeper switching to open source after Linus's initial decision to use it doesn't refute the original commenter's point.
yum upgrade
Done.
No problems for years now. Not a single one.
That’s not to say I won’t have trouble of some sort one day - but what software is 100% trouble free?
Edit: typos
I guess you folks gave it enough hardware to run properly. From what I'm reading that's what's missing in a lot of failing installations. It seems particularly resource hungry.
Relevant: https://docs.gitlab.com/ee/install/requirements.html#hardwar...
Changing that URL from "/ee/" to "/ce/" gives the same RAM requirements.
...of course, it replaced Upsource for us, and Upsource is incredibly resource hungry, so maybe we just have a very, very skewed frame of reference. :)
It’s probably the easiest thing to upgrade in our entire app stack.
I'm actually surprised that many people you know have had issues with it.
- 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" 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"
Info: https://about.gitlab.com/installation/ce-or-ee/?distro=ubunt...
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.
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).
The CI obsoleting Bamboo and the collab tools obsoleting the dev features of Jira were icing on the cake. And a true up license model that doesn’t immediately bring all work to a screeching halt when you add one user too many to the app access group in your directory was just the cherry on top.
Normally I’m a huge fanboy of everything Atlassian but the Jira/Bamboo/Crucible/Bitbucket stack just feels very clunky and outdated with Gitlab as something to compare against.
Unfeature to me. If you add a new user 1 day before your yearly renewal, the "true up feature" means you pay an entire year's worth of usage for that 1 day. Other apps like LastPass pro-rate, and you would just pay a few cents to add a user for 1 day.
So, it is open source? Doesn't this fall under the adage of "free as in free speech, not as in free beer?"
Open source doesn't mean you can't charge for your work.
If you cannot deploy it without a paid subscription, it's not Open Source by most commonly accepted definitions of the term.
----
[0] https://www.gnu.org/philosophy/free-software-for-freedom.en....
> Generally, open source refers to a computer program in which the source code is available to the general public for use or modification from its original design.
You cannot do that with Gitlab EE but you can do it with the community version. The community version is a subset of Gitlab EE with a few features missing. But I completely agree. You cannot have it both ways. I don't think Gitlab could support their work just by providing commercial support. They need to have a "not so open source" version to sell. And just providing you with the source code to verify (and possible modify and fix if they were to ever go bankrupt), is a huge advantage over a fully closed source solution such as Github.
Edit: They call it Shared Source actually: https://www.microsoft.com/en-us/sharedsource/default.aspx
> ...and all such modifications and/or patches may only be used, copied, modified, displayed, distributed, or otherwise exploited with a valid GitLab Enterprise Edition subscription for the correct number of user seats.
You can do all that assuming you have a license for your production users. It's not GNU-style Free Software, sure, but it still feels like Open Source to me.
The ability to reuse code is IMO an important part of both open source and free software.
Their license says...
Notwithstanding the foregoing, you may copy and modify the Software for development and testing purposes, without requiring a subscription. You agree that GitLab and/or its licensors (as applicable) retain all right, title and interest in and to all such modifications. You are not granted any other rights beyond what is expressly stated herein. Subject to the foregoing, it is forbidden to copy, merge, publish, distribute, sublicense, and/or sell the Software.
I disagree. If you need a paid license in order to redistribute modified copies, that's really not how developers think of open source and it seems disingenuous to conflate the two meanings. It definitely does not "feel" open source.
Even Microsoft understood this difference, which is why back in the day (before current Microsoft practices) they used to have an initiative called "Shared Source" [0]. Notice how they avoided calling it "open source", since this would have contradicted reasonable expectations about the meaning of the term.
----
In fact, the OSD is nearly identical to the Debian Free Software Guidelines [1].
The meaning of Open Source is a lot more precise than just "the source code shall be available". See:
Personally, I think using "open source" to mean "the source is open to the public" is as misguided as using "free software" to mean "the software is free of charge," but in practice there's a lot more ambiguity in the former, not the latter.
I would disagree. Both the terms "open source" and "free software" existed prior to the open-source software movement. Either way, you don't get to co-opt the plain English meaning just because you've invented your own jargon. That's not how language works.
That's precisely how language works: we co-opt words and change their meaning all the time; this happens all the time with software, engineering and physics. Open source has come to mean something in the software development world (and it arguably never meant "the source is open to the public but they must pay for its use", so it's not even an actual subversion). Some companies now might be trying to redefine the term, and it's up to us -- the programming community -- to stop them by rejecting this redefinition.
That some wish to draw a distinction from a term of art does not meant that all uses of that term must draw the same distinction or be considered a term of art. English, and indeed all natural languages, support words with multiple, often contradictory meanings. English, being defined by usage, does not care at all about any authority in language.
The words "free software" will essentially forever mean "software obtained without monetary cost" because that's what those words mean in plain English. That's the semantic meaning of combining that adjective with that noun. The fact that a second definition exists where "free software" is a compound word is mostly irrelevant. The fact that engineers have a specific meaning for "shear" doesn't mean I can't call my scissors "shears". That's why so many terms of art are invented whole-cloth and why acronyms as terms of art are so prevalent. It's precisely to avoid that contextual semantic collision that plain English doesn't give two shits about.
Well, "software" is a relatively new word, so I'm not sure about "forever" (is software a soft ware?). And within the short lifespan of this word, the term Free Software in the technically accepted jargon has been in use for a really long time (at least early 80s, apparently).
Yes, non-technical people won't understand what "free software", "open source", or "source" means for that matter. They don't understand what a license means in terms of software either. They don't know or care about hacker culture, or the history of computing. That's ok.
Language has meaning within communities. This is our community. GitLab, GitHub, Microsoft, and most HN readers do understand the mainstream meanings -- within our community -- of "Free Software" and "Open Source". This is just like when physicists say a nuclear reactor goes "critical" they immediately understand the term, even when to a layperson it sounds scary and in common language "critical" means something else.
(Also, the fact that "intelligence" has a jargon meaning other than "smartness" is a good example that that is in fact how language works.)
Here's the overlap diagram with a bunch more detail. https://www.gnu.org/philosophy/categories.html
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.
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
https://en.wikipedia.org/wiki/Darwin_(operating_system)#Open...
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.
Android leans towards the GitLab side because there are meaningful third-party distributions of Android.
Matlab is an interesting case because there are extremely popular libraries using its open-core components - essentially the entire scientific Python ecosystem depends on them, so while e.g. Jupyter Notebook doesn't ship LAPACK or FFTW itself, a huge number of its users pip install scipy, and many install PyFFTW. And from where I sit, the scientific Python ecosystem appears to be eating Matlab's lunch.
I don't know if "open core" is the right term to distinguish these cases, but there is an interesting distinction - third parties meaningfully using the free subset, third parties not meaningfully using it, and third parties using a competitor product based on the free subset.
Edit: a bit off topic, but why do you want "Rebase merge requests before merge" - wouldn't `s/merge/testing/` be much more useful?
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.
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.
Open source doesn't mean the maintainers have to accept your patches.
An open core model done well is great. This doesn't seem to be an instance of that :)
TypeSafe/LightBend removed a fully functional MS SQL implementation from Slick.
I've written about this type of split in OSS software and what it means for developers:
https://penguindreams.org/blog/the-philosophy-of-open-source...
The way I see it, someone is providing a free product and is maintaining it. They are even doing (imho) a great job. Of course, that costs money - and we only need to look at other opensource solutions to see what kind of UX they have if the creators are only charging for support.
So the options I see are:
- have a worse product, but truly opensource
- have a great product, fully opensource, but some features will never be added
In my view GitLab is a perfect example how to make a sustainable business around opensource core. So the question is - can you think of a better sustainable business model to support development of opensource solution?
we'd have to carry our own internal fork of Gitlab
GNU emacs (or more specically RMS) rejected patches that would integrate clang, or provided colorful emoji support on OSX, for political reasons, and that's perfectly fine for a project to do.
Gitlab will reject some patches for business political reasons, which is also perfectly fine.
If you don't like that, fork. If a lot of people don't like it, then the fork becomes effectively the new upstream (e.g. GCC/ecgs).
There is no "Right to have my patch merged" anyway.
What fee structure would work for you? Maybe per-installation or per-repo?
This has come up in the past; they've stated that this hasn't happened yet, and that they wouldn't outright reject it, but would have to consider the situation.
So you might want to give it a try.
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.
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.
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.
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.
For example, I believe Fedora is developed via Pagure, which also importantly supports "remote" pull requests. (https://pagure.io/pagure) (Fedora's instance: https://src.fedoraproject.org/)
There's also Kallithea, but I haven't looked at it much. (https://kallithea-scm.org/)
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.
[1] http://www.dr-chuck.com/csev-blog/2014/09/how-to-achieve-ven...
Maybe google re-opens google code, but that wont be free open source either.
> 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.
I heard those good things here, iirc.
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.
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.
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-...
[2] https://blog.usejournal.com/salesforces-acquisition-of-mules...
[3] https://blog.usejournal.com/wso2s-open-source-business-model...
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.
For their size. There are other open source projects that are actually profitable. They're just not billion dollar companies. e.g. ghost.org
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.
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
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.
I don't like/love GitLab or GitHub in an emotional sense. They're good tools, but they're tools.
Bitkeeper was also a very good tool, offering immense value compared to any of the other options there, and the effective death of Bitkeeper and the existence of Git was an incredibly good thing for both the world as a whole and my personal workflow. https://en.wikipedia.org/wiki/BitKeeper
In other words: GitLab's strategy allows it to open source as much as possible, while also actually developing and maintaining the project. At least for now, it's one of the most successful projects to do so.
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.
- comping employees with options and/or RSUs;
- taking $350m of VC money.
Do the founders wanted billions or a big impact on the world?
Today, they've sold their customers to an evil tech empire.
far as the govt goes, its a good idea but the problem is the moment you take survival fear out of a company right that moment they'll start dragging their feet and become unproductive. so you are back to square one. IMO a social utility like model needs to evolve. And we need near religious zeal on enforcing antitrust/monopoly law.
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