By investigating several OSPs, I was able to identify some structures that help to understand their organization and illustrate the model of a typical OSP.
This section originates from the question about what OSPs actually do. In order to answer this question I identified several major activities. They are continously running processes which interact with each other. Although the picture might not be complete looking only at the given activities it should at least illustrate the fundamental structure of the development work.
The available information of a project is distributed among its members. In order to work together and to achieve best results they need to exchange a lot of their information between each other. For this reason a project needs to provide an opportunity for its participants to share their knowledge with each other efficiently. This leads to the following questions:
Since there is no general answer to the other three questions, I have tried to find something that is close to the situation in current OSPs. I do not claim that the following answers are the only or the best ones, but they are suitable for this context.
Everyone who requires certain information notifies the other project members. This might be expressed by a call for comments, petitions, questions or just presenting material with the convention that any missing information should be transfered. Making any kind of working results available to others might be the most important and most fundamental request for getting information in OSPs as the publication of the material normally implies the invitation to review and comment it on condition that the reader is qualified for this job.
By being aware of the situation of the requesting participant other project members can help him if they have some knowledge which they consider helpful for the presented issue. Having identified some useful information they transfer it to the other person through some kind of communication (e.g. email).
Coming back to the questions above: Requested knowledge should be transfered (first question) from everyone who thinks to have something to contribute to the specified topic (second question) to the participant who announced the information request (third question).
The important aspect is the active request for information. This is also a difference to the documentation activity which is done without such a request. In that case, nobody is really asking for this information at the time they are produced, but they might be useful later on for some purposes which may be even unknown at the writing time.
Setting up goals or priorities for the future, choosing between contradicting ideas, changing the project's policies are all part of this activity. One person, a group or all members might be involved in such a process. It can be done formally following rules the members agreed on before or informally by a simple conversation. The result might be considered as final or temporary. All this is done by decision-making processes inside the project.
It is not much work to actually make the decision: a single word is normally enough. But in order to be able to find the best alternative a good preparation is indispensable and that can be a lot of work: The collection of all required information, working out all alternatives, inform everyone who should know that the decision is about to be made and so on. Although most of this is covered by the other activities someone has to start, stop and direct them. For instance, the collection of the required information is part of the communication activity, but as mentioned someone has to specify the information that is needed by a request for the communication to start. This is done by decision-making, maybe by working out a document describing the issue which is done by the work activity which again is controlled by a coordination activity to manage dependencies with other activities.
Human beings do many things without thinking about them because they are used to it for example. Considering the large number of situations where it is necessary to make decisions it would just paralyze us when we would have to do all this consciously. As this activity is focused mainly on decision-making it does not make sense to cover these situations. So, I consider only decisions as part of this activity that fulfill the following conditions:
The task of the coordination activity is to make the different elements of the project collaborate together as if it were one big organism.
All activities of an OSP need some kind of coordination as they all depend on their context including other activities. These relations of the project's activities have to be considered somehow in the performance of actions. However, a lot of these dependencies are hidden in the work activity as the coordination process can only handle relations that are visible in the used level of detail. Besides, many communication actions can be considered as part of the coordination process, too, because in order to manage relations I need to actually know them and communication is about sharing information.
Since OSPs consist of voluntary developers, they normally do not have a strong management authority that is capable of a centralized coordination process. Therefore most dependencies are regulated by social conventions and interactions.
The method of open source software production seems to produce only a few dependencies. Their special handling of resources, the high independency of open source developers and the acting on their own authority are probably major reasons for this phenomena.
The work activity is close to this one. I have chosen to split them because these are actually two different tasks although the boundary between them is fluid. The issue of documentation is to provide any interested party with a detailed description of the development process. The primary goal of the work activity is to get the job done. Therefore the documentation activity slows down the projects productivity at first glance, but becomes valuable in the long term.
Documentation of the development process should not be confused with a manual in this context. It is supposed to store information about how the results are achieved and why things were done this way. The collected data is not intended to help someone to use the final result, but to understand the construction work. The goal of this activity is to enable another expert to understand and improve the developments.
Although this is aimed at others than the original developer it might be even valuable for him as people tend to forget things and it is nice to have something that helps to bring back the memories.
Additionally, such information is useful for various other reasons, too. I just want to give some examples:
Someone else than the developer can write manuals based on the stored information.
It is helpful to have a detailed change history to track down bugs. Maybe you can even find out the point of time the bug was introduced to the system.
Any piece of software is situated in a software system21. Compatibility requires to avoid contradictions to other software that is installed on that system at the same time. Investigations on source code level might be sufficient in the short term but ineffective as it is simply a large and complex amount of material to look at. This is especially true considering the rapid and frequent changes of software.
Every little note that is describing the idea behind the source code is helpful in order to avoid problems and to reduce work to be done when this part of the system is changed as the idea often remains longer than the code representing it. And even documents like simple log messages often contain important information for this purpose although they are originally done for other reasons.
E.g. the change of a standard library to a newer version has broken Star Office 5.022 as it used so-called 'undocumented functions' which are intended for internal use only. They had to update their product in order to make it compatible with the newer version although they used the old library code correctly, but had not considered the idea behind the source code which was to only use documented functions outside the library.
All other activities I have investigated in this section take place on a meta level. ``Work'' is the actual production of the software. Therefore it is the most important activity and all other ones only serve the purpose to optimize this one, but the way the work activity is done depends on the processing of the other activities as well.
It is something like a small sub-project and requires all described activities again internally on a lower level: decision-making, coordination, communication, documentation and even work itself. All these sub-projects have a certain issue that they want to handle. This might be large things like the creation of a system kernel or small ones like the fixation of a certain bug. Although this matter might be specified precisely it is usually expressed vague, e.g. by a prototype, a short description or an example.
Some people like to collaborate without splitting the task to smaller sub-task which requires more communication and others want to work more separately and have clear boundaries between their responsibilities. The observer's focus is scalable and it is up to him if he wants to analyze the next lower level in detail as well.
There are many different perspectives and you choose the level of detail that is suitable for your purpose. Therefore even the project itself might be considered a regular work activity of a higher level undertaking.
The number of people participating in a work activity may vary from one to several hundreds.
The activities of OSPs normally are not planned much in advance and there is no central authority which has the power to assign certain responsibilities to someone. Therefore it is rather difficult to identify abstract roles in specific projects and even harder to find suitable roles for OSPs in general. For this reason, a concentration on specific tasks of the project work seemed to be the most promising strategy to divide the performed actions in different categories. Following this idea I have identified five major roles:
Fig. ![[*]](crossref.png)
shows the
four active roles and their major interactions. Developers and maintainers provide
the required software, managers manage it and commentors review all activities
and give feedback. The administrator is the invisible agent which supports all
these activities.
As OSPs act in the virtual space of the Internet the most important entity is information in any form. Therefore an investigation of the organization of projects' data helps to understand OSPs and how they work.
Three different categories of data objects can be distinguished:
Fig. shows a generic,
hierarchical structure which seemed to be suitable for describing most organization
types: A project consists of one major section. Each section again consists
of a meta domain (for meta objects), work domain (for work objects), sub-projects
(0 or more) and sub-sections (0 or more). A sub-section consists of one section.
A sub-projects consists of another project.
Since administrative objects are part of the underlying support system they are not represented in the figure.
There are a lot of relations to other organizations or individuals. Some use
the produced software (user), some provide components the project based their
work on (component provider) and others provide software tools or services the
administrator uses to provide the support system for project members (support
system provider). Fig.
illustrates these relations.
The materials given in this section so far are pieces of one big picture. They show OSPs seen from different perspectives: activities, roles, objects and relations.
In order to demonstrate how the described structure could be used to understand the organization of real project I have mapped some procedures on the given structure. However, they are only abstract examples and might work differently in reality. For instance, a person might have both roles in a communication process (e.g. find a bug in his own work) and therefore leaves some steps out since he would not communicate with himself per email.
| No | Action | Activity | Actor's role |
| 1 | declare yourself responsible for a certain issue | coordination | developer |
| 2 | work on issue | work | developer |
| 3 | present your results and all available information | communication | developer |
| 4 | review presented material | work | commentor |
| 5 | discuss material | communication | developer, commentor |
| No | Action | Activity | Actor's role |
| 1 | find a problem, specify it accurately | work | commentor |
| 2 | propose problem as a potential issue | decision-making | manager |
| 3 | discuss potential issue | communication | manager, commentor |
| 4 | accept or cancel issue | decision-making | manager |
| No | Action | Activity | Actor's role |
| 1 | propose preparation of a public release | decision-making | manager |
| 2 | discuss release issue | communication | manager, commentor |
| 3 | accept or suspend release issue | decision-making | manager |
| 4 | prepare release | work | developer |
| 5 | declare release ready | decision-making | manager |
| 6 | prepare public download | work | administrator |
| No | Action | Activity | Actor's role |
| 1 | realize issue of your responsibility and declare it | coordination | maintainer |
| 2 | pass issue to maintained project | communication | commentor, maintainer |
| 3 | initiate procedure for new issue | communication | commentor |
| No | Action | Activity | Actor's role |
| 1 | realize issue of your responsibility and declare it | coordination | manager |
| 2 | pass the issue to your section | communication | manager |
| 3 | discuss presented issue | communication | manager, commentor |
| 4 | confirm, dismiss or return issue | decision-making | manager |
| 5 | process issue | work | developer |
| 6 | present results to other project members | communication | manager |
| 7 | review presented material | work | commentor |
| 8 | discuss presented material | communication | manager, commentor |
.
contains
a detailed examination of OSP's coordination.
for a closer examination of software systems.
