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.
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 -- 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.
> I don't understand what compelled the author to write this but GitLab CE really is open-source.
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.
I agree, and I think this is a valid reason. However, I think the author could have been more explicit about this (assuming that this in fact the author's reason for writing the post, and not a steelman)
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.
Same here. After a few years and moving it around from server to server (switched hosts a couple times), it's run flawlessly and upgrades are just one apt-get upgrade away...never had a single issue with that. We have 40+ projects and utilize container registry and CI with Kubernetes as well.
Dang. Afaict, you guys are the exceptions to the rule.
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.
Code repository management is a central part of every company. I don't see any problem in throwing sufficient hardware at such a crucial piece of software.
I would be guessing someone at gitlab was playing around with his/her Raspberry. But yeah, I would advise against running anything important on a Raspberry ;).
Actually, one of the things we're liking about Gitlab is how lightweight it is.
...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 currently running as an omnibus installation on a KVM node. 8GB of memory and 4 vCPU (E3-1230v6). Anything more than 4GB of memory and a couple cores appears to be sufficient for our use.
Anecdotal but I’ve gone through two major versions and a bunch of point releases at $dayjob and the worst that ever happened was a failed database migration that didn’t actually break anything.
It’s probably the easiest thing to upgrade in our entire app stack.
I ran the latest version inside docker for 6 months and used daily CI/CD across multiple environments. It's been perfectly stable and fast. Highly recommended.
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?
"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 :)
Probably because BitKeeper definitely was proprietary back when the Linux kernel was using it even if it got open sourced later... Your comment seemed to be suggesting otherwise.
> Probably because BitKeeper definitely was proprietary back when the Linux kernel was using it even if it got open sourced later... Your comment seemed to be suggesting otherwise.
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.
People probably mistook "by that time" as "at that time" instead of "since", which was what you meant. Also, use "has been" instead of "is", as the open-sourcing happened sometime in the past (although it is in the state of open-source now).
I would suggest that needing to defend a particular use of grammar on a discussion site is a bit like needing to explain a joke. It means your original message simply wasn't effective.
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.
Because they bought the service that they chose to use, and in choosing the criteria of what to buy, they chose "best overall" over "best 100% open source." Microsoft is one of the the largest contributors on GitHub.
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" 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
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.
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.
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).
A couple years ago I exchanged email with the gitlab ceo on the idea of developing a few huge macro features separately from gitlab. Basically a strategy focused around using gitlab as a customer acquisition channel to sell other related products. He correctly pointed out this meant having more than one product, instead of two versions of the same product. At the time, I strong suspected mixed feelings like yours would crop up among their customer base. I understand why he went the route he did, but I still think they made an error. Of course, it's his company, so I can't be too critical. However when I think gitlab I think 'github knockoff' not 'open source heroes'. Maybe gogs or someone similar could follow that monetization strategy.
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.
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
Oddly enough we went exactly the other direction. Atlassian user tiers are huge (almost geometric in size) with the result that you end up paying for a ton of unnecessary head count.
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.
> 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.
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.
I’ve been wondering why Bitbucket just gets ignored with all the Github news. I get that Gitlab is the new hotness but they’ve been offering free private repos before gitlab was even a thing.
> 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?"
"Open source" is an incredibly ambiguous term. Some people use it to mean the literal "the source is open to the world." Some people use it to mean the Open Source Definition from the Open Source Initiative https://opensource.org/osd , which is a very small set of modifications of the Debian Free Software Guidelines https://www.debian.org/social_contract#guidelines to make them not talk about Debian or use the term "free software". GitLab EE does not fit the Open Source Definition at all.
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.
> 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.
My point is that while, yes, terms of art are coined all the time, they don't get authority over plain English by virtue of existing. Sociologists don't get to say, "Well, that's not technically what gender means," when you can open up a dictionary and show that, yes, that is damn well exactly what gender means in English. I mean, yes, they do try to do that, but they don't actually have any authority to do so.
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.
> The words "free software" will essentially forever mean "software obtained without monetary cost" because that's what those words mean in plain English.
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.
I think that's true of "free software," but I'm not sure it's true of "open source" - the primary meaning before the FOSS movements was open source intelligence (OSINT), i.e., intelligence collected from open sources. https://en.wikipedia.org/wiki/Open-source_intelligence I'd believe that a phrase like "open source code" or something (parsed as "open source-code," not "open-source code") existed in the way "free software" did.
(Also, the fact that "intelligence" has a jargon meaning other than "smartness" is a good example that that is in fact how language works.)
Usually when people speak about open source, they include not only not being able to view the source, but also the possibility to modify, distribute and use it (and modified versions) in the requirements for a license to be labeled an open source license.
> ...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.
> 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.
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.
It is certainly not in compliant with Open Source Initiative's definition, which is the primary meaning
of open source in the engineering field.
https://opensource.org/osd
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.
It also means that if you write some generic code for GitLab EE, like a widget that lets you select git branches or validate some JSON or whatever, you can't reuse that code elsewhere. Copyright in the code you wrote is owned by GitLab, and nobody who's not a GitLab customer can use it.
The ability to reuse code is IMO an important part of both open source and free software.
The open source and free software movements came from a time where if you bought a big piece of software - a UNIX system or what-have-you - you would get the source code, and be permitted to modify it and maybe even share your patches with other people who’d also bought the software. That wasn’t the point of either movement at all.
Exactly. For instance Windows source code has been "open source" for about 18 years or so via a license anyone can request. This is still not what most people think of when speaking about open source though.
But it is also commonly understood that open source means you can change and then distribute your changes. Here is an excerpt from Wikipedia[0]:
> 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.
Why not? You can modify/redistribute it, you can't just deploy it to production without having a valid subscription. It's not Free Software, but it is Open Source.
Free Software and Open Source's differences are more philosophical than technical/legal [0]. This means that if something cannot be Free Software it cannot, more often than not, be Open Source either.
If you cannot deploy it without a paid subscription, it's not Open Source by most commonly accepted definitions of the term.
It's not Open Source because the terms aren't compliant with the OSD[1]. And while the OSD may not be a de-jure definition of "Open Source" it is the de-facto definition in the popular vernacular around this subject.
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.
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].
GNU has listed "Four Essential Freedoms" https://www.gnu.org/philosophy/free-sw.html to meet the definition of "free software". Does the gitlab-ee license meet these? I think for the most part it does, although I'm not sure this ever had a "subscription model" in mind when it was written. You can run the software, you can modify the software, you can distribute your changes... You could theoretically sell your modifications so long as third parties had a subscription with gitlab, although you'd have the weirdest business model ever.
Free speech is a superset of free beer, not a subset. The proprietary version of GitLab is publicly viewable and amendable, but it is close source, not open source.
It's neither a superset nor a subset. Some programs cost money to get a copy (or support or whatever), but then once you have the program you can do what you want with it.
"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.
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.
One important difference between macOS and GitLab is that there are people running GitLab's free-software edition (e.g.,. https://salsa.debian.net/ ), and I know of I think nobody who's running Darwin.
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.
The company I work for used Darwin in place of CentOS up until some time in 2015 for a good number of years. Do not recommend. At all. The case insensitive file system didn't help though in terms of running things it seemed okay but I have a feeling it wasn't really that great. Darwin seems like a good idea on paper but I don't feel like it's all that usable.
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.
> 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.
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.
My personal take on the open core model is that I'm generally in favour with it, so long as the paid features are significant and make sense to be paid features. Like, the two features the parent are asking for could be added by an open-source contributor in an afternoon. Removing them from the CE edition and only including them in the paid version just feels like picking and choosing things to include or not include.
An open core model done well is great. This doesn't seem to be an instance of that :)
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.
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.
But absolutely nothing is preventing you from using a a fork of CE which adds every EE feature so long as they were developed independently of the closed-source EE code-base.
Open source doesn't mean the maintainers have to accept your patches.
Alfresco does this as well, and they removed things that worked in the community edition, like clustering, requiring people either switch to the EE version or implement the missing/removed features themselves as a plugin or fork.
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:
That seems to be part of the $4 / mo / user subscription. A server to self-host costs $100-$500 / mo, so it doesn't seem like an impossible obstacle with < 100 users.
What fee structure would work for you? Maybe per-installation or per-repo?
I am genuinly curious about your view, so please be patient with me when answering.
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
If you develop the missing features, you would need to maintain a clone. You could do it if you really wanted to, it would take a lot less work than developing the whole solution from stratch. But - and this distinction is important for me - if the company ever went under or, worse, got sold to Oracle, community would almost surely take the CE sources, add those features and maintain a clone. At least for a while...
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
So you have the choice between buying Gitlab or coding yourself. You would prefer it to be free and without hassle, but lack to see everything has a cost.
That's not OP's main point. It's that even if they implement it (as in a clean room), there is no chance of it being merged upstream. Now, if the OP implements some entirely different feature not related to gitlab's pricing, it can be merged upstream in the CE. This is in contrast to conventional open source projects.
uh, a lot of patches to open source get rejected for all kinds of reasons, incl code quality, being off topic or just because the maintainers (irrationally) dislike the patches.
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.
The incentives are really not aligned here. Over time it's likely more features will be removed from or never added to CE. Gitlab provides only a very basic plugin system [1] so that nobody else can provide these basic features into CE. (Instead users are encouraged to contribute back to CE.) So, yes, the only option is "fork and fuck off." I don't predict a happy future for users of GitLab CE.
> 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.
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.
Check out the issue list on gitlab-ce and see if anyone has requested it come to CE. They may have other reasons or they may bring it over if enough people ask. I've seen threads on HN where they've agreed to bring something over from EE because someone was asking about it so they definitely are happy to do that where it makes sense.
I'm not familiar; are the features you mentioned new and perhaps not "ready" or ported to Gitlab OSS? But if they're older features in "proprietary" Gitlab then I'd have to agree.
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 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.
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.
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”.
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
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?
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.
> 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.
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
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.
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.
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.
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.
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.
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?
> 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.
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.
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.
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.
To illustrate: I used to use Gitorious back when, because it was fully open source. Its founders couldn't keep the lights on/weren't motivated to continue working on it any more. Instead of waiting for it to shut down, GitLab acquired it and (of course) facilitated easy migration from Gitorious to GitLab if so desired.
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 you like/love GitLab/GitHub, you'll want the companies behind them to thrive financially, to continue offering their products to you at reasonable prices for the immense value they offer to your workflow
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
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
> 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.
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
> 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.
I'd argue that our company, WSO2, which is now the 7th largest OSS company is doing well. We will push $50M in sales this year, EBIT positive, cash flow positive. Growing 60% yoy. All of our software is Apache licensed.
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.
My working hypothesis is that more 'evil' the player is higher the margin they'll have because by definition they are providing as much value to their customers. problem is this means they'll have a lot more resources to burn on 'non-essential' avenues such as lobbying and kickbacks. this, IMHO, is the reason you see the rise of so many BS professions all the while little hourly worker is getting squeezed out. honestly I dont see an end in sight.
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.
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