Open-source ecosystems are built on a seemingly straightforward idea: no matter who you are or where you’re located, you can participate and make a difference. Yet that promise quietly falls apart at the margins. A contributor who needs written background before jumping into a live call, someone who interprets a brief pull request comment as aggressive, or a newcomer who can’t make sense of an issue template that presumes deep familiarity with the codebase — each of these individuals runs into obstacles that nobody intentionally created and that remain invisible to most. These unspoken assumptions baked into documentation, communication habits, and project governance structures accumulate into genuine cognitive strain.
The Merge Forward Neurodiversity group is an expanding cloud-native community centered on neurodivergent (ND) open-source contributors and those who support them. What began as a gathering place for people trying to decode the implicit social and operational norms of the tech world has gradually broadened its scope.
That progression borrows a concept familiar to our cloud-native audience. In the operations world, “Day 1” means launch — getting a service up and running — while “Day 2” refers to the harder, ongoing work of operating it reliably over the long haul. We’ve discovered this same distinction maps neatly onto accessibility. Over the past year, the dialogue has moved from Day 1 accessibility, focused on raising awareness and equipping individuals with strategies for navigating existing setups, to Day 2 universal design, where the priority becomes reducing cognitive friction at the systemic level. This reframes accessibility not as a challenge each person must adapt to alone, but as an architectural obligation shared among maintainers, contributors, and the designers of entire ecosystems.
This article follows that evolution through three conferences over the past year: from foundational awareness at KubeCon + CloudNativeCon North America 2025 in Atlanta, to community-building at KubeCon + CloudNativeCon EU 2026 in Amsterdam and several other events, to the pivot toward system-level design at Open Source Summit NA 2026 in Minneapolis. Each step carried the community further from “help people cope with the status quo” and closer to “rethink the system itself.”
The Starting Point: KubeCon + CloudNativeCon North America 2025 – “Agile for Every Brain”
The first real blueprint for universal design began to take form at KubeCon + CloudNativeCon North America 2025 in Atlanta, where core ideas around neurodiversity within engineering teams were first put forward.
Focus Areas
Making Neurodiversity Approachable in Cloud Native: Moving past a purely clinical lens to examine how cognitive differences — including ADHD, autism, dyslexia, and dyspraxia — might show up in distributed engineering settings.
Pinpointing Communication Anchors: Spotlighting asynchronous communication methods — such as written specs and structured RFCs — as potential levelers, provided expectations around response times and tone are made explicit.
Alleviating Cognitive Overload: Providing tactics for reshaping high-pressure synchronous routines (for instance, rapid-fire stand-ups) into more flexible, multi-modal update formats.
Key Insight
At this point, inclusion was viewed less as a box to check for compliance and more as a systems-thinking advantage. Diverse ways of thinking can improve engineering outcomes by surfacing edge cases and alternative problem-solving methods that more homogeneous teams might overlook.
Expanding the Community: KubeCon + CloudNativeCon Europe 2026
As the conversation deepened, the emphasis moved toward scaling up, building peer-support structures, and sharing practices across the wider ecosystem — including KubeCon + CloudNativeCon Europe Amsterdam 2026 and several other gatherings. The ND community hub session resonated strongly, and we received valuable feedback from attendees on the ground.
Focus Areas
Peer Mentorship Networks: Pairing seasoned neurodivergent maintainers with newer contributors to exchange practical guidance on managing burnout, sustaining focus, and handling rejection sensitivity within open-source settings.
Allyship in Practice: Equipping maintainers and community managers with concrete steps to make feedback less ambiguous, clarify PR reviews, and handle high-volume asynchronous communication more thoughtfully.
Working-Style Readmes: Encouraging contributors to document how they prefer to collaborate (“How to Work With Me” guides) in order to reduce social uncertainty in distributed teams.
Key Insight
These initiatives showed that organized community support can lessen isolation and boost participation. But this phase also revealed a persistent gap. We kept hearing two contrasting messages at the same time. From contributors: I don’t think of myself as having some special superpower — I’m just dealing with anxiety, or simply trying to get by. And from managers and leaders, a recurring practical question: How do I start building awareness on my teams? How do I bring people up to speed on this? What are the best practices, and do you have any guidance? This exposed a critical limitation: much of the burden of adaptation still fell on individuals working within existing system constraints, rather than on systems evolving to reduce friction by design. This realization has increasingly driven the shift toward
Evolving the Movement: Open Source Summit NA 2026 — “Day 2 & Engineered Accessibility”
At Open Source Summit North America 2026 in Minneapolis, we led a Birds of a Feather discussion centered on the shift from personal adaptation to accessibility built into the system itself. We kept the format open and conversational, and the attendees carried most of the dialogue.
A recurring thread was the need to rethink the “neurotalent” narrative — the tendency to portray neurodivergent people as naturally gifted or extraordinary. While usually well-meaning, this framing can set unreasonable expectations, narrow the perception of what neurodivergence looks like, and quietly push aside those whose struggles are less apparent or less aligned with high-productivity cultures.
One participant — a sysadmin who is both ADHD and autistic — shared that those traits became real assets in his work, but only because his manager established a candid, two-way dynamic from the start. He could openly say, “this is how my brain operates — tell me directly when something isn’t landing,” and know that honesty flowed both ways. In a previous role without that trust, staying silent would have been the safer bet. To him, the so-called “superpower” wasn’t something innate waiting to be mined — it was the result of an environment where he no longer had to mask.
Neurodivergence isn’t a single experience. It’s an umbrella covering a broad spectrum of cognitive differences, each bringing its own strengths, limitations, and support requirements.
Another major point of discussion was how organizations can define “best practices” when neurodivergent lived experience varies so widely. Instead of chasing a one-size-fits-all framework, participants stressed the importance of flexible systems that minimize ambiguity, set clear expectations, and accommodate different working styles.
A further insight that surfaced repeatedly — especially among engineering managers — was the hunger for hands-on guidance around onboarding, management practices, and team structure. This signaled a clear evolution: the conversation has moved beyond raising awareness and into the realm of practical execution.
Focus Areas
Governance and Participation Models: Looking at how maintainership frameworks and decision-making processes can unintentionally favor contributors who thrive in fast-paced, verbally driven, or always-on settings.
Lowering “Blank Page” Barriers: Strengthening issue templates, contribution guides, and documentation layouts so that pathways to contribute are clearer, more structured, and easier to navigate.
Strength-Based Contribution Mapping: Investing in ways to match tasks with cognitive styles — for instance, pairing deep-focus contributors with intricate refactoring work, or visual thinkers with system architecture mapping — without forcing rigid labels or exclusions.
Key Takeaway
The discussion brought to light a deeper structural issue: many open-source systems quietly assume an “ideal contributor” who is always reachable, highly responsive, and comfortable in synchronous, socially intensive settings. Breaking past that assumption demands deliberate rethinking of workflows, expectations, and governance norms — shifting toward asynchronous-first and more inclusive defaults.
It also underscored that both contributors and maintainers often lack the tools and training needed in this area. There’s a shared capability gap: awareness on its own isn’t enough without concrete operational patterns, consistent training, and a common vocabulary that can be reliably applied across projects.
What Comes Next: Scaling Practice, Not Just Awareness
A clear message emerging from recent conversations is the rising demand — particularly from engineering managers and maintainers — for structured, actionable guidance on supporting neurodivergent professionals within real organizational settings.
This represents a pivot in the discourse: from awareness toward systemic enablement and operational design. Several key questions are taking shape across the ecosystem:
- How do we support individuals when neurodivergence varies widely and is often invisible?
- How can “best practices” exist without compressing a vast range of lived experiences into oversimplified templates?
There is also growing momentum behind recurring, structured training — modeled on the cadence of ethics or compliance programs — so that teams and managers develop a shared foundational understanding rather than depending on individual goodwill.
Alongside this, a concrete idea gaining support is the creation of Open Practice Library (OPL) entries for neurodiversity-aware collaboration patterns. This would function as a living, community-maintained collection of practical approaches for documentation, onboarding, feedback loops, and team design.
All of these efforts address the same fundamental question heard time and again: how do organizations move from awareness to consistent, ethical, practical action? No one has fully cracked it — but the demand is now tangible enough that the next phase of work is building these tools, not debating whether they’re needed. One reflection from the Minneapolis session has stayed with us: the value of revisiting past collaborations through this lens, and recognizing how different the outcomes might have been if communication norms and cognitive diversity had been better understood at the time.
Conclusion
Merge Forward Neurodiversity has grown from a community centered on individual coping strategies into a broader initiative aimed at reshaping how accessibility is understood and practiced across open-source ecosystems. Genuine inclusion doesn’t ask people to contort themselves around outdated systems. It builds systems that strip away unnecessary cognitive friction from the outset.
Moving from good intentions to engineered accessibility isn’t a one-time project. It’s a continuous redesign of how we communicate, collaborate, and govern — and it’s already in motion. What it needs now is sustained involvement from contributors, maintainers, and organizations throughout the ecosystem.
Get Involved
Join the community on CNCF Slack (#merge-forward, #neurodiversity), take part in upcoming working groups, and watch for local meetup chapters focused on practical, low-friction collaboration methods. You don’t need to identify with any particular group to participate. We’ll be hosting multiple community hub sessions at KubeCon + CloudNativeCon NA 2026 in Salt Lake City this November — come connect with us.
