Building software packages yourself is generally a waste (why package selection matters)

January 28, 2014

I recently spent a day working on building a version of Amanda for our new OmniOS fileservers to be. The story of why it took a day is beyond the scope of this entry, because the point of this entry is that time was a deadweight loss to my employer. It was in a sense unproductive.

Building software packages is a solved problem. I can't bring anything new or novel or particularly valuable to it and as a result I add no value by doing it myself. Building software myself is pure overhead. I could have been spending my limited time doing something new and novel for my workplace, something that cannot be done by anyone else, but instead I was forced to do something that anyone else could do and probably any number of other people either had done already or are going to do in the future. I and my employer tolerate this loss of my time because the alternative is worse (ie, no Amanda and thus no backups for our new fileservers). But make no mistake, it's still a waste.

This is why sysadmins care about the available package selection for operating systems that we want to use. The more packages available, the less time and effort we must spend duplicating other people's time and effort as we do the low-value, low-productivity work of building our own copies of packages. In a real sense, maintaining packages locally is wasted work.

(The other thing about building packages is that it's fundamentally uninteresting. It is a boring drag to spend all day iterating configure settings, verifying that what you've assembled can be rebuilt on a clean system, and so on.)

PS: This would be different if it was trivial to build packages well, but it's not for various reasons I'm declaring beyond the scope of this entry.

Sidebar: why I'm not building OmniOS Amanda packages for people

Because it takes much more work to go from a compile that works locally in our specific situation to an OmniOS package that I'm relatively confident will work for anyone who installs it (especially since I don't know OmniOS packaging). Publishing things is also making a commitment to support them if problems come up. We might chose to not patch Amanda if an issue arises (in fact we're very likely to never change our build unless a serious security issue comes up) but this is not something that other people will really appreciate.

This is unfortunate in a game-theory way. Collectively the entire OmniOS world would be better off if someone spent the time to do this sort of thing for various packages; sysadmins would on aggregate spend less time overall. But for me individually, I'd be losing out to build a real package for Amanda instead of just doing 'configure' and 'make install'.

I don't have an answer to this.


Comments on this page:

From 46.144.78.131 at 2014-01-28 04:13:43:

if it was deadweight loss, then you should not have done it. You and your organization needed it, so it was not a deadweight loss.

You could also obviously buy support by omniTI and get them to build the packages for you. I am quite confident they would agree to that for the right fee, which could or could not be cheaper than the time you spent yesterday building the software

I really like the approach of Arch AUR, where everyone can share their package builds... often others will contribute patches to fix things or update them if you forgot about them.

Of course, I only package software that has no package build yet. (Ocassionally, I adapt a foreign package build to local needs.) It doesn't take much time because Arch packages are pretty simple to make, and it's already a benefit for myself since I have half a dozen machines running Arch and can trivially install the package on all of them then.

Written on 28 January 2014.
« Things that affect how much support you get from a Linux distribution
One cause of Linux's popularity among Unixes »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Jan 28 00:23:05 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.