[[!tag programming debian rant]]

The construction, deployment, and use of software involves a number of roles. I do not have an exhaustive list, but I have a couple in my list that seem to be surprising to some developers.

In the traditional Unix (mainframe) model, there are three roles:

• developers actually create the software; they include architects, coders, documenters, testers, maintenance programmers, etc; their deliverable is a release tarball
• sysadmins install the software on a host, and install new versions when appropriate; often, the sysadmin is expected to carefully read README files, and construct or tweak configuration files accoriding to the specific needs of their users; their deliverable is some files in /usr/local and /etc, plus perhaps an announcement e-mail to an internal mailing list
• users use the software; they have no deliverable in this context

In my personal reality distortion bubble, this model is badly broken, and has been since the middle of the 1990s. Here's an updated model:

• users control their own machines, and are not experts on the software, or on using computers at all, and requiring them to be would be to limit their freedom in important ways; the big change is that users now have much more control of their computing environment than before
• sysadmins mainly work for companies or other organizations; they need not be experts on what their users do, and in fact often aren't, but they know how to handle systems that are by nature too complicated or hard for the layman to handle, because of performance, reliability, security, or other such needs
• distro developers create a system consisting of thousands or tens of thousands of components (mostly provided by upstream developers), and integrate and adjust things so that they work together; they also monitor upstream projects and other news sources for updates, and provide those
• upstream developers actually create the software; they include architects, coders, documenters, testers, maintenance programmers, etc;
  their deliverable is a release tarball (no change from earlier)

A common misconception is that distro developers merely compile software and shove the binaries into glorified tarballs. That is, of course, part of the job, but it's also the part that most distro's tools completely automate. There's a lot more to do, though. For example, just keeping track of known security problems among thirty thousand packages, and making or finding fixes for them, and testing the fixes, and releasing updates for them, takes up quite a bit of effort.

Another thing distro developers have to spend effort on is dealing with the multitude of build systems upstream projects use. The freedom to experiment with different solutions is one of the cornerstones of free software development. However, when it comes to build systems, many of them are not serious experiments, and instead are quick hacks thrown together to imperfectly solve problems that sometimes should not exist at all.

This highlights one role prominently still missing: build engineer. Their task is to solve the problem of taking the upstream source code, dealing with build-time configuration issues, actually building the software, and then installing it in whatever location the person installing the software wants it installed. Further, their task is to provide the software to do this in a sensible manner.

Build engineers already exist, of course. For example, the developers of the autotools suite are such. Every upstream project also has someone who sets up autotools for their project, or some other build tools, or writes them from scratch for that project.

However, what's lacking, perhaps, is recognition that build engineering is an important part of software development. Mostly, build systems are set up (or, worse, written) by upstream developers to fit their narrow view of how things should work, a view anchored in the old, broken model of roles.

This attitude matters, because for the most part, build systems do not seem to be written to the same quality standards as the rest of the upstream software. For example, when an upstream developer writes a Makefile, and does not consider distro development, they'll often make it hard to differentiate between install-time location and run-time location of various components of the software. Thus, it might be hard for the Debian packager to get the software installed into debian/tmp rather than /usr/local, because the build system hardcodes debian/tmp/usr/lib/foo/plugins as the location of the plugins, since that's where the software gets installed, even if, in the Debian scenario, it's not where it gets run from.

Luckily for much software these problems have been solved or avoided. Indeed, as crufty as autotools is, it's one of the things that has kept upstreams sane about their build systems, by providing such good tools that it's more work to write a new, bad one than to use autotools.

We currently have roving bands of translators, who move from project to project and translate them into various natural languages. I would like to see a future where there are people dedicated to build engineering, who go from project to project and set up or fix their build problems. A good build system, once set up, should require a minimum of work to keep working.

I'd also like to see much improvement in the build software. As good as autotools has been to free software, I'm sure there's a lot of room for improvement. For example, autotools requires setting up a bunch of boilerplate files in each project, which seems like something that could be avoided by relying on specific conventions. However, those improvements are a separate topic. I might go into them some day, if I decide to start developing build tools myself, but until then, I'll let those who do that decide how they want to do it.

PS. There are lots more missing roles in my model of free software development, of course. For example, security engineers (find and fix problems, but also provide ways to prevent problems, or limit their scope), internal politicians (keep the project's human wheels from squeaking too much), diplomats (keep different projects from clashing too much), release engineers, etc. Someone should make an exhaustive list.