posted by Thomas Leonard on Tue 16th Jan 2007 00:32 UTC
IconIn the Free and Open Source communities we are proud of our 'bazaar' model, where anyone can join in by setting up a project and publishing their programs. Users are free to pick and choose whatever software they want... provided they're happy to compile from source, resolve dependencies manually and give up automatic security and feature updates. In this essay, I introduce 'decentralised' installation systems, such as Autopackage and Zero Install, which aim to provide these missing features.

[Digg this story!]

I am the author of Zero Install, but I hope to focus on concepts rather than particular implementations here. I'll start by describing our goal of allowing programmers, users, administrators, reviewers and QA teams to collaborate directly, and explain a few of the limitations of traditional centralised systems.

We'll look at the technical issues involved in distributing software without a central authority; how to prevent conflicts, handle dependencies, provide updates, share software efficiently, compile from source, and provide good security. Finally, I'll look at the possibilities of converting between different formats and systems.

Use cases

Stepping back for a moment from implementation issues, let us consider the various people ('actors') involved and the things they should be able to do. Here is a simplified Use Case diagram:

Use Cases for a decentralised installation system

Here we have a user who selects and runs a program, which has been made available by a programmer. The user may provide feedback to help with future versions. Patched or improved versions may come from the original programmer, or from a third party represented here by a "QA team" providing timely bug-fixes on the programmer's behalf. Users must be able to receive these updates easily.

The user's choice of software will be guided by advice from their system administrator and/or from 3rd-party reviewers (e.g. magazines). In some situations a system administrator may need to lock down the system to prevent unauthorised programs from being run. The administrator may also pre-configure the software for their users, so their users don't need to do it themselves.

Since users run many different programs, and each program will use many libraries, a real system will involve many different programming teams, QA teams and reviewers.

Language translators and producers of binaries for particular architectures are not shown; they are included in "Programmer" or "QA team" (depending on whether their contributions are distributed separately or bundled in the main release). Providers of hosting and mirroring services are also not shown.

Note that in these high-level use cases I don't talk about 'installation' at all, because this isn't something anyone actually wants to do; it's just a step that may be required in order to do something else.

The challenge, then, is to provide a framework in which all of these different people, with their different roles and goals, can easily work together.

Traditional distributions

The picture above doesn't quite correspond to the model used by traditional Linux distributions, where users must pick a distribution and then only use software provided by that distribution. This model falls short of the ideals of Free software, because a user is only free to install programs approved by their distribution (of course, it may be possible for users to do this; here and in the rest of this essay I am concerned with things being easy and reliable).

As a software author in this system, I must convince one or more major distributions to accept my software before most users will be able to run it. Since distributions are unlikely to accept the maintenance burden of supporting software with a small user-base this makes it very difficult for new software to be adopted.

The situation is worse if the program has network effects. For example, few people will want to distribute documents in a format that is readable only by users of a particular distribution (because only that distribution has packaged the software required to read them). In this case, the programmer must convince all the major distributions to include their software. This problem also applies to programming languages: who will write programs in a new language, when many users can't get hold of the required compiler or interpreter?

For example: I want to write a program in D because I'm less likely to introduce security flaws that way, but I actually write it in C because many distributions don't have a D compiler.

The situation with traditional distributions is also highly inefficient, since it requires multiple QA teams (packagers) doing the same work over and over again. The diagram below shows some of the people involved in running Inkscape. I've only shown two distributions in this picture (plus a Linux From Scratch user, who gets the software directly), so you'll have to imagine the dozen or so other packagers doing the same for other distributions.

One packager for each distribution

Do we need this many people working on essentially the same task? Are they bringing any real value? Without the Fedora packager, Fedora users wouldn't be able to install Inkscape easily, of course, so in that sense they are being useful. But if the main Inkscape developers were able to provide a package that worked on all distributions, providing all the same upgrade and management features, then we wouldn't need all these packagers.

Perhaps some of them would join the main Inkscape development team and do the same work there, but benefiting everyone, not just users of one distribution. Perhaps they would add exciting new features to Inkscape. Who knows?

Table of contents
  1. "Introduction, Use Cases, Traditional Distributions"
  2. "Naming, Conflicts"
  3. "Avoiding Conflicts, Dependencies"
  4. "Publishing Software, Sharing Installed Software"
  5. "Security"
  6. "Compiling, Converting Between Formats"
  7. "Summary"
e p (8)    76 Comment(s)

Technology White Papers

See More