A BRCK Journey

We’re about to ship our first orders of BRCKs next week, on July 17th.

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.

A BRCK Journey - how it was made

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.

the Journey

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.

My initial notes on the BRCK in the airplane, thinking through what it should be, basic features, and products I liked.

My initial notes on the BRCK in the airplane, thinking through what it should be, basic features, and products I liked.

Initial BRCK idea, drawn in my notebook in November 2011.  You can tell I hadn't a clue as to where things should go yet.

Initial BRCK sketch, drawn in my notebook in November 2011. You can tell I hadn’t a clue as to where things should go yet, it was just barebones features and simplicity was key.

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.

An Early BRCK Prototype from mid- 2012

An Early BRCK Prototype from mid- 2012

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.

From Prototype to Production

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.

Rachel running on a BRCK in Uganda, by Johnny Long

Rachel running on a BRCK in Uganda, by Johnny Long (more on their Education page).

We’re finally there, after many, many months.

Some Thanks

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! :)

Making Ushahidi

[Below is my Tech4Africa talk, given today in Johannesburg, South Africa, titled “How we built Ushahidi, w]

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.

1. Let’s look at the ad hoc cast that got it started:

The Ushahidi Team - circa Jan 2008

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:

  • You’ll notice that there was not a single one of us who had any humanitarian experience
  • None of us had taken part in any open source project. (v1 was built in .NET)
  • Most of us were self-employed, running our own businesses or consulting, and didn’t like working for big companies.
  • The only common denominators that we shared was our love of our home; Kenya, and the ability to blog.

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:

  • If it wasn’t absolutely necessary, throw it out.
  • Pick a name, any name, we don’t care if non-Kenyans can’t say it, just get a domain up asap
  • Launch this app, it’s functional, we’ll fix bugs and features on the fly
  • No one has a short code for us yet? Screw it, it’s not worth waiting, we’ll get one eventually.
  • Money, what’s that for? Media budgets are overrated, we’ll blog it.
  • We don’t have a logo. Oh well… Launch already!

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:

  • This taught us to keep a shallow and wide decision-making structure so that everyone had access to all the information about ops or platform that they desired. Anyone was empowered to make decisions, since thy understood the macro-game.
  • Release code early, it’s better to have it out and being tested and worked on in the real world, than hidden away in a sandbox somewhere.
  • If you want it done, build it yourself, don’t put it off onto another team member.
  • Community = success
  • No money, no worries. Build good stuff and good stuff happens, money follows.

2. Technology is only a tool

allocation

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:

  • Technology is only 10% of the solution needed. The rest is administration and messaging.
  • Stick to what you do well. Our team is built to build software, not be a deploying organization
  • (caveat! We do help in deploying rarely, like Haiti and Kenya, but we now pass those off, or partner)
  • Own your failures publicly, learn from them.

3. Enter the failephant!

The Ushahidi Failephant

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:

  • Listen and apply that listening to real changes
  • Again, own your failures. Fix things that are wrong.
  • It’s okay to think different in how you execute on a project as long as you don’t stray from the spirit of your community and self
  • .

Finally, I’ll end with this.

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.