The PeerLibrary community is quite young, and I've been told that there haven't really been any tough decisions encountered yet. Many important decisions are spearheaded by the group's benevolent dictator, Mitar. This includes the decision and reasoning for using the Meteor platform instead of node.js to build the PeerLibrary tool, and also the recent decision to switch from a BSD to an AGPLv3 license. After speaking with others at the international Open Knowledge Conference conference that was held in Geneva this past September, Mitar learned about the benefits of this latter type of license. Specifically, the AGPL requires code used and modified by another party to be made public and available for others (including the original suppliers) to use, wich is not the case with the BSD license. From my understanding, Mitar became the leader of this project because of his seniority in terms of: the very early stage at which he joined the project, his experience with the technology, his deep interest and knowledge about the content area, and experience with leading other open source software project teams. Having a thorough understanding of both the technology and the content matter, Mitar makes an effective leader. He is open to discussing all sorts of questions that newcomers have and devotes a significant amount of time making sure the project stays on track, including sending updates and reminders on the developer mailing list, while being careful to hear others out. Ultimately, contributors to an open source, unpaid project like this one must be motivated at least on some level intrinsically to be cooperative and work together to make the project improve. A benevolent leader is very helpful for focus and direction in this situation.
As PeerLibrary is in its early stages, we are still adding more documentation and details about the governance model on the project's GitHub wiki. Last week Mitar and I worked on the Contributing to PeerLibrary and Development Model sections to give possible contributors and newcomers an idea of our work flow, needs, and specifications for contributions. Mitar also added a new section about the code style used in this project, which I found very helpful. As the community grows, the plan is to add a "PeerLibrary Contributor Agreement" similar to the one Meteor has in order to protect the project from legal battles stemming from contributors committing code that they did not have the right to commit to PeerLibrary. The signature form that Meteor has in their contributor agreement site integrates with GitHub, which is nice because that means each contributor only has to sign the form once, and the agreement remains active for all future commits. For each pull request that a contributor submits to Meteor, GitHub authenticates that the agreement has been signed before letting the request go through (see the green box under Mitar's recent pull request to the Meteor GitHub repository). Other systems have contributors "sign off" on each commit/pull request, which can be problematic. If the project leads like the proposed change but they are unable to get the contributor confirm publicly that they have the right to use this code, then the project team may be obligated not to accept the changes (even if they like them!).