Tuesday, March 8, 2011

Fabfi 4.0 Progress Report

It's been two months to the day since the beginning of my follow-up visit to the Fablab in Nairobi, and high time for a little status update, first about the networks themselves, and then about what makes them tick

The Networks

As of today, there are three Fabfi networks under development in Kenya:
  • Mountain View Estates / Kangemi
  • Njabini
  • ARO Fablab, near Bondo
All three networks are operated by local residents, and each has a unique business model.

Mountain View / Kangemi

While the latter two networks above are still pre-production, the Mt. View network has been in full production for about two months. Mt. View is the closest to US-Style commercial model where the typical user pays a subscription fee to receive unlimited access for a month at a predetermined speed.

The network currently operates with 23 nodes across 9 distribution points, providing network coverage to between 60 and 75 households (green circles are "indoor" quality coverage while purple ones are "outdoor" quality): 

After some trial-and-error with power solutions, the entire network is also now protected by 2-6 hours of expandable battery backup per node, keeping the internet available even in the event of a total blackout (which are really frequent, wouldn't ya know...)

 A few weeks ago, the network made its first leap into Kangemi District, which is a considerably more "underserved" area than Mountain View.   As the team begins to automate the monitoring and management of existing infrastructure over the next few weeks, they will be looking for locations to expand on the Kangemi side of the wall.

Of the 9 distribution points currently operating, 6 were added during the months of January and February, with word-of-mouth rapidly turning up residents eager to host new nodes.  We now have at least one subscriber for every distribution point, and John and Nick have been out and about actively recruiting more.  

An unexpected challenge in building a subscriber base has been structuring our demo program.  As you may have seen on the website, the team is offering one week free to new subscribers, however the original program of "Try it for a week, then pay"  was exploited almost immediately by groups of people calling for a user account, sharing it for a week, then calling for a new one the next week.  As a result, the offer has been changed such that your first "month" of  subscription comes with an extra week subscription bonus.

Surprisingly, we have seen very little discovery of the limited free service option.  This is the option where you can sign up and have a small amount of access per day (15min or 15MB, whichever comes first).  This option has not been aggressively marketed, but have had fewer people than expected asking about it given that it's mentioned only one click in from the main splash page. I expect we'll see a lot more of this use once users can sign themselves up from a web form on the splash page. 


As you may have read in earlier posts, I spent a significant amount of time in Njabini working with local Entrepreneur, Peter Murimi, and the Flying Kites orphanage to get a network up there.

One of the biggest challenges in his area is the mobile dongles are the only connectivity method.  In this network, the pricing structure of the mobile dongles informs a business model where Peter, the local operator can buy bulk packages from the mobile provider and share those packages among local users who buy smaller units at a price below the Safaricom rates. This is partially enabled by the use of an aggressive web-caching system that runs locally to save bits. 

While the necessity of pay-per-bit (as opposed to pay per unit of capacity) informed a solid business model, the resource constraint immediately caused us to pause and rethink our rollout strategy. In this cost scenario system overhead equates directly to cost so Tom is busy working out some proper performance monitoring software that will help us trim the fat before we go live.

The Nairobi team will be visiting Njabini this weekend to make some modifications and teach some network management, after which I expect we'll see a lot more activity out of the sit.

ARO Fablab:

On the outskirts of Bondo-town and truly off the grid, the ARO Fablab is perhaps the most extreme location for a Fabfi deploy.  Our friend Boris is out there working with them now.  Once they're consistently online the global Fabfi crew can log in and provide remote support. I received mail from the lab Manager today saying:

"Tom from Nairobi came over to assist us complete our FabFi configurations. We successfully configured the headnode and its tested and working fine. We tried to flash the pico devices with the new firmware but did not succeed so far, the old versions we did while I was in Nairobi works well.

We were planning to connect the nearby high schools and also to the cyber cafes at the nearby market centre. This would assist us in paying for the internet connection and providing readily access to the internet for school students and their teachers."

The Tech

While we like to give the impression that building fabfi consists of simply pointing a couple wifi routers at each other and calling it a day, there's an enormous amount of development that goes into creating that illusion.  The current fabfi system does first-order integration with dozens of open-source projects, including:
And with every day we're adding new tweaks to improve stability and performance that require testing in the UoN Fablab development network.


The move to version 4.0 prompted the switch to all new hardware, while all the new routers are now working very well, we're still cleaning up the prototype reflector feeds for mass consumption.  Info on the process and the designs can be found in the RF section of the wiki.

System Management

Over the last couple of months, the most development has gone into ways of keeping track of nodes and users.  We have a few things working nicely now, including a remotely hosted splash page for user logins, a live network map, and a web form that makes .kml for Google Earth or Maps showing all the important data for each node.

Tom is actively developing Nagios-based service alerting and bandwidth monitoring tools that we should be seeing in the next couple of weeks.  I also hear rumor that he wants to build a web form to let users sign themselves up in the fablab (yes, please!).


Today (fittingly at rev. 400) I finally completed the core wiki for Fabfi 4.0, and updated the fabfi site to point to the new content. We also finally have a complete site for JoinAfrica Kenya where users can learn about their local networks and get online.

The Connections

One of the most exciting parts of what's going on in Kenya right now is networking of the social variety.  When Paul came to me last spring and said "I want to find a sustainable way to get more people online in Africa," my biggest concerns were not technical (though I had a few of those) but social.  What was the use case for the internet in rural Kenya?  Who knows how to operate computers competently?  At least the latter is something that even the most technologically advanced societies on earth still wrestle with.  Sustainable internet expansion is not simply an economic issue but one of knowledge transfer.  You need to carry the knowledge of how to use the tool with the tool.
In Kenya, the UoN Fablab team is now not only expanding internet networks, but creating a network of operators and supporters that share their aims and their skills. They are actively training the operators of the two other networks, as well as working with organizations like KENET and local bandwidth providers to create meaningful partnerships.

Meanwhile operators like Peter from Njabini are setting an example of what could be the future of rural and urban-fringe networking.  By combining technical knowledge from the Fabfi team with his local knowledge of community needs and supporters, guys like Peter are key to bridging the gap between the available services and their utility to local residents. Personally, I can't wait to see the results...

Also Special Thanks To...

About a million people, but this project would especially not be possible without contributions from these major supporters and virtual team members:
  • Paul English
  • Kamau Gachigi, and the UoN Science and Technology Park
  • Amy Sun and Sherry Lassiter of FabFolk, Inc.
  • Antoine VanGelder of Afrimesh
  • MIT Center for Bits and Atoms
  • Anjali Sastry, Shiba nemat-Nasser and Nipun Virmani from MIT Sloan
  • Kerry Lynn
  • Riyaz Bachani of Wananchi Online
  • Meoli Kashorda and KENET
  • Christiaan Adams from Google Earth
  • Pete Szolovits (for letting Keith spend so much time on this project)
You all rock, and we hope you'll stay with us as we try to grow the networks described above.


  1. Not sure if it is helpful, but you could, beside the local proxy, also use a remove proxy, so you can force gzip/deflate compression of the http content even if the original host doesn't support it. This way you can squeeze even more bytes through the limited internet connection. I see squid has a module for gzip.