Re: Role of sourceware for hosted projects

["Bradley M. Kuhn" <bkuhn@sfconservancy.org>]

Frank answered on other points, I just want to address the ones that relates
specifically to SFC:

Paolo Bonzini wrote at 07:04 (PDT):

> 1) it does seem weird for Conservancy to be the fiscal sponsor for
> *Sourceware*, which is essentially "a machine" rather than a
> coherent/cohesive set of projects.

Organizationally and governance-wise, it's not much different than a member
project that's a library used by other FOSS projects.  The users of such a
project are all developers, usually with their own FOSS projects, and those
FOSS projects that combine with the library aren't usually member projects
of SFC.

Logistically, it's a different because the needs of an infrastructure
project are quite different than the needs of a software development
project.  However, I urge you not to think about Sourceware as merely a
machine, because that does a disservice to the individuals who have spent
person-years of their lives maintaining and improving this infrastructure.

From SFC's perspective, Sourceware is actually primarily a group of
volunteers, deploying solutions for the guest projects, working with the
community of the guest projects to assess needs and prioritize those needs.
Eventually, once Sourceware has a fiscal sponsor, it will probably also be a
community of volunteers working with paid contractors to do that work.
IBM's Red Hat (and Cygnus before it) is a donor to that effort — donating
bandwidth and machines.

> 2) Migration to IT infrastructure hosted by Linux Foundation, as in the
> "GTI" proposal, might not take into account the needs of smaller projects
> very well.

I really agree with this too, and it's a point that Mark has been raising
quite a bit — or at least tried to during his interrupted presentation.  I
think the Sourceware Overseers and SFC have been quite clear that feedback
from guest projects (and their own fiscal sponsors) about plans for fiscal
sponsorship *of Sourceware* are quite welcome.  However, we really have to
keep reiterating the distinction that *fiscal sponsorship of Sourceware has
nothing to do with the fiscal sponsorship of any guest projects*.  (e.g.,
GitHub isn't automatically fiscal sponsor if you host your project on
GitHub.)  But, we do hope guest projects (and their own fiscal sponsors, if
they have one) express their needs, concerns, and any other opinions.

Indeed, with regard to the GNU projects on Sourceware, the opinion of the
FSF is highly relevant and we should consider it.  I was really glad Zoë
(FSF's Executive Director) has been able to join this list and attend the
Cauldron sessions, and I look forward to hearing more from her.

> But there is no reason for these projects to live on the same server or
> have the same development model; and there's no reason for all of the
> services to be provided by a single server. Different services can be
> easily outsourced to different people, companies or external providers.

As we discussed on one of the public BBB chats, another part of SFC's
excited interest in helping Sourceware is how bad things have gotten with
regard to proprietary infrastructure for FOSS projects.  Sourceware is one
example among many of initiatives that are trying very hard to resist
proprietary software infrastructure for FOSS development.

SFC has been collaborating for the last year with OSU-OSL, and recently
began dialogue with projects such as Codeberg, and a few other ad-hoc
collectives that run self-hosted GitLab Community Edition instances.  As
part of our GiveUpGitHub campaign <https://giveupgithub.org>, we're seeking
to provide as many alternatives as we can to FOSS projects that don't want
to use proprietary infrastructure.  This is admittedly a very big challenge,
but in SFC's opinion, the best way to face a big challenge like this is to
diversify approaches — working in collaboration with volunteers who care
deeply about the issues.  When we received the Sourceware application, we
were thrilled about it for this very reason.

On this point, plainly stated: Linux Foundation does not offer a commitment
to FOSS infrastructure for FOSS projects.  At the Cauldron session, the
example was given of Yocto as a project that LF has served well with
infrastructure.  Yocto's mailing lists are hosted on groups.io, which is a
proprietary mailing list software for which even to *subscribe* to the
mailing list, every subscriber must agree not to attempt to reverse engineer
their mailing list system (which would include, say, trying to figure out
how they deal with things like spam to apply the solution to GNU Mailman).
That's as FOSS-unfriendly as it gets.  Yocto also uses a Slack instance for
their chat services.
-- 
Bradley M. Kuhn - he/him
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Sustainer today: https://sfconservancy.org/sustainer