From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id 4MYOMXfzHGegfwEAqHPOHw:P1 (envelope-from ) for ; Sat, 26 Oct 2024 13:49:43 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 4MYOMXfzHGegfwEAqHPOHw (envelope-from ) for ; Sat, 26 Oct 2024 15:49:43 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=dustycloud.org header.s=fm3 header.b="G HkyAob"; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=YSY7XYHz; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1729950583; a=rsa-sha256; cv=none; b=BS/7gGeMbVZhtvWtArM2KBwYHlJY1WIHnbsQdQRBvYSB7i888E+abrZg0bGmj0Ub4Yuz7J KmkeQgYbm8cedn6iRB6+J1SyXcpeTga61d9nnwH/jtlon5Ldx+OjW2YlOUDC6QaKJpwwfU GtxKY9ruc8PCjwKEFFaSFVtkp42yzG6KiFxyUWHIbjR36J4XGassLHL2mK7d22KDBVwHlm IUvQbpx+HhUqJTRwJ+pVFLjiTuxNPJFS1w4Y0KTofbdcCd0LUka585bVtEdDK8v+6tBcpK LFvph3KJgbiygYzh5XWfHd1fvfh54/RAosfkVVd4kqWbgm2DEPSA+UHLmzvEOQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=dustycloud.org header.s=fm3 header.b="G HkyAob"; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=YSY7XYHz; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1729950583; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=xxkYV58IqL/4Ve5r1b+SGdHgtFV+ZQPdYZXLNv08Ngg=; b=CojqH0ZPTL8jFb5YOmNIzq9kX9CYCBSOcz7dvusY497of12O1oNi2bbos6VOSvtlv2Zyg2 2WTbAxyYHf6P2Anv4CHEiI1AaU9/14ybovqXmBt6V42nqW3SM7Jq09Uw/E6JlvIVggbCWZ dbm0jbd+0PY/fZGZ1tHseRkertOeMD3FB95S2DFwfnaDNiXfKT6nxlLa1lyydhJV/NYMEz wkM+wy7iNSKwwnRwX3zr9zLndzoU2ducNdaseSksKwMLcexoyVDm6JTWp8wt30ZdpA4C8h V612HiFoamERY8ORBUzxMANcRHRNE5U2KTEhVVjjyLQEZ4K1fAyAPsCGWo7bCQ== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D537C826A1 for ; Sat, 26 Oct 2024 15:49:42 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t4hA8-0004SZ-Cg; Sat, 26 Oct 2024 09:49:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t4hA6-0004SC-Ep for guix-devel@gnu.org; Sat, 26 Oct 2024 09:49:02 -0400 Received: from fhigh-a2-smtp.messagingengine.com ([103.168.172.153]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t4hA3-00044C-2M for guix-devel@gnu.org; Sat, 26 Oct 2024 09:49:02 -0400 Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfhigh.phl.internal (Postfix) with ESMTP id 37C231140138; Sat, 26 Oct 2024 09:48:56 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-02.internal (MEProxy); Sat, 26 Oct 2024 09:48:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dustycloud.org; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm3; t=1729950536; x= 1730036936; bh=xxkYV58IqL/4Ve5r1b+SGdHgtFV+ZQPdYZXLNv08Ngg=; b=G HkyAobCLSzExirgq2cd0KbyB1JrVNFALWqQkxAzeypGjdZj2XQEyfkqrJRnQ/eq4 v/lGNwU7W97j71CWCRpDpKfMmUdR4TDOmTNQ5FnJUztRFEUEd+7bH2c3jJV5RIHv Bg256uxR7+XI8SUJYMRpq+7cUU5B9QIv+FHl9p+u2HuX87sxaXwChyOCjCxi9Jgt qzL1l/z/eaih4N6T51HjPD0Drz/tJb3lpnPrdU/Viv6DjiJf3qB7Ww/BPAjoWQx+ Q+uClLB1N+5tmBWETvXsO9mMFpFSzE+IUaymnVBz32sWqJ3Ljbzk/rQ5/BlawnDR IfVmJEEf+AA5+OXgMTd+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1729950536; x=1730036936; bh=xxkYV58IqL/4Ve5r1b+SGdHgtFV+ ZQPdYZXLNv08Ngg=; b=YSY7XYHzHqF3jOlvMaq8klnnxUbBURJbNLcZMPegwxI6 OXidQU3i+7Sct0zr4VAH70LMz6bghRLnBeF4Kb0Axi8dTZkY8uQIrqeo7Lhz1KA4 xrWt6TE0Kz5FHGpaCmX1fd1OcysQWVUX0Yp8n9TvU/ie0BnJKo3PlTSvAt9gH14I qy8nFgTulOQlxKg6a3wxTuOIKHW7uCCgOUmKv2KLTxHjLpJHGW0HZ7Ic0ep75pM0 ZpEzUCLWDyswkRRf8gDnQcFyaYBukSLtNRyUuQECk360j/xUnjLKXz9vDaUL2J07 eLJm+vlGvPcUhTs0JPddN740PrQafu0VPyg4Lh6/9w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdejgedgieekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhephffvvefujghffffkgggtsehttdertddttddtnecu hfhrohhmpeevhhhrihhsthhinhgvucfnvghmmhgvrhdqhggvsggsvghruceotgifvggssg gvrhesughushhthigtlhhouhgurdhorhhgqeenucggtffrrghtthgvrhhnpedtgfejueel gfevvdduuddvfeduffeutdejleetfedtvdfhtdehjedvteetudelhfenucffohhmrghinh epshhhvggurdgsihhkvgenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpegtfigvsggsvghrseguuhhsthihtghlohhuugdrohhrghdpnhgspghrtg hpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepghhuihigqdguvghv vghlsehgnhhurdhorhhgpdhrtghpthhtohepvghkrghithiisegvlhgvnhhqrdhtvggthh dprhgtphhtthhopeguthhhohhmphhsohhnvdesfihorhgtvghsthgvrhdrvgguuh X-ME-Proxy: Feedback-ID: i006446df:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 26 Oct 2024 09:48:54 -0400 (EDT) From: Christine Lemmer-Webber To: "Thompson, David" Cc: Ekaitz Zarraga , guix-devel@gnu.org Subject: Guix (and Guile's) promise, and how to (hopefully) get there In-Reply-To: (David Thompson's message of "Fri, 25 Oct 2024 08:58:58 -0400") References: <6daee7b4-a5d6-4f80-bbfa-995e65e17ae0@elenq.tech> Date: Sat, 26 Oct 2024 09:48:54 -0400 Message-ID: <87r083ht4p.fsf@dustycloud.org> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=103.168.172.153; envelope-from=cwebber@dustycloud.org; helo=fhigh-a2-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -5.62 X-Spam-Score: -5.62 X-Migadu-Queue-Id: D537C826A1 X-Migadu-Scanner: mx10.migadu.com X-TUID: zAyPiASq5a86 Hello, hello! Thanks for starting this thread, Ekaitz, and it's nice to see the comments which have rolled in so far. We were talking about this thread on the daily Spritely engineering call and Dave went over what he had already said and I went on a long ramble of opinions, and juli and Dave said "well you really ought to say that on the list", so here I am, laying out my thoughts and opinions. On the challenges and opportunities we face =========================================== I want to open with saying that despite the challenges, I remain in belief that Guix is one of the most promising and hopeful projects in the entire FOSS space. Guix starts with good technical foundations and good community, and the areas for potential in terms of how many issues Guix solves that *nobody* else in the space is as well poised to take on continues to astound me. Of course, having potential and achieving potential are two different things, and I do think Guix has become somewhat stagnant, but not fully. The current trajectory is not particularly good, but we could steer the ship in ways that could be wonderous. Let us not waste our potential. On the challenges of being a contributor, in particular ======================================================= Consider this almost a subsection of the previous; it's large enough to also precede the rest. We're seeing a lot more interest in Guix these days I feel, but also less contributors "sticking around". I haven't done any metrics or comparisons, this is a gut sense. But I have talked to many people who have wanted to contribute to Guix, and we've certainly had many mailing list threads about it, and we know the following is true: - If you aren't yet a maintainer today, it's hard to gain commit access, and it's hard to feel empowered - The barrier to entry to participation is high; you have to not only learn emacs and so on, but you also have to learn to navigate mailing list structures which seem foreign to most young people. Only FOSS oldtimers feel immediately at-ease with the mailing list flow (and actually many of us old-timers don't feel that comfortable thesedays either). This isn't great. - Even if you pass those thresholds, even if you get a patch to the mailing list, what's the #1 complaint in Guix? That patches aren't being reviewed and aren't making it in. Alas. I think we're seeing some promising potential here around the move to teams, but I haven't been following that closely. Let's mostly acknowlede that we're not doing good here, and we need to do better. We're seeing enthusiasm that isn't translating to participation because people are feeling disempowered and that's no good. Okay, it's time to start talking about what we can do. On Guix, on GNU, on institutional housing ========================================= Let me open my suggestions with the most controvercial, so those who would be so upset with me leave the conversation early. Guix is allegedly a subproject of GNU, but this is mostly in name only (and with a small amount of not very reliable institutional support) and it's time for this connection to go. I feel sad to make this argument myself, because I *am* one of the people who believe that GNU is incredibly important from a historical perspective, and that this is underrecognized and underappreciated. But let's be frank: GNU's reputation is in the toilet, and Guix's own reputation is not boosted but tinged presently by association. You've seen the trope in movies, and it's one in reality too: "I can fix him!" the heroine thinks, and ultimately, she cannot fix him. The audience knows it, why do we not know it, as those playing the heroine's role? GNU's leadership is too stubborn and hopeless to be brought in a more positive direction. Many people here have tried, and I too tried to participate in GNU to bring it to a more positive direction, but ultimately I have come to the conclusion that this is a hopeless effort. It's time to move on. I think what we can do is carry the parts of GNU that *are* good, that *are* important historically, and bring them with us. A commitment to free software is good. Guix should remain a pure distribution; it is far easier to add impurities to an impure system than to remove them, and Guix has gone to great efforts to be built on pure foundations, and we should preserve that. Much of GNU's tooling (not all of it, but much of it) is also good, and we should carry that with us where appropriate as well. There's an obvious candidate with the Guix Foundation, and I think this is the right choice. I have some experience with US-based nonprofits if you'd like to talk about finding a US-based home as well. Perhaps moving away need not be done all at once, but I believe it should be done. I lay this out first, because I believe it impacts other aspects of this writeup, even though I think it is not the most critical. On leadership, on governance ============================ This leads to an immediate followup question: what is and should be the governance and leadership structure of Guix? I think there's a general feeling that there's stagnation and that things can't be done because we need a robust and non-heirarchical decisionmaking structure, but also we kind of don't have that, and so nothing is happening. I consider myself a "practical political anarchist"; I'm unhappy with the beauraucracies of the world and would like to see us do better in supplanting them, but the irony is that trying to produce flat structures of governance sometimes results in *more* beauraucracy and stagnation entering a system. So okay, let's talk about what we can do in the meanwhile. I think there's a lot we can do to iterate towards more cooperative governance structures, but in the meanwhile, we need to get un-stuck. And I think the right answer is an ironic one: I think the shortcut is to put Ludovic, with substantial support, as a kind of "chief visionary" of the project. Ludovic is probably reading this and dreading these very words I am putting down and that is *exactly* why he is a good candidate. The right people for leadership are often not those who want power, but those who are worried about the consolidation of power, who ironically are the best to put in the role. Every time there has been a major source of disagreement, it's usually Ludovic stepping in and giving his opinion that sets everything back to right. And I know Ludovic is deeply concerned about embracing that, and is far too well aware of the problems of Founders Syndrome etc, and that's partly why I trust him in this role. I have already said "ironic" in this section three times, so I won't say it again, but you get the point. The fact that Ludo ends nearly every email with "WDYT?" says an enormous amount about how he gathers consensus, which is really important, and one of the reasons he's a trusted steward of the project. (I feel a lot of affinity towards this personally. I am the Executive Director of my organization, but I would actually rather be on the engineering team, and indeed I tried originally to arrange things so that would be the case, but as you can see, well, now that's not the case. So it goes, I have traded my preference for hacking for building out opportunities to have other people be able to hack on the things I wish I was instead by providing the relevant structure.) Personally I tend to look at three projects in terms of how they are governed, and I have modeled a lot of the vision of Spritely off of these three orgs, and I think some amount applies to Guix, but not all of it: - Debian has the most successful example of an actually democratically-run organization in FOSS of all times. This has not removed the challenges of governance, because if you know someone involved in Debian governance, you probably also know someone who has experienced serious governance burnout. But it's still the best example we have, and if that's where we want to go with Guix, it's worth learning from Debian. But Debian also moves very slowly, and that's one thing that won't improve under this model. It's still probably worthwhile, though. - Linux is the most well known example of a start-topology model, and actually I'm not a huge fan of the project or its leadership and *certainly* not the communication culture that has been historically associated with the project, but I think, awkwardly, we can paint things as a "Linux to Debian pipeline" trajectory in my proposal. What Linux does have very well though is a lot of people successfully contributing and getting their code in, while being supported in the process. One interesting thing also about Linux is that there's an institutional home with the project leader being paid, and comments on that particular leader aside, I think that's important for avoiding burnout. The real big lesson for Linux is the history of "Linus Doesn't Scale" and its aftermath: I *am* actually suggesting both having more central vision, but also recognizing that the central vision - Blender is actually the project I think is most interesting of all (well, maybe more for Spritely than for Guix, but it is interesting to some degree). It has a nonprofit side at its heart (Blender Foundation / Blender Institute), and also has a more experimental usage-production driver on the side (the Blender Studio, which makes free cultural production artifacts which shape the software itself). Blender also has had a strong amount of vision/leadership, and I think in this way also has no small amount of Founder's Syndrome to work through (but it *has* been working through it afaict), but also has a large number of volunteer and paid contributors who don't work for the organization itself. (The ways it runs its community meetings is also interesting, but this is an aside.) What I think would be best for Guix is a bit of all three of these. In In the immediate, I think Guix already has a strong community, though it's a community people are having trouble "getting into". But its community is its first and most important, and *must be preserved and fostered*. I am just vaguely remembering my Philosophy 101 stuff, but I there's a part in The Republic where they're saying something like "Nobody who wants power should be trusted with power, and the people who should be put in power wouldn't want to do so, so in a just society, instead of people vying for power, they should be putting the people who don't want to be but are properly qualified in power." In the short term, I think, and it does not have to be necessarily a BDFL way, that it would be good to see Ludovic be appointed more as "Chief Visionary" and so I am probably, somewhat unwillingly on his part for all the right reasons, pushing him forward into the spotlight in that role. However, I think Ludovic really needs support, and it may take some time to arrange this, but I think it would be good to make sure that he can remain full time focused on this. More on that later. So let's say Christine's proposal for Guix is the "Linux to Debian pipeline". I'm saying that somewhat jokingly, but I think it's a useful framework to think about. I would also like to see more Blender'y aspects, but let's expand on that in the "paid opportunities" section later. I am not in earnest suggesting a return to a "true BDFL" type model; it may be mostly that I am saying that it's actually quite reasonable for Ludo to not be shy about chiming in. For years, Python had both an RFC process and also had Guido playing a stronger leadership role. It was good that he scaled back from it, but in the intermediate term while ramping up community ownership over the project, it was very helpful to have both. But really, even asking for more confidence in Ludovic's leadership, I say that because I know Ludovic cares about *empowerment* of contributors, which is the most important thing. My favorite Debian Project Leader, Stefano Zacchiroli, once said something like: "Debian is not a meritocracy, because meritocracies do not exist. However, Debian is run by the people who step up and make things happen, so Debian is a do-ocracy." It's not all on Ludovic or the present maintainers or anyone individually; we should all feel empowered to make Guix into the beautiful system we want it to be. (Also, if you have never read the origin of the "Bikeshed story", please do so now: https://shed.bike/ ) On infrastructure ================= A lot of the concerns recently have been "what's the back of the envelope math to keep Guix going infrastructure-wise and uhoh wow this looks like a lot". I think that's the reality we're in for the present, though I think that we have some opportunities to change the landscape. We have a number of people involved in the project with a background in P2P tech. This is something I would like Spritely to be more involved in with cooperation with Guix; I think we can get to the point where there's less assumptions about a centralized approach to package distribution at all. We aren't there yet, but it should be a priority. At the very least, we already have a content-addressed system... ignoring the trust issues of substitutes, even a naive approach to sharing source packages should be quite feasible in a peer'ish way. I think Goblins could provide a nice transport-agnostic foundation for unlocking content-addressed package distribution, but anyway. But we aren't there. In the meanwhile, investing in the infrastructure approaches we have does make sense. However I'd consider centralized package distribution, and building, should be something we consider "aspirationally part of the future-past". Regarding what to do in terms of "are we built entirely on mailing lists", etc: I do think we need to build more infrastructure, but this isn't entirely on Guix. Truth be told the mailing list structure is a barrier but isn't the biggest barrier... the biggest barrier is that contributors drop out from lack of getting their patches reviewed and accepted. So in a way, this isn't actually the biggest priority; helping get to better patch review is. On paid opportunities ===================== One clear way in which patch review could be improved is by paying someone to do full time patch review. There are two challenges here: how to allocate the funds, and whether or not this would decrease the motivation of other contributors. In my opinion, the most important things to spend money on are things that are important but otherwise would not get done in a project. In Guix, that's patch review. The problem with patch review is that it's boring comparative to authoring packages; unless someone comes in with a patch you really *want*, it's hard to be motivated to review patches. Certainly some members of our community do so, but not at the level that would be good, and also not with those same community members being committers who are able to help those patches get upstream. I don't think it would be the case personally that nobody else would be motivated to review patches if we had someone working full time on patch review; for me, I'd be delighted to see more happen, and I think I would find Guix even more exciting to participate in. I don't think that a bounty type system or other type of retrospective payment system would help. I think someone needs to be paid to do this, as part of their job. But there's an interesting phrase there, "as part of their job". The Linux kernel has primarily people working on it "as part of their job", but also many volunteers. Nobody seems afraid that people will stop being interested in working on the Linux kernel. Similaly for Blender, there is a core group of developers working on Blender for the Blender Institute, but what's interesting is that many of the people working on both Linux and Blender are not working for the "home" organization (though certainly some are), many are working for other companies that use said projects. But some people do indeed work for the home organizations of Linux and Blender, particularly on either core work or on important work that isn't exciting enough to volunteer on. But speaking of satellite organizations with paid contributors, well, *you*, dear reader, may be able to help make this possible! If you work at an existing organization, one easy path is to make the bold choice to say "Guix is the best way to solve this problem", should you have the authority to do so, and in that way prioritize using and also advancing Guix in that domain. "guix deploy", for instance, could use a lot of love, and an organization choosing to use "guix deploy" for devops could really unlock a lot of work. And if starting a new organization which is fairly Guix unrelated but you're in charge of choosing what tooling to use, why not choose Guix? Push for "guix shell" for development environments (well, we'd do a lot better here if we had MacOS support), push for Guix on your servers, etc cetera, et cetera. Even without Guix being at the center of your org, by relying on it, you can find time to improve it, and at least find time to find all the things that need improving. ;) But maybe, if you are so inclined, you could be even bolder, because I actually believe Guix could be a key foundation for several really interesting companies: - You could ship laptops pre-configured with Guix on them. (Maybe even the MNT Reform Next as a foundation would be really promising; I have high hopes.) Guix could be used to produce a system image that you can blast across said laptops. The biggest challenge actually would be updating the system; we need something like the synaptic package manager so that non-schemers can update their system. But holy moly I am sick of buying laptops for people and having them be just as afraid to upgrade them as I am afraid to upgrade computers I have with imperative systems, and where things go badly they can't roll back. Look unto System76 and what they have done with PopOS on top of Debian; something like that with Guix would be more than welcome. - You could run a hosting service company for end-users which you deploy with Guix. It could even have a web interface with simple drop-down selections of which services the user wants (you could even use Hoot for the frontend UI), and it could compose system definitions *programmatically* based on the selections which users make. - You could do the same as above but for businesses. - You could sell -- bear with me here -- IoT'ish type devices which the system images for the devices are programmatically generated by Guix and rolled out on microsd cards. Look, this isn't my market, I dunno. It feels like there's something here though. - For that matter, you could choose to use Guile and Guix as the default ecosystem for a startup. Go get that lush Silicon Valley venture capital money and roll around in it (or eat instant noodles) and build the next hype train product that someone would have built on top of Rust, but build it on top of Guile instead. Okay, and here's the one that I really think is quite possible: - You could build an open source competitor to Cloudflare Workers and AWS Lambda on top of Guile and Guix and Spritely's stuff. Yes, I think this is possible, and I suspect there's money in it. The point here is that by choosing to integrate Guile and Guix and etc into your place of employment, you can help the ecosystem, even without being a paid contributor from a central Guix Foundation home. And this is actually really good and healthy to have these kinds of things happen and it's the type of reason that Python and Rust have *such good ecosystems around them*. Schemers, and Guile people in particular for being such principled FOSS people, tend to be somewhat allergic to being in such positions, but grab some antihystamines, because a few research labs (I'll consider Spritely one of those) can't be the only ones pouring resources into Guile and Guix. Though oh yeah, you can absolutely use Guile and Guix in an academic context too. More of that! On Guix and Guile ================= Guix can't succeed unless Guile succeeds. I'm proud to be part of Guile, and I'm glad Spritely is pouring resources into Guile (and our funders as well, indirectly) and Hoot and etc. But we can't do it alone. Most of the concerns that reflect on Guix in this article are true for Guile too, even more so. Guile needs a lot more support. I hope we can see it happen, but I'm afraid it's another email, another chain of thought. But probably enough could be recycled from the above. I think Guile actually has a lot of promise which has been being realized recently, though. Guix brought the initial life to Guile which, for instance, allowed Spritely to be bold enough to choose Guile as its foundation (of course we dabbled in Racket initially; I am glad we landed in Guile-land again). We have to do a lot to make Guile more accessible and better maintained. I think Hoot will help a lot with that; I've also been impressed with a lot of the work that Andrew Tropin has done, but there's a lot more in general. I think, to return to Stefano's quote above, Guix and Guile and etc are at their best when they're a "do-ocracy, lead from good vision". I talked about Ludovic's role a lot, but actually it's everyone's role. But we should aim for less bikeshedding and more action. How do we make things move forward? Money is one thing. It isn't the only thing. But it does help. But really, most especially, we need to think about: "what will help us move forward?" We have good people, we have a wonderful project. Let's help people feel empowered, let's make things happen. - Christine