next up previous contents
Next: 4.4 Software Production Up: 4. Basic Concepts of Previous: 4.2 Improvement of Open   Contents



4.3 A Simple Framework for Open Source Software

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 [*] .


4.3.1 Objects

Objects represent passive elements of the model.

4.3.1.1 Source Code8

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.

4.3.1.2 Package

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:

Source Code Packages
The main content is source code. Although it is required to translate them into binary code before usage, there are several reasons why some people prefer them. As they are compiled in and for a certain computer system it is possible to optimize the result for the local machine. Besides, anyone considering to modify parts of the component for some reason depends on the source code. The major disadvantage of this type is the extra work, time and know-how required for compiling.
Binary Packages
The main content is executable code (binary code). Most regular users prefer this type as it provides the desired functionality with the smallest efforts in most cases provided that everything was prepared correctly. However, sometimes problems are encountered because of bad compilation or incompatibilities with your system. In these cases they cannot be resolved independently without the source code and the difficulties are sometimes tiny, but fatal (e.g. wrong search path).
Beneath the actual software component packages normally contain a lot of meta data. The stored information depends on the used packaging system. They are important in order to support the integration of the component. In the following, I have chosen a list of entries I consider important. Although it might not be complete, it should give a good understanding of the subject.

  1. Information about the containing software component

    1. Dependencies11
    2. Short description of the functionality
    3. Release data: version, date, work status (stable/experimental, alpha/beta/final), etc.
    4. Information about the producing person or organization
    5. License
  2. Information about the package itself

    1. Extra package dependencies (e.g. required for integration procedure)
    2. Release data: version, date, etc.
    3. Information about the packager
  3. Procedures for integration, update and removal

4.3.1.3 Documentation

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.

4.3.1.4 Distribution

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:

  1. Software developers want to have accurate access to most parts of their system and eventually like to modify some parts of it.
  2. A secretary would like to have a comfortable distribution for efficient work without knowing or accessing anything of the technical details.
  3. Computer systems used for the control or observation of critical processes want to have the highest possible reliability.
  4. Game players require good multimedia capabilities (e.g. excellent 3D graphics) and support for special devices (e.g. force-feedback joystick).
It might be possible to produce a generic distribution for most of these users, but it would result in low satisfaction for each single task. Today, computer systems are too complex for comfortable handling anyway, more generic systems make this situation even worse. However, it might be possible in the future.

4.3.1.5 Packaging System

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:

Installation
The transfer of the software to a storage media of the computer system, its integration and configuration.
Update
When a new version of the component becomes available it is normally not necessary to follow all steps of the installation again and sometimes harmful when user data is replaced with default data by the corresponding procedures.
Removal
Cleaning up all references, software, data, etc. that was established by the software component. It is also an important task of these tools to prevent the removal of essential components without replacement as it would result in an unusable system.
Observation of Integrity
As the installation, update and removal of packages require some superuser privileges these procedures are dangerous. Therefore the integrity and the origin of a package should be observable and checked before usage in order to prevent severe damage.

4.3.1.6 Issue

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:

Bug
Someone discovered a strange behavior of a software component.
Improvement
A user or developer has a good idea to improve a component in some respect at processing a certain task.
New Feature
A suggestion to integrate some new functionality.
Question
A person requires some information about a certain matter.
Comment
Someone wants to share certain information with another involved person. (e.g. an important project started)

4.3.2 Roles

Roles represent human actors in the model. They are defined by a specific abstract task.

4.3.2.1 Developer

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:

  1. Produce source code for a software component
  2. Document the development process
  3. Document the usage of software components of other projects
  4. Release source code and documentation to packager
  5. Resolve issues passed by consultant
  6. Communicate with consultant about issues (arising (used packages) and resolved)

4.3.2.2 Packager

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:

  1. Select a packaging system
  2. Collect source code and/or documentation
  3. Collect and produce required meta data
  4. Write procedures for installation, update and removal
  5. Build package(s)
  6. Resolve issues passed by consultant
  7. Communicate with consultant about issues (arising and resolved)

4.3.2.3 Distributor

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:

  1. Determine primary goals for the distribution
  2. Select a packaging system
  3. Search for suitable packages
  4. Compare found packages and choose the best solutions
  5. Collect required packages (dependencies)
  6. Observe and control included packages
  7. Provide tools to administrate and configure the distribution
  8. Simplify customization of packages for the usage in this specific distribution
  9. Resolve issues passed by consultant
  10. Communicate with consultant about issues (arising and resolved)

4.3.2.4 User

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:

  1. Select distribution
  2. Install basic computer system
  3. Select tasks he wants to process
  4. Select packages suitable for these tasks
  5. Install selected software packages
  6. Use selected software packages
  7. Communicate with consultant about arising issues

4.3.2.5 Consultant

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:

  1. Communicate with user, packager and distributor about issues
  2. Resolve received simple issues independently
  3. Summerize, filter and complete other issues
  4. Identify affected parties (developer, packager, distributor) for these issues

4.3.2.6 Integrated Service Provider

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:

  1. Provide communication channels
  2. Collect informational objects
  3. Provide informational objects

4.3.3 Relations

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.

Figure: Information Exchange between the Different Roles
\resizebox*{0.9\textwidth}{!}{\includegraphics{oss-communication.eps}}



next up previous contents
Next: 4.4 Software Production Up: 4. Basic Concepts of Previous: 4.2 Improvement of Open   Contents

Footnotes

... Code8
source code (noun): ``a text listing of commands to be compiled or assembled into an executable computer program'' [Oxford98, source code]
... phases9
See section [*] about the different phases of component usage.
... scripts10
Scripts are simple command sequences. Normally, they are used for short tasks and require an interpreter in order to run as there is no binary code.
... Dependencies11
See section [*] for details about dependencies.
... HOWTOs12
HOWTOs is a common term for documents that explain 'HOW TO do something', e.g. 'How to configure your sound card XYZ'.
... objects13
'informational object' is a term I use for any object that could be transfered by electronic communication systems. This could be source code, software, text, speech, etc.

Copyright © 2000 by Steffen Evers -- -- Send feedback to: tron@cs.tu-berlin.de
Lyx document: RCS version 2.5, last modified Fri Jul 28 22:12:42 2000