Ideas for Guix development priorities from the Survey
What the survey tells us the priorities are for adopters, users and contributors
(ideas for discussion!)
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
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?
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?
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.
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?
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.
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.
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.
"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?
“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 is growing - with many new users getting started
Reason for adopting Guix | Percentage |
---|---|
Declarative configuration | 82% |
Reproducibility | 72% |
Scheme, Guile and Lisp are cool | 72% |
Group 1: Increased interest in "declarative" - Nix halo effect?
Group 2: Guile and Lisp curious seems a separate group - also people coming from Emacs
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.
Category | Percentage |
---|---|
GNU/Linux distro as a desktop (guix system) | 46% |
GNU/Linux distro as a server | 5% |
Package manager on top of another Linux distro | 36% |
Shortage of example configuration: templates and code to use
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?
Over 70% of users use Guix as a graphical desktop directly on hardware
Deployment type | Percentage |
---|---|
Graphical desktop on hardware | 73% |
Server on hardware | 24% |
Server in a VM | 18% |
What are the implications for packaging priorities, testing and docs?
Usage type | Use % | Stop % |
---|---|---|
Guix package | 64 | 17 |
Guix home | 48 | 9 |
Guix shell | 36 | 10 |
Package own software | 40 | 9 |
Deploy (deploy/pack) | 19 | 8 |
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?
Possible difficulties in the user experience when hosted as the stop % are much higher (e.g. nearly 20% stop using Guix Home.)
Usage type | Use % | Stop % |
---|---|---|
Guix package | 50 | 26 |
Guix home | 17 | 11 |
Guix shell | 41 | 18 |
Package own software | 28 | 9 |
Deploy (deploy/pack) | 13 | 7 |
What does 26% "stop" for guix package mean, using Guix home?
Potential for expanding the 'package my software' use-case?
"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."
Most users are satisfied and ❤️ Guix
Survey asked which areas limit users satisfaction
User satisfaction limiter | Percent |
---|---|
Guix runtime performance (e.g. guix pull) | 48% |
Missing or incomplete services | 40% |
Error messages and debugging | 39% |
Shortage of informal guides & examples | 39% |
Hardware drivers not included | 33% |
"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"
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
Rank 1 | Priority |
---|---|
Package freshness (latest vers) | 1 |
Performance - faster guix pull | 2 |
Make Guix easier to learn | 3 |
Package reliability | 4 |
Hardware drivers | 5 |
More packages | 6 |
All Ranks | Priority |
---|---|
Performance - faster guix pull | 1 |
Make Guix easier to learn | 2 |
Package freshness (latest vers) | 3 |
More packages | 4 |
Package reliability | 5 |
Hardware drivers | 6 |
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"
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
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
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
Rank 1 | Priority |
---|---|
Debugging and error reporting | 1 |
Package freshness (latest versions) | 2 |
Automate patch test and acceptance | 3 |
Runtime performance (speed / memory use) | 4 |
Package reliability (installs and works) | 5 |
Contribution workflow (e.g. Pull Requests) | 6 |
All Ranks | Priority |
---|---|
Automate patch testing and acceptance | 1 |
Runtime performance | 2 |
Debugging and error reporting | 3 |
Project infrastructure (e.g. CI) | 4 |
Contribution workflow (e.g. Pull Requests) | 5 |
Package freshness (latest versions) | 6 |