distrochooser: a questionnaire that points Linux beginners at a distribution

The service promises orientation, not a correct answer

The project describes itself as an orientation guide for Linux newbies, and the description of the service is careful in a way that is worth quoting for what it implies about the design.

The Distrochooser is a service to help Linux beginners to orientate. The service is not an oracle and can not calculate 100% accurate results, but it helps to orientate.

That single sentence sets the bar for the whole product. A service that cannot be wrong is a service that never helps, because distribution choice is not a decision with a right answer. It depends on the hardware, the desktop environment preferences, the software a person needs, how much they value rolling releases versus long support windows, and whether they want a community they can ask questions in. What a quiz can do is take that pile of unstated preferences and turn it into a shortlist, with the reasoning visible.

The result is that the interesting engineering question is not how accurate the mapping is but how the questions and the weighting are expressed and maintained. That is a data problem more than an algorithm problem, and it is a data problem that has to be revisited every time a distribution changes its release cycle or a new one appears.

The project is hosted at distrochooser.de, and the topics attached to the repository include beginner, beginner-help, newbie-help, distributions, oss, web, linux and hacktoberfest, which is a fairly complete description of both the audience and the contributor recruitment pipeline.

Two branches, one live site and one in progress

The versions table in the project documentation is small and it is the most operationally important thing in the README.

The table has three columns: the version, the branch it runs from, and a remark. The row for distrochooser.de names the branch viisi and calls it the production version. The row for beta.distrochooser.de names the branch main and calls it the next version, currently in active development.

So the production site runs from a branch called viisi, and the branch called main is the next version, served on a beta subdomain. The default branch of the repository is main, which means a visitor who clones the project and starts reading will be looking at the unreleased version.

The two deployment targets are consistent with that. The production version is on distrochooser.de and the beta is on beta.distrochooser.de, and the logo asset in the README is served from an assetsbeta.distrochooser.de path, which suggests the beta environment is the one with the newer asset pipeline.

This branch arrangement is unusual enough that it changes how you contribute. A pull request opened against main lands in the next version, not in what users see today, and a change that needs to ship immediately has to go to viisi. The project does not explain the release process between the two branches in the README, so anyone with a hotfix requirement is asking the maintainers.

The release tags follow a plain version scheme, 6.7.0 from 2026-07-05, 6.6.0 from 2026-05-31 and 6.5.0 from 2026-04-25, which is a steady cadence of roughly one release every two months. The last push to the repository was on 2026-10-21, so the code is being worked on right up to the present.

A Vue front end and a Python server, built as two containers

The repository layout describes the architecture more clearly than the README prose does, and it is a two part application.

The top level contains a code directory, a doc directory, a locale directory, a matrix directory, a static directory and a static_root directory, plus a run.sh script and a GIT_HASH file. There are two Dockerfiles, Dockerfile.frontend and Dockerfile.server, which is the clearest statement of the split: the front end and the server are built and deployed independently.

The matrix directory is almost certainly where the distribution comparison data lives, since that is what the service actually decides, and the name matches the topic list entry. The locale directory is the translation set, and the contributor list makes that concrete: of the names shown in the contributors table, most are credited for translation, with a smaller number credited for code, for design, for infrastructure, and for answering questions.

That contributor breakdown is a signal about where the maintenance effort goes. A quiz that recommends distributions needs its content to change whenever a distribution's release cycle, support window or installer changes, and the people best placed to notice that are the ones who follow those distributions. Translation is a bigger share of the work than code, which is what you would expect from a service whose value is in its content rather than in its logic.

There is also a directory called .adr-dir, which by convention holds architecture decision records, and an OPENDATA.md file at the top level. Between them, those two entries suggest the project keeps a written record of why it is built the way it is, and that it intends its data to be reusable outside the site.

Two forges, and a request to coordinate before you start

The project is present on two code hosting platforms, GitHub at github.com/distrochooser/distrochooser and Codeberg at codeberg.org/distrochooser/distrochooser.

The reason for the second one is not stated directly, but the ecosystem context is well known and the topic list includes oss and hacktoberfest. Two platforms, a contributor request to coordinate, and a large translation contribution base is the shape of a project that has moved its primary community or is running two in parallel.

The coordination request is specific: if you plan to contribute, feel free to give a ping first, so work can be coordinated between platforms and efforts can be used in the best possible way. The README explains that the point is to avoid two people doing the same task in two places.

That is a small thing to state, and it is the kind of small thing that decides whether a project with a large volunteer base stays coherent. The alternative, which is what usually happens, is that the same fix lands twice or that a translation is done in one language on one platform and never in the other.

The README also points to CONTRIBUTING.md for additional information about contributions, and there is a CODE_OF_CONDUCT.md and a SECURITY.md in the repository root, so the governance basics are in place. The community also has a Discord server, linked from the README.

For a project whose main asset is a maintained comparison dataset, the governance of the dataset is the product. A code of conduct and a security policy are table stakes; the ping-first request is the part that actually protects the work.

Running your own copy means picking a branch and reading the docs

There is no installation or deployment command in the project documentation, and there is a reason for that which is stated plainly: this repository contains the code of the live site, and the site is deployed by the project.

If you want to run your own copy, the repository gives you the pieces rather than the recipe. There is a run.sh script at the top level, a Dockerfile.frontend and a Dockerfile.server for building the two halves, and separate static and static_root directories, which is the conventional split between the raw assets that get copied in and the served output.

The documentation for the running site itself lives in the doc directory, and the operational details for contributors are in CONTRIBUTING.md. For a project of this shape that is a reasonable arrangement, because the deployment story is tied to the maintainers' own infrastructure and the branch structure, and a fork is more likely to be a local study copy than a second production instance.

The one thing a fork has to decide immediately is which branch to base it on. The viisi branch is what the production site runs, and main is the next version. Both will run, but they will present different behaviour to a user, and a fork that wants to match what people actually see needs viisi.

The AGPL-3.0 licence is the other decision. It is a copyleft licence, and for a web service the obligation that matters is network use: if you run a modified version and let other people use it over a network, you have to offer them the corresponding source of your modified version. For a self hosted instance used by a single household or a company internally, the practical effect is small. For a public fork that people point their browsers at, it is not.

What a quiz cannot do, and who should reach for it

The limitation is stated in the project documentation, so it is not an inference, but it is worth spelling out what it means in practice.

A questionnaire narrows a field. It cannot check whether the distribution you land on has a working driver for the specific WiFi chip in your laptop, because that is a fact about a kernel package on a specific ISO, and it changes between releases. It cannot know whether the project you work on publishes packages for the release cycle you would get. It cannot tell you whether the community you will ask questions in is friendly to a newcomer, which is often the thing that decides whether a person sticks with Linux at all.

That is why the project says it is not an oracle. The service is a filter, and a filter that claims to be a decision procedure is worse than useless, because a person who trusts it will not do the second check.

So who should reach for it. A newcomer who has a dozen tabs open with distribution names on them and no way to narrow the list is the intended user, and the shortlist with reasons attached is the output that helps. A person with a specific constraint, such as needing a particular application, or a machine with unusual hardware, will not get a useful answer from a questionnaire and should be reading distribution documentation directly.

For contributors the target is different again. The valuable contributions are the ones that keep the comparison data current, the ones that add languages, and the ones that keep the site running. The code is a vehicle for those, and the contributor table shows the balance between translation, code, design, infrastructure and answering questions.

One last practical note for anyone evaluating the project as a dataset rather than a service. The presence of an OPENDATA.md file at the repository root is the place to look, because a comparison dataset that is maintained anyway is worth reusing, and a project that publishes its data under an open licence lets you build something other than a quiz on top of it.

Editorial conclusion

distrochooser fits a Linux newcomer who is overwhelmed by the number of distributions and needs a shortlist with reasons attached, and it fits a community that wants to point people at something concrete rather than at a forum thread. It is the wrong tool for anyone who needs a correct answer, since the project states plainly that it cannot calculate 100 percent accurate results, and it is the wrong tool for a distro maintainer looking for a compatibility statement. Before contributing or forking it, read the branch table in the project documentation, because the production site runs from a branch named viisi while main holds the next version, and that difference decides whether your change reaches users today or later.

Frequently asked questions

Official sources

1. distrochooser/distrochooser on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases