Author: Bruce Byfield
The answer reflects why many free and open source software (FOSS) projects fail, and the difficulties of introducing any major changes to the fundamental structure of Linux today.
As described in an article posted in 2005 on Linux.com, Autopackage offers several advantages over native package systems. Designed primarily for use with desktop applications rather than for basic operating system files and utilities, it can be used to install software only to non-root accounts.
This is not only convenient, but also protects the system as a whole against malware. Unlike native packaging systems, it works on any distribution, and includes a interface that is at once attractive, powerful, and simple. Its documentation is also clear and organized. On the surface, Autopackage seems to have everything going for it.
Nor is the situation entirely negative. Xara Xtreme‘s releases are available in Autopackage format, and a Dutch tax software program was released as an Autopackage in 2005. Moreover, one of the most active Autopackage contributors, Isak Savo, says the project team has worked hard to encourage Autopackage’s use.
Project members have made packages and sent them to projects in the hopes of finding maintainers, and pointed out the advantage of using Autopackage to make the latest software versions available quickly to users. Given a chance, they will happily argue Autopackage’s merits in articles and blogs, and in mailing list discussions.
Yet, despite these efforts, the list of available packages has not grown much in the last year, and many packages, such as the one for the GIMP, are no longer current. Admittedly, not all uses of Autopackage are noted on the project Web site, as a search will quickly show. But, all too clearly, adoption of Autopackage is not increasing, and may even be regressing.
The problems with a small project
One of the most obvious problems for Autopackage is the small number of volunteers working on the project. Three developers contribute most of the code, although a number of others maintain specific packages. Of the three, Savo has recently graduated from university and found that work leaves him little time for FOSS development.
Similarly, Mike Hearn, one of the founders of the project and its major driving force, has taken a job at Google in the last year and is no longer active in the project. “I still handle email and take part in discussions,” Hearn says, “But I don’t write code any more or do any evangelism.” Short-handed even in its heyday, Autopackage has only one member of the core team, Taj Morton, who is still active, and, so far, no one has volunteered to take on much of the work that has to be done.
To make matters worse, this shortage of volunteers occurs at a time when basic functionality is already coded, and much of what remains are bug-fixes. This kind of detail work often has trouble attracting volunteers in any project, partly because it is less interesting, and partly because it often requires greater expertise and attention to detail than the initial programming. Hearn has prepared a list of the main technical issues with Autopackage, but there are simply not enough people with both the expertise and the time to solve them.
As a result, Savo says, “we still are having problems with integration on some distributions.” Nor, Savo notes, is there time to make changes that would make Autopackage appeal to independent software vendors, such as the ability to display an end-users license agreement. While most of these problems are ones that most developers for Linux must face, they are difficult obstacles for a project like Autopackage that faces a shortage of volunteers.
The conservatism of the distros
Along with the problems of a small project trying to tackle large problems, Autopackage also faces difficulties because of its explicit challenge to such a basic part of the operating system as software installation.
For one thing, Savo notes, many projects have no reason to consider Autopackage. “For large projects, the incentive to distribute as Autopackage is rather small, since they have dozens of packagers ready to package the app for every major distro anyway.”
Moreover, as Robert Staudinger, the maintainer of the AbiWord autopackage, observes, “Distros are better maintained these days and a number of them are doing frequent releases.” Under this regime, the argument that Autopackage can provide more timely releases for desktop applications is becoming less attractive. Used to the native package systems, many distributions, Hearn suggests, “over-estimate the cost and under-estimate the benefits” of a universal installer such as Autopackage, preferring to cling to what they know.
Furthermore, Staudinger suggests that experienced users, who understand native package systems, have little incentive to switch to a new system. “On the other hand,” he says, “We’ve had many of the non biased newcomers just try alternative installers and continue using them if they work out well.”
Such reactions are only aggravated by the fact that advocacy for Autopackage often turns into a specific critique of native package systems. On his blog, as well as at the Free Standard Group’s Packaging Summit in December 2006, Hearn has critiqued native packaging systems as both out-dated and anti-democratic.”The whole idea of packaging/installation is bogus and leftover from the times when software was distributed on floppy disks,” Hearn claims. “The web ‘instant activation’ model is better but requires advances in client-side platforms first around streaming and security.”
The problems with software installation, he continues, are similar to other architectural issues with Linux, such as drivers. He describes these problems as “not technical but rather due to cultural/social issues.” After discussion with major distributions, he suggested in his presentation at the Packaging Summit that most distributions were too competitive to agree to the underlying changes that he believes are necessary.
In some aspects, Staudinger seems right about the conservatism that stands in the way of Autopackage’s acceptance. Jeff Licquia, a Debian developer and an employee of the Linux Foundation, criticizes Autopackage for not working in conjunction with native package systems.
In another blog entry entitled “Autopackage goes insane,” Licquia writes, “Apparently, nearly everything violates [Autopackage’s] of how the world should work: package managers, Python, C++, the standard C library, the ELF executable file format, and the dynamic linker, at least.”
Criticism is especially strong from Debian developers, including Joey Hess, who described Autopackage as “designed by monkeys” from a technical perspective. However, the negative response is not confined to a single distribution: the Gentoo Development Guide, for instance describes Autopackage as “totally unsuitable for Gentoo systems.”
Hearn’s statements may explain the resistance to Autopackage’s acceptance, but clearly they also help to fuel it. As Staudinger says, “One of the issues with Autopackage is the controversy that surrounds it.” From Staudinger’s perspective, the largest problem that Autopackage faces may be simply that “many people are just annoyed by the fact that Mike Hearn openly addressed some Linux core issues.”
Looking ahead
Autopackage is not officially dead, and development on the project is continuing, albeit slowly. All the same, between the logistical problems and the controversy generated by its advocacy, its moment seems to have passed as its lead programmer became increasingly disillusioned.
Recently, Hearn has shown less interest in continuing his direct criticism of Linux architecture, choosing to approach the issues more indirectly by focusing on the need for standardization instead. However, he remains pessimistic about any fundamental changes.
Talking about the issues that surround Autopackage, Hearn says, “I eventually concluded that Linux was never going to make the big improvements to desktop computing that I wanted to see, and, therefore, that it’d never get non-trivial market share. That’s one reason why these days I work on servers for Google instead of client-side stuff for a Linux company.”
If Hearn is correct, the real lesson of Autopackage is not how to improve software installation, but the difficulty — perhaps the impossibility — of large-scale changes in Linux architecture this late in its history. It’s a sobering, disappointing conclusion to a project that once seemed so promising.
Bruce Byfield is a computer journalist who writes regularly for NewsForge, Linux.com, and IT Manager’s Journal.
