The OpenStack Summit held in Austin became an excellent platform for exchanging open source project management experiences. It turns out that after years of community participation and project contribution work, I do have some say in these matters.
However, in today’s article, I plan to interpret this topic from a negative perspective, discussing practices that should not be adopted in open source project management.
1. Adding Hassles for Contributors
Software developers and maintainers are already busy, so excessive task allocation only makes people more resentful. In fact, one of the biggest misconceptions in the open source field is that managers often think overwhelming work can increase members’ sense of participation. Let me be blunt—if there are too many tasks, people might just leave.
I have a good friend who has been contributing to Ceilometer since 2013. His code review level is quite high, even able to spot many errors that others don’t realize. The project management team eventually promoted him to core reviewer—rather than simply assigning him more tasks. Trust me, it’s this sense of achievement that keeps more highly skilled technical professionals in the project.
2. Only Letting People Participate in Boring Work
When newcomers join, their motivations are often different. Some users hope to realize their value through contribution, while others join for learning purposes. But generally speaking, people are actually quite resistant to always doing the lowest-level boring work. If managers don’t care about the feelings of grassroots contributors, then boring content combined with the work intensity mentioned in the previous point will definitely make many friends interested in open source quickly withdraw.
3. Not Valuing Small Contributions
Does fixing a typo count as a contribution? Does reorganizing documentation count as a contribution? This mentality is not uncommon in open source projects, but it turns out that such work actually has important value.
I personally was once responsible for fixing documentation errors in a project, and in a short time published 56 patches, fixed some bugs, and added some extra features. No one looked down on me because these were small things, and I believe my work indeed had value.
4. Setting Too High Barriers for Newcomers
When newcomers participate in open source projects, their personal technical level and professional experience are often very different. Many managers directly assign them overly complex tasks, which makes many people feel frustrated, even thinking they’re too stupid and quietly withdrawing.
In fact, we should assess newcomers’ technical level (simple communication should roughly figure out their level), and then assign them work that’s within their ability but still somewhat challenging.
5. Asking People to Sacrifice Their Personal Lives
Most participants will only use their free time for open source contributions, which is a very healthy way of development. Please note, don’t expect project members to sacrifice their personal lives for contribution—that’s neither realistic nor beneficial for the long-term development of the project.
Also, overly frequent video conferences and even IRC meetings will make people feel annoyed. Open source projects should be people-oriented and adopt different communication and contribution methods for different members.
6. Potential Code of Conduct Too Hard to Integrate
As the community develops, there will always be a potential style or way of doing things that becomes its personality label. Although this can make old hands enjoy it, it may also deter newcomers.
Admittedly, we don’t need to organize any explanation guide for behavioral norms. But as project managers, it’s best to let the team fully consider newcomers’ feelings while maintaining their personality. Throwing out a bunch of internal terminology or “memes” from time to time really doesn’t do any good besides hindering the further expansion of organizational scale.
7. Making Non-Native English Speakers Feel No Sense of Participation
The vast majority of open source project communities communicate in English, and this has become an important prerequisite for everyone’s collaboration. However, we should also consider that some technical personnel come from countries where English is not their native language, which means they may have difficulty communicating smoothly with original members, and may even be discouraged by this.
Facing this situation, we can think of other alternative methods. For example, adopting asynchronous communication methods, sending communication content via text. This way, the other party can roughly understand the meaning with the help of translation software, while also avoiding the tension brought by speaking a foreign language.
8. Lack of Vision, Unwilling to Delegate
These two mistakes are common in various open source projects. In fact, some contributors will develop new features after joining and seek feedback from original members. At this time, the maintainer manager may realize they’re not familiar with this part of the technology, and may even decide to quit. It must be emphasized that the project’s development vision and communication around this point are very important, so that we can let all members have the same judgment and understand whether they should stay in the team to play a role.
Also, part of the responsibilities should be confidently handed over to other members, rather than all controlled by oneself. Patch review, subsystem design, bug fixing, and documentation writing can all be handled by dedicated personnel. Through this method, every member can feel their role and value, and more actively stay in the project team.
9. Not Recognizing Contributors’ Achievements
There are many ways to contribute to open source projects, not limited to writing code. Documentation, bug debugging, user support, experience design, dissemination, and even translation, all of these are very important work.
Therefore, we should give full attention to non-technical contributions and be very careful when establishing team member hierarchies, so as not to miss any type of talent.
10. Lack of Gratitude
As a conclusion, I want to emphasize the importance of gratitude in open source projects. Such projects are often built by participants for free. As managers, we should cheer for everyone’s sharing spirit—of course, in a way that they can intuitively feel!
Reposted from: Developer Relations »
