MetaLab Policy

This is the MetaLab archive's policy document, version 1.0. It's intended to help MetaLab co-maintainers get up to speed quickly. It's also intended to explain our mission and practices to people who aren't co-maintainers. These are are our house rules.


1. The MetaLab archive is dedicated to Linux.

The MetaLab archive exists to support the Linux community. Anything that makes Linux a more powerful and/or more pleasant system is of interest to us.

Conversely, we're not interested in hosting resources for non-Unix operating systems here, unless they are directly tied to configuring, supporting, or enhancing Linux in some way.

2. Our mission is to help Linux evolve faster and spread further.

This archive's core constituency is people who do not merely use Linux but actively seek to improve it. We'd like to have four billion users who never have to tinker with Linux someday, but in order for that to happen we have to build the largest and most effective possible hacker support community first. Thus we want to speed the evolution of Linux so it improves as quickly as possible.

(If the word `hacker' made you nervous, please go get a clue about what it means and then come back.)

The Linux experience seems to show that even very complex software is most rapidly debugged by throwing it in front of a lot of savvy users. Therefore, we encourage developers to upload their newest versions of software even if they're not yet perfectly stable. (If you want to upload two versions, one marked "production" and one "bleeding-edge", that's fine, and in fact a very good idea.)

To help Linux spread faster, we make the site as friendly as we can to to non-technical users without compromising our usefulness to developers.

3. The archive is primarily for redistributing freeware sources.

(By `freeware' we mean software that is freely redistributable; that is, either explicitly public-domain or copylefted on terms similar to the MIT or BSD licenses which permit unrestricted free redistribution. See the Debian Free Software Guidelines for more.)

Software evolves fastest when it's freeware and available in source so that anyone can hack with it. Therefore we honor the Linux tradition of encouraging freeware source sharing, and discouraging more restrictive kinds of licensing and packaging.

Accordingly, we will cheerfully accept `convenience build' binaries submitted with redistributable sources, but binaries without sources, or sources that are not freeware, are not as welcome. These may be rejected on submission, and in some cases may be dropped entirely when a true freeware alternative develops.

There are limited exceptions to this rule:

  1. Sources with a license restricting use or redistribution to `noncommercial' or `nonprofit' use may be carried if they are already either very well established and popular, or fill a function not served by any true freeware.
  2. Linux binaries of very well-known Unix freeware may be carried with a pointer back to the source site.
  3. Demo binaries of Linux ports of well-known commercial software may be carried if those binaries are freely redistributable.

But in general, we dislike restrictions on free redistribution, whether they're commercial or anti-commercial in nature. Besides preventing some users from getting having the richest choice of tools. non-freeware gives us practical problems, too. It complicates life for commercial Linux CD-ROM makers using Sunsite, a group we want to encourage.

4. The MetaLab archive is market-friendly.

Besides serving individual Linux users, the MetaLab archive is also meant to be be a resource for people who press inexpensive Linux CD-ROMs.

We think this is a good thing, because it spreads Linux much faster than pure network distribution possibly can. It also creates market incentives for people to support Linux as a full-time job, something we think is essential if we want to succeed at waking the world up from the Microsoft nightmare.

Making the MetaLab archive available to CD-ROM distributors for free lowers the barriers to entry in the Linux industry. It thereby promotes healthy competition, prevents any one vendor from locking up the commercial market, and frees up vendor capital to be spent on support and enhancements. We consider these worthy goals in themselves.

Some hackers think the commercial market is nasty and discourages cooperation; they look down on commercial Linux vendors. We disagree, and we think the Linux experience is proving our point. The free market is a wonderful device for cooperation, and we say there is no point in fighting it when it's so much easier (and so much more fun) to co-opt it.


The purpose of an archive isn't just to have a lot of information, it's to help people find the information they need. One of the maintainers' primary long-term jobs is to tune the archive tree so that it is easy to use, and matches the archive users' model of software functional categories.

Here are some of the things we consider in shaping the tree:

1. Group by function first, by interface type second

Grouping by interface type or implementation language is less useful than grouping by what things do for the user. So functional categories should be higher up in the tree than interface or implementation categories; this will help keep the user's search path simple as long as possible.

2. Small categories are generally more useful than large ones

We lean towards lots of little categories rather than a few big ones. This makes individual directory pages easier to digest. If the directory structure is well designed, it also cuts the total number of package descriptions a user has to sift to find the right thing.

3. Avoid mixing files and directories at the same level

In general, if a directory has subdirectories in it, it should be all or nearly all directories. Subdirectories are hard to spot in a thicket of package files.


1. How maintainers become maintainers.

The MetaLab archive is maintained on an entirely volunteer basis by a small group of senior Linux hackers. The group is not closed; we welcome new members who have shown Linux technical competence, commitment to free software, and the hacker spirit.

This is not a job for newbies; it demands an experienced feel for the way the Linux culture works. If you're qualified, you'll be able to figure out for yourself who to approach about joining the group, and how to approach them. We don't need to see a resume, but it would be helpful if you could point us at a successful Linux FAQ or freeware resource you have maintained.

2. What the work is like

Our day-to-day job is mostly processing packages out of MetaLab's incoming directory into the archive tree. For packages that are updates of stuff already in the archives, this is a semi-mechanical process. New packages, on the other hand, sometimes demand some thought to see where they fit in.

Most of the drudgery of the job is automated away by a Perl program called `keeper', an archivist's assistant written specifically to support a MetaLab-style FTP-and-WWW site. Keeper enables you to make high-level decisions about where things should go, knowing that all HTML and README files will be automatically updated correctly and change notices sent to all interested parties.

It's occasionally necessary to reconsider the shape of the archive tree itself. Keeper also provides high-level support for this. Because reshaping the tree's topic categories can break HTML pointers from elsewhere (especially Linux Documentation Project resources and FAQs) we don't do this casually.

If you are signing on as a co-maintainer, the first thing you should do after you get your MetaLab account in download the latest version of keeper from the `search' directory and read the manual page. Then browse keeper's on-line help.

3. How the work is divided

There is a core group (two people in March 1997) of archive maintainers that worry about the whole site and develop the tools and procedures to keep it running. They support a larger group of topic specialists.

We encourage new co-maintainers to start by picking a topic specialty. That is, to adopt an archive subtree and take care of it; keep the header comments in the indices up to date, create new subcategories when necessary, etc.

Keeper supports a watch-list feature; you can declare you want to see all change notices and email that keeper sends about a particular directory or set of directories. This will enable you to track, and if necessary correct, any actions taken by other co-maintainers on directories that are `yours'.

Any maintainer can process stuff out of the Incoming directory. The watch-list feature guarantees that if you are a topic specialist interested in the directory where the package lands, you'll be notified and be able to review and possibly correct the action.

(That anyone can process incoming stuff also has the consequence that package processing time and index quality degrade gracefully when topic specialists are absent or only occasionally paying attention.)

4. How we make decisions

We believe in finding competent people, encouraging them to take responsibility for a piece of the job that interests them, and letting authority follow responsibility. Everybody involved is too busy with their piece of the job and lots of other projects to waste time joggling each others' elbows.

Accordingly, we don't often try to make group decisions at all, nor need to. When we do, we operate by consensus.