Open Source Has a Design Problem Nobody Wants to Admit

You’ve felt it. You discover some incredible open source tool — it does exactly what you need, the README is immaculate, the stars are climbing. Then you open the interface and it looks like it was designed by someone who thinks CSS is a personality flaw.

You don’t stick around. Nobody does.

And here’s the thing everyone in the open source world refuses to say out loud: The best open source projects aren’t losing users because of missing features. They’re losing users because they feel hostile to anyone who isn’t a developer.

Recently, someone on Hacker News asked a painfully simple question: Which open source projects are actually accepting pull requests for UI design contributions? The answers were telling. One person pointed to goodfirstissue.org — a site that tags beginner-friendly code issues, not design issues. Another accused the poster of being an AI proxy generating “design slop.”

That thread, in microcosm, is the entire problem.

Open source was built on a beautiful idea: anyone can contribute. But somewhere along the way, “anyone” silently became “anyone who writes code.” Designers who want to contribute hit walls that don’t exist for developers. There’s no design equivalent of a good first issue. There’s no reviewer with the authority to merge a UI overhaul. There’s no maintainer who treats a Figma file with the same respect as a well-structured algorithm.

An open source project that only respects code contributions isn’t open source. It’s a gated community with a liberal guest policy.

Let’s be honest about what happens when a designer tries to contribute to most OSS projects. They file an issue describing a UX problem. A maintainer says “feel free to open a PR.” The designer doesn’t write code. They don’t know how to navigate the contribution pipeline. They submit a mockup. It sits there. Someone eventually closes it as “won’t fix” or “out of scope.” The designer never comes back.

Now flip it. Imagine a developer submitting a pull request and being told “great idea, but we don’t have a workflow for reviewing code, maybe come back later.” That would be absurd. Yet this is exactly what happens to design contributions every single day.

The real bottleneck isn’t a shortage of designers willing to help. I’ve talked to designers who are desperate to contribute to open source. They use these tools. They see the problems. They want to fix them. But they’re staring at a contribution model that was designed by developers, for developers, and has never been updated to accommodate anyone else.

You don’t have a designer shortage. You have a culture that treats design as decoration instead of infrastructure.

Think about the projects that broke through to mainstream adoption. VS Code didn’t become the dominant editor because it had the best compiler integration. It won because it felt good to use. Obsidian, Notion, Linear — these tools raised the bar for what software interfaces should feel like, and users’ expectations shifted permanently. Open source projects competing against that standard with a 2008-era interface aren’t fighting a fair fight.

And the damage compounds. Poor UI drives away non-technical users. A smaller user base means less community energy. Less energy means fewer contributors. Fewer contributors means the project stagnates. The interface that nobody fixed becomes the reason nobody sticks around to fix anything.

Here’s what needs to happen, and it’s not complicated:

First, projects need design contribution pathways that are as clear as their code contribution pathways. That means design issues tagged for newcomers. It means maintainers who can review and merge design work. It means treating a design system with the same versioning rigor as a codebase.

Second, the open source community needs to stop treating design as an afterthought that gets bolted on when a project gets popular enough to hire someone. If you wait until your project is successful to care about design, you’re guaranteeing it never gets successful enough to afford it.

Third — and this is the uncomfortable one — developers need to accept that they are not designers. The same person who would never let a designer rewrite their core algorithm somehow feels perfectly qualified to make every interface decision. This isn’t about hurt feelings. It’s about recognizing that design is a discipline with its own expertise, its own patterns, and its own contribution model.

The open source world has solved harder problems than this. It built operating systems, browsers, databases, and the infrastructure that runs half the internet. The idea that it can’t figure out how to accept a design pull request isn’t a capability gap. It’s a priority gap.

And priorities, unlike capability, are a choice.

So the next time you see a technically brilliant open source project with an interface that makes you wince, don’t blame the developers for being bad at design. Blame the system that never gave design a seat at the table. Then ask yourself: what would change if that project treated a designer’s contribution with the same weight as a developer’s?

The next great open source project won’t win because it has the best code. It’ll win because it was the first to realize that design isn’t the cherry on top — it’s the foundation.