Through my help with VoteReport.in I have been diving much more into supporting and deploying the Ushahidi platform as part the front-end for user contributed reports. Ushahidi itself started out as a quick mashup a year ago and since then has blossomed into a much fuller platform that is being utilized in dozens of initiatives and projects.
Each of these projects evolves the platform, adding new customization capabilities, more input types, browser support, and more. These modifications may be happening in rapid succession without the main Ushahidi development team even being aware of these changes. And the system may even be running in a remote area with little connectivity.
Traditionally, this has meant that a deployment would download a copy of the current release version, or maybe a development snapshot if there was some emminent new feature that was very useful, and then go off, make modifications – probably on a live server, and maybe email these changes back way after the event in hopes that some of the changes are accepted back into the platform. Updates to the main code base wouldn’t be easily applied to these heavily modified derivatives – so essentially every deploy is a fork of the code.
How Git can save the day
Fortunately, Ushahidi chose Git as the code repository server, although the installation instructions still suggest that you download the code. Git is meant to support just this kind of distributed workflow and collaboration.
If you’re not familiar with Git, I highly recommend checking out Git Internals. But to summarize, it is a versioning control system that is fast, efficient, has local indexes (stored in a local .git directory) and can reference any number of remote indexes to share commits, branches, and files. Where in traditional systems there is an ‘official’ host repository – in Git all repositories are equal and can quickly connect and syncronize.
What this means in a system like Usahidi is that any deployment would first just get a local clone of the official Ushahidi repository to their local system and setup and get running. If they make changes to this code they can just do a commit into their local index. In order to share this code with other developers on this same deployment they could just provide them with the Git link to this repository, or make a branch and add a deployment specific “remote” index that multiple developers could all push into.
Along the way as new code is released in the Ushahidi repository, these deployments could merge in these changes to their local branches without losing their local modifications. And conversely, local modifications could be merged and pushed back into the Ushahidi master index very easily.
Now lets think about some really powerful uses of the Git architecture. Since the entire index is stored locally in a .git folder – it is easy to put an Ushahidi deploy on a USB stick or archived folder, send it around, make modifications in the field and continue to commit these changes to a local repository even while offline. Then when connectivity is restored, or the USB stick can be brought back to a networked computer, the modifications that had been made, and tracked, could be pushed back to a deployment or Ushahidi instance.
And with arbitrary remote indexes – individual deployments could share code and modifications between themselves without having to go through an Ushahidi instance. Local networks around an incident, culture, language, or feature set could easily collaborate and iterate the code. Imagine if in Gaza, the Al Jazeera instance could have shared code to other local organizations running similar systems.
I think there are even more potential applications of Git to distributed architectures that would be useful for document and database sharing that occur in fast paced situations. However, Git itself will have to work on some of the usability and interface design issues that make it a difficult tool for novice users.