Is Open Source Overrated?

The following article is cross-posted from our program blog at DIAL, and offered here for those of you interested in open source in digital development.

Is Open Source Overrated?

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:

  1. Open source is free.
  2. If one has to pay, it should only be for the next features needed for a project.
  3. Once the code is written, there are no recurring costs for the lifetime of the project.


David McCann (second right) speaks with fellow panelists at the MERL Tech Conference 2017

The problems for practitioners tend to be related to misconceptions of open source, as well as concerns of quality:

  1. Open source is about more than just licensed code in a public repository, it’s also about sustained communities.
  2. 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
  3. 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 DIAL Open Source Center. He brings 10 years of experience building and managing small teams to achieve greenfield goals in both the non-profit and private sectors.

6 Likes

Totally agree with David McCann in his answer. Open source is totally not over-rated.

I do really think that it is the only way that we’re going to start being able to address big challenges like accessibility, sustainability & security too. I’ve delivered a presentation on this, but these 3 issues are always left out of tech projects.

If we want to have:

  • sites that are accessible to everyone, not just those without disabilities…
  • tech that is light-weight and performant so that it consumes less electricity & is faster for those without broadband
  • a community of people looking at and enforcing best practices for security

Then we have to be thinking about open source in all of our projects.

I’m a Drupal Core Accessibility Maintainer, so am a bit biased.

Mike

2 Likes

Thanks for the interesting points raised in the oped. I like the idea of “ecosystem with mature open source products, co-funded by multiple organizations, and contributed to by multiple software developer organizations”. But: how could project management and tendering procedures be aligned with such a vision? (see the fallacies section …). Also, some of the “chicken and egg problem” is not really specific to the development sector. This is true for many areas of open source development, and there are multiple ways to start with an “egg” or a “chicken” … Cheers, Balthas

I totally agree. Free & open source software (FOSS) projects of all types are regularly struggling with sustainability right now, so it’s not just the digital development sector with a challenge on its hands.

However, I do think that there are some unique aspects to the development world (“big aid”) as @dmccann calls it, that change the economics and incentives quite a bit compared with other parts of open source.

So we probably will have to come up with some (at least partially!) unique solutions to sustainability. However, if we play our cards right, and we stick to the Digital Principles (“Design for Scale”, “Reuse and Improve”) such work would be reproducible and translatable to other areas of the FOSS world. At least we can hope so as we experiment in our own work!

Choosing a mature community to work with is key. There are a lot of great tools out there that just don’t have the critical mass. A little research can go a long way.

Even back in 1999 when I was working for Oxfam there was interest and investment in open source by some affiliates. There may not have been awareness of this in management, but it was certainly happening.

I like going back to the whole discussion of free. Folks often talk about free as in beer or free as in speech. I prefer free as in kittens. It can be millions of dollars worth of software development and testing that you are getting for free. It can be a real joy and delight for your organization, but if you don’t find a way to nourish the ecosystem that builds it, you likely won’t be able to rely on it to be there for you.

I’ve tried to encourage NGOs to co-fund projects, but it usually doesn’t work. I’ve tried influencing funders like OSI, but that hasn’t quite worked yet either. I’ve gathered some ideas about open source procurement though that may be of interest:

1 Like