The Unwritten Rules of Open Source Are Keeping Women Out — Here's How We Rewrite Them

Scroll through the contributor graphs of almost any major front-end framework on GitHub. Webpack. React core. Vue's compiler. The pattern is pretty hard to miss: a sea of avatars that skews overwhelmingly male. Women represent somewhere between 3% and 6% of open-source contributors depending on which study you read — a number that hasn't budged meaningfully in years despite all the "diversity in tech" conversation happening around it.

This isn't a pipeline problem. Women are writing front-end code every single day, professionally and personally. Something else is happening at the door of open source — and it's worth looking at directly.

What the Research (and Women) Actually Say

A landmark GitHub survey found that women were significantly more likely than men to encounter "hostile responses" when submitting code to open-source projects. They were more likely to have their contributions dismissed, questioned, or simply ignored. They were also more likely to abandon a project after a single negative interaction.

That last point matters a lot. Open source runs on momentum. If your first PR gets met with a terse, condescending review — or worse, radio silence — the calculus for trying again shifts dramatically. Men in the same study were more likely to brush off negative feedback and keep going. Women were more likely to conclude the community wasn't for them.

"It's not that we don't have the skills," says Danielle Park, a front-end engineer from Portland who spent two years trying to make meaningful contributions to a popular CSS-in-JS library before eventually giving up. "It's that the unwritten rules of the community were never written with me in mind. And nobody was going to hand me the key."

Those unwritten rules show up in a lot of ways: insider jargon in contribution guides, IRC or Discord channels with aggressive debate cultures, maintainers who respond differently to the same question depending on who's asking, and "good first issue" labels slapped on tickets that are anything but straightforward for someone new to the codebase.

The Documentation Problem Nobody Wants to Talk About

Here's a contributing factor that gets less attention than it deserves: bad onboarding documentation actively filters out people who don't already have access to informal knowledge networks.

When a contribution guide assumes you already know how to set up a local development environment for a monorepo, or when it refers to architectural decisions without linking to the original discussion threads, it creates a steep hidden tax. People who are already plugged into the community — who can ask a friend on Slack or have been lurking in the Discord for a year — can absorb that tax. People who are newer to the ecosystem, or who don't have those informal connections, hit a wall.

Women in tech are statistically less likely to have those informal networks, especially in open source, where community relationships often develop through in-person events, alumni networks from specific companies, or social circles that have historically been harder to access.

"I've started requiring that every issue tagged 'good first issue' include a link to the relevant code, a plain-English explanation of what needs to change, and a note about who to ping with questions," says Keiko Yamamoto, a maintainer of a React utility library who has made contributor inclusivity a deliberate project priority. "It took us maybe two extra hours to retrofit our existing issues. The number of first-time contributors we got in the following quarter doubled."

What Gatekeeping Looks Like in Practice

Sometimes the barriers are structural. Sometimes they're interpersonal. And sometimes they're subtle enough that the person doing it would genuinely argue they're not doing anything wrong.

Consider the common experience of a woman submitting a PR, only to receive a review that questions her entire approach rather than engaging with the specific change she made. Or the pattern — documented in multiple community post-mortems — where women's suggestions in issue threads get ignored until a male contributor makes the same suggestion and gets traction.

This isn't unique to open source, of course. But open source has a specific vulnerability: it's largely ungoverned. There's no HR department, no formal review process for how maintainers communicate, and no real accountability mechanism for contributors who make the environment hostile. The culture is whatever the most active people decide it is — which means changing it requires those active people to actively choose differently.

The good news? More maintainers are making that choice.

Finding Communities That Actually Want You There

If you're a woman who's curious about contributing to open-source front-end projects but has been burned before — or just intimidated by where to start — here's a more targeted approach than randomly picking a big-name repo and hoping for the best.

Look for projects with a public Code of Conduct that's actually enforced. A CoC that's enforced means someone is paying attention to culture, not just code. You can often tell by browsing past issues and discussions — is the maintainer responsive? Do they step in when conversations get heated?

Check the contributor demographics of the maintainer team itself. Projects led by women, or with women in significant maintainer roles, tend to have cultures that are more thoughtful about inclusivity. Some front-end repositories actively led by women worth exploring include: Fable (F# to JavaScript compiler with a notably welcoming community), projects under the OpenCollective umbrella, and many repos within the A11y Project ecosystem, which centers accessibility and tends to attract more intentionally inclusive communities.

Start with documentation contributions. This isn't a consolation prize — it's genuinely high-impact work that gets you familiar with the codebase and visible to maintainers without the pressure of a code review. Many projects are desperate for documentation help and will be thrilled to have you.

Use programs designed to get you in the door. Outreachy, specifically designed for people underrepresented in tech, places participants in paid open-source internships with supported mentorship. Google Summer of Code also has front-end projects regularly. These programs exist precisely because the cold-start problem is real.

Making Your First PR Count

When you're ready to submit code, a few things will dramatically improve your experience:

Read the contribution guide completely before writing a single line. Then read it again. Maintainers can tell immediately whether a contributor did this, and it sets the tone for the entire interaction.

Open an issue or comment before you write the PR if the change is anything beyond trivial. Something like: "I'd like to tackle this bug — my plan is X. Does that approach make sense to you before I dive in?" This surfaces potential problems early and signals collaborative intent.

Keep your first PR small and focused. One thing. One clear explanation of why. This is not the moment to refactor everything you noticed along the way.

And if you get a rough review? Try to separate signal from noise. Sometimes maintainers are just blunt. Sometimes the feedback is genuinely valuable even when the delivery is rough. And sometimes — not always, but sometimes — it's worth moving on to a project with better culture.

The Ecosystem We're Building Together

The front-end community is, in many ways, one of the more accessible corners of open source. CSS, HTML, and JavaScript have lower barriers to entry than systems programming. Accessibility work, design systems, and documentation are all deeply front-end adjacent and all desperately need contributors.

The women who are already in these spaces — maintaining repos, reviewing PRs, writing contribution guides that actually make sense — are doing the quiet work of rewriting the rules. Every welcoming community they build is a data point that it doesn't have to be the way it's always been.

Your contribution matters. Not just the code — the fact of your presence in these spaces shifts what they look like and who feels welcome to follow.

The door's open. We're holding it.