HomeNews and blogs hub

Increasing participation in distributed projects

Bookmark this page Bookmarked

Increasing participation in distributed projects

Author(s)
Mario Antonioletti

Mario Antonioletti

Community Officer / Research Software Engineer

Nikoleta Glynatsi

Nikoleta Glynatsi

SSI fellow

Lawrence Hudson

Lawrence Hudson

SSI fellow

Cyril Pernet

Cyril Pernet

SSI fellow

Thomas Robitaille

Thomas Robitaille

SSI fellow

Posted on 22 March 2017

Estimated read time: 6 min
Sections in this article
Share on blog/article:
Twitter LinkedIn

Increasing participation in distributed projects

Posted by s.aragon on 22 March 2017 - 9:00am

Participation in distributed open source projectsBy Mario Antonioletti, Software Sustainability Institute, Nikoleta Evdokia Glynatsi, Cardiff University, Lawrence Hudson, Natural History Museum, Cyril Pernet, University of Edinburgh, Thomas Robitaille, Freelance.

Running an open-source project with geographically distributed participants is a substantial undertaking. Attracting and retaining participants can be hard. Communicating project progress via social media, websites and mailing lists can take a lot of time, as does organising and running regular meetings since contributors are typically separated both by geography and time zones. It is important to identify mechanisms for (i) attracting participants (social aspect), (ii)  communications and development processes (which can encompass workflows, standards, conventions, project administration) and (iii) remote collaboration. In this blog post, we summarise some social and technical challenges and provide suggestions for how to successfully start and maintain an open project with remote participants.

Before starting your project it is important to decide upon a licence. The licence clarifies ownership, rights and responsibilities of each contributor. Without one, people may be reluctant to contribute to, or even to use, your software. Changing a project's licence requires agreement of all contributors—this might be impractical once a project has had contributions from many people over several years. Resources such as choosealicense.com make it relatively easy to decide upon a licence, including one for non-software outputs.

Attracting participants

The main challenges projects face are attracting new participants and widening the community. One of the main ways to start a collaborative project or expand the community is to hold ‘event days’.

The title of the event itself should not make any assumptions about the kind of people we are targeting (e.g. ‘hack day’ and ‘code sprint’ day may target too narrow an audience compared to ‘project day’). An appropriate title can be chosen to be welcoming to people of all genders and backgrounds. The ideal event type we suggest is a get-together for potential contributors in the development of the project (such as a sprint day). The contribution of an individual could be more than just coding—it could be documentation, testing, outreach via social media or ideas.

Furthermore, to help individuals get over their fear of contributing we also suggest to offer 'training days'. Training days would be about introducing anything, including source code organisation, code style, testing framework, version control, good issue report practices, code or documentation contribution steps, etc. Training days can be done in groups and/or remotely pairing a future contributor with a mentor.

Retaining participants

Keeping people involved in a project is just as important as training new contributors. If too little effort is spent in keeping contributors, a lot of time will be ‘wasted’ in training contributors who then don’t stay on the project. Building a sustainable community is something that needs to be actively managed rather than something that ‘just happens’. Examples of ways to keep your community strong and retain contributors include:

Face-to-face meetings: Communicating via mailing lists, issue trackers or chat rooms is important but these methods are not enough in themselves, and tend to remove the human element from the community. Face-to-face meetings (in-person or via video for example) are a much more efficient way to discuss and resolve issues, as well as a way for people to become familiar with other members of the community beyond nicknames and avatars. As communities grow beyond a certain size, face-to-face meetings with everyone become trickier, but face-to-face meetings for subsets of people are still possible.

Having a governance model: one danger with open source projects is that even when people start contributing to them, there is a barrier between contributors and core developers, and it’s often not clear how one contributor can become a core developer, making the maintainer group seem like a private ‘club’. Having a proper and public governance model is essential for open projects, so that people can better understand how they can take up more responsibilities in the project, and how contributions are recognized.

Giving people responsibilities: as people continue to participate in a project, it is important to provide recognition for this by making sure that their role in the project in recognized. Providing an official role gives something that can be included on a CV, and also motivates people to live up to that role and continue contributing. As an example the Astropy project has recently listed a number of roles in the project and assigned people to them, making sure that the responsibilities of each role are described in detail. This ties into the governance model mentioned above, since acquiring or leaving a role should be a semi-formal process (rather than being based on nepotism).

Remote Participation

The technologies used by the project must allows easy contribution, and using a social coding platform like GitHub, GitLab or BitBucket is key. Creating documentation is key to any software and easy collaborative tools like a wiki or even a Google Doc can be effective. Finally, meetings are very important beyond keeping internet communications open; that means, having an email list (powered by, for example, GNU Mailman, Discourse, Google Groups) and/or text messaging channel (powered by, for example, IRC, Slack, Gitter) but also organise regular ‘face-to-face meetings’ (see above). Keep in mind that free VOIP like Skype and Google Hangouts have limited bandpass and meeting can become difficult to manage beyond 10 to 20 participants. This can be avoided with meetings between smaller groups of people who have similar roles within the project.

Conclusion

Attracting and retaining participants in an open source project is a difficult enterprise but is mandatory to ensure sustainability. As most open source projects (especially academic ones) rely on people's free time, it is essential to create an active community allowing the project to thrive without its founders. Open licences, good communication and clear governance are key to retaining people.


 

Share on blog/article:
Twitter LinkedIn