Re: Should we apply for GitLab's open source program?

[Daniel P . Berrangé]

On Thu, Sep 17, 2020 at 09:32:57AM +0100, Alex Bennée wrote:
> 
> Paolo Bonzini <bonzini@gnu.org> writes:
> 
> > On 17/09/20 01:39, Bradley M. Kuhn wrote:
> >> One thing to note is that my understanding is that most of what you're
> >> getting access to through this program is proprietary software features 
> >> that
> >> GitLab offers as add-ons.
> >
> > Basically all we need is the increased access to the CI environment (not
> > just 400 minutes), and none of the add-on features.  Self-hosting would
> > of course help but we'd have to pay for the hardware resources to run
> > the CI, and have someone that can keep the hardware running.
> 
> It seems for the time being that public CI is still unlimited. The idea
> of making our position as an FLOSS project "official" was to preempt any
> changes to that might come down the track.
> 
> The question of using proprietary features hadn't come up beyond a
> hand-waving of "ohh there is a long list". We are however thinking about
> consolidating some of our more disparate infrastructure onto gitlab so
> it's mostly in one place - for example the bug tracker currently hosted
> on launchpad. Personally I'd think it's unlikely we want to move things
> like the mailing lists which are currently on nongnu (via Savannah).
> 
> Ultimately as developers having to manage infrastructure is a bit of a
> time-sink and currently it's hard for volunteer admins to be as
> responsive as cloud-scale hosting companies who's income from non-free
> software hosting pays for all our server time.

All the evidence we have is that developers generally do not do a good
job at maintaining infrastructure in their spare time. This is largely
unavoidable since a developer is always going to treat sysadmin tasks as
a part time thing to spend as little time as possible on, prioritizing
their coding work. So we end up either with unreliable services that
continuously break (look how many times has Patchew died from ENOSPC
this year), or the service happens to work reliably but is unmaintained
becoming increasingly out of date and thus vulnerable, or the service
simply ends up lagging behind state of the art offered by alternatives.

>                                                 If there was a free
> software only instance of GitLab which offered the same level of service
> I would personally be interested but I don't know how much of the
> projects income could be diverted to supporting that versus the travel
> bursaries and other such things we usually spend our money on.

Clearly the ideal situation would be 100% free software infrastructure
we can use at zero cost, while still being state of the art in terms
of services available to support our workflow. This doesn't exist, so
we have to figure out the most effective tradeoff to make that supports
QEMU's needs in an effective manner.

GitLab's open core model means we're at least partially using open
source infra, even if some features are closed. The basic GitLab CI
features are actually open source AFAIK, so we're not relying on the
closed source infra part of GitLab in that area. IOW, joining the
open source program there is simply about getting an increased grant
of free hardware resources to use.

This is certainly preferrable to us making more use of Travis or
Cirrus CI, or GitHub Actions, all of which are 100% closed CI
systems AFAIK.

Some projects have deployed their own GitLab instances (GNOME,
FreeDesktop), but that is not without significant challenges in
terms of deploying and maintaining the software as well as
providing sufficient hardware to go along. eg See the surprising
effect this self-hosting had on FreeDesktop costs:

  https://lists.freedesktop.org/archives/wayland-devel/2020-February/041232.html

It has been a long tedious road merely to bring up a small number
of CI runners on hardware sponsored by Red Hat, let alone get
enough hardware to replace everything that we and our contributors
currentl get for free via various public services. 

There's ultimately a big gap that exists in terms of a publically
host Git Forge that offers state of the art features, based on
100% open source infra. I'm not seeing anyone being able to solve
that in the forseeable future, and it doesn't seem like a sane use
of QEMU's limited contributor time to divert resources away from
development into infrastructure. We need to make a pragmatic
tradeoff, certainly favouring open source where possible, but if
we need to use other services too that's acceptable.

Our switch to increasingly use GitLab for CI is certainly an
improvement over our historical use of Travis, Shippable and
Cirrus, and better for our contributors than our reliance on
a handful of machines that only the QEMU Git maintainer can
access, or the patchew system that breaks multiple times a
year.

> In this regard FLOSS projects are both leaches on paid for services as
> well as being useful public facing PR for a SaaS platforms abilities.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|