Towards a more open Distrochooser

Just recently, I started labelling issues with the version-6 label. While the development did not started at all, I thought about several aspects of the project and if/ how they need improvements.

In detail, I want to address following topics in this blog post.

• Licensing
• User interaction and community
• Accessibility

Let's take a closer look into this:

Licensing

Currently, Distrochooser 5 is licensed using the MPL-2.0, which is a weak copyleft license. I am considering switching to (A)GPLv3 with the project.

I need to be honest. I put a lot of work into Distrochooser. It's my project for 8-ish years. I never expected it to grow like it did especially in the last two years, so I am quite attached to "my baby" (please note the quotes).

Personally, I see copycats (like services just doing a plain copy of the service) as a disgrace for open source.

If your fork/ idea has some significant improvements, then why not. That is good and wanted. This helps users and software to gain innovation. But just to host a basically identical service without any improvements? That's not open source, thats copying. For this reason, I think a stronger copyleft license will be needed. But more on this topic on a separate blog post.

User interaction and community

Currently, decision matrix refinements are mostly done using GitHub issues, followed by an by-hand change of me inside the admin panel. While this worked most time in the past, I think it is time to rethink this process. I have following reasons for this:

1. Inconsistency between "my" interpretation and the desires of the users
2. Long timespan between issue creation and actual processing (aka I am slow to react)

About the inconsistencies

When I talk about inconsistencies, we need to consider how the Distrochooser counts results. Currently, an answer can have multiple dimensions, which are either a "positive", "negative", "blocking" or "neutral" hit. Neutral hits are meant to redirect information to the user, stating some hints they might need to know. The neutral results do not affect the result calculation. But in some cases, these hints are more needed as a "negative" hit. So in fact, there is an inconsistency here.

Additional, it shows that ratings are more a scale than an numeric value, which needs to be put into a concept aswell.

About (response) time

The second point is about time and the fact that my response time is not that good, so I need to rework this process to get these changes quicker into the system. So how we could archieve that?

I am thinking about a some kind of entry point, where user can do a change request, e.g. for following:

• Addition of a new distribution
• Correction of translations
• Correction of the matrix

So basically the stuff currently only be addressed into my mailbox. But I have following ideas for changes. All of these changes will need different requirements:

The addition of new distributions will remain the job of the project maintainer (as of me). Why? This is due the fact that I don't want to repeat the mistake of adding fork-of-fork-of-fork distros to the service, which will confuse the user completely (and bloating the result list by alot).

I will keep the range of distributions compact, including distributions with an proper community. So for this aspect, I am thinking about an issue-based approach, allowing users to propose new distributions, while other users can agree on these proposals. An 100% agreement rate will not guarantee the addition, while I still think that the maintainer holds power on the update button as he needs to review if all information required are present. But this could allow to make this process a lot easier and community-friendly.

Translations are a tricky topic. While Distrochooser 4 was available in like 5 languages, Distrochooser 5 has 11. This means at the point where anything user-facing will be changed (like distro descriptions, answers, questions, help text, UI sections), anything needs to be translated aswell. So for these changes, besides the change itself, it requires a lot of localisation work before it can be updated to the service. I think there is the need for something easy, web based.

Matrix corrections are even trickier. They require a bit of knowledge how the service works, for example the currently 4 dimensions an answer can lead to:

But also here I think the proposal pattern could be used. This allowing people to actively participate in the service, even without having to work directly on a database, which I still do not see any need for.

In general, I don't know if all of this could be a piece of software or just putting pipelines together, this needs further concept work. But such an patter might be the easiest way to allow user to actively participate in improving the service. This will help to make the closed database more open. So you can actively participate even without having an SQL-Dump.

Accessiblity: Code

I am often writing tools as proof of concept,  while they tend to escalate towards being some kind of actual tool. Distrochooser was no exception to this. During development, this requires to "ignore" several aspects.

Documentation for example. But with user interactions rising and people willing to contribute, this needs to be adressed. Nobody likes spaghetti code.

Another point is the stack. Currently, the Distrochooser is based on Nuxt.js (a Vue.js framework) and Django. While I think Django is quite good for the backend part, I think the frontend needs to be revalidated. While I did a lot Vue.js work in the past (and nowadays React.js), I think the stack is not suitable. Like absolutely not suitable. Let me go into detail here.

SEO

The seo is..difficult. Due the fact that the JavaScript is absent, the template will always show an generic, english translation. This also affects OGP tags. So the target here is clear, make the SEO-visibility better. And use less JavaScript, if there is no other solution.

JavaScript

JavaScript. Thanks, I hate it. The clusterf*ck of node_modules dependencies is too much. Even as reactive apps are nice, they require a lot of client side loading. Additional, µMatrix or some Adblockers have issues with the frontend of the Distrochooser. Why adblockers? I am not entirely sure. Distrochooser has no ads, but I guess it's somehow related to the shadow DOM Vue.js might use. Additionally, there are users with NoScript an similar tools. For them, the service completely falls apart.

Personally I like using PUG instead of HTML, but for the sake of a more robust and JS-independend frontend I will consider to move the majority of the business logic of the frontend back to the server side. More details on ideas on this topic can be read in this older blog article.

Accessibility: User view

Several client-sided tricks done in the frontend showed to be a real bad way for accessibility reasons. They successfully prevent to use the service, e. g. for people using special browsers or text-to-speach modes. This needs to be adressed aswell.

Wrapping it up

This article became longer than I expected and will result in quite a lot of work, I guess. But currently,  I am keeping development low profile to focusing on the job/ study.

Actual development of version 6 could possibly start towards the end of the year. But I will focusing for this version more on a community-based service model to allow direct participation in the project. The technical implementation of Version 6 is still just a stub in my mind, but I think it is important to rethink some concepts instead of recycling all the time, ignoring long-standing issues.

That is all I have for the moment about version 6 👋

Photo by Martin Wettstein on Unsplash

Photo by Bozhin Karaivanov on Unsplash