Digital Project Management Tips from GitHub
Shapechange
With the ease of telecommunication because of the internet, finding and communicating with others across the world has only grown to be more accessible. This gave birth to open source software projects - projects which the original source code is made freely available for others to redistribute and modify. Many programmers and designers across the world are forming project teams to create their open source software. 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. The survey revolved around problems encountered while working in their open source team and what they consider to be important. At the end, they asked what aspect open source software users consider as most important too. More than 6,000 open source project coordinates from different academic institutions, industry and open source communities across the globe answered the survey.
Like working with any project team, conflicts happen when working on open sourced projects as well; disagreement, confusion, and frustration may happen among team members. Unsurprisingly, confusing documentation is the biggest problem, and about 93% of the respondents claimed they had witness such problem. Different people have different names to portray their and not everyone can understand how others name their files. The second problem is unresponsiveness. About 80% of the respondents claimed they have experienced moments like having their project coordinators not responding to their emails or message on time. Not everyone is on their phone or computer 24/7. Other issues such as 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 can still be problematic to the team whenever they arise.
Major problems encountered in open source teams, mostly are communication problems
When problems among team members arise, some ill-tempered members will try to deal with in the “tough” way. Although only 18% of the respondents have personally experienced rude interaction, 50% of the respondents witnessed it. It could be an angry team leader criticizing an incompetent coordinate’s work, or simply avoidable arguments. Harassment or immature acts like name calling and stereotyping at work may happen, but usually on a 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 male respondents said they are very interested in making contributions. Such similarity only proves that passion is all that matters. 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%).
On the technical perspective, both men are women consider responsive maintaining, licensing, and a welcoming and active developing community to be important in an open source project team. Code of conduct, widespread use of the final product, and the contributor license agreements are somewhat important to the developers.
What are importance for open source project coordinators
Lastly for users, stability and security are the biggest concern when using open sourced software; functioning and malware-less software are basic requirements. User friendly experience and compatibility comes next. These are essential for whether the software be working and how easy it is for them to navigate through the software.
What users really look for when using open source software
In conclusion, when working on open source projects, the team should have a standard naming convention for files that everyone should follow. There should be a period of time throughout the day that all project members meet and work together, online or at a physical place. Lastly, project teams should be encouraged communicate to each other in a respective tone. As for the occasional behavior issue, project leaders should have a code of ethics that everyone could accept - perhaps even ban certain behavior if necessary. Interesting enough, these phenomena could apply to online forums and in non-software development teams, video production teams sometimes encounter such issues too. A code of ethics and desire to work on a team should be a natural quality that most should have.