According to Rolfe Leary’s article, appropriate technology is defined as “a simple technology created for, but not by, the people“.
Compared to the practice of international technology transfer that it eclipsed, appropriate technology was a progressive form of technology for development. Rather than transferring capital-intensive technologies from industrialised countries, appropriate technology practitioners consciously set out to design technology appropriate, as they saw it, to the needs of non-industrialised countries.
Although progressive relative to technology transfer, appropriate technology remained fundamentally flawed in at least two respects. In the first place the appropriate technology movement was premised on a belief that the solution was technology and they thus operated with a ‘technological imperative’ to improve whatever already exists through the application of new technology. Secondly the technology solution was almost invariably devised, designed and delivered by foreign experts – especially in the early decades.
Today we find both failings in some ICT4D practice. Both errors – starting with technology rather than community, and locating power in the hands of foreign experts – disables local people. We need to improve our practice in both regards.
If the appropriate technology movement (or ICT4D) relies for its solutions on engineers in London or Washington who have been socialised in technocratic cultures and who live in industrialised economies, then we should not be surprised if they continue to prescribe technical fixes for development; nor should we be surprised if those solutions often misjudge local priorities, fail to reflect local custom and practices, or prove to be unaffordable or otherwise unsustainable.
In order to create truly ‘appropriate technology’ we must take an altogether different approach to ICT4D – one which from the outset is community-owned and directed, and where decision-making power, resources, and capacity are located as near as possible to intended the site of development. Rather than transferring technologies internationally ICT4D agencies might think constructively about transferring the location of their HQ, decision-making, and budget-holdings to developing countries?
A re-engineered ICT4D should aim to avoid dependency on foreign experts, donors or institutions, and instead set out to develop participatory people-processes that enable communities to define their own development objectives, priorities and activities. To reduce dependencies there is also a need to build operational capacity in the field that is able to innovate new solutions to development challenges – or appropriate and modify (hack) existing solutions according to identified needs.
One possible way to build such delivery capacity is to use the kind of hackspaces and iHubs that are gaining such popularity worldwide. Hackspaces are places equipped with engineering tools and workspaces where people can meet, share skills and work on collaborative projects. iHubs are similar except that they focus on software development projects. Hackspaces provide a vibrant community of makers, engineers and tinkers able to learn from and teach each other the practical skills of manufacture and production.
ICT4D agencies could set up rural hackspaces and iHubs and employ engineering and development graduates from African universities to hack solutions to community-defined problems. Regular opportunities to share experience and expertise with co-creators from other communities would need to be a feature to enable cross-pollination and diffusion. This could be facilitated through open-days, volunteering schemes and hacker-in-residence programs. Rural Hackspace R&D teams could work on community-identified challenges such as alternative power for rural areas, open-source adaptive technologies for the disabled, or irrigation pumps for arid areas..
Instead of running apps4dev competitions out of UN agencies with sponsorship from multi-national corporations, ICT4D agencies could run Maker Faires and Hackathons in rural Africa, catalysing creative solutions to rural problems, and building sustainable capacity to address development challenges. One example of work in this vein is the establishment of an Ubuntu Campus in rural Macha in Zambia’s Southen Province in collaboration with the University of Zambia (UNZA).
I believe that a Rural Hackspace would result in indigenous solutions that are grounded in an appreciation of the local operating environment: context, culture and markets. I think that enabling people to appropriate technology for development would be a powerful way to build self-reliance and local capabilities.
Instead of running apps competitions in New York judged by corporate CEOs let the communities around the Rural Hackspace award their own prizes to the solutions that they have most reason to value.