Facilitating Innovation in Open-Source Collaboration

Since our last blog post, the ThoughtWorks software team has begun its work and is making steady progress towards its deliverables. The user interface for the web application has been enhanced, a majority of the Blackberry app has been moved to Android, and new security features have been added to both platforms.

Over the past few months though, the team has realized that one of the most unique, and challenging, aspects of the RapidFTR project is not necessarily the development of the software itself. Rather, it is working to ensure that the open-source volunteers and the new, full-time software development team collaborate and move the project forward together.

Although open-source collaboration is not a new thing, this type of collaboration is usually seen on more tech-related projects such as Mozilla Firefox, Ubuntu, or Apache Server. Open-source collaboration in software projects aimed squarely at less fortunate individuals has only been attempted in a few other instances. One example is OpenMRS (openmrs.org), from which the RapidFTR team has adapted several communication principles.

In order to better support the open-source volunteers that have been driving RapidFTR for the past two years (and will continue to do so in the future), the full-time software developers from ThoughtWorks have adopted the mindset that they are attending a code jam every day. This means that they need to constantly think about their methods of communication and ensure that the proper project history is documented at all times. While their contact with the RapidFTR project may be short-lived, the code that they have written will likely be updated by volunteers at some point in the future.

This focus on ensuring that the discussions are shared by everyone in the RapidFTR community has manifested itself in two specific ways. Two of the most basic communication tools used by teams today are an instant-messaging platform for quick chats (IM, Skype, Gchat, etc) and email. However, the important thoughts shared with these tools only reach the persons that are included in the conversations. It is difficult to save this information for others that may become involved in the project in the future.

This focus on long-term knowledge management has required the full-time development team members to use different communication tools than they would otherwise. Instead of private emails, the majority of email discussions are posted on the Google Group that has been used by RapidFTR contributors since the beginning of the project. Instead of Skyping or IMing each other for answers to quick questions, the team works on a public Internet-Relay-Chat (IRC) chatroom that logs all of the conversations. These conversations are posted publicly so that the open-source volunteers are able to access them at any later possible date.

All of this open-communication is extremely important as it is firmly recognized within the Thoughtworks team that their work is only short-term. It is the open-source community who will ensure the long-term viability of RapidFTR, and so the mindset is necessarily to provide the foundation for this support even now.

Inter-Agency Cooperation
This same mindset of open-collaboration also applies to the gathering of design requirements from the broader child protection community. UNICEF actively seeks feedback from its partners in the Inter-Agency Working Group on Unaccompanied and Separated Children for the design specifications of RapidFTR to ensure that the system is in line with Child Protection requirements. There are important considerations for each organization that are taken into account in order to provide the most flexibility and acceptance of RapidFTR for any emergency situation, no matter which agency chooses to deploy it.

More about this inter-agency cooperation will be explored in the next blog post, as it goes hand-in-hand with the preparations for the advanced field-testing being planned Uganda.