
A proposal to move Gnome to GitLab - rbanffy
https://lwn.net/Articles/722870/
======
iambvk
Am I the only one who thinks gitlab is a poor product?

They upgrade every week. Who the hell does that to paying customers? And half
of their website functionality doesn't work when they upgrade -- but their
upgrade-banner always says "no down time is expected". It is a running joke in
my company.

We constantly get error 500 during upgrades. Merge requests don't commit.
Rebase feature didn't work till a few weeks back. Gitlab runners get stuck
every now and then. I use it everyday because of company policy, but folks,
Gitlab is a really poor product. Feels like they test their product on paying
customers.

Also, do they even know how good their competition is at? You can't see the
what is changed in response to your comment between two MR uploads. You can't
add comments on unchanged parts of the code in the diff-view. You can't add
comments when you view the diff between two uploads of an MR. My list of
complaints is endless.

~~~
Perihelion
I'm really sorry to hear about the crappy experience you've had with GitLab.
If you'd like to detail some more complaints, I'd love to hear them and open
some issues about these things. Feel free to shoot me an email (located in my
profile) or reply here. Either way, thanks for the feedback you've provided
here.

As far as the frequent upgrades go, we've been using .com as a way of
dogfooding GitLab at scale. Sometimes this goes well and other times it
doesn't. We're actively working to improve this process so that downtime and
breaking changes are less frequent. The end goal is to eradicate both issues
so that upgrades are seamless.

~~~
ghrifter
One issue I encounter often-ish is that when I'm on a gitlab page then hit the
back button in the browser - I get a bunch of JSON spit onto the page instead
of an actual HTML document.

Whats up with that?

~~~
Perihelion
I've actually experienced this exact thing. Usually a refresh fixes it for me
so I never gave it too much thought. I'm not sure what causes it exactly but
I'll follow up with the team about it. It usually happens to me on merge
requests -- do you notice it on specific pages at all?

~~~
sytse
I think this is due to Rails Turbolinks. Since we're deprecating Turbolinks
[https://about.gitlab.com/2017/02/06/vue-big-
plan/](https://about.gitlab.com/2017/02/06/vue-big-plan/) I think this problem
should go away.

~~~
sytse
It seems to be caused by and fixed in [https://gitlab.com/gitlab-org/gitlab-
ce/issues/28909](https://gitlab.com/gitlab-org/gitlab-ce/issues/28909)

------
awalton
Not convinced GitLab is the solution, but I'm definitely convinced GitHub _isn
't_.

Not as active in GNOME these days, so my vote is not really a vote... but I do
have my own reservations about both "Git-Wrapped" solutions, _especially_ if
they start requiring pull requests.

Splinter/Bugzilla is definitely not a long-term code review solution though,
so something really has to give there.

~~~
xkarga00
What's your solution?

~~~
awalton
I don't really have many issues with bug management on GNOME (that pain really
goes to the bigger multi-module maintainers and the reassigning of bugs to the
right places in the stacks), but for code review I'd probably just replace
Splinter with a standalone instance of Review Board and call it good enough
for the time being - basically waiting for someone to come up with an
integrated code review/issue tracker that isn't tied to their company's
infrastructure (Hello Google), is standalone installable and manageable (sorry
GitHub) and doesn't impose a pull model on patch pushers (goodbye GitLab).

~~~
newsat13
GitHub EE is standalone installable.

~~~
awalton
GitHub EE is not in consideration.

~~~
mintplant
...because it is, of course, proprietary software, and this is the GNOME
project we're talking about.

------
aidos
Is this all gnome projects?

I submitted my first patch to Cairo a few weeks back and depressingly it was
met with tumbleweed. I tried contacting people on irc but again, nothing.

In contrast I submitted my first patch to fontforge recently too (GitHub) - it
was merged in a couple of hours.

Developer interaction matters and I know plenty of open source devs who have
put in a lot of good work are going to hate me for saying this - but those old
platforms you're using suck for fostering community contributions. (And I
thought the code quality in Cairo was great - I bet if it was on GitHub there
would be loads more activity)

~~~
pooper
> I submitted my first patch to Cairo a few weeks back and depressingly it was
> met with tumbleweed

There used to be a time (from what I've read) when free software meant a
tarball available for download every n years. Apparently, Open Office under
Sun was very good at not accepting patches at all.

Things are looking up though. Please don't give up. Look at the comments on
previously on hn
[https://news.ycombinator.com/item?id=14051106](https://news.ycombinator.com/item?id=14051106)

Now, we have things like KDE Neon with git-unstable and git-stable which
basically allow end users to participate in the latest changes in KDE and now
the windows/meta/super key actually does something in KDE which I wouldn't
know if I was on Kubuntu.

~~~
treve
Any details on that last point? Pretty curious what they're doing with the
meta key!

~~~
kuschku
Tbey merely introduced modifier-only shortcuts.

So you can bind a menu, or an application launcher, such as the start menu, or
app dash, to Super.

------
derefr
Keep in mind that this proposal is for GNOME to run a GitLab instance
themselves; not for them to use GitLab's SaaS product. AFAIK GNOME just avoids
using SaaS generally.

~~~
audidude
Furthermore, the GNOME project will only consider the Community Edition (CE).
This is good news because it actively helps push the boundary for what goes
into the CE.

------
cyphar
As an aside, are there any plans to improve the GNU rating of GitLab from a C
to something higher[1]? While the LibreJS not working problem looks like a bug
in how the licence files are tagged (shouldn't be too bad to fix), the way
that licenses are presented and bad licensing practices promoted seems like a
fairly easy UX thing to fix...

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

~~~
mikegerwitz
See:

[https://gitlab.com/gitlab-org/gitlab-
ce/issues/15678](https://gitlab.com/gitlab-org/gitlab-ce/issues/15678)

More discussion can be found in the archives:

[https://lists.gnu.org/archive/html/repo-criteria-
discuss/](https://lists.gnu.org/archive/html/repo-criteria-discuss/)

------
nathan_f77
This is great. There are so many enormous open source projects that could
really benefit from modern tools like GitLab. Ruby is another example.

------
zanny
Interesting anecdote, KDE had the opposite conclusion and now uses
Phabricator. They said enough was missing from Gitlab CE (ex: LDAP support)
they couldn't drop in replace their current infrastructure with it.

~~~
audidude
GNOME heavily investigated Phabricator as well. Including much work with
multiple contributors using large Phab installations (such as FreeDesktop.org
and Endless). All of this is publicly documented on the wiki.

~~~
phillc73
I currently use a self hosted GitLab instance at work. I also have a
collection of personal repositories on GitLab.com. I chose to put my personal
work on GitLab.com because of free private repositories.

Over the last few weeks I've started to trial Phabricator, using the hosted
Phacility.com service. I haven't actively migrated any code yet, but just
using Phabricator to manage some workflow elements is a much enhanced
experience. Phabricator's Maniphest (tasks, issues) and Project Workboards
feel much more intuitive than GitLab's. The Kanban board on GitLab drives me
insane with the amount of clicks I need to do things, small glitches with tags
and lack of a single unified multi-project view. Perhaps I haven't used
Phabricator enough yet to hit such little frustrations.

The point is, I'm probably going to migrate all my personal work over to
Phacility.com and if things continue to move smoothly recommend using
Phabricator at work, mostly for their workflow and project management tools.

I should make it clear that as a developer, I'm just messing about for my own
interest. Professionally, I'm a project/product manager with a small team of
developers and scientists. I wanted to try and standardise on a single tool to
manage workflow, while still staying out of the developers' way while they did
the important stuff of building the product.

~~~
wyldfire
Does phabricator include git repos? I've only used it for code reviews.

Also, does it have a CI facility?

~~~
phillc73
It does have repository hosting, called Diffusion in Phabricator parlance.[1]
You can also "observe" remote repositories.

I haven't looked into CI with Phabricator, and this could be a killer for a
move away from GitLab if it's not available.

[1]
[https://secure.phabricator.com/book/phabricator/article/diff...](https://secure.phabricator.com/book/phabricator/article/diffusion/)

~~~
phillc73
Harbormaster is the Phabricator CI tool.[1]

[1]
[https://secure.phabricator.com/book/phabricator/article/harb...](https://secure.phabricator.com/book/phabricator/article/harbormaster/)

~~~
jhasse
They should have just called it "Phabricator CI".

~~~
pas
Too late, everything has some phucked up name. :/

~~~
phillc73
It's almost as if they named it all just for me.

------
iamnothere
Glad to see GNOME supporting another OSS product, even if GitLab uses a hybrid
OSS/proprietary model.

Don't understand the hate here for GitLab. It's a rapidly developing product,
so yeah, it's got some rough edges. But my experience with it has been hugely
positive, and I much prefer it over GitHub for a number of reasons. Integrated
CI is a huge plus; for instance, I've set up a project that runs a static site
generator after each merge to prod. This is certainly possible with other
tools, but I'd rather have a one-stop shop. (This is why I also like Visual
Studio Online, at least for professional work.)

Even if you're a die-hard GitHub fan, you have to acknowledge that some
competition in this space is healthy. We don't need a repeat of the
Sourceforge debacle. Centralization is dangerous.

------
usmeteora
Why has the entire conversation veered away from Gnome to everyone elses
projects gone wrong on Gitlab?

I was hoping these comments could be about the benefits that could be had by
gnome from enabling dev access through gitlab.

If you have issues with that one project you worked on with gitlab, please
contact Gitlab and let them know, as they are very open and responsive and
willing to work with you, but this is not the place to change the topic from
gnome to complaining about that one project you worked on two years ago and
why gitlab sucks even though you never took the effort to submit a ticket with
gitlab to fix it

------
sametmax
When Python moved from their own silo to github, the project instantly gained
more visibility, with thousand of stars in a few days.

You see, github is not just a fantastic plateform, well crafted and reliable,
to use git. The important part in the name is "hub".

Everybody is on github, have a github account, nows how to use it. It removes
a lot of friction.

Now I know it's proprietary. And it's close source. But since their track
record as a company is exemplary, and since you can easily backup the data in
there anyway, not being on github is like refusing to put shoes for a marathon
because your feet will breathe better.

~~~
cyphar
The GNU project did an evaluation of code hosting providers recently[1].
GitHub got an F (and note that 'server code is free software' is only a
requirement for an A grade). GitLab only got a C. There are more severe
problems than just "is the server free software".

Also please note that neither GNU nor the FSF really care about new fads.
Their main concern is software freedom, and much like the whole convenience-
security tradeoff there is a freedom-convenience tradeoff too. The FSF and GNU
project do not compromise on freedom.

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

~~~
deadbunny
> There are more severe problems than just "is the server free software".

Nonsense.

They have 2 reasons for it getting an F rating.

> 1\. Important site functionality does not work without running nonfree
> JavaScript. (C0)

Contradicts what you say.

> 2\. Specific information may not be available in all countries

Both are abiding by laws restricting access to that content. If you have an
issue with that perhaps talk to the relevant governments.

> see roskomnadzor[1]

This was blocked by the Russian .gov, nothing to do with GitHub

> and export controls[2] for more details.

They are a US company hosted with a US provider complying with US laws on
exporting controlled data.

So to counter your point one issue is because they're using non free software,
one reason is out of their control, and the other is following the law of the
land they are doing business in. If this is a fail in the FSF then that's
fine, claiming they have "more severe problems than not running free software"
is disingenuous.

1\.
[https://github.com/github/roskomnadzor/blob/master/2014-10-2...](https://github.com/github/roskomnadzor/blob/master/2014-10-21-roskomnadzor.md)
2\. [https://help.github.com/articles/github-and-export-
controls/](https://help.github.com/articles/github-and-export-controls/)

~~~
mikegerwitz
> Both are abiding by laws restricting access to that content. If you have an
> issue with that perhaps talk to the relevant governments.

In the case of Roskomnadzor, GitHub is not under the jurisdiction of the
Russian government---they made a choice to comply. They could have instead
chosen to stand up to the Russian government, which would surely upset its
citizens and the world and possibly lead to change. Possibly not. It's
certainly a gamble.

rms drew a hard line on this. When I asked him about Roskomnadzor
specifically, he was not moved. Quite the opposite, in fact.

I forget what he said about the export controls; I'll have to look at my mail
archives tonight. But if they are complying with US law, and they have no
choice, I don't think they'd be penalized in these criteria.

------
dguest
I'd wait for the forking model to be fixed[1]. The current model can be really
annoying when you have a large project where contributors are supposed to
direct merge requests to deputies before merging with the main repository.

[1]: [https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/5760](https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/5760)

~~~
audidude
I'm not aware of a single GNOME module that uses the Linux kernel style deputy
system.

------
Grue3
This is great. I dislike the Gnome project itself, but they have some
subprojects like GIMP that would benefit from this. Props for not just moving
to the most popular service _cough, Python_ , but the one that is actually
free software.

------
snakeanus
Last time I tried GitLab I wasn't able to add my Ed25519 ssh keys to it. Hope
that they fixed it now.

~~~
sytse
The issue for this seems to be [https://gitlab.com/gitlab-org/gitlab-
ce/issues/2784](https://gitlab.com/gitlab-org/gitlab-ce/issues/2784)

------
angryteabag
I don't know where all the hate for GitLab is coming from, but for my use
case, their SaaS git solution is almost exactly what I have been looking for.

It's so good, I am both surprised and angry I didn't find it sooner.

------
AsyncAwait
I agree with a bunch of the UX issues raised, but a lot of the other problems
are related to GitLab.com and if you self-host, it's a much, much better
experience.

------
arunc
I've always wondered why they refuse to support Mercurial. I agree that git
has won the race, but people still like and use hg. And it's always a win-win.

~~~
winteriscoming
I have been using Mercurial for some years now and before that was on Git.
Github used to be one of our remote repositories. The thing that Git excels is
feature/bug-fix branches, which can literally be considered throw away
branches. You work on one or more feature branches, independently and then
submit a review request (github is just one option) and then have it merged
against the actual release branch - all this without polluting the history of
the release branch or without juggling with too many complex version control
commands/tricks. Github wrapped around a lot of end user tooling around this
concept (pull requests for example) and showed to the world how easy it is to
accomplish this level of "parallel" feature work or bug fixing.

Coming to Mercurial, now that I have been using it for more than a couple of
years, my experience is that, this workflow (which is now considered standard
and well known through git and github) isn't possible to achieve. Mercurial's
concept of branching doesn't fit into this scheme of things. They stamp each
commit with a branch id and there's no way to erase that which effectively
leads to a lot of issues if github has to support the model that I mentioned
above - a model which is well known and popular at github. Mercurial
recommends bookmarks for cases like these, which based on my experience and
some of the discussions in mercurial dev list, doesn't work either. I hear
they are working on a "evolve" plugin in Mercurial to sort out some of these
issues. But overall, it's still very complex and requires a deep understanding
of the mercurial concepts/commands to achieve what can be achieved in git
pretty easily.

Given all this, I personally don't think it adds much value for github to
support mercurial in such a way that the workflows remain (almost) the same
irrespective of what underlying version control system you use.

~~~
arunc
RhodeCode already does this to perfection. They support mercurial, git and
svn. I understand from the value point though! AFAIK, mercurial is being used
in enterprise environment.

------
usmeteora
ahem, away from gitlab rants about projects unrelated to gnome, and back to
gnome...

yes please

I actually spent most of last week working with Gnome edits.

One thing to note however. I use Fedora and the latest version moved away from
X11 to using Wayland as a default (they can be switched).

Wayland is fine except its not viable for the gaming community. I am not a
gamer, but I work with GPUs, so up until the past year with big moves from
khronos to get GPU dev abstracted from just the gaming dev community, my dev
dependencies are still tightly tied to the gaming community.

Theres also some things about Wayland that make it a bit premature in my
opinion to be a Fedora default, though I appreciate Fedora being experimental
in all of their releases.

To switch back to X11 from Wayland, which in my case was not for anything
fancy GPU related, just to actually disable the touchscreen on my Asus UX303ub
zenbook with a skylake processor. Wayland can't do that....

I had to downgrade gnome, and edit both wayland.conf and X11.conf files to
switch X11 back as a default and then force disable the touchscreen.

This requires me to use an older version of gnome.

Why is this relevant? Because I'm not the only one right now retrograding
gnome because of Wayland/X11 defaults. A huge majority of the PC gaming
community operating outside of Windows OS is.

For me, in addition to doing all this, which only took a few hours to figure
out, I had to reconfig releases of the gnome themes I use to get everything
working. That being said, I'm obsessive about minimalist set ups and having a
synchronized desktop/terminal tmux/vim setup for development, so I will spend
6 hours to get a tiny aspect working the way I want it to.

Right now, alot of experimental OSes using gnome are using different versions
of gnome, so there might be overall less convergence on people using versus
working on the latest gnome if it were moved to git.

That also being said, people who do that kind of thing are the people who will
be deving on gnome, and it's what got me into UI linux dev in the first place.

That also being said, people in this world of gnome dev, are all using
different versions of gnome.

That being said, it could help expediate convergence of gnome with upgrades to
various Linux distros, as I know theres some mismatch between what I'm using
with Fedora right now to have some basic default settings work.

However, I'm still in favour of moving it to git. I would love to have access
to gnome dev that way.

I know I'm not the only one...

~~~
loudmax
> I'm obsessive about minimalist set ups and having a synchronized
> desktop/terminal tmux/vim setup for development

I think a lot of us here on HN are the same way. But if you want a minimalist
desktop, why in the world run GNOME? In my experience, XFCE and LXDE are both
at least as stable as GNOME and far more lightweight. Or you could go all in
and run a tiling window manager like i3 or Awesome.

~~~
usmeteora
TERMINAL SETUPS

I havnt tried i3 or awesome.

I use VIM almost exclusively except in some more applied settings for maybe
specifically an app.. and tmux works really nicely with Vim. That's why
everyone says "tmux and vim should just get married and get it over with
already" as a quote all over the internet. It could be the case with the other
two as well.

tmux also has a really easy way to create your own plugins, and tmux persist
sessions for savings windows and setups through reboots.

Again, these were things I wanted and found tmux to offer, while working
really well with unique vim setups I had integrated across multiple computers.
I don't know if i3 or awesome has these same features, but I think tmux is a
good setup and I don't see a need to switch especially with tmux persist.

I'd be happy to hear recommendations about i3 or awesome over tmux advantages.
tmux is so great to me, so if you had some good examples of how i3 or awesome
trump tmux then I would definitely listen and consider and look into switching
more. I've never had an issue with tmux and have really really liked it, and
found every aspect I need to be easily customizable through .confs and never
had to work with a predecided set of options rendered through a gui type
customization, which I always find limiting for me, rather than just knowing
or learning what to type in the .conf file for sys configs and having it just
work.

DESKTOP THEMES I've only recently switched to gnome and used LXDE before and
really liked it. I try to ride with Fedoras upgrades, and I know there were
alot of opinions going around about having the default installs being switched
to gnome, but I have not had any runtime issues with it.

That being said, I have a really powerful laptop, the one I'm running gnome on
(other is a hackintosh but thats not by choice its for dev reasons), so I
don't find anything I do on my laptop being compromised due to gnome, maybe my
own bad code, but not gnome.

That being said, outside of initial testing of my skylake, I mostly run
testing on centos on other systems and my main laptop currently running gnome,
is an interface for which to run other setups I effectively use as servers or
actual servers (and tmux persist sessions make it great to do that easily and
save my entire detailed setup if i have to suddenly walk away from a detailed
complex environment and not come back to it for two days and pick up where i
left off, and that happens often considering I work simultaneously on multiple
projects depending on my priorities for variable work schedules and more
entrepreneurial endeavors.) so I don't find myself fighting over computing
resources because of gnome.

I have not used gnome since I first tried ubuntu about 7 years ago, so I've
had it for about 6 months before and not too many issues, only with
integration for other unix setups, which is exactly why I think making dev on
it more accessible or inviting to people (gitlab being a good venue for it
aside, any venue) is a good option.

so far, I've been really happy with gnome since i came back to it. It took me
about 3 hours to be set up and learning how to customize and make my own
themes for it.

Gnome is not a bad desktop and it could benefit from more development by users
who care about these things, minimalist setups and are constantly aware about
runtimes and computational efficiency in every piece of code they write, which
sadly...and somehow, many people missed day 1 of learning coding (big 0) and
never seem to consider it until everything is breaking, and then say "hey lets
throw this on AWS without exploiting the backend at all to optimize for the
GPUs were paying for at the kernel level and assume AWS will figure out how to
optimize our code at every layer instead"

at the low level, I've never done any custom mods on LXDE, so I can't sit here
and pretend like I know some really good comparisons on computational
efficiencies and design of LXDE versus gnome, but I think gnome is a fine
interface, but could benefit alot still from more user dev.

Thanks for the reply and open to any other suggestions you have.

I still consider myself an amateur at everything computer/compsci related. I
only minored in Compsci and code 30% of my time at work and then alot outside
of work, but I'm not a top level dev by any means. I'm an Electrical Engineer
(one of those I know) and code because I want to..not to mention due to the
overlap.

So I'm always grateful to get feedback from people who spend more time
exclusively working in this space than I do.

------
simplehuman
I feel gnome should use the best product out there that they can afford
instead of the best opensource product.

Even Linux used the closed bitkeeper for a long time

~~~
cyphar
GNOME is part of the GNU project. If you think that the GNU project would use
a proprietary product, you might want to have a refresh of what the GNU
project stands for.

The fact that Linus used proprietary software to manage Linux was not seen
positively by the community and eventually (after one of the developers tried
to write a free client to interact with their proprietary service) everyone in
the free software world got a reminder why we shouldn't promote or use
proprietary services (the "gratis tier" access got revoked for the project).

~~~
jbicha
GNOME isn't really part of GNU these days.

------
tbrock
The core idea here is great. I've often wanted to contribute to Gnome projects
but have been more than slightly put off by having to learn their ecosystem of
tooling/hosting on top of already having to learn how their projects are used
together, built, etc.

Hosting on a git based system will lead to more people discovering and reading
the code and ultimately contributing. This benefits everyone. Gnome has truly
excellent projects and the more people work on them the better we have it.

However, this is one case where being a curmudgeon about being hosted on an
open platform will shunt the possible growth of contributors.

Please use github instead.

~~~
audidude
Using proprietary tooling is almost certainly outside of our foundations
charter.

~~~
tbrock
I'm talking about proprietary hosting in this case, not tooling.

~~~
maxvu
GitHub is far from commodity hosting -- a lot of what they provide is tooling.

------
dustinmoris
I don't get how a developer who's income directly depends on the code which
they are writing or in general thinks that their project has value can be too
cheap to pay a few little $ for an excellent, RELIABLE and FAST git source
control, which without doubt is GitHub and certainly NOT GitLab.

I mean as a developer your code repositories are the single most important
thing where you want to sleep well (and your production infrastructure).
Rather save money on shitty cinema tickets, Starbucks milkshakes (the shit
they produce cannot be called coffee) or save some money on some shitty Apple
adapters, but please get yourself a GitHub subscription.

~~~
Maken
It's not clear if hosting your own Gitlab instance (they are not using
Gitlab's servers, but their own) is cheaper than a Github's subscription. It's
more a question about owning your own infrastructure rather than cutting
costs. Also, as open source developers they probably are not comfortable with
depending on a privative software.

That said, given the option I would rather use Phabricator (as I currently
do).

~~~
dustinmoris
> not comfortable with depending on a privative software

I am sick of hearing this argument. What does that even mean? How is the fact
that GitHub doesn't publish their internal code making it's usage
"uncomfortable"? Do you think that if they opt to use GitLab and GitLab goes
down (and they will because they are shit) that they will adopt GitLab's
source code afterwards to continue the project because they rely on it? No
way... they will just move their git stuff to a different provider, done. So
what's the worry about a private hoster? Git itself is open source which is
probably what matters more.

~~~
cyphar
GitHub has other ethical issues aside from the server code being proprietary.

However, you're missing the point. Using proprietary software for hosting
means that contributors are forced to use the same software (thus giving up
their freedom). Not to mention it would promote proprietary software over free
software. Neither is acceptable for the GNU project.

Why are people surprised that the GNU project prioritises freedom over all
other factors? That was sort of the whole point of the project in the first
place, and compromising on that would mean that modern GNU/Linux wouldn't
exist.

~~~
dustinmoris
I think you are missing the point, because your argumentation about the GNU
project doesn't really apply/make sense for not using GitHub. When an OSS
project pays for GitHub it doesn't force contributors to pay for GitHub.
Contributors are still free to do what they want. The only thing which they
get forced to use it Git, which is open source itself and which is the same
with any other Git provider. On GitLab they would be just as much forced to
use Git. It is just as much as they would be forced to use the maintainers
chosen programming language. So the whole point about GitHub not putting their
source code open is really a moot point. It feels like that there's some
people who are so religious about open source everywhere that they have become
blind to the actual situation. Also not everything in the world can be free.
If a software developer doesn't want to pay for GitHub, then what on earth
deserves to be paid for. I mean why do I have to pay anything in the world,
why don't musicians and actors just decide to devote their time to only
produce free movies (equivalent of developers to only doing open source
software) or why shall I pay for my food? Surely everything should be free and
so should I only go to cooks who cook for me for free...

~~~
cyphar
The GNU project did an evaluation of various code repository services, and
GitHub has problems other than the server code being proprietary[1].

The problem is that GitHub's client code is also proprietary (namely their
site does not function when proprietary JavaScript is blocked), which makes it
a user freedom issue.

However, their server code being non-free is additionally problematic because
it would mean that GNU was recommending the usage of a proprietary service
when there are free software alternatives. Which goes against the mission of
GNU.

> If a software developer doesn't want to pay for GitHub, then what on earth
> deserves to be paid for.

When I use the word "free" I am referring to software freedom, not price.
Please re-read my previous comment with that context in mind.

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

------
kt9
Github should donate a license for Github Enterprise to gnome so that the
gnome folks can have the best of both worlds - self hosted + github. Its a win
for github to have a big project like gnome running on GHE.

~~~
zanny
Gnome already discounted Gitlab Enterprise as an option because its
proprietary.

It is very hypocritical to promote free software while using proprietary
software that you got special privilege for on the backend. KDE had the same
line of thought when they chose Phabricator - if features like LDAP weren't
locked behind Gitlab EE they would have used that, but they were only
considering freedom respecting options, because they are communities of
hackers that want access to improve their tools.

~~~
sytse
What kind of LDAP functionality did KDE want? LDAP login is in GitLab CE (open
source) but LDAP group sync is in GitLab Enterprise Edition (proprietary).

I wrote
[https://news.ycombinator.com/item?id=11092182](https://news.ycombinator.com/item?id=11092182)
but I can't find LDAP references in any of the linked emails.

