Open Source software as part of development cooperation is not a matter of principle. Choosing software in development cooperation projects is about finding good software tools to help you do the job.
There are challenges with both commercial and open source software. This article focuses on challenges with commercial products in development cooperation.
I am basing the reflections on my own experiences with and reflections from development partners.Working with IT projects in developing countries does involve special challenges which only open source software can meet.
Structuring the pro and cons for open source in developent cooperation projects deserves more than a posting written one late evening. But this is about as good as it gets this time around. This is my list of challenges on this subject:
1) Project funding ends
All projects start and end. Development cooperation projects are special in the sence of them being initiated because there has been few or no local incentives to start that particular project.
There is a good chance of the project dying if the source of funding for recurring license fees or initial free license disappears. If the software is central to the procedures central to a project, the project outcomes are reduced to sweet memories the day after the software license comes to an end.
I would like to rely on humans and not software licenses.
2) The money trail problem
Some software just costs too much. Getting funding for a project might be hard enough. Adding recurring software expenses which are paid directly to US or European companies might be enough to sink the whole thing. It really does not look good to have employee expenses @ $12.000 for a year and then adding the same for a piece of software.
In development projects a question often raised is how much of the money ends up in the receiving end. Money are used on airfares, travel allowances, consultancy fees, hotels and more. In a worst case senario most money ends up outside the supported country. Software licenses is of no help in this equation. Open Source helps. Using local companies like Mountbatten in Uganda or others helps balancing the equation.
I would like to see more partners in developing countries.
3) Bad luck
At one point a colleague of mine visited a GIS facility in an African country. They had sophisticated GIS software installed on several of the office computers. Some of the officers were conversant with using the software. There was one problem though. The software license key was a small piece of hardware not unlike memory sticks. At some point someone had mistaken the licence dongle for beeing a misplaced memory stick. They needed a memory stick and took it away from the office. Who could really blame them for doing so?
Replacing the dongle requires information about where the software was bought and relevant documents. They were not available as the software was paid by an external entity. So no dongle – no GIS. No GIS. No analysis. No analysis no project outcome.
I love being lucky – but planning and good outcomes trumps lucky any day.
4) The expensive gift
Some international organizations are giving away licenses as part of them going into partnerships on a national level. After a year the bills might land on the GIS officers desk – or the software might just stop working.
Sometimes the commercial entities themselves provide software licenses as partnerships with governments or organizations.
It is not a gift until it’s yours to keep.
5) The disappearing engineer challenge
Quite often projects will attract clever engineers eager to learn something new. Contributing to establishing a project is something any engineer love to do. Throw some new software at them and the good ones will get up to speed on it in no time. Some training courses and weeks of intense work later the still present engineer is able to run the project without further support.
Restless and clever people tend to move on after reaching their goals. So after running the project for some time the engineer moves onward to greener pastures with his new competence – leaving behind a useless license fee.
If left unused open source software is still for free.
6) Language barriers
For some users a system might be problematic if it is provided in English language only. Open Source software allows for access to the code and relevant changes to accommodate for the users not fluent in English.
If you own it you can make changes to it – and possibly make it better
Projects in developing countries are inherently difficult to manage. Adding commercial software software adds to the complexity. The factors mentioned above points to using open source software. Commercial software has their pres as well. Having access to professional training is one area where Open Source software is weak. Support systems is an other one.
Considering which software is best for the job is not a straight forward one. But for projects in developing countries the factors above should be considered when choosing software.
For an example of an open source spatial data infrastructure implementation take a look at this posting:
As always the plan is to do some more thinking about this theme. Comments are most welcome, and with some substantial contributions I might be able to develop this posting further.
The following issues could be further researched: Ease of integration, scalability, deployment complexity, more?