(The other day I talked about how we think of ourselves as Ushahidi and how we think of success in our world. It's part one two posts that sets 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.
Re-envisioning Crowdmap
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 on stage 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 on stage 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, Juliana 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 6 weeks in. When I heard what they had planned, and got a complete walkthrough 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 LA and San Francisco, so that gave me ample time to think by myself before I made any snap judgements. 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 chat. It was at that point that we realized that being 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 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.
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 on stage 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 on stage 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, Juliana 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 6 weeks in. When I heard what they had planned, and got a complete walkthrough 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 LA and San Francisco, so that gave me ample time to think by myself before I made any snap judgements. 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 chat. It was at that point that we realized that being 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 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.
Ushahidi personas scenarios
As 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 fits and starts, SwiftRiver is now being tried out by 500+ 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 it's 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.
View more presentations from Ushahidi