How to build an open source community
The community is vital to any open source project. An active and vibrant community is the heart of the project. However, writing a code under a free license is not enough to attract users and developers to build a community. This article discusses what allows you to build a successful OpenSource community.
Open source programs are in fact no different from other software development projects in the way they start. They start either because someone wants to build something, or in the case of product development, someone hopes to anticipate the future needs of other people. In the first case, the opportunity to share the final result may not even be expected, in the latter case there is a keen desire to share the final product.
Communities are groups of individuals sharing common interests. Both closed and open projects have their own user communities, most of which are relatively passive, to talk about their interaction with the rest of the community. On the other hand, any type of community can include participants who decide to take a more active part, for example, sending bug reports, helping other users, writing documentation or advocating.
The most active participants should be rewarded for their efforts. Microsoft, for example, rewards those in the user community who help people build most of Microsoft technology through the MVP (Most Valued Professional) program. In open source communities, active participants expect rewards in the form of increased access to the project and increased control over it.
')
Although closed projects carry some benefits to the community, there is a clear restriction on the types of voluntary participation in the project for the community. Due to the fact that the code is not open to study, there is absolutely no way for users to actually develop a product, solve problems, develop new functions, and contribute program code to the main project. However, on the contrary, things are with such opportunities in the Open Source communities. There is possible the flow of information in the form of code and documentation from any member of the community to the center, albeit in moderated form. And more importantly, with any problem that has arisen, there are a large number of eyes that will pay attention to it and unite the brain efforts of the whole community. In projects with closed code, the maximum number of people watching this problem is always limited by the total number of hired developers.
At birth, open source communities can be extremely small, sometimes consisting of one or two developers and almost no users. Depending on the type of project, this may continue for some time, maybe even years, as an “incubation period” during which the original team is working on getting something working out of the box. Eric Raymond, in his book, “Cathedral and Bazaar,” notes that a necessary pre-condition for success is the presence of 'something working and testable that you can play with.' It is worth noting that 'working' does not mean gorgeous or even ready. “Releases early and often” is a well-known mantra of Open Source development, which makes sense, since such a project’s behavior can help get early feedback and increase project reliability. For this reason, communities should not be afraid to post material earlier. Thanks to early releases, you can gain significant benefits by providing expectations and managing the project clearly and correctly.
If a software product should attract users, presentation and branding should convince advanced users that the program does something much better than its competitor. Once interest has been fixed, it is worthwhile to omit the threshold for users to enter: for example, such simple things as the installation process should go completely smoothly. However, user experience is not the end of the story. In the long run, developers will also be required, at least managed with minor improvements that can drive a single developer into the swamp. Developers can grow out of an existing user base, but they can also come from anywhere, driven by the need to gain skills, fame, or look for an opportunity to show their programming skills.
Opening a project in this way can add a completely new set of problems. Karl Fogel (Karl Fogel) in “Production of Open Source Programs” notes: “Opening means bringing the code in an understandable form for arrivals from outside, setting up the developers site, mailing list, and most often the first writing of documentation. All this seems to be a large amount of work. And of course, if someone from interested developers appears, they will have to answer their questions for some time before any benefit arises from them. ”However, additional efforts are at least partially overlapped by the availability of ready-made collaboration tools like Google Code or Sourceforge. And in addition: opening a project does not necessarily mean losing control. Many projects in the early periods work as a “generous dictatorship” with one person responsible for developing most of the functions and analyzing the written code.
Generous dictators do not have to possess outstanding technical skills, but according to Vogel, they will have to “be able to distinguish between good design”. Vogel goes further and notes that the main responsibility of the dictator is to make sure that the participants believe that they "can do more than one at a time". Developers will remain only if the project leader can make the project a place where they want to return. This means rewarding the work, delegating to those who deserve it and those who want it, more responsible job sites. Project management Open Source has been described as active, informal and inconspicuous. Successful generous dictators must also "speak quietly." All this requires universal human skills, and, as Raymond suggests, "a little ability to fascinate people."
The responsibility of community leaders is to ensure that the conditions remain usable for the potential of Open Source. It does not come by itself and must be carefully managed.
In the early stages, the most significant problem of the project is to deal with a very heavy load of support. Poorly organized support can, at best, lead to the loss of users, and at worst cause the project founder to surrender. If you plan to at least some success of the project, the leader must find people who will be engaged in this work. One way is to hire them. Another is to invite users to help each other by writing documentation and correcting errors. However, if this happens, an infrastructure should appear that will allow users to do this. Any contribution should be actively welcomed and leaders should be sure that the contribution is useful and of sufficient quality.
As soon as the project is more or less stabilized, other dangers come into play. One of them is the always existing possibility that someone can take a code and start a competing project based on it. This phenomenon, known as fork, causes damage by sharing and separating the developer community. This event also confuses and undermines user confidence and leads to unnecessary doubling of effort. Since the user and developer communities are the blood of the Open Source project, any damage caused to them will in any case affect the sustainable development of both projects. A rush to create a fork may arise for any reason, technical or political, but it is worth paying attention to only when it comes from someone with a sufficient number of followers in the community. In any case, well-documented negative aspects of creating a fork lead to a strong desire of society to resist this, because it is known that the decision to divide the community should never be made easily.
To be considered healthy enough, Open Source communities must be able to outlast the original founder’s interest in them. If they rely heavily on the dictator, they risk breaking apart and disappearing when their leader changes his sphere of interests or retires.
In most communities, even in those that are governed by dictatorship, people, in addition to the supporter, are becoming more and more responsible for making decisions. The natural result of this is a transition to democracy based on consensus. This new state of affairs does not guarantee that all decisions, especially minor ones, will be made deliberately. Most of the time, proposals will be accepted on the principle of “lazy consensus” when silence is tantamount to agreement. In order to deal with proposals for which no agreement has been reached, all communities use some form of voting.
The more complex these customs and procedures become, the more important it becomes to inform new participants about how they can start participating in the project and use their voting rights in the decision-making process. Young communities may return to the practice of using mailing lists to accumulate information, but this does not always help newcomers and may leave them with a misunderstanding. What is really needed is something written down, a kind of “management model” fixing the existing understanding in a documentary form. The formalization of agreements helps to be sure that the community lives its own life, independent of anyone, that it can survive and flourish for a period while there is a need for the product produced by this community.
Building a community around an open source product can be slow, hard work and success depends on many criteria. However, without a community there is simply no project. Forming a community will not happen by itself and should be carefully managed. All communities begin with users attracted by the form and design or oral recommendations. As soon as they arrive, the task appears to meet their expectations. A thriving community of developers can meet and expand user expectations, but only if their leader can keep them together and be sure that the participants will not wander to create their own projects. In the long run, communities should have an open development mechanism to ensure that, if the key players, including the founders, leave, they can easily be replaced by someone else.
Why do open source projects start?
Open source programs are in fact no different from other software development projects in the way they start. They start either because someone wants to build something, or in the case of product development, someone hopes to anticipate the future needs of other people. In the first case, the opportunity to share the final result may not even be expected, in the latter case there is a keen desire to share the final product.
What is a community and why build it an Open Source project?
Communities are groups of individuals sharing common interests. Both closed and open projects have their own user communities, most of which are relatively passive, to talk about their interaction with the rest of the community. On the other hand, any type of community can include participants who decide to take a more active part, for example, sending bug reports, helping other users, writing documentation or advocating.
The most active participants should be rewarded for their efforts. Microsoft, for example, rewards those in the user community who help people build most of Microsoft technology through the MVP (Most Valued Professional) program. In open source communities, active participants expect rewards in the form of increased access to the project and increased control over it.
')
Although closed projects carry some benefits to the community, there is a clear restriction on the types of voluntary participation in the project for the community. Due to the fact that the code is not open to study, there is absolutely no way for users to actually develop a product, solve problems, develop new functions, and contribute program code to the main project. However, on the contrary, things are with such opportunities in the Open Source communities. There is possible the flow of information in the form of code and documentation from any member of the community to the center, albeit in moderated form. And more importantly, with any problem that has arisen, there are a large number of eyes that will pay attention to it and unite the brain efforts of the whole community. In projects with closed code, the maximum number of people watching this problem is always limited by the total number of hired developers.
Typical paths for open source communities
At birth, open source communities can be extremely small, sometimes consisting of one or two developers and almost no users. Depending on the type of project, this may continue for some time, maybe even years, as an “incubation period” during which the original team is working on getting something working out of the box. Eric Raymond, in his book, “Cathedral and Bazaar,” notes that a necessary pre-condition for success is the presence of 'something working and testable that you can play with.' It is worth noting that 'working' does not mean gorgeous or even ready. “Releases early and often” is a well-known mantra of Open Source development, which makes sense, since such a project’s behavior can help get early feedback and increase project reliability. For this reason, communities should not be afraid to post material earlier. Thanks to early releases, you can gain significant benefits by providing expectations and managing the project clearly and correctly.
If a software product should attract users, presentation and branding should convince advanced users that the program does something much better than its competitor. Once interest has been fixed, it is worthwhile to omit the threshold for users to enter: for example, such simple things as the installation process should go completely smoothly. However, user experience is not the end of the story. In the long run, developers will also be required, at least managed with minor improvements that can drive a single developer into the swamp. Developers can grow out of an existing user base, but they can also come from anywhere, driven by the need to gain skills, fame, or look for an opportunity to show their programming skills.
Opening a project in this way can add a completely new set of problems. Karl Fogel (Karl Fogel) in “Production of Open Source Programs” notes: “Opening means bringing the code in an understandable form for arrivals from outside, setting up the developers site, mailing list, and most often the first writing of documentation. All this seems to be a large amount of work. And of course, if someone from interested developers appears, they will have to answer their questions for some time before any benefit arises from them. ”However, additional efforts are at least partially overlapped by the availability of ready-made collaboration tools like Google Code or Sourceforge. And in addition: opening a project does not necessarily mean losing control. Many projects in the early periods work as a “generous dictatorship” with one person responsible for developing most of the functions and analyzing the written code.
Generous dictators do not have to possess outstanding technical skills, but according to Vogel, they will have to “be able to distinguish between good design”. Vogel goes further and notes that the main responsibility of the dictator is to make sure that the participants believe that they "can do more than one at a time". Developers will remain only if the project leader can make the project a place where they want to return. This means rewarding the work, delegating to those who deserve it and those who want it, more responsible job sites. Project management Open Source has been described as active, informal and inconspicuous. Successful generous dictators must also "speak quietly." All this requires universal human skills, and, as Raymond suggests, "a little ability to fascinate people."
Transparent management on pitfalls
The responsibility of community leaders is to ensure that the conditions remain usable for the potential of Open Source. It does not come by itself and must be carefully managed.
In the early stages, the most significant problem of the project is to deal with a very heavy load of support. Poorly organized support can, at best, lead to the loss of users, and at worst cause the project founder to surrender. If you plan to at least some success of the project, the leader must find people who will be engaged in this work. One way is to hire them. Another is to invite users to help each other by writing documentation and correcting errors. However, if this happens, an infrastructure should appear that will allow users to do this. Any contribution should be actively welcomed and leaders should be sure that the contribution is useful and of sufficient quality.
As soon as the project is more or less stabilized, other dangers come into play. One of them is the always existing possibility that someone can take a code and start a competing project based on it. This phenomenon, known as fork, causes damage by sharing and separating the developer community. This event also confuses and undermines user confidence and leads to unnecessary doubling of effort. Since the user and developer communities are the blood of the Open Source project, any damage caused to them will in any case affect the sustainable development of both projects. A rush to create a fork may arise for any reason, technical or political, but it is worth paying attention to only when it comes from someone with a sufficient number of followers in the community. In any case, well-documented negative aspects of creating a fork lead to a strong desire of society to resist this, because it is known that the decision to divide the community should never be made easily.
Let go
To be considered healthy enough, Open Source communities must be able to outlast the original founder’s interest in them. If they rely heavily on the dictator, they risk breaking apart and disappearing when their leader changes his sphere of interests or retires.
In most communities, even in those that are governed by dictatorship, people, in addition to the supporter, are becoming more and more responsible for making decisions. The natural result of this is a transition to democracy based on consensus. This new state of affairs does not guarantee that all decisions, especially minor ones, will be made deliberately. Most of the time, proposals will be accepted on the principle of “lazy consensus” when silence is tantamount to agreement. In order to deal with proposals for which no agreement has been reached, all communities use some form of voting.
The more complex these customs and procedures become, the more important it becomes to inform new participants about how they can start participating in the project and use their voting rights in the decision-making process. Young communities may return to the practice of using mailing lists to accumulate information, but this does not always help newcomers and may leave them with a misunderstanding. What is really needed is something written down, a kind of “management model” fixing the existing understanding in a documentary form. The formalization of agreements helps to be sure that the community lives its own life, independent of anyone, that it can survive and flourish for a period while there is a need for the product produced by this community.
Conclusion
Building a community around an open source product can be slow, hard work and success depends on many criteria. However, without a community there is simply no project. Forming a community will not happen by itself and should be carefully managed. All communities begin with users attracted by the form and design or oral recommendations. As soon as they arrive, the task appears to meet their expectations. A thriving community of developers can meet and expand user expectations, but only if their leader can keep them together and be sure that the participants will not wander to create their own projects. In the long run, communities should have an open development mechanism to ensure that, if the key players, including the founders, leave, they can easily be replaced by someone else.
Source: https://habr.com/ru/post/116290/
All Articles