In building the community for PeerLibrary, we assessed what leads to effective community participation in open source projects. Which organization structures best facilitate the inclusion of new contributors? Why are there, on GitHub, popular projects in which there are a lot of contributors outside the core team and some compelling projects which attract none? How do we best effectively use the tools we have to encourage community participation? What about for potential contributors who can help out in ways other than committing code? These were a few questions that we had in mind when we were laying the foundations for an inclusive community.
We discovered that a lot of the built in features on GitHub were integral for community participation. One feature I was not aware of until Mitar joined our team was the existence of the built-in issue tracker. Our issues page in the main PeerLibrary repository is a way for contributors to get a perspective on what the pressing work that needs to get done. Our issues are labeled as "bugs", "duplicates" or "for new contributors". We thought it would be a good idea to guide new contributors by identifying which features would be implemented easier. We also have a roadmap which lays out the long term goals for the project. This helps to keep our team aware of the upcoming deadlines for version launches. At the time of writing we are close to launching 0.1, which will be the first alpha release to the public. I've noticed more issues have been submitted at this time as the standards of contributors have been more rigorous as we're preparing to ship to production. I would imagine joining a project as a new contributor could be quite intimidating and we wanted to provide as much guidance as possible. We published contribution guides on our GitHub Wiki which includes an overview of the codebase, information on how to start contributing, and code styles and development guidelines. We also have links to related projects such has Hypothesis in solidarity for other smart folks working on solving similiar problems with open source. In the early stages of PeerLibrary there has been problems with me and other contributors running the app on our local machines and this has been a significant bottleneck for new contributors. We added a troubleshooting guide to our [README] (https://github.com/peerlibrary/peerlibrary/blob/master/README.md) file for debugging server side Meteor problems for different operating systems.
PeerLibrary also does some offline community outreach as well. We have presented our project at spaces around the area such as the WikiMedia Foundation, the Internet Archive and Noisebridge. Our core team also attended a variety of hackathons in which we have recruited new contributors such as the Science Hack Day (at the California Academy of Sciences), the Aaron Swartz Memorial Hackathon and the Meteor Summer Hackathon (which was awarded 1st place for highest impact). Members from our team also travelled to academic and open source conferences internationally such as the Open Knowledge Conference (Geneva), the Mozilla Festival (London) and the Creative Commons Global Summit (Buenos Aires) in which we presented and promoted PeerLibrary in keynotes and lightning talks. In these confererences, we have forged an invaluable network with open access advocates, software developers and academics whom we've been reaching out to collaborate with.
I found that it's often difficult to recruit new developers to work on an open source project. In fact there have been very few consistent contributions from outside our core team. I think one of these reasons could be the scope of the project. The problems we are trying to tackle within academia and scholarship are non-trivial and are part of a larger movement in making academic knowledge accessible to the general public. For this reason, I've often found it difficult to pitch the idea of PeerLibrary (as one might do in a startup) because it's a project of such a large scope. We also haven't spent much of our efforts making new features for demos so it's difficult to convince developers this is a worthy project to contribute to. Most of the work so far is also not very visible as it deals with the internals of the application such as PeerDB, a Meteor package that implements a database for collaborative data. We are constantly working on finding work for new developers and convincing others that this is an important project to work on. I believe that this starts with making the language in our documentation more accessible and being transparent with our goals in our community principles.