Setting the Pace for Swift

This morning's release of SwiftRiver v0.0.9 Rumba is the culmination of nearly a year's worth of planning and a few months of development time. When I came on board in December, the Ushahidi staff, Kaushal Jhalla, Chris Blow, Ed Bice and many others had already done fantastic jobs of making Swift known and prototyping their ideas. But they still needed an application, and to get it done (amidst all the other chaos like Haiti and launching the iHub) Ushahidi needed someone who could focus only on Swift for however long it took to get the job done. As a huge supporter of SwiftRiver for months prior, it was exciting to be asked to take on the task. My philosophy was, no matter how long it takes to perfect, people want something they can use sooner rather than later. An okay product can always get better and quite a few people were very much looking forward to the final product. That said, our first goal at Team Swift was to get something done that would be tangible -- something usable. This was supposed to take two months. The course was charted, we had small team in place, and we were ready to go. Then Haiti happened and threw our whole organization (and much of the world) into a bit of choas. So Swift was delayed for a few weeks while I did my best to aid with our efforts there. This actually ended up helped out significantly, as we now had real world scenario (albiet, an unfortunate one) to learn from. As an organization we learned firsthand the crippling effect of having too much information. In the first few days we had 50,000 reports, then 100,000, then 150,000. We were floating in a sea of data (much of it irrelevant noise, cross-chatter, spam and duplicate submissions) that needed to be verified by human volunteers. There had to be a better way to manage; this is where we found the critical need for an application like SwiftRiver. How do you deal with 'too much information'? How do you filter it in a way that saves time, without sacrificing accuracy? This is the problem SwiftRiver is attempting to solve. Rumba marks the first step in this process. With it you can easily aggregate content, tag and vote. There's also an option to 'Pair with Ushahidi', which will allow users to link their Swift instance with an Ushahidi instance. In that scenario, Swift manages all incoming data which is then posted as a Report in Ushahidi. Our next step is to swap out the core (for scalability reasons). And to integrate our natural language processing module SiLCC and our distributed authority system - River ID. We've also integrated existing semantic web applications like Open Calais and TagThe.net. You can look forward to all these things and more in our next release, Apala. For the next few months there will be many versions of Swift in rapid succession as we iterate our way to our Beta release in August. I like to compare this entire process to long-distance running. When a runner sets out, they usually have already set their course, they already know what kind of energy they need to reserve to complete their journey, and they know that maintaining their 'runners high' can carry them along, far past the point of exhaustion. So for us, Rumba is like our feet hitting the pavement for a jog, we know the course, we're saving our energy and we're focused only on the road ahead. In the video below Erik Hersman talks about SwiftRiver at TED. Runner photo by Thomas Hawk