- There is a massive failure to provide consistent packaging of open source software. RPM and DEB and several other formats exist even in the confines of a single operating system - Linux. Even Ubuntu, which uses the Debian format, seems to mostly re-create all the packages for its users. Most of this work is done by volunteers, who in the process probably use up more energy than a small city, and which makes a non-zero contribution to global warming. Why do we need a dozen different binary packagings of my file command, for example? They all do basically the same thing.
- Most of the packaging formats don't do a very good job of capturing everything needed to rebuild a package. The BSD distributions have learned to do a better job of this; they run on so many different CPUs (not just PC's) that they have to make it easier for users to build packages. The BSD packaging takes the form of a Makefile and patches, which they ship on CD and make available for download. So in "BSD land" it's pretty easy to build a package (if you can't find a pre-compiled one already, which you usually can). Of course they also support the functionality of installing and upgrading binary packages without building, for those who don't want to bother.
- In BSD-land there is a strong emphasis on repeatable, automated building. Files are downloaded, checked with MD5 for SHA1, and then extracted; the software is then configured, made (compiled), installed in a test area, packaged, and installed - all with no manual intervention. And of course its prerequisites are also downloaded automatically, so BSD users using the ports/packages system never have to go looking for a -dev version of something - you just type "make" and it all just works.
Another annoyance is the actual lack of a downloadable source distribution. And as much as I like Java, it seems that some Java projects are among the worst offenders here. For example, a well-known teaching tool until recently only provided downloads in Windows .exe and in a Java-based interactive-installation format. You simply could not get the source for this program without running a GUI-based installer, interacting with it as per the usual installation script time-waster, and telling it to extract the source code. How does that support the premise of being able to inspect the source code before running it? To their credit (and the reason I'm not naming them here), when I mentioned this and explained the problem it was causing, they had a .zip file up on their SourceForge site (and the SourceForge mirror network) in under an hour.
Another example is Sun's Project Glassfish, a "Java EE" server. You download a big distfile (which is versioned properly), but as soon as you try to build it, the Maven build tool first starts scribbling in its private directory in your home directory, and then - starts downloading newer versions of some files! Folks, you can not get to repeatable automated building if you don't leave the platform-specific ports maintainers the flexibility to get distributions, install them in a known location, and just use them. On a bad day I think that Maven is one of the biggest roadblocks to repeatable automated building. Maybe it isn't, but today it seems like it.