Tomorrow (Wed, July 9th) we have a launch event happening at Sarit Centre for our Nairobi friends and media, starting at 9am, where we take over our partner Sandstorm‘s store for the day. We’ll be there all day, so come on buy if you can make it. You’ll be able to use the devices and ask questions from anyone on the BRCK team.
The BRCK is a rugged, self-powered, mobile WiFi device which connects people and things to the internet in areas of the world with poor infrastructure, all managed via a cloud-based interface.
It is designed and engineered right here in Nairobi, with components from Asia, and final assembly done in the USA. Specs here.
Most people heard about the BRCK a year ago when we ran our Kickstarter campaign that raised $172k. What a lot of people don’t know is that the journey started long before that, 1.5 years earlier in fact.
Back in November of 2011 I was in South Africa for AfricaCom, and it was in a discussion with my good friend Henk Kleynhans (the founder and then-CEO of SkyRove) that we started talking about routers. Knowing nothing about routers, I asked him why he didn’t build his own, to which I think the answer was something like, “that’s hard” and it wasn’t their core business anyway.
Later on that evening I was flying back to Kenya and I started pondering what it would be like if we built a router made for our own environment – something that would give us good solid connectivity in Africa. I started sketching out the first ideas around what would be in the BRCK, what it would need, etc. When I landed in Nairobi, I started talking to the Ushahidi team about this, and whether anyone wanted to try prototyping this with me in their free time.
With the problems we have around power and reliable internet connectivity in Nairobi, we all had an itch to do something, and so we did.
The 1.5 years between that point and the Kickstarter was filled with Jonathan Shuler doing a number of early prototypes, Brandon Rosage hammering out an early brand and design, and Brian Muita getting into the guts of the software. Sometime in there was a walk with Ken Banks in a field in Cambridgeshire, discussing what this future product could be as a company. Then there was the entry of Philip Walton, volunteering his time to do the first truly functional designs that married the components and some customized firmware, throwing it all into an Otterbox case, held together by Sugru and tape, to make sure it worked (seem image below). Then Reg Orton came along in late 2012 and started volunteering his time and knowledge around case and PCB design, and started to professionalize our hardware production. All of this culminated in a working prototype.
We ran the Kickstarter in June last year to test the market, to see if there were others who thought this BRCK device was cool, useful and something that they would purchase. It worked out well, and we found out that there were a number of business types who wanted something just like this.
Then the real work began.
It’s fairly easy today to prototype a cool new device, we did that for 1.5 years with many iterations even before we did our Kickstarter in June last year. When you go to production though, that’s a whole different beast, and we ended up spending a year from our Kickstarter until today going through more levels of prototypes before we finalized on our production-level hardware back in February. Keep in mind, that’s with people on the team, like our CTO Reg Orton, who have been in this hardware space for 12+ years.
There’s also the software integration issue that had a lot of unknowns which we couldn’t tell in advance. It’s not just hardware we’re building but an integrated software and hardware package that consists of hardware + firmware + cloud. Fortunately we’ve got some pretty amazing problem solvers who don’t seem to sleep on our team, between the heroics of our COO Philip Walton and cloud lead Emmanuel Kala, we were able to find workarounds and put together a robust BRCK management package.
What I’m getting at is this – software is hard to get done well. Hardware is harder. Software plus hardware is amazingly complex, and it’s easy to underestimate the level of difficulty in what seems like a simple device.
It’s been a battle, one with multiple fronts and many setbacks along the way. We’ve had our modem supplier go end-of-life on one of our core components, and subsequently had to find a new supplier and redesign our board and case. We’ve found crazy bugs in OpenWRT that took us weeks to figure out a way to work around. We’ve mixed in some fairly harsh testing of the BRCK in some of Kenya’s hardest environments, and we’ve seen it perform and change the way a business can do their work. We’ve also seen our earliest users loading up education materials on it for schools that aren’t fully on the grid.
We’re finally there, after many, many months.
It’s with great gratitude to my BRCK partners and team that I say thanks for pushing through. I’m also extremely grateful to Ushahidi, especially David and Juliana, and the Board, for helping push the BRCK through, even in those early days of 2012 when it seemed so crazy. None of this could have been done without a few brave souls willing to risk some money on us, to our seed round of investors who came together and put in $1.2m, which meant we could hire more people and build an amazing team.
Finally, our biggest debt of gratitude goes to our early backers, those of you who over a year ago put some money into this little black box. You will have your BRCKs soon, and we hope that they live up to your expectations. After all this time, I can say I’m probably more excited about getting them into your hands than you are in getting them!
]]>I’m used to talking about Ushahidi, and as all of you guys who frequently talk about your product or company know: it gets old spouting off the same old stuff over and over again. That’s why I’m excited about today and for being invited to this excellent conference, since I’ll be telling the backstory, the quirks and funny bits that got us to this point and made our Ushahidi culture what it is today.
This is my story of Ushahidi – Of a small organization that dislikes hierarchy and being told what we can’t do. One that questions everything, embraces innovative thinking, takes risks boldly, and sometimes learns the hard way that we’re human after all.
In January 2008 I spent a week watching news reports roll in from Kenya, frustrated. Frustrated because I had said for years that “technology helps us overcome inefficiencies”. Wasn’t the madness of Kenya, in it’s post-election violence throws, it’s lack of media coverage, and lack of real information just this? Why was I unable to do anything?
It turned out that I needed an idea, and for once I couldn’t come up with one on my own. That seed of an idea that grew into what you see today came from a simple bullet point by my friend and fellow blogger Ory Okolloh, asking if we could map reports of violence around the country. Thus Ushahidi was born.
I’m going to walk you through three defining moments for our organization, and our platform, not all of them pretty, but which make us who we are.
Ory Okolloh – lawyer, blogger and Kenyan political pundit
Juliana Rotich – renewable tech geek, blogger and database admin
David Kobia – developer and top Kenya forum webmaster
Daudi Were – blogger and web guy
Erik Hersman – Africa tech blogger, web guy
Others – a various cast of tech and non-tech people swarmed around the first Ushahidi deployment in Kenya, helping with small tasks and then disappearing.
Key points:
Thus, we felt we were the best placed to create an African open source platform for crowdsourcing information, our tech gift to the rest of the world.
We didn’t think of that at all actually. Instead we were madly Skyping, emailing, wireframing and coding over a 3 day period to get something up as quickly as possible.
We were brutal about every decision:
How our team came together, the way we made those initial decisions and how we interacted and leaned on what would become our community was defining. It still colors how we operate, our organizational communications and our community focus.
Lessons learned:
No background in open source projects meant that we had little experience in how to engage programmers, designers and the help needed to get things moved from that initial .NET build into an open source language. David and I were trying to decide what language to write this in, and we ended up picking PHP over Python since we thought more African programmers would be proficient in it.
David wasn’t a PHP guy (yet), so the early helpers, the volunteers like Jason Mule, Henry Addo and Chris Blow were a huge help in making the decision to go with the Kohana framework and a myriad of other decisions.
3 months later we announced v0.1 of “THE NEW AND REBUILT USHAHIDI PLATFORM!”
We were very excited, after all, wasn’t this the platform that would save the world? And we were ready to show the world just how it could be done. Gamely mounting our white steeds we charged into a deployment of Ushahidi in the troubled North Kivu region of the DR Congo.
Echoes of that failure splatting against the ground remind us still, today, of the complexities of the space we build software in. We learned from those lessons though, and Ory wrote a good blog post making sure that it was shared within and without.
Lessons learned:
Only a few months later, after the DRC debacle, we were rested and ready to fail again.
Al Jazeera had used the alpha version of the Ushahidi platform in Gaza, a group of organizations and individuals were deploying it to monitor the worlds biggest elections in Indian, and we had a number of groups in East Africa testing it out.
Our model was that we had a small team at Ushahidi whose job was to come up with and guide the core architecture of the platform. Volunteers also worked on core, but were also encouraged to extend the platform in their own ways. It was working very well, and still does.
We were ready to release the code publicly.
Before I say anything, let’s revisit that point earlier about none of us having eroded on an open source project before…
Preperations were made, blog posts were written, tweets were tweeted – and we got lambasted by one of the guys we respect a great deal in the open source community. Rabble called us out on all the things we did wong.
– The code repository was behind a user/password wall
– We werenâ€t available in the normal programmer channels like IRC
– Hard to plug into the rest of the dev community
Our team went to work, madly working over the next 12 hours to get our stuff straightened out. Finally I wrote another blog post, introducing our failephant mascot and apologizing for our ignorance and missteps.
Lessons Learned:
.
]]>We’ve learned that technology does overcome inefficiencies, but that it still takes people to make it happen.
We’ve learned that more people need to buck the status quo, that questioning everything makes us better.
We’ve learned that Africans can build world-class software, and to expect nothing less.