From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from pine.sfconservancy.org (pine.sfconservancy.org [IPv6:2001:4801:7822:103:be76:4eff:fe10:7c55]) by sourceware.org (Postfix) with ESMTPS id 40CDA3858D1E for ; Fri, 23 Sep 2022 22:00:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 40CDA3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sfconservancy.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sfconservancy.org Received: from localhost (unknown [216.161.86.19]) (Authenticated sender: bkuhn) by pine.sfconservancy.org (Postfix) with ESMTPSA id 619C7E2C8; Fri, 23 Sep 2022 22:00:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sfconservancy.org; s=pine; t=1663970409; bh=6fCRgEGM9c7VZFwxiLorsTeTrAfVfNjsPIY5jRCvjVc=; h=From:To:Subject:References:Date:From; b=GVJTRMTfM4ZPtIT8dSZcBkLIqbITjfIaczy+oHvmyiy8rfhs2XQRQAngePOTLCXGT /p8vMZ454aAzhUSb4kpV+hfKsW0BRa2dkURlM/mFOgvOJgbgazIcf5EsxlXER4e3Gn iTc1wxwAl6jWqEEQwhoLIo70PddbgbXkAl5yZzkTuZchREhz7oidp8gUobIaKuwwwy PqVMBPrMxUs+xnQDbYLeAL6YtORA1osjl6twkQRstky6Jzclf5OIornWZhCCBhKm9K neQNqt3oG7IR8zWq7b2BMO9twi/XMYih6IP+W9XpsDkvdDjq6am0xzHJ0EBMVtTAAo 9M4vbBQeyLixg== From: "Bradley M. Kuhn" To: overseers@sourceware.org Subject: Re: Role of sourceware for hosted projects Organization: Software Freedom Conservancy References: <58991505-d402-bc5f-5ee8-fff48dcde6cd@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAABVQ TFRFAAAAWjotvpiH/PHt27Sj7sq8lXFeBchlBgAAAAFiS0dEAIgFHUgAAAAJcEhZcwAACxMAAAsT AQCanBgAAAAHdElNRQfiCx4VFw6omMmeAAACAklEQVQ4y43UPZPbIBAGYGdu0puzQ51bI+qMdXId r0F1RoLrwfb+/5+QF307VVR4PDxiF14h7Xa7t3q8LJGjavj7a1euCYiZnaPnv9DF4FyMLKdXOPs4 XM7KKzzKaF83gem+hUuF8QYUg7Fb4LEQAK1OG3hu4bbC3LpUC87+B9AMfQOg0yv0owEOK4x1+gnu M3yaV3jOMGxvKoXEKC9gAoabJtZYlXO8wJcb1hMHQClZgSj7cbzsY4a2vSqltIlz8nMpZnMkEmVw N4DtcYJo3AMPXFIMRMax/BjhOxZi2CpKKpWSZCd4C8aZ4CpzjR+Cint9WEp5H12IbbySEpHdaYVh OY9onf0Qq9//zDCFEW0MbFjUz7mHD1UdO4B3iErk9whdKdWVRuW5YLl5KnU2rjTBDyPmQImm5mec WQx7X3fBNwAzQ9kvBTKR0BwR3Bewhisn2mpkhea3BZwBcdorRlQk9QKecyZukRPeHTmuEL1FdjlJ tmTlvoAJPnRaMnKinNICn4QthNaKlNAlLae9sc5UODaelVh+l345u7ZMIY89GNdmWV8cIaTFlLGm QKLrzQykh/Aw02WsdoE2l1g7JIPdyWGFL6Hy1uJZsEjavLUXkVyeIdrbpPoXQHxDG0l68wEoW8vG BLI6qc2XoUEWCUI26aQfK1wypuwV7v6mtMhtgL8avOP/pBCiigAAAABJRU5ErkJggg== Date: Fri, 23 Sep 2022 14:59:51 -0700 Message-ID: <87czblg3ag.fsf@ebb.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 =E2=80=94 do= nating 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 =E2=80=94 or at least tried to during his interrupted presentat= ion. 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=C3= =AB (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 , 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 =E2=80=94 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. --=20 Bradley M. Kuhn - he/him Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Become a Conservancy Sustainer today: https://sfconservancy.org/sustainer