This is part 2 in a series. In part 1, I talked about how we think of ourselves at Ushahidi and how we think of success in our world. It set up the context for this post, which is about where we’re going next as an organization and with our platform.
We realize that it’s hard to understand just how much is going on within the Ushahidi team unless you’re in it. I’ll try to give a summarized overview, and will answer any questions through the comments if you need more info on any of them.
The External Projects Team
Ushahidi’s primary source of income is private foundation grant funding (Omidyar Network, Hivos, MacArthur, Google, Cisco, Knight, Rockefeller, Ford), and we don’t take any public funding from any country so that we are more easily able to maintain our neutrality. Last year, we embarked on a strategy to diversify our revenue stream, endeavoring to decrease our percentage of revenues based on grant funding and offset that with earned revenue from client projects. This turned out to be very hard to do within our current team structure, as the development team ended up being pulled off of platform-side work and client-side work suffered for it. Many internal deadlines were missed, and we found ourselves unable to respond to the community as quickly as we wanted.
This year we split out an “external projects team” made up of some of the top Ushahidi deployers in the world, and their first priority is to deal with client and consulting work, followed by dev community needs. We’re six months into this strategy, and it seems like this team format will continue to work and grow. Last year, 20% of our revenue was earned; this year we’d like to get that to the 30-40% range.
When anyone joins the Ushahidi team, we tend to send them off to some conference to speak about Ushahidi in the first few weeks. There’s nothing like knowing that you’re going to be onstage talking about your new company to galvanize you into really learning about and understanding everything about the organization. Basically, we want you to understand Ushahidi and be on the same mission with us. If you are, you might explain what we do in a different way than I do onstage or in front of a camera, but you’ll get the right message out regardless.
You have a lot of autonomy within your area of work, or so we always claimed internally. This was tested earlier this year, where David Kobia, Juliana Rotich and myself as founders were forced to ask whether we were serious about that claim, or were just paying it lip-service. Brian Herbert leads the Crowdmap team, which in our world means he’s in charge of the overall architecture, strategy and implementation of the product.
The Crowdmap team met up in person earlier this year and hatched a new product plan. They re-envisioned what Crowdmap could be, started mocking up the site, and began building what would be a new Crowdmap, a complete branch off the core platform. I heard this was underway, but didn’t get a brief on it until about six weeks in. When I heard what they had planned, and got a complete walk-through by Brian, I was floored. What I was looking at was so different from the original Ushahidi, and thus what we have currently as Crowdmap, that I couldn’t align the two in my mind.
My initial reaction was to shut it down. Fortunately, I was in the middle of a random 7-hour drive between L.A. and San Francisco, so that gave me ample time to think by myself before I made any snap judgments. More importantly, it also gave me time to call up David and talk through it with him. Later that week, Juliana, David and I had a chat. It was at that point that we realized that, as founders, we might have blinders on of our own. Could we be stuck in our own 2008 paradigm? Should we trust our team to set the vision for a product? Did the product answer the questions that guide us?
The answer was yes.
The team has done an incredible job of thinking deeply about Crowdmap users, then translating that usage into a complete redesign, which is both beautiful and functional at the same time. It’s user-centric, as opposed to map-centric, which is the greatest change. But, after getting around our initial feelings of alienness, we are confident that this is what we need to do. We need to experiment and disrupt ourselves — after all, if we aren’t willing to take risks and try new things, then we fall into the same trap that those who we disrupted did.
A New Ushahidi
For about a year we’ve been asking ourselves, “If we rebuilt Ushahidi, with all we know now, what would it look like?”
To redesign, re-architect and rebuild any platform is a huge undertaking. Usually this means part of the team is left to maintain and support the older code, while the others are building the shiny new thing. It means that while you’re spending months and months building the new thing, that you appear stagnant and less responsive to the market. It means that you might get it wrong and what you build is irrelevant by the time it’s launched.
Finally, after many months of internal debate, we decided to go down this path. We’ve started with a battery of interviews with users, volunteer developers, deployers and internal team members. The recent blog post by Heather Leson on the design direction we’re heading in this last week shows where we’re going. Ushahidi v3 is the complete redesign of Ushahidi’s core platform, from the first line of code to the last HTML tag. On the front-end it’s mobile web-focused out of the gate, and the backend admin area is about streamlining the publishing and verification process.
At Ushahidi we are still building, theming and using Ushahidi v2.x, and will continue to do so for a long time. This idea of a v3 is just vaporware until we actually decide to build it, but the exercise has already born fruit because it forces us to ask what it might look like if we weren’t constrained by the legacy structure we had built. We’d love to get more input from everyone on this as we go forward.
SwiftRiver in Beta
After a couple of fits and starts, SwiftRiver is now being tried out by 500-plus beta testers. It’s 75% of the way to completion, but usable, and so it’s out and we’re getting the feedback from everyone on what needs to be changed, added and removed in order to make it the tool we all need to manage large amounts of data. It’s an expensive, server-intensive platform to run, so those who use it in the future will have to pay for its use when using it on our servers. As always, the core code will be made available, free and open source, for those who would like to set it up and run it on their own.
The amount of change and internal change that Ushahidi is undertaking is truly breathtaking to us. We’re cognizant of just how much we’re putting on the edge. However, we know this; in our world of technology, those who don’t disrupt themselves will themselves be disrupted. In short, we’d rather go all-in to make this change happen ourselves than be mired in a state of stagnancy and defensive activity.
As always, this doesn’t happen in a vacuum for Ushahidi. We’ve relied on those of you who are the coders and deployers to help us guide the platforms for over four years. Many of you have been a part of one of these product rethinks. If you aren’t already, and would like to be, get in touch with myself or Heather to get into it and help us re-envision and build the future.
Raised in Kenya and Sudan, Erik Hersman is a technologist and blogger who lives in Nairobi. He is a co-founder of Ushahidi, a free and open-source platform for crowdsourcing information and visualizing data. He is the founder of AfriGadget, a multi-author site that showcases stories of African inventions and ingenuity, and an African technology blogger at WhiteAfrican.com. He currently manages Ushahidi’s operations and strategy, and is in charge of the iHub, Nairobi’s Innovation Hub for the technology community, bringing together entrepreneurs, hackers, designers and the investment community. Erik is a TED Senior Fellow, a PopTech Fellow and speaker and an organizer for Maker Faire Africa. You can find him on Twitter at @WhiteAfrican
This post originally appeared on Ushahidi’s blog.