Well, you might not have suspected it from my blogposts of late, but I AM actually here in Nepal to work. Since I don’t read much on the net about the inner workings of the XO deployments, I thought it would be nice to spend some brainpower and time on our rapidly expanding deployment-NGO-startup. Consider this an introductinary post. I’m a sucker for framing, so the following will perhaps be a bit to general for the acquired taste you undoubtedly have, but subsequent posts will bite more into the flesh. Is the plan…
So what did we do again? Giving cute little laptops to cute little kids. Not all the time do we perform that tangible act of course. Until now we only distributed 135 of them to two pilot schools. When I came to Nepal in the end of Feb we didn’t even have those yet. We had about five at the office in total. And it was a hassle to get your hands on one to test stuff.
There was less to test of course. On the productive side, there were only three activity developers, one graphic designer, a Bryan, one curriculum expert and a freshly hired admin and we didn’t have to worry at all about networking and server interoperability.
After three quarters of a year we tripled in size. We’ve got 6 activity developers (and we’re looking to hire two more), two graphic designers, two curriculum experts, a network guy, two admins, still that Bryan, a power guy, four volunteers, a me, a guru (not the Indian kind though, we’re not that kind of organisation; more the “in the old days we cut our bytes out of the bones of buffalo’s” kind), and there’s no sign of saturation.
So yea, we’re a startup. Operating in uncharted territory. When was the last wave of laptop deployments in poor rural area’s? Before the AI winter? No there was none I tell you. So requirements change all the time; the mess we need to control grows exponentially.
And time is never on our side. In my perception the last couple of months the biggest struggle was in content creation. Perhaps because I was very involved in it. We write activities to compliment the Nepali curriculum and it was a big struggle for us to churn out enough of them to satisfy the hunger of classes 2 and 6; the ones we initially service. How should the activities look like? Where do you pin the needle between quality and quantity? What’s the workflow?
But now we’re starting to get some rhythm going. We ended up creating a framework for every activity; with introduction, notes for the teacher, a theoretical part and a practice part. The activities are now properly versioned, packing is automatic. Still we’re struggling with a number of aspects, but it almost seems like we know what we’re doing!
Now the centre of mayhem-gravity has moved towards deployment. Or perhaps it’s just that I’m mostly involved in that atm . In spring we’re going to expand our operation manifold. Nothing is certain, but we’re going to deploy thousands of XO’s. Today I heard the number of around 7000 (it’s a fuzzy number-type), perhaps more, perhaps much less. Nothing is certain as of yet, but that number is gonna be a hell of a lot bigger than 135.
All those XO’s need to be connected to schoolservers. All those servers need to be connected to the internet. All that equipment needs power! The XO’s need to be updated in batch and reliably. Teachers need to be trained. Wireless networks need to be installed. XO’s need to be repaired. And all this needs to be done in remote area’s in perhaps the most mounteneous (is that a word, and if so, is it spelt right?) country of the world, with inherent massive logistics problems. It’s a huge task for a small organisation as ours, and we’re working hard to get up to speed.
Especially the scale scares me. Imagine you accidentally put on some wrong firmware version, and you brick 7000 XO’s all over Nepal, without experienced on-site help… you, ehh.. well I at least would disconnect from the internet and run into the nearest pub to.. ehh.. reassess.
Baby steps.. First things first. One thing we need is a reliable way to update general XO stuff. Say we hack Sugar to force activity updates from only the schoolserver (check) we should have a reliable way to update the XO’s. So I figured using olpc-update from our schoolservers. A good suggestion from the olpc-devel list was to set up pilgrim to prepare for a sane way to service the update script, with the added benefit that we automate our custom XO build-process. Which makes perfect sense of course.
That’s a nice rounded task. I can handle that. Baby steps…