This section illustrates the main model of open source software by presenting
its surrounding framework. It is closely associated with the identified structures
of OSPs in section
.
Objects represent passive elements of the model.
Source code objects contain a human readable form of a software component. Basic information should be included to explain how the software works, e.g. comments. Therefore a skilled developer should be able to understand each given step of the program and be able to modify it according to his needs providing he has a sufficient knowledge about the functionality of the program (e.g. accounting). However, the source code only often demands a lot of extra work in order to understand the concepts and ideas behind the code. For this reason additional information is usually stored in documentation objects.
Most source code contains instructions and procedures for building an executable. So, these objects could be considered as a source code package with little meta information and a very simple packaging system, but source code is a developer's object, packages are intended for users. Therefore it is sometimes a question of perspective if an item is a package or a source code object.
Packages are software components prepared for integration into a suitable computer system. The preparation could support any of the usage phases9: system preparation, installation, customization, daily usage, problem solving, update, replacement or removal.
Therefore packages include certain meta data additionally to their main contents. The notation and contents of the meta information depend on the used packaging system. Stored information could be dependencies, scripts10 and signatures.
Two different types can be distinguished:
In most cases there is a lot of additional information available for a package or source code. It could be a text document, figures, pictures, videos or anything else that is helpful for the corresponding subject. The contents might explain how something was done, how it works, or it should be used, etc. Good examples are online manuals or HOWTOs12.
It is hard work to collect and build a complete efficient software system out of several thousand packages provided via the Internet. Therefore users may prefer to pay someone else to do most of this job for them. Thus distributions are pre-selected collections of packages that fit together. They are administrated with the help of packaging systems. Normally, the included software components do not require any other ones that are not provided as well.
The various available distributions differ mainly in the containing packages, component's release versions and the used packaging system. Therefore each distribution is aimed at a different user group. Some examples:
This is a method to partially automate the administration of software components in a computer system. In order to handle available and installed packages the various packaging systems normally include tools to process the following tasks on packages:
People who are engaged with open source software often have some ideas they want to share with others. I call this an issue. Normally, issues make a reference to another object. The referred object might be any of the given object types including issues. Examples for the subject of an issue:
Roles represent human actors in the model. They are defined by a specific abstract task.
The developer role represents open source projects. Although the main interest might be executable software, other subjects like documentation or data collection could be the subject as well.
The following activities belong to this role:
A packager collects results of a developer and prepares their integration into a specific computer system by producing one or several packages of the collected material. Sometimes, a split of different parts of provided material is reasonable as projects may release several components combined together that could be used separately (e.g. application, used library and documentation). On the other hand, a combination of different components in one package could be done, too.
The following activities belong to this role:
Distributors collect the different available packages for their purposes and combine them together in a distribution. Normally, each distributor aims for particular goals, e.g. high security or ease of use. According to this goals they will choose the components and the released packages.
The following activities belong to this role:
A user obtains a distribution somehow and utilizes it. He may get it from a shop, by downloading or borrow it from a friend. The different opportunities depend on the specific distribution and its license. The main concern of a user is the processing of his tasks.
The following activities belong to this role:
It is quite normal that many problems and ideas arise when dealing with software components. As there are various parties involved from the creation until usage, the identification of the problem's origin is often the hardest part of the problem. Therefore a central point of access is essential for unskilled users because they are not able to locate the origin themselves and do not know which party they should contact. Although the distributor and the consultant could be the same organization, they do not have to be. Smaller companies might use another distribution, but offer the corresponding consultant service.
The following activities belong to this role:
Since the participating parties could be spread all over the world, most of the communication will be done via the Internet. Therefore an advanced communication and information infrastructure is required. The integrated service provider offers this service.
Although one big homogenous infrastructure is a nice thing, it would be hard to establish. Therefore interfaces between the different systems are necessary. If they do not exist, the transfer has to be done manually.
The following activities belong to this role:
As the subject of open source software is information in various forms, I have
chosen the information exchange to illustrate the relations in figure
. Although some aspects are not considered
in this point of view, it resembles a major part of the actual relations.
The simple provision of informational objects13 is represented by single-sided arrows. Putting something on your home page is a suitable example for the nature of this communication, but there are more efficient ways to publish this kind of information as you know who is potentially interested in the provided objects (where the arrow points at) and it would be better to put them at a central point, so interested persons do not have to search the whole Internet in order to find your information.
Lines with arrows on both sides do not stand for the simple supply of information in both directions, but a process of an interactive exchange of knowledge which normally results in an increase of knowledge on both sides, although the nature of this information is usually different. For instance one person gets an answer to his question and the other obtains the knowledge about the lack of information the first one had.
about the different
phases of component usage.
for
details about dependencies.