I have spent a fair amount of time working with open source communities in countries that are usually described as “the Global South” (a term that groups Africa, Latin America, parts of Asia, and Oceania in contrast to wealthier “Global North” nations), and the challenges those communities face are not the same as the ones in the European and North American projects that get the most attention. Some of the challenges are about infrastructure, some are about policy, and some are about who gets to participate in the upstream projects (the original, canonical version of a project that others fork from). I want to lay out the ones I see most often, and the ones I think the open source world is getting wrong.
The infrastructure gap is closing, but unevenly
A decade ago, the dominant story about open source in developing countries was bandwidth. Developers in places with intermittent or expensive internet had to choose between downloading a 4 GB Linux ISO (disk image) and paying for the rest of the month’s data. That story is less true today in many places, but it is still true in others, and the gap inside a single country is often larger than the gap between countries.
What I see on the ground varies a lot. In some cities, fiber-to-the-home (high-speed internet delivered over fiber-optic cables straight to a residence) is cheap and reliable, and a developer there has a better experience than a developer in a small American city. In rural areas, mobile data is the only realistic option, and the cost of a multi-gigabyte build artifact can still be a meaningful budget item. The community projects that have thought about this tend to mirror their artifacts widely, use delta updates (patches that contain only the changes between an old and new version, instead of the whole new file), and publish smaller, more focused images. The ones that have not thought about this tend to assume the same infrastructure as a Silicon Valley engineer.
The other piece of infrastructure is hardware. A developer without a current-generation laptop is a developer who cannot run a current-generation build. Some open source projects are starting to think about low-spec builds and CI (continuous integration, the automated build-and-test pipeline that runs on every code change) on low-end hardware, but most are not. The result is that the developer in a low-resource environment is excluded from the parts of the workflow that are CPU-intensive, and the visible work in the project drifts toward the people who can run the whole thing.
Policy and legal frameworks are not neutral
Open source licenses are written for a legal environment that assumes the rule of law is reliable, courts are accessible, and patent litigation is a thing that happens to companies, not individuals. None of those assumptions hold everywhere. In some countries, the legal infrastructure for software licenses is so thin that the question of whether an open source license is enforceable is essentially academic.
There is a real, ongoing debate in the open source community about whether this matters in practice. The pragmatic answer is that for most developers, the license is a signal, not a contract. Most people will not violate the GPL (GNU General Public License, a copyleft license that requires derivative works to also be open source) on purpose, and the absence of a court that will enforce the license is rarely the difference between a company respecting the license and not. The exception is when there is money on the line, and the countries with the most working open source communities are usually the ones where the rule of law is reliable enough that the licenses are not a real barrier.
A related issue is export control. Some open source projects have been caught in the crossfire of US-China technology restrictions, and the friction has been real. The maintainers of cryptography libraries, in particular, have had to spend time on legal questions that have nothing to do with their actual work. The open source community’s response has been mixed, and the policy environment is moving fast enough that any specific advice I give here is likely to be out of date by the time you read this.
Who gets to be a maintainer
The hardest challenge I see, and the one I think the open source world handles the worst, is the question of who gets to be a maintainer. The traditional model is that maintainership is earned through contributions, and contributions are largely English-language, asynchronous, and time-zone-friendly. None of those are neutral. A developer in Lagos or Lima or Hanoi is at a structural disadvantage compared to a developer in London or San Francisco, and the gap is not just about the language.
A few things I have observed:
- Conference travel is a real bottleneck. The conferences that matter for visibility are still mostly in North America and Europe, and a developer in a developing country often cannot afford the trip. The conferences that are moving to virtual or hybrid formats have made this better, and the conferences that have not are falling behind on diversity.
- Time zones matter. A maintainer who can only contribute in the evening hours of a US timezone is going to miss the synchronous parts of the project. The shift to async-first workflows has helped, but the projects that are still very synchronous are still very Western.
- Maintainership selection is informal, and informal is biased. A project that picks its maintainers through “people who showed up and did good work” is going to pick people who could afford to show up. The fixes for this are well known (active recruitment, paid fellowships, structural support for new maintainers) and most projects have not adopted them.
- The cost of being a maintainer is borne by the maintainer. Most open source maintainers are not paid for the work. In a country with a high cost of living, that is a sacrifice. In a country with a low cost of living, it is a different kind of sacrifice, and the math is different, but the sacrifice is real.
What is working
I do not want to be all bad news. There are open source communities in developing countries that are doing well, and the patterns I see in them are real:
- Local user groups that meet regularly and produce a pipeline of contributors who can work their way into upstream projects.
- Government policies that prioritize open source in public procurement, which creates a real market for local companies that can support and customize open source software.
- Diaspora networks (communities of professionals who moved abroad but maintain strong connections to their home countries) that connect developers in developing countries to projects and jobs in the global market. The Indian and Nigerian tech diasporas have been particularly effective at this.
- Regional foundations and conferences. The Africa Open Source Network, the Asia-Pacific open source communities, and the Latin American foundations have created spaces that are not just mirrors of the global events.
- Localized documentation. Translating documentation into local languages is unglamorous work, and the projects that have invested in it are reaching a wider audience.
Trade-offs
A few things I would call out honestly:
- The “open source is the great equalizer” narrative is partly true and partly a story we tell ourselves. Open source removes some barriers, but it does not remove the barriers that come from infrastructure, time zones, and money. Pretending otherwise is a disservice to the developers in places where the barriers are real.
- The push for “diversity” in open source has been mostly cosmetic. The structural changes that would actually shift who gets to be a maintainer are not as catchy as the conference talks about diversity, and they have not been funded.
- The local language documentation effort is necessary and not enough. A developer who reads documentation in their native language still has to write code in the project’s primary language, which is English, and the language barrier for that is the real one.
- The government procurement story has worked in some places and failed in others. Where it has worked, it has produced sustainable local companies. Where it has failed, it has produced procurement fraud and resentment against open source as a category.
- The diaspora story is real but also extractive. A developer who emigrates to work at a US company and contributes to a project from the diaspora is contributing, but they are also no longer in the country the project is supposed to be helping.
What I would do with this
If I were running a global open source project, the things I would do are not glamorous. I would set up a small grants program for contributors from underrepresented regions. I would publish a low-bandwidth version of the project, and I would test the build on low-end hardware. I would pay for translation of key documentation, and I would pay maintainers in local currencies rather than expecting them to navigate a US bank account. I would accept that maintainership looks different in different places, and I would be willing to spend the time to make it work.
The open source world has gotten a lot better at talking about these problems. It has gotten less good at funding the solutions. The communities in developing countries that are doing well have usually done so by finding funding outside the traditional open source ecosystem, and that is both a sign of the communities’ resilience and a sign that the ecosystem has not caught up.