Management models of open source projects (Part 1)
From the translator: this translation continues the cycle of publications on managing Open Source projects, which was started here .
The management model describes the roles that project participants may take as well as the decision-making process within the project. In addition, it describes the basics of the rules for participation in a project and the process of communication and information sharing between project team members and the community. In other words, it is the management model that protects the project from falling into chaos. This document explains why a management model is needed, gives some recommendations for solving problems arising when a project adopts a management model, and describes key areas that should be in the model. Also here you will find a description of the process of incorporating your management model into control documentation.
There are about as many different open source management strategies as there are open source projects themselves. However, reporting to potential users and developers of their policies and strategies is a critical moment for the project. A clear management model also allows potential volunteers to understand how they should interact with the project, what is expected of them and what is the guarantee that their contribution will always be available to them. In addition to this, the model describes a quality control process that will help users to assure the viability of the project. Development and implementation with a clear and concise management model is one of the most important steps that a project can take towards sustainable development through open source development.
')
Management patterns vary from centralized control by one person or organization (generous dictatorship) to distributed control imposed in accordance with the contribution (meritocracy).
At any point in this spectrum, you can detect a control model; It is also possible that the selected control model will move along this spectrum as it (the project) matures. The following are some examples of typical models and types of projects in which these models can be found. The table is taken from the work presented in the article "Open Source Software: Is It Worth Converting?" The terms "Cathedral" and "Bazaar" are explained in the article "Cathedral and Bazaar" on Wikipedia.
Table 1 Typical Management Models
Let's look at some examples of management models. First, the Ubuntu management model . This model focuses on the description of the community structure and areas of responsibility associated with each element of this structure. It also briefly describes the decision-making processes within the project. The Ubuntu project has chosen to separate the developer information from the structural information contained in the control document, but the technical management process is also clearly documented.
The Apache Software Foundation has two sets of control documents for each project. The first concerns the management of the foundation, which establishes the hierarchy of the organization as a whole. The Foundation also provides a set of documents on key processes within its projects, for example, on decision-making. However, since each project is free, to a certain extent, to determine its own verification of these processes, many projects have their own control documents. As an example, review the Apache Forrest project management description.
Our third and final example of a management model in practice will be the Taverna project model (note: PDF document) . This is an example of an open source project that has grown up within the scientific community and, therefore, demonstrates a model that can, as it turned out, work in the scientific community. The Taverna project model, like the Ubuntu and ASF models, focuses on the project hierarchy and management processes.
Despite the importance of defining a management model at the very beginning, many projects fail to do this. And for this there are several reasons. Among the typical there are:
Although each of the first three concerns is potentially true, these fears are easily dispelled by choosing the appropriate management model. However, the last concern that puts the age of the project into account is never true. This is due to the fact that every potential volunteer in the project should know how to contribute effectively and usefully and how to manage his contribution. Without clear guidance on these issues, most people will pass by instead of joining an immature project. But if these early users are shown that they can help lead a project to its maturity - they may decide to stay. One outside volunteer can have a big impact on the success of a project, so project initiators may not take into account the risk of losing this volunteer as a result of trying to save a little bit of energy at an early stage.
It is useful to dispel each of the above concerns. And the sooner this happens - the better for the life of the project, because otherwise they can become obstacles to the adoption of a clear management model. Let's look at them in a little more detail.
Some people suspect that the management model is just a red tape. But the description of the management model is not necessarily just an unnecessary bureaucratic exercise: it all depends on how well the model is drawn. The main goal is to make the model simple but effective. It should not have a rule for every situation; on the contrary, you should not even try to do it. Instead, the model should provide a simple way of clearly and clearly following the project management process. This clarity will allow third parties to boldly connect to the project. They will be able to see how the project works and predict how it will react to their contribution before they spend significant efforts on their activities.
It is important to note that the management model should make the process of creating and verifying contributions to third-party projects easier, and not more complicated. It should eliminate inaccuracies that can lead to loss of time for all interested persons.
Fearing that a management model will lead a project to a loss of adaptability to a changing environment can be attributed to the fact that there are many poorly managed Open Source projects in the world that are certainly limited in their flexibility. However, the real problem is caused by the lack of a transparent management model to a greater extent than its presence. A good management model will actually increase the flexibility of the project, since it determines how new participants can support the project in a completely unexpected way, without affecting the main objectives. It provides a mechanism that allows the community as a whole to determine the direction in which the project should develop, while ensuring that the core project team maintains control. The issue of control is discussed in the next section, and here we focus on vision and direction.
Since a project can not be everything and for everyone, the goal of a rational project should be presented as a complete solution, seen by the main ideologues, not ceasing to be of interest to other potential ideologues. The project should also be prepared to accept input from unexpected sources, and should be prepared, if possible, to respond to the needs of volunteers in their vision of the future and direction of development. This model of behavior significantly increases the space of resources that the project can use in its quest for sustainable development. However, attempts to become comprehensive almost all lead to the collapse of the project, since efforts are distributed in too thin a layer across the whole range of problems.
The main solution is to implement a management model that would provide mechanisms for clearly announcing and delineating the acceptability within the project. The model should be designed to allow project leaders to avoid unnecessary and useless sabotage by potentially dangerous community members. Also, the model should give confidence that projects with a prescribed strategy can take work in themselves through constructive interaction. This type of interaction expands the scope of the project without increasing the requirements for the original project team.
Perhaps the strongest fear of all is the fear that the management model will open up to third parties the way to seize project management. In the end, the management model blesses the participation of third parties in the project by throwing out the authority over these people. However, as in all other cases mentioned here, a well-designed management model gives confidence that control will remain where the project leader wants. This may mean that all decisions are controlled by the central organization (for example, MySQL or SuragCRM), or that all decisions are made by the community entirely (for example, Apache HTTPD Server or DoJo).
When deciding on the required level of control over the project, consider how stable the efforts made by your team will be. If, for example, a project produces a highly profitable product for which commercial exploitation is planned, it is quite profitable to maintain management and encourage interaction. It is quite true that the choice of a centralized model gives a guarantee that the development of the product will be directed according to the chosen usage model. However, it limits the width and depth at which voluntary project participants may discover their interest, since their strategic objectives may differ from yours.
On the other hand, if a project produces a component that itself has a low commercial value, the main task is to make sure that the component is used as widely as possible. In these circumstances, the goal may be to expand possible participants by allowing interested and active partners to participate in strategic planning.
One of the strengths of the open source licensed model is that everyone can take the source code and start independent development. This is called a fork. This means that the control exercised by the project leaders is as strong as the support of these leaders by the project community.
Despite the content of the control document, for those who fundamentally disagree with the control there is an opportunity to start a new project. Preventing such incidents is not part of the management model. On the contrary, the model should clearly define the influence of a potential project participant, which may extend beyond the scope of the project’s development. Only through careful management of the community, leaders of Open Source projects remain in power. Clearly defining the rules of community behavior in this case is an essential part of the management process.
Finally, we return to the problem that the project is too young to attract users from outside and volunteers, and therefore does not need to manage them within itself. Very often there are projects that feel that they do not need a management model yet, but this, in our opinion, can never be the cause.
It is never too early to choose a suitable management model. Without it, the chances that third parties will want to take part in the project are significantly reduced. And for this there are several reasons:
Since you never know at what points a participant can join a project, it is important to be prepared for this from the very first steps. Every missed opportunity to attract a volunteer causes damage to the sustainable development of the project. Remember also that the first contact of the project with the participant is the most important. For example, the correction of an error proposed by a third party can lead to an improvement in the use experience, which in turn affects the influx of users. This, in turn, makes the project more attractive to users and volunteers.
Another common misconception is that the project does not have enough users or volunteers to protect them. Again, we insist that even one volunteer who improves the quality and usability of the product is already a volunteer. The effort expended on creating an adequate management model is usually less than the effort put on all the smallest contributions to the project.
The last misconception that is often encountered is that the project is too small to cope with the influence of users from the side and the participants. This illustrates the lack of understanding of how open source software works: first, even the largest projects never attract anyone other than active developers. Secondly, a well-managed community will be largely self-contained. In particular, this is true for decentralized communities.
Note Lane: the article is large, so it is divided into two parts. To be continued...
The management model describes the roles that project participants may take as well as the decision-making process within the project. In addition, it describes the basics of the rules for participation in a project and the process of communication and information sharing between project team members and the community. In other words, it is the management model that protects the project from falling into chaos. This document explains why a management model is needed, gives some recommendations for solving problems arising when a project adopts a management model, and describes key areas that should be in the model. Also here you will find a description of the process of incorporating your management model into control documentation.
Why does the project have a management model at all?
There are about as many different open source management strategies as there are open source projects themselves. However, reporting to potential users and developers of their policies and strategies is a critical moment for the project. A clear management model also allows potential volunteers to understand how they should interact with the project, what is expected of them and what is the guarantee that their contribution will always be available to them. In addition to this, the model describes a quality control process that will help users to assure the viability of the project. Development and implementation with a clear and concise management model is one of the most important steps that a project can take towards sustainable development through open source development.
')
Management patterns vary from centralized control by one person or organization (generous dictatorship) to distributed control imposed in accordance with the contribution (meritocracy).
At any point in this spectrum, you can detect a control model; It is also possible that the selected control model will move along this spectrum as it (the project) matures. The following are some examples of typical models and types of projects in which these models can be found. The table is taken from the work presented in the article "Open Source Software: Is It Worth Converting?" The terms "Cathedral" and "Bazaar" are explained in the article "Cathedral and Bazaar" on Wikipedia.
Table 1 Typical Management Models
| Type of project | purpose | Control style | Community structure | Examples |
|---|---|---|---|---|
| Research oriented | Share innovation and knowledge | Cathedral method, central administration | Project leader, many readers | Perl, Linux kernel |
| Usage oriented | Satisfying individual needs | Market method, decentralized control | Many peripheral developers, mutual support between passive users | GNU / Linux (excluding kernel) |
| Service oriented | Provide stable service | Deliberative centralized management | Leading participants instead of the project leader, many users developing systems for end users | Apache, PostgreSQL |
Management models in action
Let's look at some examples of management models. First, the Ubuntu management model . This model focuses on the description of the community structure and areas of responsibility associated with each element of this structure. It also briefly describes the decision-making processes within the project. The Ubuntu project has chosen to separate the developer information from the structural information contained in the control document, but the technical management process is also clearly documented.
The Apache Software Foundation has two sets of control documents for each project. The first concerns the management of the foundation, which establishes the hierarchy of the organization as a whole. The Foundation also provides a set of documents on key processes within its projects, for example, on decision-making. However, since each project is free, to a certain extent, to determine its own verification of these processes, many projects have their own control documents. As an example, review the Apache Forrest project management description.
Our third and final example of a management model in practice will be the Taverna project model (note: PDF document) . This is an example of an open source project that has grown up within the scientific community and, therefore, demonstrates a model that can, as it turned out, work in the scientific community. The Taverna project model, like the Ubuntu and ASF models, focuses on the project hierarchy and management processes.
Barriers to applying the management model
Despite the importance of defining a management model at the very beginning, many projects fail to do this. And for this there are several reasons. Among the typical there are:
- Fear of turning the process into red tape
- Concerns that the project will lose its “sense of direction”
- The feeling of losing control over the project strategy in the future
- The project is considered too young or too small to attract active users or developers.
Although each of the first three concerns is potentially true, these fears are easily dispelled by choosing the appropriate management model. However, the last concern that puts the age of the project into account is never true. This is due to the fact that every potential volunteer in the project should know how to contribute effectively and usefully and how to manage his contribution. Without clear guidance on these issues, most people will pass by instead of joining an immature project. But if these early users are shown that they can help lead a project to its maturity - they may decide to stay. One outside volunteer can have a big impact on the success of a project, so project initiators may not take into account the risk of losing this volunteer as a result of trying to save a little bit of energy at an early stage.
It is useful to dispel each of the above concerns. And the sooner this happens - the better for the life of the project, because otherwise they can become obstacles to the adoption of a clear management model. Let's look at them in a little more detail.
Red tape
Some people suspect that the management model is just a red tape. But the description of the management model is not necessarily just an unnecessary bureaucratic exercise: it all depends on how well the model is drawn. The main goal is to make the model simple but effective. It should not have a rule for every situation; on the contrary, you should not even try to do it. Instead, the model should provide a simple way of clearly and clearly following the project management process. This clarity will allow third parties to boldly connect to the project. They will be able to see how the project works and predict how it will react to their contribution before they spend significant efforts on their activities.
It is important to note that the management model should make the process of creating and verifying contributions to third-party projects easier, and not more complicated. It should eliminate inaccuracies that can lead to loss of time for all interested persons.
Loss of direction
Fearing that a management model will lead a project to a loss of adaptability to a changing environment can be attributed to the fact that there are many poorly managed Open Source projects in the world that are certainly limited in their flexibility. However, the real problem is caused by the lack of a transparent management model to a greater extent than its presence. A good management model will actually increase the flexibility of the project, since it determines how new participants can support the project in a completely unexpected way, without affecting the main objectives. It provides a mechanism that allows the community as a whole to determine the direction in which the project should develop, while ensuring that the core project team maintains control. The issue of control is discussed in the next section, and here we focus on vision and direction.
Since a project can not be everything and for everyone, the goal of a rational project should be presented as a complete solution, seen by the main ideologues, not ceasing to be of interest to other potential ideologues. The project should also be prepared to accept input from unexpected sources, and should be prepared, if possible, to respond to the needs of volunteers in their vision of the future and direction of development. This model of behavior significantly increases the space of resources that the project can use in its quest for sustainable development. However, attempts to become comprehensive almost all lead to the collapse of the project, since efforts are distributed in too thin a layer across the whole range of problems.
The main solution is to implement a management model that would provide mechanisms for clearly announcing and delineating the acceptability within the project. The model should be designed to allow project leaders to avoid unnecessary and useless sabotage by potentially dangerous community members. Also, the model should give confidence that projects with a prescribed strategy can take work in themselves through constructive interaction. This type of interaction expands the scope of the project without increasing the requirements for the original project team.
Loss of control
Perhaps the strongest fear of all is the fear that the management model will open up to third parties the way to seize project management. In the end, the management model blesses the participation of third parties in the project by throwing out the authority over these people. However, as in all other cases mentioned here, a well-designed management model gives confidence that control will remain where the project leader wants. This may mean that all decisions are controlled by the central organization (for example, MySQL or SuragCRM), or that all decisions are made by the community entirely (for example, Apache HTTPD Server or DoJo).
When deciding on the required level of control over the project, consider how stable the efforts made by your team will be. If, for example, a project produces a highly profitable product for which commercial exploitation is planned, it is quite profitable to maintain management and encourage interaction. It is quite true that the choice of a centralized model gives a guarantee that the development of the product will be directed according to the chosen usage model. However, it limits the width and depth at which voluntary project participants may discover their interest, since their strategic objectives may differ from yours.
On the other hand, if a project produces a component that itself has a low commercial value, the main task is to make sure that the component is used as widely as possible. In these circumstances, the goal may be to expand possible participants by allowing interested and active partners to participate in strategic planning.
When a community is divided (fork)
One of the strengths of the open source licensed model is that everyone can take the source code and start independent development. This is called a fork. This means that the control exercised by the project leaders is as strong as the support of these leaders by the project community.
Despite the content of the control document, for those who fundamentally disagree with the control there is an opportunity to start a new project. Preventing such incidents is not part of the management model. On the contrary, the model should clearly define the influence of a potential project participant, which may extend beyond the scope of the project’s development. Only through careful management of the community, leaders of Open Source projects remain in power. Clearly defining the rules of community behavior in this case is an essential part of the management process.
The project is still young or small
Finally, we return to the problem that the project is too young to attract users from outside and volunteers, and therefore does not need to manage them within itself. Very often there are projects that feel that they do not need a management model yet, but this, in our opinion, can never be the cause.
It is never too early to choose a suitable management model. Without it, the chances that third parties will want to take part in the project are significantly reduced. And for this there are several reasons:
- potential participants don't know how to get involved
- they are not sure they understand what will happen with their contribution to the project
- the project does not look serious enough in terms of interaction with third parties
- There is no obvious guarantee that the contribution to the project will be properly managed, while retaining the mention of the participant who made it
Since you never know at what points a participant can join a project, it is important to be prepared for this from the very first steps. Every missed opportunity to attract a volunteer causes damage to the sustainable development of the project. Remember also that the first contact of the project with the participant is the most important. For example, the correction of an error proposed by a third party can lead to an improvement in the use experience, which in turn affects the influx of users. This, in turn, makes the project more attractive to users and volunteers.
Another common misconception is that the project does not have enough users or volunteers to protect them. Again, we insist that even one volunteer who improves the quality and usability of the product is already a volunteer. The effort expended on creating an adequate management model is usually less than the effort put on all the smallest contributions to the project.
The last misconception that is often encountered is that the project is too small to cope with the influence of users from the side and the participants. This illustrates the lack of understanding of how open source software works: first, even the largest projects never attract anyone other than active developers. Secondly, a well-managed community will be largely self-contained. In particular, this is true for decentralized communities.
Note Lane: the article is large, so it is divided into two parts. To be continued...
Source: https://habr.com/ru/post/116386/
All Articles