How Can Open Source Software be Sustainable in International Development?

open-source-software 640w" sizes=" 640px) 100vw, 640px" />
Recently Chris Fabian made the very interesting declaration. Since the UN’s charter is to produce public goods, he says “we do everything Open Source and Public Domain at Unicef Innovation because it’s 2016,” and doesn’t invest his organization’s resources in proprietary software.
Previous, Karl Brown made a similar declaration in his 10 Theses on Power and Efficacy of ICT4D Indulgences. His seventh thesis states that “NGOs funded with public funds should not be writing proprietary software.” Both Chris and Karl were critical in the development of the Digital Development Principles and pushing for Principle 6: Use Open Data, Open Standards, Open Source, and Open Innovation.
Principle 6 has helped convince a whole cadre of techies and aid workers that international development programs should only be investing in Open Source technologies. Enough that we can say that the international development community is now moving towards Open Source solutions.
Open Source Costs
However, Open Source should not be thought of as “free” software. Developing and maintaining Open Source solutions does require significant resources. Like proprietary code, someone needs to develop and maintain the code, maintain version control, keep documentation updated, train and support new users and developers, and market the product to others.
In fact, the cost of building and maintaining an Open Source product is about the same as creating and maintaining a proprietary one.
How Can Open Source be Sustainable?
That brings us to one small problem with Open Source technologies: making them financially sustainable. Building a good software product in alignment with Principle 4: Build for Sustainability needs more than great code; it needs a business model for its full lifecycle.
As far as I can tell, there are only three Open Source business models that work in the international development context:

  • Get project funding to write good, documented code that you hand over to an organization that then maintains and grows the code with dedicated internal resources. See RapidSMS. Unfortunately, successes like RapidSMS are rare, and this usually means developers have to jump from project to project, building new solutions for each client, and GitHub becomes cluttered with abandonware when projects end and clients move on.
  • Build proprietary interfaces to Open Source software and sell those services to organizations that don’t have the resources to do it themselves, and hopefully support the Open Source code base in the process. TextIt did this with RapidSMS, and many, many companies do this with Open Data Kit. Yet, these are not true Open Source solutions, so they don’t fit Chris’ and Karl’s declarations.
  • Build a complex solution that while technically is Open Source, anyone who wants to use it still needs to hire you to customize and configure it for them. See DHIS2. This is the model that most Open Source software efforts aspire to, but very, very few achieve. A major challenge to this model is that you need to build a market for the Open Source product and for your consulting services, when the product itself may be immaterial to your clients.

Of the three models, I see the first one as the greatest risk to international development. As Herb Caudill recently pointed out in The Revolution Will Not Be Open Source:
The world of ICT4D has generated lots of abandonware – software projects that fizzled as soon as the donor’s attention shifted and the free money ran out. But there’s nothing more sustainable in the long term than a profitable company providing a service that people are willing to pay for.
In fact, Herb went farther in his post to make an interesting prediction that should make us question our love of Open Source software. He says:
The ICT4D revolution will not be Open Source, but it will be created by scrappy startups like Magpi, iFormBuilder, TechChange, Souktel, and DevResults, by people who are unapologetic about building a business for the long term, and who have bet their very livelihoods on their ability to create proprietary tools that people will pay for.
And the issue of business models for Open Source solutions isn’t just in the international development space. Even commercial companies are finding that Open Source is not a business model on its own.
Join the Debate
As you can see, the tension between Principle 6: Use Open Source and Principle 4: Build for Sustainability is multifaceted and nuanced, which creates lively debates online and in-person.

Either way, please help us think through how to make sure Open Source software solutions are sustainable. We do not need any more abandonware – be it Open Source or proprietary.