Producing, testing and accepting software should be done in a well defined, reproducable environment^[13]. This holds true for all software of at least some importance, but especially for software used in the medical profession. But to be able to reproduce an environment we should be able to obtain all versions of all objects we ever used to create that environment, including the description of the relations and configuration between these objects. We need a huge vault and a method to retrieve and rebuild environments from that vault.

To facilitate version- and release management and enable controlled transferral to and from the various development workstations, developers typically employ a central source code repository (CVS). CVS acts as such a software vault: you can not, for example, delete files in it. You can merely put a new version in it that does not contain some files anymore. However, the old version (which still contains the "deleted" files) can still be retrieved.

That CVS repository can be seen as part of a much larger structure with similar aspects: the Software Library (SL). The SL consists of a set of interconnected servers, off-line storage and administrative facilities. Its purpose is to enable reconstruction of all (environments for all) versions and releases of software used or build by the various teams (development team, test team, acceptance team and system engineers and -administrators). The SL contains all versions of all packages, often both sourcecode and binaries, and contains information about the relations between the items stored there. Also it contains information about the actual configuration of systems and the period when and location where they were used. Note, that the SL also includes various versions of various operating systems and related configuration files and documentation.

An outline of the DSL