Caption: Hard at work at a computer in Zambia

NDI, Software Development, and the Long Haul

How can one do software development right if you're not a software development shop?

I was recently discussing with a colleague what software development means to a non-profit like NDI. My thinking on this has evolved quite a bit over the seven (!?) years I’ve been working in international development, drawing on our team’s successes - and failures.

At NDI we’re really lucky to have a small software development team in-house, which is a rarity among our peers. Since it’s a small team, we necessarily have a limited set of skills. We're really good at Drupal and PHP, OK at Python, great at MySQL, and OK at MongoDB. We can always shift some of those – for example, we’re piling into Python and pulling out of Perl – but with a small number of heads, people will only be able to wear so many hats.

For a team like ours, the real value-add is not in cranking out massive volumes of code, but in knowledge about the field of development, politics and democracy, particularly the needs of civic or political partners in the developing world.

Ironically the initial coding effort to build something new – Herculean as it may seem – is easier for a time-limited, project-based organization like NDI. Projects have a finite start and end; the costs can be estimated in advance and put in a proposal. There is, however, a terrible curse with grants: they run out. Traditional thinking is that when the clock runs out, the implementers (like NDI) simply cut the lights and walk away, having cleanly handed over all the skills necessary for the folks in the country to continue doing the same thing indefinitely.

That is a recipe for failure when it comes to technology generally, and farcical when it comes to custom code.
Maintaining software over the long haul is hard. The world of international development funding is strewn with the wreckage of well-intentioned (and sometimes even well-built) software that didn’t have a model to be maintained over time.

There's too much reinventing of wheels in this business. If there's something out there that generally works - be it affordable, usable commercial or FOSS software, we should try to jump on board and support, unless the software or people around it are totally broken.

Open sourcing alone is not a sustainability strategy. Licensing is easy; community is hard. Unless you're piggybacking on an existing group that was there before you arrived and you expect will continue after you're gone, you've got to carry almost all the water in perpetuity and/or build a self-sustaining ecosystem.
For most of our partners, even giving them perfect and well-maintained tools as code is as useful as giving a laptop to a dolphin. There's no way for them to access it.

So, where that's left me?

  • NDI can develop and sustainably support only a small number of software tools. For us, election data management systems are in that category, since the dozens of elections we support each year creates enough demand that we will necessarily be doing the long term care and feeding. However, we can’t responsibly just build new things without proof of a huge market failure and a viable way to support it over the long haul, or without dropping something else.
  • When possible, NDI instead works with existing open source communities that value and embrace our membership in their community. Open source is great, but often built by well-intentioned white dudes in California, which means it may not be designed with usability for folks in the developing world. Through our DemTools initiative and before, we’ve worked with the core development communities of Civi, DKAN, Tails and Fix My Street to improve their products for a broader audience. We provide money and use cases to shape their products in the form our partners want, but since contributions go back into the core projects we don't have to carry the weight of code maintenance going forward. While we could use our own developers to do in-kind coding and commits, we more often contract with the core teams directly. We do, as a part of that, sometimes have to maintain modules or smaller pieces of code. That's more responsible, since it's both an easier lift and if NDI ceased to exist the core software would still work well.
  • When we're doing virtually any program using open source tech, we have something of a responsibility to "pay" for this free software in useful community improvements, and fight the tragedy of these tech commons. Incremental progress is key, and often our partners get large benefits from the relatively small contributions we can make.
  • Much as I constitutionally love FOSS, if there's good enough commercial software out there at a sustainable price point for our partners, we should use it and avoid this whole morass. Being a purist can get in the way of impact, and can be a messianic imposition of values on people who just want to get stuff done.

This is all reflected in our approach to DemTools, our signature software suite. Our rockstar Nigerian coders TimbaObjects built our Apollo elections tool from scratch; we have a custom platform on Drupal for Issues; and we worked with pre-existing civic tech communities for Fix My Community, CiviCRM, DKAN, and Petitions.

NDI is in technology and code for the long haul, because that’s what democratic institutions need to be relevant for the digital citizens of the 21st century. We’re doing our best to make sure that it’s a sustainable long haul, for us and for the people actually using these tools.