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.
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.
(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.
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:
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.
Here are some of the things we consider in shaping the tree:
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.
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.
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.)
Accordingly, we don't often try to make group decisions at all, nor need to. When we do, we operate by consensus.