« December 2005 | Main | February 2006 »
|
Southern California doesn't usually yield quite such varied reports, but just recently Dad started seeing a blue heron on near the flood control channel that runs up from Seal Beach towards Long Beach. He managed to snap a picture of it perched on the peak of an aluminum-roofed building, and sent it on to me. Beautiful bird, isn't it?
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.
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.
I had a long chat with Ellen Reitmeyer of OpenUsabilty.org on Monday. Ellen's a usability designer, based in Berlin, and was involved in founding OpenUsability because of her company's usability design work on the KDE project. (KDE is a graphical desktop interface for Linux and Unix environments.)
What they noticed were that many open source projects could use the attention that they gave to KDE, but that there was little interaction between the two communities. So OpenUsability was set up as a matchmaker service for designers and open source projects to find each other. The problem that Ellen points to now is not the lack of interest of the open source community (more than 100 projects have signed up on OpenUsability, looking for help), but the too few usability designers. Currently, most of the designers listing themselves on the site are based in Germany (although the site is set up in English), as Ellen is. Most of them, she said, she knows personally.
Working on usabliity on open source projects is not easy, as I wrote about a couple of days ago. Ellen echoed several points, including, perhaps most importantly, the social engineering that goes into implementing usability suggestions from designers. "You need to have a personal relationship with a key person in the development group," Ellen said, which of course means more time and effort on the part of scarce designers. She also emphasized the problem of finding developers in open source projects who are interested in revising design components, rather than adding new functionality to a project.
We ended up talking about ways to get more usability expertise involved in open source projects. After batting around the idea of raiding design schools during the summertime, or running competitions to encourage usablity experts to submit projects, Ellen made what sounded to me like a brilliant suggestion: why not run something like Google's Summer of Code, but for usabliity/design students. The Summer of Code 2005 was a project I missed at the time, but which I love in retrospect:
The Summer of Code is a program in which student developers are provided with a stipend to create new open source programs or to help currently established projects. Google will be working with a variety of open source, free software and technology related groups to identify and fund up to 400 projects over a 3 month time span. Since Google couldn't possibly mentor 400 people working on disparate projects, we felt it would be wise to spread the work out.
Essentially, Google wanted to mentor new open source developers, and it put up 5000 USD a head for the summer for students to work on established open source projects. Lovely. They're planning to do it again in 2006.
Back to usability: Ellen posited that an incentivized summer program like Summer of Code (Summer of Usabliity doesn't really have the same snappy ring, unfortunately) in which usability design students could be matched up with open source projects would do both sides a world of good. She suggested that open source projects could define part of projects that particularly need usability help, and attach a student designer to that part of the development team - thus fostering a relationship within the group, and producing specific improvements by the end of the summer.
I like this idea a lot. I wonder if Google wants to expand its Summer programs to other areas?
|
Seems that the geolocation fun is not going to stop anytime soon. This morning I came across ClustrMaps (beta), a service which maps the visitors to your website. You get a little thumbnail map of world (like the one at right), which clicks through to a bigger map on ClustrMaps' servers; you can also zoom into continent level on the big map. At a glance, you can see the geographical distribution of your readers. Neat-o. The problem right now, as you can see with the image at right, is that a site with frequent visitors from around the world quickly becomes a big red blob in the thumbnail. I'm sure they're sort that out post-beta, though.
The reason I like this tool is because of its useful application to civil society networks. One of the advantages of using onling tools to organize advocacy campaigns is encouraging a sense of broad solidarity around an issue, be it land mine bans, tobacco control, or anti-corruption. More and more international advocacy movements are trying to find ways to demonstrate their reach to their existing constituency, to policy-makers, and to funders who support their work. Simple tools like ClustrMaps provide an un-scientific but still compelling visual for an advocacy site looking to demonstrate its global appeal.
ClustrMaps is free for sites with fewer than 1000 visitors a day, and the company provides a premium product for those with higher traffic.
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
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:
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.
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).
Because OSI program staff (which I am) tend to travel often, and sometimes to less-than-stable parts of the world, our employer goes to a lot of trouble to make sure we don't run into trouble. We get alerts about state-department travel warnings, and internal messages from executive management telling us where we should or shouldn't go. Which is all very helpful, because showing up in a country during a plague or revolution always makes one feel rather stupid, and worries the parents to boot.
Additionally, OSI provides its staff with an external service, the SOS International Card. SOS International takes care of tasks for its clients like crisis management, health care intervention, repatriation of remains (!!), and other somewhat scary things. One of the apparently useful services that comes with membership is the "International SOS Medical Alerts", which members can sign up for in email format. I signed up, and immediately started receiving the Daily Anxiety:
"Zimbabwe: Cholera kills 11 in three southeastern districts"
"China: Toxic spill threatens water supply in Guangdong province"
"Kenya: Measles outbreak affects Nairobi, other areas"
"Indonesia: Surge in Malaria cases in East Lombok"
"Sudan: Yellow fever in South Kordofan state"
"Turkey: Avian Influenza (Bird Flu) Situation Update: Main Points"
"Zambia: Cholera outbreak grows worse in Lusaka"
Good grief. What I haven't been able to detemine is how the SOS service decides to send out an alert. There seems to be no rhyme or reason. Surely there is more than one health crisis around the world per day that involves epidemic, poor water, or the developing world? Measles in Nairobi doesn't preclude toxic spills in China, as far as I know.
Perhaps the answer lies in the point of production: the email arrives from something called the "SOS Alarm Center". Does SOS International simply pick a random, daily health tragedy from a list of many in order to keep their clients mildly alarmed, slightly anxious, sweatily checking their supplies of generic antibiotics, iodine, and malaria tablets? This isn't to complain about the services that SOS International provides, which I'm sure are very good and useful (although I, thankfully, have never had to make use of them myself, and hope not to). But it's useful to remember: alarmed clients are good clients, at least to a crisis management service.
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:
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.
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.
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.
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.
Q: Could we stop along the road to the ferry so I can buy a hat?
A: It depends on what time we cross the equator.
Needless to say, I wasn't able to process that correctly at 4 in the morning after two hours of sleep at the Hotel Niagra, Kampala, Uganda.
(I didn't buy a hat, as it turned out, but I did learn that, according to our guide, the toilets really do flush in opposite directions on either sides of the equator, even when the distance is only a few meters from the big north/south divide. This legend from middle school science class days always troubled me slightly, along the lines of: aren't people on the other side of the earth from where I am standing upside down? Etc.)
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.
As noted earlier, I'm in the middle of a group read of Don Quixote. The translation was selected by our good professor, Micheal Miller; many chapters in, I learned that it was a particularly well-regarded translation, new, by Edith Grossman. Lucky us, I thought, failing to realize that Professor Micheal had obviously done a little research on the topic to get us to such a happy place.
While I was in New York in December, I loaded up all the empty crevices of my suitcase with books to replenish our stocks in Budapest. At the Columbus Circle Barnes and Noble, I lingered in front of a shelf of Proust, and finally selected a copy of Swann's Way much as I would choose a California pinot gris: the packaging was pretty, with a sort of festive shiny purple swoopy deal on the front. And feeling in the holiday season, that seemed like a better choice than the somewhat mournful Currier & Ives-type print on the front of the other translation. Besides, the Penguin translation I bought was new, and I decided that in the world of translations, new was probably superior to the creaky old one-- otherwise, why would Penguin have gone to the trouble and expense of forking out?
(Actually, it turned out it be a marketing trick of the academo-geekiest sort: they had each volume of In Search of Lost Time translated by a different person, and re-released the whole thing. Which, by the way, used to be translated from À la recherche du temps perdu to Remembrance of Things Past , if you read it long ago in college).
A kind but mildly punitive reader friend pulled up for me a December article from the New York Review of Books on the very volume that I hauled back to Europe in my bag. If you're one of those interested in various translations of Swann's Way, I encourage you to read it: it's very good, and it makes clear why I made a tragic mistake in choosing Lydia Davis' plodding and earth-bound translation of Proust because of its Christmas-paper-wrapping cover over the emotionally honest and spiritually rewarding versions by Scott Moncrieff and Terence Kilmartin. Oh, the folly of shiny baubles!
The moral of this story, however, is one that you probably already know, but perhaps like me, you ignored. More Pinot Gris, less Proust. No, that's not it. Research your translation if you're reading in second language! Books aren't cheap, and I'm now stuck with the sorry choice of either consigning my copy of SW to the guiltily-abandoned pile of never-to-be-read brand-new books by the side of the bed (someday I'll post a list of those for public excoriation) OR ploughing through the damn thing, knowing that I'm missing out on soaring prose and emotional reward in spades. As Proust himself opined, "The only paradise is paradise lost." Woe is me.
My friend and colleague Jerzy Celichowski has the soul of an artist; his Budapest flat is filled with pictures and paintings that give the feel of an ecletic, homey gallery as well as a family's residence. Over the upright piano, Jerzy has hung a painting of wise-looking dog with a tiny erection surrounded by cherubs; the picture is unframed and both simple -- almost like a child's drawing -- and strange enough to pause in front of, repeatedly. I always spend several minutes admiring the dog when I visit Jerzy and his wife Orsi.
The artist, Emil Für, is Hungarian, and tends to paint angels, Central European Jewish men, mobile phones, circus escapees, and potent devils, often in surprising combinations. I confess I have no idea what the paintings are about, but his paintings are by far my favorite from a contemporary Hungarian artist (though barely surpassing the recent enthusiasm in our household for that other fabulous Hungarian artist, photographer Dezső Szabó.)
Für's paintings combine a flat, folk-art sensibility with characters who use modern appliances (mobile phones are clutched even by angels in his world) and take off their clothes at the drop of a hat. When they do wear clothes, they are at extremes: either goofy (see the devil from "Tempation" to the right, clad only in spotted blue underpants) or, as in the case of many of Für's Jews, religiously black, white, and providing neck-to-ankles coverage.
Angels are everywhere in Für's pictures, either as subject or standing guard in pairs above the action. Many of Für's subjects are Jewish, but it's entirely unclear whether the angels are as well. I usually think of angels in terms of Christian iconography, but angels of course litter the Old Testament, stepping out of burning bushes and wrestling with troublemakers. They also, I've just discovered, appear throughout Jewish teachings, although the interpretation of their role is varied. Angel in Hebrew (mal'ach) means "messenger", and indeed, it seems that angels continue to play that role both in the the Torah and in Jewish writings. However, Rabbi David Wolpe, in an article on angels and Judaism, explains that some medevial Jewish commentators explained angels as " necessary because they perform tasks that are beneath the dignity of God's 'personal involvement.'" That is, they act as a sort of PA/project manager for God. I like this explanation best, in light of Emil Für's paintings, because it seems to make sense: there's so much watching over in his art that God himself couldn't possibly get involved -- but the angels themselves, armed with mobile phones for quick reporting, are nearly always present.
More recent paintings and drawings can be found here.
Emil Für's site is here.
Poor Ukraine. As the country that bore the brunt of the 1986 Chernobyl disaster, Ukraine is still paying for it, both in the health of its citizens and in the resulting cleanup. According to chernobyl.com, an information website set up by the Swiss Agency for Development and Cooperation and UNDP (United Nations Development Program) to track the effects of the disaster, the Ukrainan government still spends 5-7% of the national budget dealing with the consequences. And now they're struggling with their Russian gas bill in the middle of winter, while their bad-tempered neighbor to the south tries to decide how nasty to be.
There are, however, a couple of somewhat cheering bits of fallout in the Gazprom mess. One is simply the fact that Russia has gotten so cranky with Ukraine: Putin could not more clearly highlight Ukraine's moves towards an open, democratic political system, and away from Russian patronage and control. Quite simply, Ukraine isn't Russia's obedient poodle any longer -- Russia only props up subservient gangsters like Belarus' creep-in-chief, Alexander Lukashenko, who pays 48 dollars per 1000 cubic meters of Russian gas. Romania, Hungary, and other countries formerly under Soviet influence have long since moved on to paying market price (220-230 USD/1000 cubic meters) for their gas coming from Mother Russia.
Another cheering thought for Ukraine is their coming debutante ball as a real energy market. Whatever happens in this specific showdown, Ukraine will eventually have to pay market price for gas like other European democracies. What this means is that Ukraine, a country with severe winters and 50 million people, will become a true open market in time. Russia may now have Ukraine in a corner, but a few years down the road, that won't be the case -- other producers of natural gas, particularly in the Middle East, will be in a position to offer competitive rates to the country.
A final thought, which is more puzzling that cheering, is that of Russia's hubris. It's not crazy of Russia to ask that Ukraine, no longer under the Russian thumb, pay what other countries do. As noted above, it's a compliment of sorts. Given, Ukraine is a poorer country than Hungary or Romania, but one of the steps towards Europe is to get itself off of the Russian subsidy. However, it's quite strange that Russia, trying so actively to position itself as a stable world leader in energy, would do something so unsettling to their major customer (Europe, that is) that EU countries responded unilaterally by telling Russia to get its act together and stop throwing a tantrum. Russia, as of tonight, has been backed into the face-losing act of both turning the gas back on (for the EU) and of whining that Ukraine is stealing gas going through the pipeline to Europe (which is probably true, to some extent, but isn't really the point). The question is, what did Russia think was going to happen by threatening western Europe's energy supply? It seems, from the country's reaction, that they either didn't really consider the consequences, or that they believed that Ukraine would cave quickly to their pressure, making this a non-issue in Europe. And if they were wrong about that...
The leaves of memory seemed to make
A mournful rustling in the dark.
~Henry Wadsworth Longfellow
I'm not a person who owns life insurance. I have the minimum legal Hungarian coverage on my beat-up Fiat Brava. I've even gone through periods without health insurance, now and again, placing my trust in God/the loving embrace of potential bankruptcy and state-handout health care. However, the one place where I've always been willing to pay for peace of mind is in hard-drive backup -- that is, in backing up all the content and programs on my computer onto separate storage. Considering that I'm one of the few people I know who has never had an unrecoverable hard-drive failure, this may seem like an unlikely obsession. I don't think it is, though. For one, it's entirely inevitable that a person like me who travels with a computer everywhere, who uses a computer every day, will fall victim to loss, theft, mechanical failure, creepy viruses, trip-and-fall disasters, etc. Perhaps more important is that my life is contained on my little IBM x40 -- my photos, email history both personal and professional, documents in progress, etc. The backup, in other words, IS the life-insurance.
Further, part of my job is advising non-profit organizations on how to protect their (sometimes very sensitive) information; my colleagues and I always emphasize the need to back-up any important information, as well as to keep it off-site from their offices -- many human rights organizations, for instance, work in repressive countries where their offices may be under some kind of surveillance, or subject to raids and searches .
At this point, many of the groups we work with use writable CD's and a CD burner, probably the most available technology for major backups. This works acceptably well for a few large files or a group of smaller files, but there are still problems:
I have always hated backing up to CDs for all the reasons above, and have instead wasted hundreds of dollars over the course of the last ten years on bespoke backup products marketed to memory obsessives like myself. These products inevitably, and usually quickly, become obsolete. Usually they become obsolete because the amount of memory expected/needed in a backup product has expanded so rapidly; others become obsolete because they are either built-in to computers as standard options, or because they are so tragically bad in design/usability that they are quickly and guiltily abandoned.
Here's a brief history of my back-up devices: