Ideas for Guix development priorities from the Survey

Guix User and Contributor Survey 2024

• Extensive survey - 943 full responses
• Broken into three parts:
  • ​Adoption (Part 1) - how do users start using Guix?
  • Usage (Part 2) - how do users develop their usage?
  • Contributors (Part 3) - how do people contribute?
• Gives us strong indications of what our community loves and struggles with
• The first section of the slides draws conclusions from the survey to create ideas for discussion - 5 development priorities
• Then - in case you didn't read the blog posts (!) - the follow-on slides show the key statistics that support the need for those priorities

5 Guix

Dev Priorities

What the survey tells us the priorities are for adopters, users and contributors

(ideas for discussion!)

#1 Improve review speed

#2 Package freshness

#3 Firmware experience⚠️

#4 Runtime performance

#5 Errors and Debugging

#1 Improve review speed

• Timely reviews with actions taken on contributions is overwhelmingly the biggest request from contributors

• Over 60% of developers selected it as their highest organisational request. It was top-3 in every question!

• Directly damaging morale of contributors

"I really dislike that 70% of my patches don't get reviewed at all, how simple or trivial they may do. I do really test them and dogfood so contributing seems like a waste of time as someone without commit access"

"already checked ”timely reviews/actions”, but I want to emphasize how demoralizing my contribution experience was. I was excited about how easy it was to make, test, and submit a patch; I would love to help improve the packaging situation for things that I use. But it’s been about a year now since I submitted some patches and have received exactly 0 communication regarding what I submitted. No reviews, no comments, no merge, nothing. Really took the wind out of my sails"

"Slow, or sometimes inexistent, feedback for submitted patches and issues"

"I still use Guix, but am a previous contributor. Important patches (for me) which I submitted were/are ignored, so I've stopped contributing

#1 Improve review speed

The survey showed improving the speed and capacity of patch review is the #1 priority. There are various suggestions that come under the category of automating patch testing and acceptance. Contributors identified this as their #1 desired technical improvement.

Some of this also mentions increasing CI capacity, and testing more branches. Contributors identified this as their #3 technical improvement.

"We really need to improve the CICD situation. I see we have so many system tests that catch issues. Let's make sure each patch has run at least a couple of those system tests before it is being merged, or even before a reviewer has even looked at [it] ..."

"Minimizing the required work needed to keep packages up to date ..."

There were a lot of comments that the overall complexity of contribution was too high. How much of the process can be automated? Is the level Nix takes it to achievable?

Q:

#1 Improve review speed

If you ask 900 people their opinion you get passionate views. We should be aware there were some negative comments about the project being elitist and inward looking:

I was passed over for commit access (even though I surpassed the 50 commit requirement) because I could only find 2 people to vouch for me, not 3. Then my patches stopped being merged, and some 2-year-pending patches I sent were closed without good reason. With the way Guix is run and how they treat contributors, it is an insulting/degrading process that I am no longer willing to put myself through."

"Keep manual up to date, I think we need more committers doing reviews and giving more love to darker corners"

All the best. The project might need more hands to review incoming patches"

How can more committers be added? What prevents this?

⚠️

Q:

Social and organisational focused comments noted that the project has more work than the current committers can handle.  A consistent suggestion in the survey is to add additional committers.

#2 Package freshness

Ideas for discussion:

1. Do the things in #1 that speed up reviews to increase capacity.

2. Add a community repository: in a similar way to the Arch User Repository (AUR) which is more open access. New developers can build up experience in this environment. Users choose to enable this if they wish. Core committers can promote from here if they wish.

3. Add a pull request workflow. This would increase the velocity and ease the path for new contributors.

"Much of the software I needed wasn't packaged, and it eventually became frustrating. I tried to package what I could, but some things felt extremely difficult, E.g., `jujutsu` `ghc`. [continues ...]

"To many packages updates were lagging behind, this was raising concerns for me from a security point of view"

If we can't increase the number of committers, can we change the framework by adding a community repository?

Q:

The survey showed that users and contributors want the latest packages (package freshness). Adopters identified missing packages as being a key reason why they couldn't use Guix.

#3 Firmware experience⚠️

Given the constraints what can be done to help users? What is the best for users and Free Software?

"Exclusion of all references to non-free software (and no suggested step-by-step easy setup) made a full-featured initial installation untenable."

Ideas for discussion:

1. Improve documentation so users are at least informed about Nonguix.

2. Provide Nonguix as an option in the installer and let them choose. 60% already do!

3. Create our own equivalent of Debians rules (DFSG) and allow firmware as they did. In Debian's case they created a separate archive and include it in their installer.

Firmware not being part of the distribution is a big problem for both new adopters and long-term users: 33% of users said it limited their satisfaction.

Q:

Doing something in this area will be difficult due to the GNU FSDG. The survey also showed strong opinions on all aspects - our community is a wide tent.

#4 Runtime performance

"Foremost faster guix evals. I forget what I was doing while it runs"

"Building guix takes too long time for packagers. It is not clear why everything needs to be compiled when only contributing a package. Why does the documentation need to be build when adding a package?"

Improving Guix's runtime performance for contributors centres on how long it takes to build and test packages.

"The core tooling was far too slow (e.g. pulling updates, etc.); Nix is slow, but nowhere near as slow as Guix (was back then, but I'm not aware of the kind of order of magnitude improvements that would have been required). Core functionality was not reliable enough for a server operating system (shepherd, logging, system rollback). [continues]"

"Guix pull is too slow. The guix ci servers are inaccessible from my location, requiring a proxy."

Improving Guix's runtime performance for users is wrapped up in their perception that "guix pull" takes too long. There are also mentions of how much resource Guix uses on small systems. It impacts about 50% of users, so it's a big issue. Is this problem tractable?

#5 Errors and Debugging

“I just want to reiterate that the debugging process can be painful sometimes. Sometimes guile gives error messages that can be bewildering.

"guix is very-very slow and consumes too much memory and CPU for what it's doing. also error messages are the worst i've seen in my 10 years of programming"

Generally for contributors that are new to Lisp and/or new to Emacs the tools are clearly a big issue. Debugging issues with tooling is also problematic since Guix is a completely different approach. Together these create a high barrier.

Contributors highest priority technical improvement request is debugging and error reporting. About 20% of contributors asked for this, and it's ranked in the top 3 overall.

There weren't any particular suggestions just lots of "this is hard!". In the widest sense there were requests for more 'how-to contribute' guides.

Similar to Runtime Performance, is this a problem that can usefully be focused on?

Guix Adopters

• How does usage develop?
• What do users love?
• What do they struggle with?

Who's curious about Guix?

• Guix is growing - with many new users getting started

  • 50% have less than 2 years experience with Guix
• Users are GNU/Linux knowledgeable:
  • ~48% Experts/Advanced - 50% Intermediate - almost no beginners!
• Some experimenters are interested in Nix, and explore Guix as well

• Group 1: Increased interest in "declarative" - Nix halo effect?

• Group 2: Guile and Lisp curious seems a separate group - also people coming from Emacs

How do they adopt?

• 50% of users adopt Guix as a GNU/Linux distro - this is surprising as it's the harder method.

  • Some are experimenting with NixOS and they also try out Guix at the same time. Many are coming directly from another Linux.

• Just over a third adopt GNU Guix as a hosted package manager
  • Debian, Ubuntu and ArchLinux were all mentioned
  • The survey doesn't tell us much about why they are doing this

How do adopters struggle?

1. Shortage of example configuration: templates and code to use

2. Lack of practical guides, how-tos and videos: not an issue with the manual
3. Lack of integrated drivers: not knowing about nonguix or unable to configure
4. Missing packages or out of date packages
5. Unable to run compiled binaries: binaries compiled on a "standard" Linux
6. Issues with encryption
7. Runtime performance and efficiency: guix pull too slow and using too much resource
8. Complexity of learning curve and maintenance: too much overall effort required
9. Nix is more practical, featureful or popular: e.g. missing 'flakes' features.
10. Language ecosystem issues (Docker, Go, Rust, PHP etc)

There's inherent complexity in Guix as it represents a different approach with substantial benefits. Even for expert Linux users it's a difficult learning curve. Additionally, there's accidental complexity in the implementation. How could the tooling, docs and support systems help users adopt?

Q:

Guix Users

• How does usage develop?
• What do users love?
• What do they struggle with?

Guix System Usage

• Over 70% of users use Guix as a graphical desktop directly on hardware

• Server usage jumps from 5% of adoption to around a third
• Guix home is used by Guix System users, but not by hosted users (17%)
• A lot of users are packaging their own software - comments compare vs Nix flakes

Q:

What are the implications for packaging priorities, testing and docs?

How can Guix make it easier to on-board into some of the features? (e.g. Guix home) Build on Guix shell? Why are the deploy features lagging when server usage is high?

Q:

Hosted Guix Usage

• Possible difficulties in the user experience when hosted as the stop % are much higher (e.g. nearly 20% stop using Guix Home.)

• A lot of comments about difficulties using (graphical) Guix packages when hosted

What does 26% "stop" for guix package mean, using Guix home?

Potential for expanding the 'package my software' use-case?

Q:

"Guix home breaking Fedora. Troubles with binary applications due to the non-fsh nature"

"Problems using it on a foreign distro. Guix Home particularly assume that you are using guix system. I had to tweak the .profile a lot to get it working."

I found setting the numerous variables and comments recommending I do so contradictory and so confusing"

"Some DEs don't integrate as well as they do on other distros."

Satisfaction & Limiters

• Most users are satisfied and ❤️ Guix

• Survey asked which areas limit users satisfaction

"examples, a show of how a task is done in Debian or OpenSUSE  and contrast it with how the task is done is guix would be helpful"

"guix is very-very slow and consumes too much memory and CPU for what it's doing. also error messages are the worst i've seen in my 10 years of programming"

"coming from Nix: smaller, less up-to-date-package set, substantially fewer home services"

"Guix is unusable without nonguix / proprietary drivers"

70% satisfied

What should Guix improve?

• Performance and resource usage is consistently in the top 3, with many comments.

• Package freshness and more packages are consistent as something users want, and the lack of required packages prevents them from using Guix more. Users and contributors consistently rejected a smaller distribution with more focused packages.

• Package reliability: many comments are about configuring and using packages - a missing service  - or not working (graphical apps) in a hosted environment

• Docs means how-tos, example code that can be cut-n-paste and videos

Hardware drivers

• Most users use Nonguix and drivers when using Linux

"As a long time Arch user I found it difficult to configure Guix for daily use. I need proprietary video drivers (and possibly other bits to get everything working?) and I don't remember if I ever got those up and running."

"Exclusion of all references to non-free software (and no suggested step-by-step easy setup) made a full-featured initial installation untenable."

"Guix is unusable without nonguix / proprietary drivers"

66% use Nonguix

Guix Contributors

How do people contribute?

• Around 454 people sent patches in the last two years ('active contributors')

• Many sent just 1, or a few patches. The top-10 contributors have all contributed over 700 patches each

• Most contributions are code (60%), but there's also plenty of other things happening!

• Project is 94% volunteer driven

• Contributors are reasonably satisfied - about 35% are Certain to contribute again

Contribution friction

• Previous contributors (59 participants) comments are very interesting. The two things that put them off are:

  • Response to contributions was too slow

  • The contribution process (e.g. email and patch flow)

• Also the number #1 issue for active contributors it was P1 on every question

• The theme is lack of response and a lot of friction

16. Check list for contribution

https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html

Technical improvements?

• Contributors #1 request is to improve the speed and capacity of patch reviews

• Package freshness and more packages are consistent as something users want, and the lack of required packages prevents them from using Guix more. Users and contributors consistently rejected a smaller distribution with more focused packages.

• Package reliability: many comments are about configuring and using packages - a missing service  - or not working (graphical apps) in a hosted environment

• Docs means how-tos, example code that can be cut-n-paste and videos

Thank You!