caryoscelus:~#

You have probably already guessed the general direction of my answer, implied by the title. That’s right: i think binary packages (at least in a way they are usually handled) make a devastating blow to FLOSS development.

Consider the following. A user happily installs a program with a few keystrokes (or mouse clicks) and in a few seconds is ready to use it. Sounds great, right? In fact it works brilliantly, until user notices a bug or a missing feature, or even a minor issue such as translation mistake.

So they go to the bugtracker and fill an issue, only to get reply “hey, it’s already been fixed in our latest version”. They wait patiently and a few days/weeks/months or even years, bugfix or feature arrives at their repository.

Or, perhaps, the issue is minor and they want to fix it themself. Surely even a non-programmer can find the piece of bad translation (which they previously noticed in ui) in code. After struggling with web interface of source repository or with vcs itself, they finally submit a fix. Weeks later another user comes to complain that interface become broken because new translation does not fit.

Even worse is the case when user wants to make a fix that involves programming. To make a fix one typically needs to test that it works, but making program run from source is likely to take much more effort than the fix itself (this is especially true of code involving C/C++ or other languages without established platform-independent build systems).

In short, it boils down to extremely slow feedback loop and initial participation barrier being harder than necessary.

So what are alternatives?

First of all, stop “protecting” user from things they should be interested in: improving software and environment they use. Instead of spending efforts on fancy interfaces that do one thing or on creating yet another tool for shipping binaries, we can create tools to make source building more accessible to everyone, both “end-users” and developers. This includes better documentation and exposure for existing tools.

As for existing approaches, surprisingly many (about all of relevant ones) package managers do actually support source building. But beyond a few distros considered “advanced”, these features are themselves considered “advanced” and are not expected to be used by everyone (i’m thinking of debbuild here, a tool i never managed to actually successfully use beyond rebuilding of existing packages).

As far as i can see, the best development in this area might be NixOS: not only it offers benefits of both binary and source distribution, it also seems to reduce the cost of experiments by allowing side-by-side installation of several package versions and rollbacks. I haven’t used it yet (i’m sticking with my few years old debian installation), but it’s certainly the next distro i’m going to try.

Gentoo and ArchLinux are another two systems which embrace source building (especially the former) and mainstream integration (especially the latter). But back in the days when i was using them, i didn’t do much with those possibilities. Not sure why.

Perhaps language-based repositories also deserve to be mentioned here, but i don’t have much to say about them now. They do have their issues, such as quality assurance and security breaches (people are still using npm, you know), but first of all most of them do not have ambition to be universal.

Finally i’d like to say that as much i like to criticize approaches taken by others (as well as my past self), i still appreciate their hard work to make this world a better place. I just wish it would be more effective.