The heavy responsibility of the package maintainer

Published on 2022-11-05.

Even though being a ports or package maintainer is voluntary, it carries a heavy responsibility.

In the world of BSD and Linux, a software developer is someone who develops software, it's someone who knows how to program in a programming language like C (or something else). A ports or package maintainer on the other hand, is not someone who develops software, it is someone who typically maintains a port or a package (I am going to use the term "package" henceforth in this article for both ports and packages).

Of course being a maintainer doesn't exclude being able to program, but the "job" of the maintainer is not to develop code, it's to make sure that the software he maintains can build and compile on the operating system and to update or backport the package when the upstream developers release a fix or a new relevant version of the software he maintains.

From the perspective of a BSD project or Linux distribution, the web browser Firefox is a third party package. Firefox is considered a third party package because even though any developer can contribute to the development, Firefox is mainly developed by developers from Mozilla, hence Mozilla is considered the upstream development.

If I where the package maintainer of Firefox in a BSD project or Linux distribution, it would be my responsibility to track the development of Firefox. Whenever upstream releases a new version of Firefox, it would be my responsibility to make sure that the new version (or backported version) of Firefox can build and compile on the supported platforms of the OS. It would also be my responsibility to make sure any provided patches that make local changes to Firefox, such as the location of binaries, etc. works as they should.

Sometimes a package is maintained by more than one person which sometimes mean that the OS is better suited to track important security issues and updates from upstream and to provide timely updates via the build-in package management system. However, not all Linux distributions nor BSD projects have enough voluntary support from people to make sure that every single package gets timely updates. And sometimes the maintainer hasn't got the necessary time to update a package when he should. This can be a major problem if the update is really important. At other times, he may simply not notice the update because he's very busy. And still, he might also simply loose interest in the package and no longer want to manage its maintenance.

A responsibly maintainer will notify the proper channels of his decision to abandon a package, but as you know, not everyone is a responsible person. Also, a maintainer can become ill, get in a accident, or die, and then there is no one to inform the project of his absence. Eventually someone will notice that the package has become outdated, but sometimes this takes time, especially if the project is small and the package is not used by many people.

On Arch Linux every package has an extremely useful Flag Package Out-of-Date feature that any user of the system can use to report an outdated package. Since Arch Linux is a relatively big project with millions of users world wide, and because Arch Linux is a rolling release distribution with a policy of following upstream very close, this means that most popular packages on Arch Linux gets flagged almost immediately. This is a fantastic way for the community to help the maintainers.

Other projects use a version controlled repository like Git for their build scripts which makes it possible for users to issue update requests. Other projects use mailing lists, bug trackers, regular email and/or other tools. The easier it is to report something, the easier it is for the users to help out.

If a package no longer has an active maintainer, the package becomes "orphaned" and eventually removed from the package repository. However, this doesn't happen over night, often a package will remain installable long after it has been abandoned, which can be problematic if security problems have been discovered in the package. On FreeBSD e.g., if you install an orphaned package, the package manager will tell you. On some systems you need to figure this out for yourself.

Even though being a package manager is voluntary, it is a great responsibility as many thousands or even millions of users might depend on timely updates to the packages they use. This also means that there is a flip side to the issue. Just like an upstream developer can become a threat to the security of an application, by secretly inserting malicious code into the application, likewise can a maintainer, if he knows how, tamper with the build script and e.g. patch the software with a malicious insertion of bad code. This is one of the reasons that you need to be really careful with AUR packages on Arch Linux and Artix Linux, since AUR packages are user-produced content. The build scripts are unofficial and have not been thoroughly vetted and use of any of the AUR provided files involves risk, which is why the user must ALWAYS check out the build script and anything else related to the AUR package. The same goes for e.g. the PPA packages for Ubuntu.

This also means that being a package maintainer involves a certain amount of trust. On most projects you cannot simply become a package maintainer over night. You first have to apply, then often your work will be supervised and reviewed over a certain amount of time, but eventually you might become a trusted maintainer of a package. Every project has its own set of rules.

In any case, all of this shows that you should be careful when you choose which project to use as your favorite OS. Of course all projects need to start somewhere, and no project is perfect, but some projects care more about these issues than others.

I recommend that you look at the track record of the packages you use regularly. Regular and timely updates are very important regarding security fixes.

Many Linux distributions are nothing more than toy projects or one-man shows. Others have very few people involved and lack the proper resources to become a serious distribution. When you choose your OS, it is hence a really good idea to look into these things before you make up your mind.