The structure of the tech-for-dev marketplace

The structure of the tech-for-dev marketplace

Going it alone?

We’ve been fortunate to have SurveyCTO widely adopted by researchers, M&E professionals, and others working in the international development sector. In leveraging a professionally-supported technology product rather than building a more costly custom solution, our users are implicitly supporting a free market in which private providers compete to deliver the best possible technology at the lowest possible cost, a market in which technical development and support costs are spread out over a large number of users with common needs. This seems to buck convention, however, making our users somewhat exceptional (which doesn’t surprise us).

I say this because I have observed that many (most?) international development projects seem to operate with a preference for staff and services over off-the-shelf software. This leads them to engage in custom, one-off software development and open-source efforts much more frequently than, for example, typical businesses outside the technology sector.

As a result, you see lots of promising technologies get built out to 85-95% reliability, piloted – and then abandoned for the next project. You typically see far less of the hard work necessary to get a solution closer to 100% reliability and little effort toward maintenance or sustainability beyond open-sourcing. (And open-sourcing alone only means that a project’s code might become one of 21+ million github repositories; it is no guarantee that it will be maintained, used, or even looked at ever again. In fact, the odds are very much against any of those things happening.)

In engaging with the development sector as a private-sector technology provider, we here at Dobility have often asked ourselves: Why don’t international development projects leverage more off-the-shelf, private-sector technology solutions? After all, the private technology sector has established mechanisms for managing technical talent, sharing development costs across many users with similar needs, and maintaining and supporting technology solutions over time.

One common answer is that development projects are poorly served by off-the-shelf solutions, the vast majority of which were designed to meet needs in other sectors. But even presuming that the international development sector has unique software needs, it would seem large enough to sustain a thriving market of small-to-medium-sized software vendors. There is certainly enough money being spent.

Much of the money currently being spent, however, is being diffused on staff, services, and one-off efforts. Even would-be software companies with a preference to serve common needs are inexorably pulled toward focusing on the lucrative business of fulfilling idiosyncratic project needs on a services basis, rather than packaging and selling an off-the-shelf product. When one project will pay $10,000 for something that is customized to their every whim, for example, it is difficult to focus instead on a product that sells for $100 and might meet the needs of hundreds of projects. Particularly in the early stages of a technology business, it is very difficult to resist the $10,000 in favor of the $100. The financial incentives are just too great.

For their part, implementing project teams often seem to place a high value on complete control, on the ability to fully customize a technology solution. While it’s not entirely clear whether these teams fully realize the true cost to build, maintain, and support high-quality software (even open-source), they often operate with large budgets very conservatively set at a much earlier proposal stage; in some sense, by the time of implementation, cost is not really a factor – budget is.

Conditional on being able to secure donor funding, in fact, larger budgets and staffs might be strictly preferred to smaller budgets and staffs. This phenomenon that more-expensive can be preferred to less-expensive is one you often see in the public and nonprofit sectors where “other people’s money” is being spent. You see it far less in the private sector, at least when market forces are operating well.

This brings us to what seems to be an important factor: donors. Anybody who works in development will readily admit (and probably bemoan) the fact that donor funding dynamics drive incentives all through the development sector. Though it’s less widely recognized, many working on the donor side do try mightily to combat the unintended and undesirable incentives that result from their funding. But in this case of what appears as a preference for staff and services over off-the-shelf software – where hundreds of projects seem to very expensively re-invent the wheel – are the incentives strictly unintended?

Donor egos or fundraising incentives could lead them to focus on bleeding-edge innovation, quick pilots, and splashy conferences over more mundane investment in technology solutions that efficiently meet project needs. They may also have an implicit (sometimes explicit!) bias against the private sector: given the choice between spending $1,000 on a private-sector technology solution or $10,000 on a custom- or nonprofit-built solution, they may actually prefer the latter option. And they may truly believe that by spending more money and focusing it on a nonprofit or open-source solution, they are acting in the public interest.

In my view, the public interest would be better served by having more development projects spend money more efficiently, by allowing a more rational, free-market dynamic to support high-quality software firms that meet the shared needs of many projects. While individual projects would give up some degree of control in principle, the reality is that software supported by revenues from many projects would come to serve those projects considerably better than any custom-built solution ever could. Truly idiosyncratic needs might not be met as well (or as directly), but there is far more that is common across projects than what is distinct – and software vendors would undoubtedly release toolkits, API’s, and other avenues for project customization. The social gains would be considerable.

Obviously, I’m biased. I have a stake in this as the founder of a private-sector technology provider – though I have this stake precisely because I saw an important role for the private sector.

What do you think?

Comments (1)

  1. Recently came across a fantastic blog post by Herb Caudill, which speaks to the whole “ICT4D has to be open source” concept:

Leave a Reply

Your email address will not be published. Required fields are marked *