Re: Guix (and Guile's) promise, and how to (hopefully) get there

[Juliana Sims <juli@incana.org>]

Hey y'all,

Ekaitz, thank you for opening this thread. RIP your inbox.

I think this thread demonstrates in itself one of our biggest issues. A 
few folks have mentioned it indirectly. I'll be direct. We can't stay 
on topic.

So once again, Ekaitz, thank you for clarifying what this discussion is 
supposed to be about. In the context of consensus decision-making, this 
is part of what's called facilitation, and it's absolutely vital if we 
want to use a consensus decision-making model for governance. I think 
we absolutely can do that if we just use the tools others have built 
for making consensus work -- like the idea of facilitators.

But I digress.

After that preface, I'm going to respond specifically to the points 
Ekaitz highlights as the topic of this thread.

 > - Do we need independent funding so we can pay for our machines and
maintenance?

I don't know the details of cost and source off the top of my head 
(they were recently summarized in another thread), but my instincts are 
screaming, "Yes!" I'll return again to this later, but we should be 
paying people to do systems administration work because systems 
administration is boring and tiring after a while. Above all, no single 
individual should have to carry the weight of paying for our servers.

 > - Is the Guix Foundation the way to do it?

Again, I don't know enough to say with certainty, though most likely. 
Because...

 > - Does GNU, or the FSF, have some role on that?

...Guix should break with GNU and the FSF. Moreso the FSF, but the two 
are irrevocably intertwined in the public conscious -- which is the 
primary reason Guix needs to break away. To avoid relitigating what has 
been litigated more than sufficiently already, the FSF made a bad 
political move that has destroyed its social capital and, as a 
side-effect, its financial capital as well. Even if it can help us with 
funding, it shouldn't. (More on why in a bit.) In terms of extant 
infrastructural support, from what I can tell, the FSF gives us hosting 
for a simple website, an ancient git forge, and mailing lists. While I 
can't speak to mailing lists, I can speak to websites and git forges. 
Given the incredible complexity of our existing CI and QA 
infrastructure, putting up some HTML and having a gitolite service 
running on a machine are comparatively no effort. I suspect the mailing 
list -- after migration -- would be the same, though I reiterate my 
ignorance here.

To forestall misunderstanding, I absolutely do *not* mean that Guix 
should compromise on free software. Guix's greatest strength is that it 
is an uncompromisingly idealistic and principled project. If we change 
anything about our stance on non-free software, it should be that we 
add a single sentence to the manual informing people about the 
well-known and well-supported channel providing non-free firmware, 
followed immediately by a disclaimer that we neither endorse nor 
support non-free software, and that's *all*. Official Guix channels 
should never knowingly ship non-free software, nor should we ourselves 
provide instructions on installing, configuring, or using non-free 
software itself -- we should just point people to the place that does.

Why, though, should we go through the effort of migrating our mailing 
lists, domains, etc. just because it won't add *that much* more work? 
This is a big and important question. The short answer is, the FSF is 
radioactive, and we're getting sick from it.

Let me be frank. I promote the heck out of Guix. I've shilled Guix to 
more people than I can count, from professional systems administrators 
at internationally-acclaimed universities to hobbiest hackers in the 
most obscure corners of the internet, and everywhere in-between, all of 
whom are incredibly capable, knowledgeable, passionate programmers, and 
some dozens of whom are free software hackers. The main turn-off people 
cite to me is our association with GNU. As a particularly poignant case 
study, in conversations with someone who has contributed significantly 
to Guix on my recommendation and did not stay around, the primary 
complaint was not the email-based workflow (which was noted as unusual 
but not overwhelming), but that the GNU affiliation *makes them feel 
uncomfortable in our community*. They haven't told me of negative 
interactions with members of the Guix community; the GNU affiliation 
alone was enough. If we recognize that there is not enough growth in 
effort going into the project, we should address the primary reason 
we're not getting new people to bring more effort: GNU.

 > - Can we improve anything relieving weight from the shoulders of some
people instead of putting even more on them?

I think so. As I noted above, if we break with GNU, I am highly 
confident we will see an uptick in new contributors, at least some of 
whom can help there. In the longer-term, we absolutely need to pay more 
people to do systems administration for the Guix project. If we start 
paying people, those are the people we should pay first. Our patch 
throughput doesn't matter if we don't have servers to distribute those 
patches to users.

 > - Would having more committers help relieve some of the weight?

Perhaps? This could allow more experienced contributors to focus on 
less-supported areas (sysadmin, for example) and help the overallow 
distribution of labor as a result. The issue is less the number of 
committers than the number of *commits* by relation to the patch 
backlog. To that end, any changes related to committers should focus on 
increasing patch throughput. In particular, we should focus on adding 
contributors who want and are able to help with specifically patch 
review. Indeed, my inability to commit (pun not intended) to patch 
review is the only reason I haven't put myself forward for commit. 
(Though I am working towards giving myself the time for patch review in 
the near-ish future.)

 > - If so, should we propose commit access to people, instead of 
waiting them to propose themselves?

Yes, and, to reiterate, we should prioritize committers who want to 
focus on patch review. This doesn't mean we *only* grant commit to 
people who want to review patches, but there should be a clear 
expectation of patch review for any new committers. Committers who see 
someone consistently providing good patches and/or review should be 
able to propose that person to the other committers.

 > - Should we ease the process of becoming a committer?

No, with one exception. If the committers discuss among themselves and 
feel that someone is making consistently helpful, quality contributions 
to Guix, but they haven't contributed 50 patches yet, they should be 
allowed to offer that person commit. For self nomination, nothing 
should change. Guix should not compromise on its ideals. We need people 
with a demonstrated dedication to those ideals screening others for the 
same dedication before entrusting them with material power in the 
project. Our current process seems well-suited for this end.

That's all I have to say at the moment.

As a final note, I want to highlight the amazing work from Arun Isaac 
and Chris Baines. While I know y'all have been working hard on Guix for 
a long time, I've paid the most attention to y'all's work this year, 
and from what I've seen, y'all have been kicking ass. You've made it so 
that the contributor workflow is not a meaningful point of weakness 
anymore. Thank you both.

Best,
Juli