Main

March 18, 2007

The Data Gap: When The Tools Are There But The Data's Not

As readers of this blog know, data sets make my heart beat faster. Data sets that have been analyzed/visualized and made to tell a story are even better. The work being done by organizations like the Sunlight Foundation Labs (who are taking publicly available data sets about US congressional/political issues and making them do interesting things online) is tremendously exciting, and inspiring to many other organizations around the world. I spoke to Tate Hausman of dotOrganize earlier this week about the Integration Proclamation, a data sharing manifesto that he hopes will lead to real action on the part of vendors and open source communities. The goal of dotOrganize's latest project: best-practice open APIs ("application programming interface") for all data applications used in the non-profit sector. The end result, in an open API world, will be data that flows easily between applications, and
perhaps equally exciting, out of applications and into the world of data analysis.

It's easy to get excited about these moves towards a world where data is free (as in freedom) and accessible, and the tools to analyze it, like Swivel and Many Eyes, are available to anyone with a web connection. Where it all grinds to a screeching halt is when you get to places where there really isn't much data. In most of the world, governments don't make information publicly available, even if they're supposed to -- see fabulous FarmSubsidy.org's efforts to make EU governments cough up information on national distributions of Common Agricultural Policy funds -- that is, EU taxpayer money. Except in wonderfully transparent countries like Slovenia (surprise!), this is pulling teeth, and only works through an application of Freedom of Information Act laws, a lengthy and complicated process that can end in stalemates and government hedging or partial release of information.

But at least in this case, the information exists -- not with easy access, and not in nice XML-y formats that lend themselves to clear comparison across EU countries. Where it gets trickier is when you move to the parts of the world where my employer, the Open Society Institute, does a lot of work. In sub-Saharan Africa, for instance, data is rarely available from governments on many issues important to civil society -- educational budget distributions, public health budget distributions, etc. Forget about information on things like political contributions or, in many cases, basic public information like parliamentary voting records. Where information is available through a government, there may be little accountability on where it came from or its accuracy. What happens is that data sets need to be painstakingly created through the hard work of civil society monitoring groups, like the Public Service Accountability Monitor in Grahamstown, South Africa, which follows the activities of the government of the Eastern Cape, or IDASA, also in South Africa, which undertakes monitoring projects on a range of issues from local government accounability to distribution of national HIV/AIDS budgets on an extremely granular level, or Mzalendo, the online project run by Ory Okolloh and anonymous blogger M out of Kenya to track parliamentary activity in their country. But this can be expensive and/or time-consuming work, and fraught with difficulties -- not the least of which are that the people who are good at this kind of monitoring are not necessarily directly in touch with the advocacy groups that can use the data effectively to change policies. Even when serious data is available in the developing world, the skills to analyze and put it to compelling use are often spread very thinly on the ground.

My guess is that the data gap will continue to plague the developing world for years to come. A combination of factors are behind it -- government corruption and self-dealing are tremendous disincentives for transparency, as well as skill gaps, technology gaps, and perhaps most importantly, the lack of consistent demand for (and support for) this kind of transparency from international donor organizations.

February 21, 2006

San Francisco wrap-up: archives, Iran, mobile phones

While my adopted home town of Budapest lies buried in snow, I'm spending the next week at the original homestead in Seal Beach, California -- deep in the heart of what I am told is now referred to nationwide as "the O.C." ("Orange County", for those not in the know: it's a TV show).

This week is following on the heels of a week spent in San Francisco with the Information Program sub-board and staff, during which we criss-crossed the Bay Area several times to attend a series of meetings with companies, foundations, and organizations. Ethan Zuckerman has written long accounts of two of them, one a meeting with Brewster Kahle and Rick Prelinger of the Internet Archive, and the other a dinner we were lucky enough to have with dissident Iranian journalist and blogger Omid Memarian.

I also had a chance to sit down with Ben Rigby of MobileVoter, a San Francisco-based organization whos tagline says it all: "Voter Registration and Mobilisation via Text Messaging!" MobileVoter is doing some very innovative projects with mobile phones in the United States; one of the things they've looked at which I think is most intereseting is the use of the mobile phone in a social context, i.e., where users are in physical proximity to each other -- for instance, at rock concerts. They see the mobile phone as a way to capture the excitement and buzz of a live event -- at the moment its occurring, rather than counting on users to remember later on to log onto a website.

Ben is one of the leaders of the MobileActive movement, a group jumpstarted by an international meeting of activists and developers interested in the use of mobile phones held last September in Toronto. The meeting was organized by Green Media Toolshed and Aspiration Tech. Currently, the group maintains an active blog, trades project ideas, and forms partnerships around those projects.

I'll be writing more about mobile phones in the coming months, as this is a crucially important area for the developing and transitional countries that OSI works in. In the US, mobile phones are ubiquitous and highly personalized -- hence offering a different and more direct path to users than internet for advocates trying to get their messages across -- mobile phones in the developing world are useful for a different reason: often, they offer the only communications path in or out of a community. Further, with the help of tools like DialoguePalette, a soon-to-be released do-it-yourself Asterisk tool, voice navigation of information sources will be relatively simple; in regions where literacy is low, the ability to connect people with information via voice has become increasingly important, and increasingly viable.

February 12, 2006

Monitoring Public Health

I spent the past week in Istanbul with public health advocates from around the globe. They're a sharp and dedicated group of people who speak their own language: those of us from outside their world quickly learned to translate the alphabet soup of government agencies they regularly deal with, as well as the acronyms for the life-extending treatments and facilities that are at the center of their work: ARV's, the main treatment for PLWA's that are often acquired through CBO'swith support from by UNAIDS (translation: Anti-RetroVirals, People Living With AIDs, Community-Based Organizations, and UNAIDS: the Joint United Nations Program on HIV/AIDS). The group was not only focused on HIV/AIDS; representatives from public health groups focusing on Roma health, harm reduction, paliative care, marginalized populations, multi-drug resistant tuberculosis were all in evidence.

The topic for discussion during the three-day event was monitoring, something that donors and governments have increasingly thrown their weight behind. What became apparent to me, a newcomer to this field, is that monitoring is not a single activity, nor is there an agreed-upon definition of what monitoring groups actually do. The range of activities that are included under the heading "monitoring" include both quantitative and qualitative work. Human Rights Watch, for instance, for the most part produces work which is akin to top-quality investigative journalism; their reports are based on extensive interviews and are carefully fact-checked against a legal framework springing from the Universal Declaration on Human Rights, as well as the follow-up Covenant on Civil and Political Rights. Human Rights Watch runs an HIV/AIDS and human rights program, which documents human rights abuses related to the epidemic, and is very much in keeping with their interview-based methodology.

Other public health groups present were working on more quantitative monitoring projects, involving government finances, distribution of drugs, and use of treatment programs. The multitude of approaches and topics was dizzying, for someone coming from outside the public health world; more dizzying still was obvious importance of these efforts. The range was also broad: some groups were setting their own monitoring goals and creating their own methodologies to meet them, like Global Health Watch, while others, like IDASA in South Africa are monitoring by using internationally recognized methodologies, like UNAIDS' NASA (National AIDS Spending Assessment) framework.

Most interesting, though, were the questions that monitoring groups across the board wrestled with: when government is a partner in a monitoring project, do you trust their data? And how does a project managed by civil society maintain independence when the only way to crucial data sets is through a friendly government official? How to ensure quality data from partners working in disparate countries with, often, little in the way of communications technologies? Should monitoring projects only be undertaken by research universities, or can community-based monitoring be reliable? And a question that seemed to underride all the discussions I had: why monitor?

Without monitoring by external organizations, there's simply no way to hold governments to their promises made at either the international level (i.e., being a signatory to the Covenant on Civil and Political Rights) or at the national level (i.e., that a certain percentage of a national budget will be spent on the acquisition and distribution of anti-retroviral drugs). Further, monitoring needs to take place in order to prove the efficacy of experimental health programs; the harm reduction movement, which advocates for, among other things, the provision of clean needles and methadone treatment for drug addict, inevitably runs up against resistance from governments who might act as implementors. Without the proof of a harm reduction program's successes in holding down the rate of HIV transmission in a population, there is little argument to be made against skeptics.

However, the above arguments assume that monitoring is a *tactic* in a larger advocacy campaign; i.e., that the monitoring is simply a way to advance a broader goal. This is not always the case, it seems; some organizations monitor as a end in and of itself. In these cases, the monitoring projects tend to be more community-based, and are being undertaken as a way to both empower civil society, and to remind government that, in fact, they are accountable to their populations. This isn't to say that these kinds of projects don't also engage in advocacy, but rather that they see the monitoring itself as a crucial type of engagement.

As for me, I was interested in how these different projects were using online tools and forum to advocate, post-monitoring, both within their home countries, and on the international level. Several people told me that they considered monitoring "the easy part" (a serious assertion, given the complexity of the projects represented); the real challenge was taking the information and making a compelling argument gauged to the right people. As one participant said, "There's a huge difference between dissemination and campaigning." Indeed. Given the growing number of online projects aimed at supporting advocacy campaigns, the time seems ripe to bring the two populations together.

February 03, 2006

Blogging the African Union

Our friends at Fahamu have recently launched the AU Monitor, a blog which aims to cover the activities of the African Union for an African civil society audience. Fahamu's concern is that much of the African Union coverage is slanted towards the concerns of western donors and international NGOs, and the AU Monitor will seek to provide a different take on their activities, and on the interactions between African civil society and the AU.

Fahamu also publishes Pambazuka News, a well-written email newsletter on African social justice issues-- just this month, it became available in French as well.

January 29, 2006

Wireless for Everyone: A Handbook

Wireless access to the internet makes a lot of sense for much of the developing world: where fiber is controlled by government monopoly, or elderly infrastructure is simply incabaple of responding to the demands placed on it by new internet users, wireless hubs and mesh networking can greatly expand access to connectivity. This is because connectivity can be shared more easily through a wireless cloud than through cables, and can be expanded easily across signficant open distances or thorughout a building, city block, or even broader area.

Tomas Krag of wire.less.dk, along with a number of other organizations, has been looking at this problem for some time. His work, and the work of others, tackles the problem of creating appropriate wireless technology for the developing world, and seeding local expertise to deploy and maintain the technology -- as well as innovate where necessary for the specific environment. A range of projects are trying different methods: wire.less.dk's Wireless Roadshow works with local partners to set up test case wireless infrastructure to attract local policymakers' interest, while at the same time training local partners on the ins and outs of setting up networks. The Association for Progressive Communication is spearheading a collaborative training effort in Africa to run "wireless workshops" in four corners of the continent; their project trains up-and-coming wireless experts, providing them with both hands-on skills and training materials to take back to their home countries and pass the knowledge on. Other organizations including CSIR's Meraka Institute (South Africa), Inveneo (San Francicso), and Geekcorps(US/Canada/Mali) have worked on projects across the continent from setting up wireless mesh for community radio stations to helping to create wireless ISPs.

Tomas now writes of the release of "Wireless Networking in the Developing World: a practical guide to planning and building low-cost telecommunications infrastructure". This is great news for a number of reasons. First and foremost, the book is sorely needed by communities wishing to build their own infrastructure. Second, the book was written collaboratively, with a group of experts who have worked on the issue for some time, both in hands-on set-up and training. Third, the book is released under a Creative Commons attribution share-alike license, which means that it's free to download (via PDF), translate, improve, and redistribute (as long as you share any changes you make under the same license). Indeed, the authors have set up a wiki at the book's website so that others can make editorial suggestions. The book can also be ordered via a print-on-demand option, available through the book's website.

To all who were involved in this project, many thanks! It's a great achievement.

January 26, 2006

Dear Google: A suggestion for Summer of Code 2006

summerofcode.gif
Yesterday, I wrote about Google's Summer of Code 2005 as a darn fine way to connect young developers with open source projects and communities. And I still think so, although I have a suggestion for Google for Summer of Code 2006 (assuming they are, in fact, planning to run it again). To refresh, last year's Summer of Code matched up young developers with open source projects that had volunteered to mentor an intern. Young developers applied to the project they were interested in from the list of available mentors, were selected, and then rewarded with a summer of work on the project they chose and 5000 USD from Google for their time (500 of which went to the mentoring organization). Google had committed to funding up to 400 developers, which works out to a heck of a lot of money (2 million USD).

Not suprisingly, the Summer of Code site has a nifty little Google Map geolocating both the mentor projects and the participating students (see the world view above). Notice anything strange? Could it really be that there aren't any up-and-coming young open source developers in sub-saharan Africa, the Middle East/North Africa or Central Asia who would want to participate?

How odd.

(Actually, it appears from the map that two mentoring members of LispNYC, and one Google mentor are based in Kyrgyzstan and Kazakhstan. Right. Strangely, they didn't manage to rustle up any locals in either country for the project.)

Yes, I'm being snarky, but only because I know excellent open source developers in these regions, and it pains me to think that with a few well-placed emails to relevant listservs and some encouragement to truly internationalize from Google to the mentoring organizations, the map above might have looked different. 2 milion dollars is a lot of money to spend on encouraging open source developers, and it's a lot more money in the regions I mention than it is in Europe or the US. 4500 USD to a computer science student in Accra or Almaty could be a year's support -- or several years' school fees. Or it could allow the involvement of a number of students for a summer, instead of just one.

So my modest suggestion to Google is this: if you go ahead with Summer of Code 2006, reach out to the developer communities in less-developed regions, and encourage your mentoring organizations to view the world as flat. Building skills, confidence, and international ties between developer communities across the globe is a fabulous way to do no evil.

January 22, 2006

Usability and Open Source Software: Don't Give Up

If the Open Source community wishes to truly prosper and have their tools used by the general public, it is fundamentally necessary for them to recognize that the majority of the users will never know that they happened to invent a particularly clever algorithm for synchronizing the multi–threaded editing of their complex data structure. What the user will see — and what they’ll judge the project based on — is the user interface. If it’s inadequate, no one outside of other geeks will touch the program.
--Michelle Levesque, Fundamental issues with open source software development, First Monday April 2004

Oh, Michelle, you're so right. I know Michelle through her work as a lead developer of open source solutions at the CitizenLab in Toronto. So while searching around for information on usability and open source software, I was delighted to find her article in First Monday from a couple of years ago that touched so accurately on some of the problems open source software faces.

In my work at the Open Society Institute's Information Program, I've been involved in funding a number of open source software projects aimed at a range of civil society constituencies. The prettiest of the lot, by far, is LiveSupport, developed by the Media Development Loan Fund's CampWare project in Prague. LiveSupport is open source radio station management software "that provides live studio broadcast capabilities as well as remote automation in one integrated system". Not surprisingly, it seems to be enjoying fairly enthusiastic uptake -- part of this is due to the clear definition of the intended audience (community radio stations), as well as the strong network that MDLF has built up over the years. But I also think that the enthusiasm I've heard for the software is due to LiveSupport's excellent set of user interfaces. They're intuitive, restrained but colorful, and make you want to use the software. It shouldn't be a suprise, then, that CampWare worked with the Parson's School of Design on LiveSupport's look and layout.

In The Usability of Open Source Software, David M. Nichols and Michael B. Twidale argue that a number of factors contribute to the lack of focus on usability in open source software. The most obvious problem is the lack of involvement of usability experts in the OSS development process, but Nichols and Twidale point to social/cultural issues as well:

  • Developers, they point out, are not typical end users. What seems obvious to a developer is far from obvious to my mother when they look at the same software interface.

  • OSS development tends to happen when programmers are "scratching their own itch". Thus, if we accept the point above, functionality is usually prioritized over usability.

  • Open source software, the authors theorize, tends even more towards code bloat (and thus confusing and event competing functionality) than proprietary software. They explain further:

    Given the interests and incentives of developers, there is a strong incentive to add functionality and almost no incentive to delete functionality, especially as this can irritate the person who developed the functionality in question. Worse, given that peer esteem is a crucial incentive for participation, deletion of functionality in the interest of benefiting the end user creates a strong disincentive to future participation, perhaps considered worse than having one's code replaced by code that one's peers have deemed superior. The project maintainer, in order to keep volunteer participants happy, is likely to keep functionality even if it is confusing, and on receipt of two similar additional functionalities, keep both, creating options for the user of the software to configure the application to use the one that best fits their needs. In this way as many contributors as possible can gain clear credit for directly contributing to the application.
    Wisely, the authors note that "This suggested tendency to 'pork barrel' design compromise needs further study". Indeed.
  • I'd add one more issue to the usability question, based on my work with teams of developers in commercial software. Developers like to do their own thing, and many engage in volunteer OSS projects for that very reason: during the day they're developing banking software to make a living, and volunteering on a project at night or on the weekend provides a creative outlet. The whole point is not to have to code to someone else's spec.

Nichols and Twidale point to two further issues which, for those concerned about software usability, should be most troubling. The first is the thing we all know but ignore anyway: design for usability should take place in advance of any coding.. This is like commenting software code: you always think you can go back and do it later. The truth is, you can't. Or you can, but it'll take a lot of time, and be a big pain, and it still won't be as good as if you'd done it when you should have.

The second point is more subtle, but perhaps the most important: usability problems are more difficult to articulate than functionality problems, and are extremely difficult to distribute for correction to a far-flung group of developers. This is because usability issues are not necessarily neat packages, but may cut across the territory of several different developers, with potentially different styles or approaches.

In poking around online, it seems like there's a lot of writing on the issue of OSS usability, but not a lot of action aside from personal initiative (information architects or usability experts volunteering on OSS projects). One project based in Germany, Open Usability provides an online matchmaking service for usability experts and open source projects. Currently OU has more than 100 open source projects registered looking for usability expertise -- but far too few usability experts signing up on the other side.

Aspiration, one of my favorite techy NGOs, organized a FLOSS Usability sprint last February and a second one in August with Blue Oxen Associates. The August meeting helped to defined the concept of ExtremeUsability, and applied it to three civil society-focused open source projects: Social Source Commons, CiviCRM, and Hallway. I'll be interested in finding out how that experience has shaped the evolution of each of those projects.

No big conclusions here, except that this is an area which clearly needs inventive solutions. It seems that there's a problem from both sides -- somehow, usability experts and information architects need to be pulled into open source projects, and leaders of open source projects need to begin with usability design rather than tacking it on at the end of a project, if at all. I'd certainly welcome thoughts on ways to approach this (and on other projects that are addressing the issue).

January 19, 2006

The nuts and bolts of Africa Source II

I've been posting over the past few days about my experiences in Uganda at Africa Source II, but haven't given a very good overview of what the event actually is. So:

You wouldn't normally expect to learn about open source software, organizational technology needs, or the finer points of information strategies for advocacy groups while sitting on the shores of Lake Victoria in Uganda. Nor would you normally hope to bring 140 people from all over Africa to Ssese Island, a spot known for its natural beauty, curving white beaches, warm afternoons, and slow pace of life, and expect them to remain excited about those topics for seven days running. But it happened, and this, in a nutshell, is the magic of the Source Camp series that the Tactical Technology Collective has led over the past three years.

The recipe involves a remote and beautiful locale, a group of dedicated and time-tested facilitators, a bunch of refurbished computers running Ubuntu (a Debian-based Linux distribution), and a crush of “technology intermediaries” there to improve their skills. These are not the hard-core geek types that scare users away when they earnestly and helpfully try to explain why Asynchronous JavaScript And XML is really going to rock their world; rather, these are the peacemakers who spend much of their professional (and often personal) lives brokering a gentle understanding between entirely non-technical end users and the technology tools that they either need to use to get their jobs done, or the technology tools they should use to do their jobs better. Africa Source II's intermediaries work in civil society and education, and so their target users tend to be students, teachers, activists, and non-profit staff.

The recipe for a Source Camp is surprisingly successful, and seems to resist derailment by adverse conditions. At Africa Source II, participants traveled over rough roads from Kampala to the island, slept in tents through equatorial rainstorms, and suffered a tragic few days without Nescafe. At the end of the week, the participants left regretfully, hugging each other goodbye, planning to stay in touch, collaborate on projects, post to the mailing list. While people looked forward to returning to their families, comfortable beds, and daily routine, the palpable enthusiasm for their experience was the overriding emotion.

The theory behind the Source Camps' anti-conference approach focuses on building community – that is, on making tangible in a real-time setting the values espoused both by open source software communities and civil society networks. The Source Camps operate on the principle that everyone has something to contribute, and that knowledge is best arrived at through group exploration. Where open source software can be produced in the virtual commons, the Source Camps bring the commons to life as a method of learning.

Jamais Cascio pondered on Worldchanging earlier this week whether the lack of good usability in much open source software would trump its potential as a leap-frog technology for the developing world. I think there is much to be done in terms of usability on OSS (and more on that in a later post), but for the present, events like Africa Source seem to be the best solution for pushing useage forward. These key intermediaries leave with two very important assets: the confidence that comes with hands-on familiarity and a network of other practioners to whom they can turn for advice. The beauty of the Source Camp model is that is brings out each person's strengths -- participants leave knowing who in the group to turn to for expertise on wireless set-ups, on managing bandwidth, on configuring a server.

In terms of nuts and bolts, Africa Source II runs on a split schedule. Mornings were given over to one of three tracks that participants had signed up for on registering. These were:


  • NGO Migration: how to migrate an NGO office using proprietary software over to an entirely open source set-up. This involves desktop applications, OSS operating systems, and server software.

  • Education Migration: this is similar to NGO migration, but focused on schools and resource centers –so there was an emphasis on linux distributions aimed at education, like OpenLabs (used by the model SchoolNet Namibia project) and the forthcoming Edubuntu, an Ubuntu distro coming out of Mark Shuttleworth's Cannonical.

  • Information Handling and Advocacy: this track focused on using open source software within the context of an advocacy campaign. They looked at blogs, wikis, content management systems, and communications technologies like cellphones, podcasts, and community radio management systems.

Morning sessions were followed by a group lunch, and then by a two-hour break. After the break, the group reconvened most days for skillshares. Marek Tuszynski of Tactical Tech descibes them on the Africa Source II wiki like this:

The Africa Source 2 Skillshare will provide a setting for participants to teach their peers, drawing from their areas of expertise and passion. "Skill" will be broadly interpreted, spanning not only systems and software but also strategic know-how, from fundrising to process models to all manner of production techniques. The focus will be on demonstrating "how to" and "how it works" in 30-minute to 1-hour time slots, with audiences ranging from 1 to 10 people.

The afternoon ended fairly late each day (between 7 and 8), and was followed by a group dinner, and an evening activity: music, dancing, talent show, and so on. The best evening activity, by my count, was provided by the staff of the resort: each evening they hauled a pile of firewood down to the beach for a bonfire, which burned late into the night. After dinner, many people brought their chairs down to the circle on the sand, and sat chatting late into the night, nursing bottles Uganda's home-brewed Bell lager.

The Africa Source II blog, a day-by-day account of the camp by Frederick Noronha and others, is here.


January 17, 2006

Infrastructure, Part II: Getting Things Done in Africa

Just back from Uganda, I'm pondering a common complaint of Westerners visiting the continent: "It takes so long to get anything done in Africa." It's not revolutionary to point to Africa's infrastructure, but having just lost a day of work to infrastructure issues, it's interesting to illustrate the small but thwarting fall-out of poor roads, irregular power and limited connectivity.

I've had the past week mostly off from my trusty IBM x40 because bandwidth at Africa Source II was very, very scarce. The inimitable Tomas Krag of wire.less.dk led a team which expertly managed our 3 GB VSAT download cap and our ad-hoc wireless infrastructure, but with 140 people on that system for a week, resources were inevitably stretched; priority was given to teaching needs necessary for the success of the workshops at the camp. Still, as I planned my departure from Kalangala on Sunday night, I noted that my laptop's battery was nearly empty. Back in my room, I plugged my computer into the single wall socket as I packed, and then noticed that in fact, it wasn't charging. A flip of the light switch revealed that the electricity was off again, and the proprietor of my little hotel was nowhere to be found. I thought of leaving the laptop plugged in overnight, in the hopes that the power would come back on, but because the wall socket had obviously been roughed up over its lifetime (probably a case of multiple re-use in multiple buildings), my plug didn't fit firmly into the socket...and so I would have had to keep a toe on the plug overnight to make sure it stayed in contact with the current. But as the electricity hadn't come back on previous nights, the nocturnal gymnastics seemed optimistic at best. (Note to travelers: you'll never regret having a small roll of duct tape on hand.)

So I gave up: I would travel back from Uganda without my laptop charged. This may sound unproblematic, but as someone who spends a good amount of time on planes and in airports, I look forward to the uninterrupted time travel opens for reading emails and writing more thoughtfully than a day at the office might allow. So it was inconvenient -- email responses would be later, fewer of the backlog of Africa Source II blog posts would be written, etc.

Instead, I turned my attention to the pile of printed reading I had hauled to Uganda in my backpack. Hoping that I'd have a chance to charge my laptop at the airport in Kampala or Nairobi, I thought I could use the seven-hour trip we took from the island to the airport for getting through this pile of reading. Of course, I wasn't thinking about the road. And indeed, when driving down a road like the one between Kalangala and Kampala, one can't do much beyond gazing out the window: it's far too bouncy to read, too loud to talk to your companions in any meaningful way, and in some ways, too bombastic an experience to even think very clearly. Further, you emerge from a drive like that tired and dusty (if somewhat exhilarated), certainly not in the most propitious mood to read case studies of ICT use in civil society groups.

Once in Kampala, we arrived at the offices of WOUGNET, our local host. They had also had their power cut. Dorothy Okello, WOUGNET's executive director, told us with a familiar mix of good humor and frustration that she had been trying since Friday both to sort out the mix-up with their power bill and to think of things for her office staff to do without their computers. Dorothy herself was working off a dial-up line on her laptop, which she had been charging at home every night. Of course, laptops are a rarity in African offices, and the rest of her staff were working on refurbished desktop PCs. Part of WOUGNET's ramping-up plan, she said as an aside, was setting aside funds to buy a generator so that future power cuts wouldn't cause their work to grind to a halt.

Obviously, many other factors figure into the difficulty of working in Africa –petty corruption and health problems are two other big issues that ordinary people face regularly. But infrastructure problems continue to thwart many on the most prosaic, day-to-day level. Hats off to those, like WOUGNET, who plan for the inevitable and keep on going.

O Captain! My Captain! Driving Uganda with Ronnie

Last Saturday morning, Stephanie Hankey and I were woken at 3:45 by Ronnie, our guide who had materialized from thin air, knocking gently on our doors at the Hotel Niagra. He advised us that he'd be down at the car waiting, and when we staggered out of the Niagra's perpetual din of CNN and florescent lighting, he loaded our bags, let us into the back seat of the three-row minivan, and set off for the ferry dock. The ferry would take us across Lake Victoria to Ssese Island where Africa Source II, at Kalangala, awaited us.

ronnie.gif

The first part of the ride was fairly smooth; we bounced over mostly-paved roads leading out of Kampala and crossed the equator as I dozed and Stephanie chatted with Ronnie in the front. After several hours, we stopped to stretch our legs, and Ronnie advised me to move up to the second row; it's better company, he observed, and besides, I wouldn't be sleeping much over the next stretch of road.

Indeed, Ronnie (in all things) knew what he was talking about. We turned off the main bouncy road onto the ferry road. This, I assumed, was a relatively short track that would take us to the ferry dock. As it turned out, it was a relatively long track that took us to the ferry dock, and was exponentially bouncier than the first road. Stephanie and I strapped ourselves in and held on as Ronnie expertly navigated the rutted dirt road, avoiding holes of axle-breaking depth by using the whole width of track freed from the forests on either side. Watching Ronnie take on this road was incredible. He threw his whole frame into wrenching the minivan across boulders and out of potholes that threatened to tip us; he managed to carry on a charming conversation while driving expertly on the balancing point of a ditch's lip. And, thanks to his speed and care, we arrived at the ferry an hour early – no minor point for travelers aiming to catch the first of the day's three 10-car ferries, where first-come first-serve is not always the rule: cars behind us paid the captain for a prime spot up front. This turned out to be a wise move on their part, as the final vehicle on the ferry – a group transport with several dozen people clinging to the top and sides – was balanced precariously on the tipped-up loading ramp of the ferry barge as we pulled away from the dock. Obviously, litigation is not an issue the government of Uganda spends a lot of time worrying about.

The hour-long ferry ride provided Ronnie (and us) with napping time. Ronnie tipped his hat over his eyes, wished us a good rest, and promptly fell asleep for the duration of the trip. Once the ferry docked, we were off again, this time over an even rougher road and moving, it seemed, faster; Ronnie saw the gathering storm on the horizon, and wanted to get us over the rural track to Kalangala before the full force of the deluge hit. We spent much of the next hour airborne, a necessity given the depth of the holes in the road.

By the time we arrived at the camp, I was starting to fully appreciate why a professional driver is required to cross much of Africa – and why driving in Africa is not at all "unskilled labor".. Literally, had I been driving the road between the ferry dock and Kalangala, it would have taken at least four times as long – had we arrived at all. Ronnie managed to guide the diesel minivan with speed, precision, and relative safety over nearly impossible terrain, and arrived smiling (but tired).

Transport in Africa is a crippling problem; despite the enormous amounts of development aid poured into the continent since the 1960's, the continent's infrastructure is still nearly non-existent in many places. Major cities I've seen in Africa (Accra, Kampala, Windhoek, Jo-burg, and Capetown) tend to have mostly paved main roads at least in their commercial centers: the road between Entebbe airport, where we landed, and the outskirts of Kampala, where we slept, was quite decent. But as soon as we left this artery, things went rapidly downhill. Similarly, Ghana's capital Accra has decent roads (albeit bordered by open sewers) around the commercial center and heading out to the airport, but turn to rutted dirt and mud the moment one turns off into more residential areas.

Given this, it's easy to see why people like Ronnie (who is actually a tour guide and environmental expert, not a driver by trade) are so important, and so in demand: his combination of calm, derring-do, good cheer, and lightening-fast decision-making are perfect for getting a van full of clueless people from A to B. The tragedy, of course, is that were Uganda's road's better, Ronnie might be better rewarded by putting those skills to use in building his businesses in tourism and environmental work, instead of shuttling people like me around the country because we can't do it ourselves.

PS: The title refers to "O Captain! My Captain!", a poem by Walt Whitman. It opens:

O Captain my Captain! our fearful trip is done,
The ship has weathered every rack, the prize we sought is won,
The port is near, the bells I hear, the people all exulting,
While follow eyes the steady keel, the vessel grim and daring...

The poem goes on to describe the death of a ship's captain at the end of a long and terrible journal, which fortunately is not part of my Ugandan narrative.

January 08, 2006

Africa Source 2: The Road to Kalangala

Tomorrow morning I'm heading off to Uganda to attend Africa Source 2, the fourth in a series of week-long technology workshops for NGOs masterminded by the Tactical Technology Collective. If AS2 is anything like its predecessors (India 2005, Namibia 2004, Croatia 2003), I'm expecting the next week will be a mix of sixth grade Scout Camp, a super-condensed semester at a tech university where the teachers are the leaders in their respective fields (and are relentlessly charming to boot), and a cocktail party with 120 very engaging guests, mostly from across Africa. I'm not at all sorry to be piling my malaria pills, international yellow fever innoculatoin certification, raincoat, sandals, sundresses, and bug repellent into a duffel tonight. Bet you wish you were going.

Aside from meeting a whole lot of interesting people and playing around with some new open source tools in the coming week, I'm also looking forward to learning more about Uganda. Looking at a map of the country, it strikes me how many challenging neighbors Uganda has: a landlocked country, Uganda is surrounded by Sudan, DRC, Rwanda, Tanzania, and Kenya. I currently live in a landlocked country surrounded by historically challenging neighbors: Hungary is bordered by Romania, Ukraine, Slovakia, Austria, Slovenia and Serbia. A country landlocked by many neighbors is inevitably a difficult place to be; you're forever looking over your shoulder at the strife brewing on the other side of the border checkpoint. Or, in Uganda's case, in the northern regions of the country as well, where the government's struggle against the Lord's Resistance Army drags on as one of Africa's longest-running conflicts. Other things I know about Uganda are few: the country voted in July last year for a multi-party system, and a presidential election is scheduled for Februrary 23rd. The incumbent president, Yoweri Museveni of the National Resistance Movement, seems to be leading in the polls; he is trailed by the Forum for Democratic Change leader, Kizza Besigye. Not so surprising that Besigye is behind; he's spent most of the last two months in a maximum-security prison on charges of rape and treason. Not surprisingly, his supporters call the charges politically motivated.

These are the kinds of things I know about Uganda from the news. However, two recent reads have cautioned me to, well, write about something else, something below the usual radar of tragedy, war, and corruption. The first, which I came across yesterday via the Velveteen Rabbi, is an intended-to-be-short-lived blog by Teju Cole, a Nigerian American currently visiting family and friends in Africa. The blog itself is beautiful and spare in design, image, and prose. Teju wrote this a few days back:

The most important thing to know about Africa is that it is normal. But no one who depends on American media for information can come away with this impression.

The most powerful lies can be those of omission, and this is the kind of lie the West tells against Africa every day. Africa is all game reserves and refugee camps. When last was a glittering African financial center- of which there are many- broadcast on American television? When was the last time you saw images of a middle-class African family at a shopping mall in their country, or of young people in a university, or in a restaurant, or on a normal city street?

And a few days before that, I came across (via Ethan Zuckerman) a piece in Granta by Binyavanga Wainaina called "How to Write About Africa". The article begins:

Never have a picture of a well-adjusted African on the cover of your book, or in it, unless that African has won the Nobel Prize. An AK-47, prominent ribs, naked breasts: use these.

Read it, it's funny. And cringe-making, if you've ever written a word about a place that you feel is more exotic that your usual locale.

I'm going to try and do some writing from Uganda, depending on connectivity and time. I'll be writing mostly about the technology workshop I'm at and the people I meet there, which I think is both fascinating and admirably normal -- but I'll be keeping the admonishments of Cole and Wainaina in mind as I do.