91–100 of 162 posts
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.
Give me service availability over "source availability" any day. The gitlab paas product has shocking performance and uptime.
Earlier quoted context omitted.
Because most of the open source world is more than happy to use that closed-source service.
Including Linux, which originally used the proprietary BitKeeper VCS system before Torvalds wrote git.
BitKeeper is by that time open source under Apache 2.0 License:
EDIT: Why the downvote?
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,…
Earlier quoted context omitted.
Open source doesn't just mean that the source is publicly available, either, though. This definitely isn't an open source license: https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE
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.
> 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?"
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 meaning of Open Source is a lot more precise than just "the source code shall be available". See:
Earlier quoted context omitted.
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.
From https://gitlab.com/gitlab-org/gitlab-ee/blob/master/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…
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.
Earlier quoted context omitted.
Sure, but that's essentially a branding criticism (labeling them "enterprise" features) rather than a criticism of the "open core" model.
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.
Open source doesn't mean the maintainers have to accept your patches.
Earlier quoted context omitted.
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.
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.
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 technicall…
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.