Contributor Experience Design (CX): shifting from consumption to belonging

Alisher · May 6, 2025, 10:01pm

A designer’s view on how to research, prototype, test, iterate, and implement Contributor Flows for sustainable and meaningful participation in open source ecosystems.

“If you’re only designing for consumption, you’re complicit in control.”
— Inspired by Jarrad’s keynote at the All-Hands

After the IFT All-Hands, it became clear: if the goal is to scale open source, grow healthy communities, and build resilient ecosystems, then designing for users isn’t enough.
The real leverage is in designing for contributors.

This insight led me to reframe my UX design practice into something more aligned with this new direction. I now think of it as Contributor Experience Design (CX)—an evolution of UX focused not on use, but on participation. It’s about enabling co-creation, cultivating belonging, and designing for long-term involvement.

How UX becomes CX — a cheat sheet

UX practice	CX evolution
Market research	Contribution research — Who’s already building, remixing, organizing? Where is it happening? What languages and stacks are in play?
User personas	Contributor archetypes — Those with initiative, not just needs. Big players, underdogs, superheroes and sleeping geniuses. Newbies and veterans.
Journey maps	Contributor journeys — From interest to PR. From solving puzzles to championing values. From autonomy to alignment—and back again.
User flows	Contributor flows — Mapping the key stages of contributor experience and ensuring they’re meaningfully connected
Usability testing	Participation testing — Friction audits and confidence loops. How contributors move through our systems. Where they stall, succeed, or drop out.
Metrics	From usage to impact — Forks, remixes, spin-offs, translations, memes. Participation in all its forms matters.

Examples from the field

I haven’t yet found well-documented CX case studies that apply the full spectrum of practices—but even a light scan of the ecosystem reveals clear examples of CX thinking in action:

GNOME’s Outreach Program: Built a full journey for contributors, from first contact to leadership
Bundler: Adopted visible contributor norms resulting in more engaged participation
Ethernaut (OpenZeppelin): Turned testing into an onboarding path, gamifying contribution
Apache/MySQL: Lowered stack barriers, enabling widespread remixing and adoption
OpenStreetMap: Built a culture of local ownership and active mapping
Drupal: Created formal contributor roles, recognition pathways, and global meetups
Home Assistant: Clear architecture docs and active community updates support contributors

(More details about the examples are available on request. Forum currently doesn’t allow me to add links)

My next steps

Understand what makes contributors stay
Collecting metrics (PRs, forks, discussion volume) and conducting contributor conversations to identify patterns of sustained engagement in successful ecosystems.
Map moments that unlock participation
Using journey maps to understand where curiosity turns into action—and where motivation drops off.
Design paths that invite and support
Prototyping systems that guide contributors from interest to action—onboarding docs, contributor portals, and mentorship flows that create confidence.
Spot and resolve contributor friction
Logging where contributors stall or shine—so we can improve flows, structure, and feedback loops.
Share learnings to uplift the ecosystem
Preparing templates and case studies for other teams to adopt and adapt CX principles.

Why this matters

CX isn’t a cosmetic shift—it’s a fundamental reorientation of what design is for. It challenges the assumption that growth means more users. Instead, it asks: what if growth meant more builders? More remixers? More designers? More aligned collaborators?

Contributor Experience Design gives me a new design question:

Not just “can someone use this?”
But “can someone meaningfully join, shape, and extend this?”

Designing for contributors means shaping more than features—it’s shaping culture.
Culture is what carries projects forward when attention fades. It’s how ecosystems evolve, outlast their founders, and stay vibrant without central command.

Designing for contribution means:

Inviting people into the process, not just the product
Turning friction into feedback, not abandonment
Creating loops that generate leadership, not dependency

That’s why I’m betting on CX. It’s not just a design method—it’s a way to build the future I want to live in.

My questions

I’d love to learn from others who are thinking about Contributor Experience Design—inside or outside our org. If you’ve worked on anything similar, I’d be excited to connect, share methods, or swap learnings.

Here are a few open questions I’m carrying:

Are there any parallel or complementary initiatives already underway that we could cross-pollinate with?
Have we conducted any structured contributor research outside our org?
Do you see value in CX? What resonates (or doesn’t) in this framing?
Are there overlooked contributors in our ecosystem who might be quietly trying to get involved? I’d be glad to reach out and start the conversation.

Thanks for reading—and for everything you’re building.

vpavlin · May 7, 2025, 8:25am

I like this change in mindset and it goes hand in hand with LogosLab: A learning experience for the home or classroom - Logos - Vac idea as well - by focusing on contributor journey we should be able to identify how best to let people try and engage with out stack.

Chu · May 7, 2025, 11:42am

This aligns with the “Make Documentation Fully Public” initiative that was discussed during the offsite. The goal is to improve contributions across codebases (mobile, desktop, status-backend), addressing key blockers such as the lack of documentation, CI builds failing on forked repositories, and the overall low structure and consistency in the existing docs.

icaro · May 13, 2025, 6:51am

Love the acronym and what it stands for @Alisher!

After the IFT All-Hands, it became clear: if the goal is to scale open source, grow healthy communities, and build resilient ecosystems, then designing for users isn’t enough.

Builders build for somebody or something (or for themselves), but ultimately there’s a human down the line, the consumer/user. We/they can build meaningfully for both ends of the spectrum, and everything in between. It doesn’t have to be one or the other, although I kind of see that we can build radically different products depending on how strongly we favor one end of the spectrum.

It challenges the assumption that growth means more users. Instead, it asks: what if growth meant more builders? More remixers? More designers? More aligned collaborators?

Different services have different healthy ratios of builders & users, therefore I think we shouldn’t correlate growth with more builders, more collaborators, more designers, etc. There are practical limits to collaboration and it’s highly context-sensitive. For example, many open-source projects tend to have a small (sometimes one) core of contributors doing high-impact work. This is particularly evident in FOSS projects where there’s no large entity(ies) steadily paying collaborators of any kind (like IFT and its projects).

After the IFT All-Hands, it became clear: if the goal is to scale open source, grow healthy communities, and build resilient ecosystems, then designing for users isn’t enough. The real leverage is in designing for contributors.

What does “scale open-source” mean? Scale and leverage to whom?

Regarding OSS collaboration from developers, many contribute for mundane reasons and it’s perfectly fine, like technical curiosity, building a portfolio to increase job opportunities, because their company needs to move the needle a bit to the left, or just a dev scratching their own itch in a very specific way. For many, it’s not about making a long-term investment, especially when it comes to their (usually) free time. I don’t have the numbers, nor do I know of any reliable way to gather such insights, but based on my developer network and my own experience, these collaborators or style of collaboration are very representative.

Evidence of this can be seen by the lack of continuity in contributor commits in many projects, for example in our beloved git Contributors to git/git · GitHub. The contributor statistics in the Blender repo is another good example for the commit discontinuity over time, but it does have a vibrant community around the core via extensions.