No.
This was my one-word stance on the question when I was invited to participate in a session about open source at this year’s MERLTech Conference. As the discussion proceeded it became clear that there was nearly a consensus view—despite a diversity of perspectives—about problems with the way the “Big Aid system” (a combination of restricted funding flows and perverse incentives) has implemented technology-driven development projects, and the bad connotations that the term “open source” has picked up along the way. But implementing a successful technology-driven project requires understanding the nuance of combining what we’ve learned from the Principles for Digital Development of “Open Source” (but also open standards, open data, which are not mere footnotes to this principle) and “Build for Sustainability.”
First, I’ll share my take on the problems expressed in the panel, from the two broad categories of experience represented in the panelists and attendees.
Panel Summary
The biggest problems for developers are centered around funding. For many T4D project implementations, the top fallacies are that:
- Open source is free.
- If one has to pay, it should only be for the next features needed for a project.
- Once the code is written, there are no recurring costs for the lifetime of the project.
The problems for practitioners tend to be related to misconceptions of open source, as well as concerns of quality:
- Open source is about more than just licensed code in a public repository, it’s also about sustained communities.
- Open source doesn’t mean free, there is a cost to ownership but also a benefit to reusing existing open-source products (or someone else being able to reuse your investment); and
- Vendor lock-in and code quality can be a problem, even when the code is open-sourced, if the “community” supporting it is all paid by a single vendor.
My take on the state of the T4D ecosystem is that we got here by combining hype and the corresponding surge in funding within a flawed system. The flaws start with a procurement model that ties funds to specific projects. The side-effect at the programmatic level is constrained time and funding, pressuring practitioners to often source one-off technology work to achieve their programmatic goals rather than consider sustainability or re-use. The side-effect of these practices is that software development companies and contractors certainly are not incentivized to quote higher and develop slower, simply to give something free and reusable back to the broader community and undercutting their own business in the process.
The Big Aid system embraced open source with expectations shaped by the fallacies mentioned above. Lacking the software dev experience, funders and practitioners didn’t understand that while helpful, open source alone is not sufficient to achieve the supposed benefits. They become part of a larger structure involved in software product development, without having the necessary experience to understand the implications.
Private companies and individual contractors emerged that could perform the necessary work, and there was enough funding at play to create a pseudo-marketplace with for-profit software product development exclusively for international development as an end user. Unfortunately, market incentives weren’t aligned with good product development, but rather with unadapted models used by the bureaucracies of international development organizations, originally intended for physical goods and constructions. Funding was awarded for good proposal-writing, and continued work would only be granted to those that could continue to prove their necessity as old projects waned and new projects waxed. Traditional corporate sustainability in a project-oriented funding environment offers disincentives to open-sourcing, or even writing re-usable, turnkey products.
To be clear, the root cause is within blame rests squarely on the Big Aid system, not the for-profit organizations. Inside Big Aid, terms like “turnkey” and “enterprise-level” are only just now slowly making their way into the vocabulary, while phrases like “my custom SMS project for rural farmers in Malawi” are taking too long to make their way out. Private companies respond most easily to the market incentives being offered. The result is a market where few products have endured, none of which are realizing their full potential; a graveyard full of failed pilot products (or products where the principal funder lost interest) abound; and an unacceptable number of frustrated practitioners and developers.
Is there a better model?
At the Digital Impact Alliance (DIAL), we believe that an ecosystem with mature open source products, co-funded by multiple organizations, and contributed to by multiple software developer organizations is the key to delivering both the “sustainable” and “open source” Principles and addressing the challenges of both practitioners and engineers alike.
This approach isn’t a proven solution in the T4D sector yet. But it also hasn’t been tested.
We need opinionated engineers that don’t succumb to analysis paralysis or kicking-the-can design techniques—creating complicated customizability and modularity, rather than picking one simple and cohesive product vision. We need to avoid over-applying the lessons learned from “by devs, for devs” open source products such as Apache HTTP Server, Django, PostgreSQL, etc. In such products, the vision of contributors and users is strongly coupled because both roles are often the same people. We must also find ways to reconcile the traditional “single product owner” role with a multi-stakeholder environment, and exploring new ways to bring users to the center of an ongoing conversation and collaboration with a product’s contributors.
This is also a chicken and egg problem. It’s hard to have a robust many-to-many relationship between funders and contributors without enough mature open source products around which to build these communities. We hope to help solve this at DIAL, and we’ll be making some exciting announcements next week about our new DIAL Open Source Center, its vision of how to effect change, and how you fit in. We’ll also be continuing this conversation in public over the coming months to improve the open source T4D ecosystem. Stay tuned!
David McCann serves as Director of Technology for the T4D Open Source Software Incubator & Accelerator at DIAL. He brings 10 years of experience building and managing small teams to achieve greenfield goals in both the non-profit and private sectors.
