Digital Project Management Tips from Open Source Developers

With the ease of telecommunication, finding and communicating with others across the world is easier than ever. This gave birth to open source software projects, projects which the original source code is made freely available for others to redistribute and modify. Every programmers and designers across the world can form project teams to develop software they passion about. GIMP is one of the famous example of open source image editor software.

Last week, GitHub, a project management software released a survey result on open source software development. It is about problems project coordinators encountered while working in their open source team and what they consider as important. More than 6,000 open source project coordinates from different academic institutions, industry and open source communities across the globe answered the survey.  At the end, GitHub asked open source software users consider as the most important for their product too.

Like working with any project team, conflicts happen when working in open sourced project teams too. Disagreement among members, confusion about directions, and frustration may happen among team members. Unsurprisingly, confusing documentation is the biggest problem, about 93% of the respondents claimed they had witness such problem. Different people name their files differently and not everyone can understand how others name their files. The second biggest problem is unresponsiveness. About 80% of the respondents claimed they there are time when their project coordinators are not responding their email or message on time. Not everyone is on their phone or computer 24/7 but it is still important to check incoming messages once a while. Bad languages, conflicts, and unexplained rejections are ranked afterward. Sometimes, your teammates get angry or impatient over matters. Although they are less likely to occur, they still problematic to the team whenever they arise.


When problems arise among team members, some ill-tempered members will try to deal with in the “tough” way. Although only 18% of the respondents have personally experienced rude interactions, there are 50% of the respondents witnessed it. It could be an angry team leader harshly criticizing an incompetent coordinate’s work or simply bad relation among team members. Harassment or immature acts like name calling and stereotyping at work happen but in a relatively small scale.


At the same time, there are still an enormous gender imbalance in this research. About 95% of the respondents are men, 3% are women and 1% identify themselves as non-binary gender. Perhaps there are much more males working on open source projects. Either way, 68% of the women and 73% of the men respondents said they are very interested in making further contributions. Such similarity states passion is all that matter. However, women are more likely than men to encounter unwelcoming language contents (25% vs 15%), stereotyping (12% vs 2%), and sexual harassment (6% vs 3%). Nevertheless, women are more likely to ask for help directly when encountering problem (29% vs 13%).

At the technical perspective, both men are women consider responsive maintainer, licensing, and a welcoming and active developing community are very important to have in an open source project team. Code of conduct, widespread use of the final product, and the contributor license agreement are somewhat important to the developers.


Lastly, for users, stability and security are the biggest concern when they are using open source software. Functioning and malware-less software are basic requirement for any software. User friendliness, compatibility come next, these are essential for whether the software be working and how easy for them to navigate through the software.


In conclusion, when working on open source project, the team should have a standard naming convention for files that everyone to follow. There should be a period of time in the day for all project members to meet and work together, via video conference, chatroom, or at a physical place. Lastly, project teams should be encouraged to communicate to each other in a respective tone. As in behavior issue, project leaders should have a code of ethics that everyone could accept and ban certain behavior if necessary. Interestingly, these phenomena could also apply to online forums and in non-software development teams, like video production teams.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s