Open source software and development cooperation

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.

The chances of doing a project on a non Microsoft Windows desktop is a far fetched one. But for software serving other purposes one might find good OpenSource alternatives to the commercial ones. In my area of work GIS servers, Content Management Systems, Office systems and operating systems for servers are relevant examples.Working with IT projects in developing countries does involve special challenges which only open source software can meet. Searches for “Development cooperation” and “open source” software on Google and Bing returns few relevant hits.

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 disappears. If the software represents the nave of the procedures the project outcomes are reduced to sweet memories the day after the yearly software license is due.

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 airfare, 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.

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. 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.

4) The expensive gift
To eliminate expensive software as a challenge some international organizations has been rumored to give away expensive software. The problem is that some of this software could end up being more of a burden than an assed. After one year the bills might be flowing. That is not a problem if the receiving agency is out of funds or not otherwise able to pay the bill. But if the adminstration has sufficient funding the math will tell it all after a couple of years. This doesen’t get any better if the software is noe even used.

5) Flop safety on
For the sake of argument, let us imagine a project resting on a dodgy fundament with a particularly incompetent foreigner doing his best but still failing amazingly. Sadly it it is not really hard to imagine…

With a policy of using open source software the funding party can reduce the potential costs of a project disaster by thousands of dollars by using open source instead of commercial software.

6) 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 onwards to greener pastures with his new competence – leaving behind a useless license fee.

7) 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.

Some of these examples are from real life. All of them based on experience and word of mouth.

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.

All in all 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:

• Environmental Spatial Data Infrastructure – technology

As allways 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, more?