I have spent the last three years working with developer communities across West Africa, South Asia, and Southeast Asia, and the open source struggle I have seen there does not match the one we talk about in the United States. We debate license compatibility and corporate code dumps. They debate whether the project will be blocked by a national firewall, whether the build server in a neighboring country will survive the next power outage, and whether the one contributor with stable internet is going to burn out before the next release.
The global open source conversation has a West-shaped hole in it. Most of the influential mailing lists, conferences, and foundations are in North America and Europe. The major code hosts are in the United States. The grant programs are denominated in dollars. None of that is a conspiracy. It is the natural result of where the money and the early contributors happened to be. The problem is what flows from it: tooling decisions, documentation defaults, and “best practices” that assume the user has fiber to the home, a credit card, and a working postal address for the swag.
If you are a developer in Nairobi or Lahore, the open source struggle is not whether AGPL (the GNU Affero General Public License, which requires network-served modifications to also be released as source) is the right license. The struggle is whether the package you need compiles on the network you have, the documentation is in a language you read, the maintainer is awake when you are, and the contributions you make get reviewed before the maintainer’s timezone collides with yours.
What we are getting wrong about the community
Linux Foundation’s 2024 census reported that contributors from Asia and Africa together made up roughly 41% of the active open source population, a number that has been growing year over year. India alone passed the United States in GitHub active users in 2023. Yet when I look at the agenda for the top 20 open source conferences this year, the speaker lists still skew heavily toward North America and Western Europe.
Not because there is a shortage of qualified speakers in the rest of the world. Because the conference model is built on assumptions:
- Attendees can afford a $1,500 ticket plus travel.
- Speakers can take two weeks off work.
- The timezone of the conference is reasonable for the speaker.
- Visa requirements do not create a six-month lead time.
- The conference’s social spaces are accessible to people who do not drink alcohol.
All of those assumptions collapse for a developer in a country where the median monthly salary is below $500. A $1,500 ticket is three months of income. A two-week trip is not a vacation, it is a financial decision that affects the family.
The result is that the “open source community” the rest of the world is told to join is actually a regional sub-community, with a very specific culture, language, and economic profile. Joining it means adopting that profile, or pretending to.
The infrastructure problem nobody is measuring
Build servers are the single biggest practical barrier I have seen in non-Western open source work. A medium-sized project on GitHub Actions (a hosted continuous integration service that runs your test suite on shared infrastructure) costs a nonprofit roughly $0.008 per minute for Linux runners. The same workload on a self-hosted runner in Lagos is constrained by power. I have watched a contributor lose a four-hour CI run (continuous integration: the automated test suite that runs every time you push code) because the local power grid went down for two hours in the middle of a release candidate build.
Most Western maintainers default to “use a cloud CI provider.” I have heard that line from senior engineers who have never tried to push code from a region where the latency to us-east-1 is 380 ms. The timeouts keep firing. Test suites that take 45 seconds on a fast connection take 6 minutes on a high-latency one. Engineers debug phantom flakes for hours. The CI is not broken. The network is broken. The debugging is the wrong debugging.
Documentation hits the same wall. If the docs are hosted on a domain that gets blocked or rate-limited (a server slows down or denies requests after a threshold of activity) from a given country, the project might as well not have docs. I have watched three projects this year lose contributors in Cuba and Iran because the documentation site returned 403 for IP ranges in those countries. The maintainers were not even aware.
The credit card problem is a code problem
Most paid open source tooling, including cloud CI, container registries beyond the free tier, and SaaS (software as a service: a tool you subscribe to and use through a web browser) project management, assumes a working credit card. It assumes a card that can be used internationally, in dollars, with a billing address that the SaaS provider is willing to ship to. In many of the countries I have worked in, none of those assumptions hold.
Workarounds stack on workarounds. A contributor in a country with currency controls might use a virtual card from a US-based fintech (financial technology company) that has its own weekly caps. They might pool cards across a small group of contributors. They might just stop using the SaaS tool and switch to the local alternative, which is usually worse and which the global open source conversation never mentions.
This is not a fringe case. The 2023 Stack Overflow developer survey found that 38% of professional developers in Africa reported using a different set of tools than their colleagues in North America, primarily because of payment and infrastructure barriers. The discrepancy is invisible in the survey data until you filter by region. The aggregated “most popular tools” list tells you what developers in rich countries use. It does not tell you what works.
The language problem is not translation
Treating the language problem as a translation problem is a real temptation in the global open source community. Translate the docs. Translate the conference. Done. I have seen this approach fail consistently.
Documentation is not the whole of the project. The whole of the project is also the issue tracker, the code review comments, the chat where new contributors ask basic questions and get dogpiled for not reading the docs, the Twitter threads where maintainers complain about “low-quality contributions” without saying out loud that the contributor’s first language is not English.
Translation makes the docs accessible. It does not make the community accessible. The community is the social layer, and the social layer runs in English with a thin tolerance for non-native English, and that tolerance is unevenly distributed across projects. I have watched a contributor’s pull request (a proposed code change submitted through GitHub’s code review tool) be rejected with a comment that said “Please use proper English in commit messages” after three months of clean code. The fix was not translation. The fix was a maintainer who decided to read past the grammar.
The mentor problem is harder than the tooling problem
Tooling and infrastructure are solvable. Cloud regions can be added, payment methods can be worked around, documentation can be translated. Mentor overload is the problem I worry about.
In a healthy open source project, a new contributor is paired with an existing maintainer who reviews their work, answers their questions, and gradually ramps them up. The mentor relationship is the actual product. It is what makes a project a community instead of a download link.
Mentor relationships in the projects I have seen in the global South (the developing countries, primarily in Africa, Latin America, and parts of Asia) are overloaded. The one maintainer who is awake during US business hours, who speaks passable English, who has stable internet and a job that gives them the time to mentor, ends up being the bottleneck for an entire region’s contribution pipeline. They burn out. The region’s contribution pipeline dries up. We then say, “There aren’t enough contributors from that region.” It is not that there aren’t contributors. There aren’t enough mentors.
Diversity training is not the fix. The fix is to fund, support, and protect the existing mentors in the global open source community who are doing the work. They are not hard to find. They are the same people who are answering the same questions in the same Discord for the tenth time this month. Pay them. Reduce their other obligations. Make the mentor role a job, not a hobby.
Trade-offs
The non-Western open source struggle is not a single problem. It is a stack of overlapping problems, and the fix for one of them tends to make the others worse. Adding more cloud regions makes the CI cost go up, which makes the credit card problem worse. Translating the docs makes the language problem slightly less acute, which makes the mentor problem worse because the existing mentors get more questions. Paying mentors makes the project sustainable, which makes the maintainer team more visible, which makes it harder for new mentors to join.
A few practical shifts that are starting to work:
- Maintainers in different timezones. At least three maintainers in non-overlapping timezones, with a documented handoff process.
- Issue templates in three languages. Not the full project, but the issue templates, so the first interaction is not a language gate.
- Mentor stipends paid in local currency. Avoid the bank transfer fees that eat 18% of a $200 stipend.
- Build server replicas in the regions where contributors actually are. Slow CI is a code review bottleneck that masquerades as a network problem.
For a maintainer in a Western country, the easiest move this month is to read three issues from contributors outside your timezone and reply with patience. That is it. Not a new tool, not a new policy, not a new working group. Read the issues. Reply with patience.
If you are a foundation, fund the mentor role directly. Pick a project, pick a maintainer in the global open source community who is already doing the work, and pay them a salary for a year. Watch what happens to the contributor pipeline. The result is not theoretical. It is the result every project I have seen funded this way has produced.
For a contributor in a non-Western country and the project you are working on is treating you as a second-class citizen, the answer is to find a different project. The good ones exist. They are not always the famous ones. They are the ones whose maintainers reply to your pull request within 48 hours, in English or in your language, without making you feel like a tourist. Join those.