Debian and GNOME announce plans to migrate communities to GitLab

https://about.gitlab.com/press/releases/2017-11-01-gitlab-transitions-contributor-license.html

by l2dy • 9 years ago

326 155 9 years ago

about.gitlab.com

Dunedan• 9 years ago

I can't help to think that Gitlab is more and more eating Github's lunch. I wonder why we see so little from Github to get out of that situation.

FBISurveillance• 9 years ago

While I'm glad to see competition gearing up, I don't think GitHub and GitLab are in the same ballpark yet.

While I'm a big fan of their team and culture approach, we yet to see better/respected GitLab.com SLA guarantees — it still feels like they're doing too much "testing on production".

zaarn2• 9 years ago

"testing in production" indeed. One of my repos has been stuck in limbo for over 2 months now after I attempted to migrate it to a group namespace from my own profile.

Though I generally do like GitLab and favor Github alternatives over Github as I see it as a single point of failure for the FOSS community at this point.

kogepathic• 9 years ago

While I'm a big fan of their team and culture approach, we yet to see better/respected GitLab.com SLA guarantees — it still feels like they're doing too much "testing on production".

Agreed. However, if you need more reliability than gitlab.com it's not difficult to host GitLab yourself in a VM or on bare metal.

Many companies already have their own physical servers in a DC (either colocated or leasing). Hopefully the people managing these servers know what they're doing and can give the developers a good SLA. Although some additional work on file/DB syncing would be necessary to have a hot spare.

edjboston• 9 years ago

Gitlabber here.

We have a plan to address this and are kicking off our move to GCP shortly. Our top-level engineering department goal is to make gitlab.com ready for mission critical workloads and are targeting industry standard SLA's (e.g. three 9's). You can see our proposed architecture here if you're curious: https://about.gitlab.com/handbook/infrastructure/production-...

lukaslalinsky• 9 years ago

GitLab being open source and easy to run on your own hardware is a huge "selling" point. I don't think it's helping their income much, but it's growing the community of users and the money will probably come later. It's very hard for GitHub to compete with that. GitHub could introduce CI and other things that GitLab has, but it would be just one extra feature you have to pay for.

knocte• 9 years ago

I don't think it's helping their income much

Being opensource is not normally an aspect that helps the income, actually the other way around. Opensource is the argument that wins for the customers that appreciate lack of vendor-lock-in.

grabcocque• 9 years ago

Classic innovator’s dilemma. Their first mover advantage has made them complacent.

icebraining2• 9 years ago

I don't see why Github would have to cannibalize their own product to compete with Gitlab..

akerro2• 9 years ago

Because github still has 99% of that market. Just look at how many repositories opened by Google, Facebook, Apple, Microsoft, NSA, GCHQ and 100s of others big players are on Github and how many on Gitlab.

syshum• 9 years ago

Yes but how many of those are just mirrors and sources for non-contributors to find the code. See Linux Kernel as an example, the Kernel is mirrored on GitHub but none of the actual development takes place there.

dordoka• 9 years ago

That is true. But I reckon those big players just said "let's go with the flow and move some stuff to Github, good from the marketing point of view, etc". My point being that is just a trend. If Github is not careful, that trend can change anytime. Debian and GNOME are well known, big open source projects. This helps them a lot and pushes that trend a wee tiny bit in Gitlab's side.

sytse11• 9 years ago

Some of these use GitHub for their open source work but mostly GitLab for their closed source work.

dalore• 9 years ago

People/companies go to GitHub to be social. It's the Facebook of computer code. That's why all the big players are there, so they can share/market themselves. It's also where a lot of programmers put their code so they can show it for interviews. That's why there are so many public repositories there.

alvil• 9 years ago

Most of these companies projects on Github are projects of their employees, not official projects :)

pizza2342• 9 years ago

It's not so easy. Which lunch are you talking about? Self-hosted or hosted?

I don't think GL will ever have anything much in the hosted sector, for two main reasons:

1. GH's infrastructure is far ahead of GL, and 2. the social factor also affects companies that have private repositories, but also public ones - it wouldn't make sense to only move the private repositories to save money

When we think about the self-hosted, then it's possible, but I'm not sure if that would significantly affect GH, which has a different business model.

regularfry2• 9 years ago

The way I see it going is that many, many large companies will have a bunch of teams on GitHub (with good reason), with both public and private repos. They will also have a bunch of teams on GitLab instances that have been wildcatted into existence, possibly before GitHub had decent inroads, but more probably so the code doesn't leave the firewall.

At some point, a Boss who may or may not have Pointy Hair will look at the bill for GitHub, and the bill for the GitLab infrastructure, and say "Why am I paying for both?" At that point, the teams with code that can't leave the firewall have the trump card, and private repos on GitHub have to move off.

It's not the money itself that makes the argument, it's paying twice for the same thing.

romanovcode• 9 years ago

Can't see this happen until they fix their unintuitive UI and general slowlness of application.

Other then that GitLab is amazing.

sytse11• 9 years ago

Have you tried our new UI in GitLab 10?

We're not done yet making GitLab faster but it is getting better quickly. Last big thing we're working on are merge requests with hundreds of comments. Should come out on a few months.

jameskegel• 9 years ago

Conversely github has never deleted my work and sidelined me for a day by making foolish mistakes

mathw• 9 years ago

I don't actually understand this. Are they referring to the agreements for contributing to GitLab itself, or for contributing to things hosted on GitLab, which surely have nothing to do with the hosting at all?

jlgaddis4• 9 years ago

Yeah, I'm not sure what they mean by "migrate their communities".

I'm not exactly real clear on "... and open source projects" either. Debian used to use Alioth [0] pretty extensively. Maybe they're getting rid of that and moving everything that was on there to GitLab.

I get that this is a press release but it could be a bit more informative, IMO.

[0] https://wiki.debian.org/Alioth

magpi3• 9 years ago

I follow the debian devel list and yes they are moving away from alioth

tribaal• 9 years ago

That's exactly what the link you pasted says - Debian is closing Alioth and migrate to using gitlab.

No automatic migration is planned - you need to migrate the repos you are responsible for yourself.

jepler• 9 years ago

The Debian project has been investigating several alternatives to Alioth's version control functionality. I have not 100% kept up on the discussion, but I think gitlab is either selected for sure or is a leading candidate. https://wiki.debian.org/Alioth/GitNext

Even if they adopt gitlab for version control and pull requests, it's a very misleading headline that the "debian community" will be migrated to gitlab.

absoluteHNnoob• 9 years ago

From Debian News (https://www.debian.org/News/weekly/): yes and it is going to be named Salsa (https://wiki.debian.org/Salsa).

detaro• 9 years ago

Contributing to GitLab itself.

bayindirh2• 9 years ago

I think they will migrate the systems which they host VCSes. Since they may need to make changes in the code to suit them, abandoning the legal stuff makes using, modifying and contributing back stuff easier.

ufo3• 9 years ago

GNOME and Debian wanted to replace some of their infrastructure with Gitlab but before they did that they asked Gitlab to get rid of their CLA. Before this announcement, people contributing to gitlab itself effectively gave full control of copyrights to gitlab but from now on contributors will keep full control of the copyrights for what they contribute.

GNOME and Debian are very serious about free software and are wary of using software with CLAs because at any moment the company can switch future versions of the project to a non-free license, without input from the community and despite the software containing code originaly from the community.

I wouldn't expect Gitlab to do something stupid like this today but getting rid of the CLA protects the free software community from Gitlab doing stupid things in the future. For example, if they end up being acquired by Oracle or some other FOSS-sabotaging company.

tinus_hn• 9 years ago

See also:

BitKeeper

plupf• 9 years ago

So how does DCO differ here? I'm not getting anything from three words.

ubernostrum2• 9 years ago

I wouldn't expect Gitlab to do something stupid like this today but getting rid of the CLA protects the free software community from Gitlab doing stupid things in the future.

I'm confused now about what was in Gitlab's CLA. The CLAs I've signed never transferred rights to someone else, only asserted that I had the right to grant a license and was granting a license I wouldn't later revoke (since the point of a CLA is to protect a project from "oops I wasn't supposed to contribute that" or "oops, new boss here decided to revoke all our contributions").

I'm also confused why GNOME and Debian would have a problem with a CLA even if it did constitute a transfer of rights, since FSF actually does require you to sign over copyright to them in order to contribute, and GNOME and Debian seem happy to use FSF projects.

glutamate• 9 years ago

GitLab, a software product used by 2/3 of all enterprises, ...

This claim is false. The linked survey shows that GitLab has a 2/3 market share in self-hosted Git providers. Not every enterprise self-hosts a git repository.

jlgaddis4• 9 years ago

Why let the truth get in the way of a good press release!? /s

Cthulhu_• 9 years ago

You're saying it's a falsehood and Nicole Plati, our media contact, gave alternative facts to that.

dominotw8• 9 years ago

I bought this up on HN in the past[1], but it gets instantly downvoted( by gitlab employees?) , my comment was a response to CEO claiming how their marketing is honest[2].

They also declared Gitlab CI as number one CI by excluding Jenkins because of their made up defintion of "modern" .

1. https://news.ycombinator.com/item?id=15590240 2. https://news.ycombinator.com/item?id=15589654

YorickPeterse2• 9 years ago

You are most likely getting downvoted because of statements such as:

    > These guys are not honest people, just copycats under the guise of "open".

SmellyGeekBoy• 9 years ago

This whole thread is full of their employees arguing (quite aggressively in some cases) with people for calling them out or questioning their marketing claims. I wouldn't be surprised if they're downvoting en-masse too. Doesn't inspire a lot of confidence in their company and I'm surprised this type of behaviour is allowed on HN.

compuguy• 9 years ago

Last time I checked Jenkins is a modern CI product.

ShabbosGoy4• 9 years ago

To be completely honest, Jenkins is garbage slow enterprise tier. GitLab CI Runner is a pleasure to work with. Jenkins was hosted on our production box, and it used to freeze up whenever someone pushed.

Marketing folks aren't technical enough to understand CI anyway. This is why marketing folks shouldn't step on us tech folks toes - you'll just look like an idiot and end up embarrassing yourself.

camgunz• 9 years ago

How much do you really care if their marketing department is aggressive? Isn't it better that GitLab is open source and a reasonably good member of the OSS community? Honestly I don't even count those stats as false; Jenkins feels super old and the context weirdness ("Not every enterprise self-hosts a git repository") actually makes sense. If this is the trade to support OSS, it's way better than building a shadow surveillance state under the guise of profit via advertising revenue.

sandworm101• 9 years ago

>> if their marketing department is aggressive?

Telling lies /= aggressive. Where advertising makes claims that are objectively false they should be called out. This isn't 'puffing' or hyperbolic opinion. This is saying X is Y. That these lies are in support of an agenda with which many here might agree does not matter.

sytse11• 9 years ago

We claim it based on the assumption that almost all very large companies (enterprise) host their own source code and they are switching to git. We have 2/3 market share with self hosted git as shown with two data points https://about.gitlab.com/is-it-any-good/#gitlab-has-23-marke... I'll consider adding the rationale to the page.

We're seeing organizations adopt SaaS but the largest companies tend to be the last ones to switch.

You quote 'a software product used by 2/3 of all enterprises'. I see this as a different and weather claim. We and our competition can easily make that claim since almost all Fortune 500 companies have at least one use of GitHub, GitLab, and Atlassian.

bunderbunder• 9 years ago

I would assume, at the very least, that some significant portion of those enterprises who are switching to Git are Microsoft shops who are just switching to a version of TFS that includes Git.

I'd also guess that "Bitrise users" is a sample group that differs in significant ways from "Enterprise users".

dominotw8• 9 years ago

From bitrise link

We randomly selected 10,000 apps as a base

"2/3 of all enterprises" can only be true if all enterprises are building apps on bitrise.

stult2• 9 years ago

I dunno. I do R&D tax credit studies for hundreds of enterprise software firms and I always ask what version control system(s) they use and where/how it is hosted. I would guesstimate between a third and a half use GitLab in some capacity. And even then a lot of the time it's only for some teams or some projects. I do work with a disproportionate number of MS shops and a disproportionate number of medium to large companies (and few very large companies), but that's kind of the point. Those companies account for a lot of the enterprise market, yet you aren't including them in your claim. You've still got amazing market share and an impressive product, so there's no need to exaggerate. Just say 2/3rds of self-hosted git. That's a powerful enough marketing statement in and of itself.

dragonwriter2• 9 years ago

We claim it based on the assumption that almost all very large companies (enterprise) host their own source code and they are switching to git.

Almost all × Almost all (even assuming that's not overstated for either of those claims, which given the evidence of your inappropriately narrow definition of “enterprise” and my experience in the parts of that space you don't seem to have considered, I doubt) isn't the same as all, or even almost all.

We and our competition can easily make that claim since almost all Fortune 500 companies have at least one use of GitHub, GitLab, and Atlassian.

“Enterprise”, as a software market, is more than Fortune 500. Not only is that an overly narrow definition for private, for-profit enterprises, “enterprise” also included large public and non-profit (e.g.—but not exclusively—academic) institutions.

tzs• 9 years ago

I tend to believe claims of the form X is used by Y% of Z, but not give much weight to them because they are usually less impressive than they sound.

For example, I recall IBM marketing once claimed that OS/2 was used in some very high percentage (it was close to 100%, if I recall correctly) of Fortune 500 companies (or some similar group). Did that mean OS/2 was taking off in the enterprise, displacing Windows left and right?

Nope. It just meant that most Fortune 500 companies had at least one OS/2 system. Take advantage of its excellent DOS multitasking to migrate a few legacy DOS systems from dying old hardware to a single new machine under OS/2, and your Fortune 500 company counts as using OS/2 even if that is the only OS/2 system you have.

williamchia• 9 years ago

Thank you for your candid feedback - we've updated our homepage to include a more accurate headline: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...

akavel• 9 years ago

The rationale analysis they published via the linked article is interesting:

https://docs.google.com/document/d/1zpjDzL7yhGBZz3_7jCjWLfRQ...

jhasse• 9 years ago

GNOME already started, check out https://gitlab.gnome.org/GNOME

connorshea3• 9 years ago

Their infrastructure tracker has a lot of interesting info about the move[0]. You can also read through the development mailing list, it has a lot of discussion about the GitLab migration.

At GitLab we're tracking the blocking issues they've brought up in this issue[2].

[0] https://gitlab.gnome.org/GNOME/Infrastructure/issues [1]: https://mail.gnome.org/archives/desktop-devel-list/ [2]: https://gitlab.com/gitlab-org/gitlab-ce/issues/35287

jwildeboer2• 9 years ago

They claim that Fedora requires a CLA. Which is simply not true. Fedora was one of the first projects to completely remove the need for a CLA. Seven(!) years ago. See https://opensource.com/law/10/6/new-contributor-agreement-fe...

sytse11• 9 years ago

Fedora requires an FPCA. In the comments below https://about.gitlab.com/2017/11/01/gitlab-switches-to-dco-l... we say the following about that: "While FPCA may not be a typical CLA with regard to rights and restrictions, this is not the only factor we looked into. We also were looking into whether there were terms in general, other than commonly used open source terms. Our analysis took into account that non-legal users do not always understand the nuances of legal language and can be deterred by any CLA, restrictive or not, if they do not understand the terms."

jwildeboer2• 9 years ago

I understand your position. But it hurts me a bit to see all of the hard work we put into replacing the Apache style CLA with the FPCA and our messaging around it to make sure we explain it in transparent ways being reduced to "doesn't really matter, it's still just a CLA if you're not an expert" :(

jrochkind14• 9 years ago

Any major open source project which is accepting contributions with no agreement at all from contributors is asking for trouble.

bobajeff• 9 years ago

I remember reading awhile back that email was better suited than GitHub for large projects (eg. Linux). Wouldn't that still be the case with GitLab?

tremon• 9 years ago

Probably this link: http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel... ?

In that case, yes, that applies to GitLab too. The main problem is how GitHub and GitLab manage subprojects: GitLab forks are strictly hierarchical in how they manage pull requests and contributions (you can only submit patches from your repo to the single repo that you forked from).

But that may not be an issue for per-package repositories like Debian has on alioth. Debian does not have a monotree like the Linux kernel, every (source) package is a standalone project so the same objection does not apply here.

ramosmd• 9 years ago

For how GitLab deals with forks, this blog post may offer some insights: https://about.gitlab.com/2016/12/01/how-to-keep-your-fork-up...

This doc may also help: https://docs.gitlab.com/ee/workflow/repository_mirroring.htm...

DouweM• 9 years ago

Note that "you can only submit patches from your repo to the single repo that you forked from" is no longer true for GitLab starting with 10.1 (released October 22, see https://about.gitlab.com/2017/10/22/gitlab-10-1-released/#me...), and hasn't been true for GitHub for a while (perhaps forever).

sytse11• 9 years ago

Previously discussed the blog post https://news.ycombinator.com/item?id=15602564

WD-423• 9 years ago

As someone who has attempted to contribute to the GNOME project, this makes me super happy. The current process is archaic: attaching patch files to weird bug trackers and then sorta just waiting for someone to get back to you... A proper pull request system with code review would lower the barrier of entry for contributions to these projects significantly.

therealmarv• 9 years ago

I don't even know how to do that although I use git every day ^^

WD-423• 9 years ago

It's not hard to create a patch from a commit, but it's very awkward and doesn't fit the "flow" I've become accustomed to while using git.

owninghome• 9 years ago

Yup, I can’t count how many times I kept bugfixes, improvements, or tweaks to myself because the submission process is too complicated and user hostile.

This is honestly a problem with any submission process involving patch files. I’ve submitted a few via mailing list and I can’t express how much I dread seeing source controled this way.

mdaniel• 9 years ago

For sure, and it's arguably worse when they claim "patches welcome" and then the PR sits for years without so much as a "please wait." Insult to injury when the PR is just a typo fix, or cleaning up a blatant lie in the documentation.

johannes1234321• 9 years ago

Then you also didn't work on the kernel, the community where git came from ;) There you have to attach the patch to a weird e-mail and hope somebody picks it up.

But it's true - a pull system is nice for drive-by contributions. In some projects I noticed that after being listed in GitHub (be it as mirror or primary place) the number of contributions improved, but also many low-quality contributions came in.

carussell3• 9 years ago

a pull system is nice for drive-by contributions

Did you mean a patch system? With a patch, you just send upstream the patch, and you're done. Pull-based syncing is good for (and was designed for) frequent collaborators. As a one-time contributor doing pull requests, after you've cloned the repo and made your changes, you have to set up some public remote so that others can pull from, push up your changes to that remote, send upstream a message that it's ready for them to pull, and make sure that remote maintains uptime until at least upstream has had an opportunity to pull, at which point you can then do whatever you want with it. It really doesn't make a lot of sense to use this workflow for anything but frequent collaborators, where the setup costs are supposed to pay off later, after you've shared your nth change.

Or did you mean it's nice in the sense that increases the volume of contributors, because there's a long tail of people who are familiar with and only know how to deal in pull requests?

chungy• 9 years ago

The kernel’s process would be far superior to what GNOME does currently. I’ve simply not sent GNOME patches because they won’t accept them over email, and require using a wonky web interface (bugzilla) with an account to do it instead.

I would really much rather to be able to just do a `git send-email` as many other projects (not just the kernel!) accept.

kochthesecond2• 9 years ago

Absolutely. There is a near hundred hour startup cost to get into helping gnome, so making this process simpler should really be prioritized.

oAlbe• 9 years ago

What do you mean? That it takes one hundred hours of experience with the code base to be able to start making contributions?

0d311• 9 years ago

I find the same issue with working on Python.

jwilk3• 9 years ago

The title says "Debian and GNOME announce plans to migrate communities to GitLab" but unless I'm missing something, there's nothing in the article about this supposed migration.

marenkay2• 9 years ago

Debian and GNOME both plan to migrate their communities and open source projects to GitLab

1st paragraph.

shmerl2• 9 years ago

I'd really appreciate Web based way of Debian bug reporting. It doens't need to replace the current one, I suppose they can make some Gitlub plugin for e-mail method.

teddyh• 9 years ago

GitLab is not replacing DebBugs, it is replacing Alioth.

shmerl2• 9 years ago

It could compliment it, not replace may be.

ericfrederich• 9 years ago

From where? Article doesn't mention where they're migrating from.

passivepinetree• 9 years ago

From the email patching system. It's a tried-and-true model, but it tends to be unfriendly to new contributors.

jwilk3• 9 years ago

GitLab is unusable without JavaScript enabled. It's disappointing to see free software projects even consider adopting it.

jancsika• 9 years ago

Just navigated my own running instance of gitlab-omnibus with Firefox's javascript.enabled set to false. It looks fine to me-- I can navigate, view the issues, and presumably post comments.

What is it that you are claiming is unusable without JavaScript?

jwilk3• 9 years ago

I can't register, because the "Register" tab on https://gitlab.gnome.org/users/sign_in doesn't work.

Issues (such as https://gitlab.gnome.org/GNOME/json-glib/issues/26) show the initial message, but not the comments.

(I'm sure that's just tip of the iceberg.)

0xFFC• 9 years ago

Although unrelated, but with recent migration to Meson in Gnome ecosystem I really want to contribute to their code base in my spare time. Autotools was just like hell to work on!

MrFurious• 9 years ago

i guess that debian and gnome are preparing her nuclear reactors for execute gitlab, :P

Ruud-v-A• 9 years ago

I was under the impression that Debian is in the process of moving to Pagure [1]. The reasons mentioned in the LWN article are not invalidated by Gitlab's announcement of dropping the CLA.

[1] https://lwn.net/Articles/724986/

connorshea3• 9 years ago

Based on the Debian Wiki, plans have since changed[0] (unless this page is outdated?). That LWN article is from June, the wiki article was last edited in September.

My understanding from the mailing list is that they're planning on using GitLab, at least that's what I heard last. I could always be wrong.

[0] https://wiki.debian.org/Alioth#Deprecation_of_Alioth

vbernat• 9 years ago

You are right. Part of discussion starts here: https://lists.debian.org/debian-devel/2017/10/msg00264.html

ausjke• 9 years ago

An active gitea user here, gitlab is too heavy for my person self-hosting site, at the moment, github for social coding, gitea for personal repo, tried but not jumping on gitlab and do not see a need for that.

marenkay2• 9 years ago

... pair that with Drone and/or GoCD.

Personally I avoid using GitLab for professional and private use as it is using Omnibus packaging and comes with a whole bunch of software that usually is neatly packaged by any Linux distribution.

jbverschoor• 9 years ago

Great news for GitLab!

Debian and GNOME announce plans to migrate communities to GitLab

Related Stories