Posted on June 24, 2026 by Diana Todea (DevRel Engineer at VictoriaMetrics and Merge-Forward Neurodiversity chapter lead), and Ryan Etten (Senior Architect & Team Lead at Red Hat and Wisconsin CNCF chapter community organizer)

The open-source ecosystem thrives on a deceptively simple premise: anyone, anywhere, can show up and contribute. But that promise quietly breaks down at the edges. A contributor who needs written context before a synchronous call, or who reads a terse PR comment as hostility, or who simply can’t parse an issue template that assumes you already know the codebase – each of these people hits a barrier that no one designed on purpose, and that no one can see. These invisible assumptions embedded in documentation, communication norms, and project governance structures add up to real cognitive friction.

Merge Forward Neurodiversity group is a growing cloud-native community focused on neurodivergent (ND) open-source contributors and their allies. Originally formed as a space for people navigating the unspoken social and operational codes of the tech landscape, the community’s focus has steadily evolved.

That shift borrows a framing our cloud native audience will recognize. In operations, “Day 1” is launch – getting something running – and “Day 2” is the long, harder work of running it well over time. We’ve found the same distinction applies to accessibility. Over the past year, the conversation has expanded from Day 1 accessibility, centered on awareness and individual strategies for navigating existing systems, to Day 2 universal design, where the emphasis shifts toward reducing cognitive friction at the system level. This reframes accessibility not as an individual adaptation challenge, but as an architectural responsibility shared by maintainers, contributors, and ecosystem designers.

This post traces that evolution across 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 multiple other conferences, to the turn toward system-level design at Open Source Summit NA 2026 in Minneapolis. Each stop moved us further from “help individuals cope” toward “redesign the system.”

The Baseline: KubeCon + CloudNativeCon North America 2025 – “Agile for Every Brain”

The initial roadmap toward universal design began taking shape at KubeCon + CloudNativeCon North America 2025 in Atlanta, where foundational concepts around neurodiversity in engineering teams were introduced.

Focus Areas

Demystifying Neurodiversity in Cloud Native: Moving beyond clinical framing to explore how cognitive differences such as ADHD, autism, dyslexia, and dyspraxia may surface in distributed engineering environments.

Identifying Communication Anchors: Highlighting asynchronous communication patterns—such as written specifications and structured RFCs—as potential equalizers when expectations around responsiveness and tone are explicit.

Reducing Cognitive Overload: Offering approaches for restructuring high-pressure synchronous rituals (for example, fast-paced stand-ups) into more flexible, multi-modal update systems.

Takeaway

Inclusion at this stage was framed less as a compliance goal and more as a systems-thinking opportunity. Diverse cognitive styles can strengthen engineering outcomes by exposing edge cases and alternative problem-solving approaches that may be missed in more uniform working models.

Growing the Community: KubeCon + CloudNativeCon Europe 2026

As the conversation matured, the focus shifted toward scale, peer support structures, and shared practices across the broader ecosystem, including KubeCon + CloudNativeCon Europe Amsterdam 2026 and multiple other conferences. The ND community hub session was particularly well received, and we gathered excellent feedback from the on-site participants.

Focus Areas

Peer Mentorship Networks: Connecting experienced neurodivergent maintainers with newer contributors to share practical approaches to burnout management, focus strategies, and navigating rejection sensitivity in open-source contexts.

Allyship Practices: Supporting maintainers and community managers with actionable ways to reduce ambiguity in feedback, improve PR review clarity, and manage high-volume asynchronous communication.

Working-Style Readmes: Encouraging contributors to document collaboration preferences (“How to Work With Me” guides) to reduce social ambiguity in distributed teams.

Takeaway

These efforts demonstrated that structured community support can reduce isolation and improve participation. But this stage also exposed a persistent gap. We kept hearing two things at once. From contributors: I don’t see myself as having a superpower—I just see myself struggling with anxiety, or just trying to get by. And from managers and leaders, a steady stream of the same practical question: How do I start raising awareness for my teams? How do I onboard people around this? What are the best practices, and do you have any advice?  This highlighted a key limitation: much of the adaptation burden still rested on individuals navigating existing system constraints rather than on systems evolving to reduce friction by design. This realization has increasingly shaped the shift toward a “Day 2” approach.

Maturing the Movement: Open Source Summit NA 2026 – “Day 2 & Engineered Accessibility”

At Open Source Summit North America 2026 in Minneapolis, we hosted a Birds of a Feather session focused on this transition from individual adaptation to system-level accessibility. We ran it as an open, informal discussion, and the room did most of the talking.

A central theme was the need to critically examine the narrative of “neurotalent”: the framing of neurodivergent individuals as inherently exceptional or “gifted.” While often well-intentioned, this framing can create unrealistic expectations, obscure the breadth of neurodivergent experiences, and unintentionally marginalize those whose challenges are less visible or less compatible with high-output norms. 

One attendee, a system administrator with ADHD and autism, described how those traits became a genuine strength in his role—but only because his manager had built a direct, transparent, two-way relationship from day one. He could say plainly, “here’s how my brain works, tell me straight when something doesn’t make sense,” and trust that the candor went both ways. In a previous environment without that culture, the right move would have been to say nothing. To him, the “superpower” wasn’t an innate gift to be extracted. It was downstream of an environment that let him stop masking.

Neurodivergence is not a single profile but an umbrella term encompassing a wide range of cognitive differences, each with different strengths, constraints, and support needs.

A key talking point raised during the session was how organizations can define “best practices” when lived neurodivergent experience is so heterogeneous. Rather than searching for a single standardized model, participants emphasized the need for adaptable systems that reduce ambiguity, clarify expectations, and allow for variation in execution style.

Another recurring insight, particularly from engineering managers in attendance, was the strong demand for practical guidance on onboarding, management, and team design. This marked a clear shift from awareness-building toward operational implementation.

Focus Areas

Governance and Participation Models: Examining how maintainership structures and governance processes can unintentionally privilege highly synchronous, verbally assertive, or continuously available contributors.

Reducing “Blank Page” Friction: Improving issue templates, contribution guidelines, and documentation structures to make contribution paths more explicit, bounded, and navigable.

Strength-Based Contribution Mapping: Exploring ways to align work with cognitive diversity (for example, pairing deep-focus contributors with complex refactoring tasks, or visual thinkers with system design mapping), without rigid categorization or exclusion.

Takeaway

The session surfaced a broader structural concern: many open-source systems implicitly assume an “ideal contributor” profile—always available, highly responsive, and socially fluent in synchronous environments. Moving beyond this requires intentional redesign of workflows, expectations, and governance models toward more asynchronous and inclusive defaults.

It also reinforced that both contributors and maintainers are often under-equipped in this space. There is a shared skills gap: awareness alone is not sufficient without concrete operational patterns, training, and shared vocabulary that can be consistently applied across projects.

Where Do We Go From Here? Scaling Practice, Not Just Awareness

One clear signal from recent discussions is a growing demand, especially from engineering managers and maintainers, for structured, practical guidance on supporting neurodivergent professionals in real organizational contexts.

This marks a shift in the conversation from awareness toward systemic enablement and operational design. Key questions emerging across the ecosystem include:

• How do we support individuals when neurodivergence is highly variable and often invisible?
• How can “best practices” exist without flattening a wide range of lived experiences into oversimplified models?

There is also increasing interest in structured, recurring training approaches—similar in cadence to ethics or compliance training—so that teams and managers build a shared baseline understanding rather than relying on individual familiarity.

Alongside this, a concrete idea gaining traction is the development of Open Practice Library (OPL) practices for neurodiversity-aware collaboration patterns. This would serve as a living, community-driven repository of practical approaches for documentation, onboarding, feedback, and team design.

All of this answers the same underlying question we heard again and again: how do organizations move from awareness to consistent, ethical, practical application? No one has fully solved it—but the demand is now concrete enough that the next phase of work is building these tools, not arguing for their necessity. A reflection from the Minneapolis session has stayed with us: the value of revisiting past collaborations through this lens, and recognizing how differently things might have gone if communication norms and cognitive diversity had been better understood at the time.

Conclusion

Merge Forward Neurodiversity has evolved from a community focused on individual navigation strategies into a broader effort to influence how accessibility is understood and implemented across open-source ecosystems. True inclusion does not ask individuals to bend themselves around legacy systems. It builds systems that reduce unnecessary cognitive friction from the start.

Moving from intention to engineered accessibility is not a single initiative. It’s an ongoing redesign of how we communicate, collaborate, and govern—and it’s already underway. What it needs now is sustained participation from contributors, maintainers, and organizations across the ecosystem.

Join the Movement

Connect with the community on CNCF Slack channels (#merge-forward, #neurodiversity), participate in upcoming working groups, and stay tuned for local meetup chapters focused on practical, low-friction collaboration practices. You don’t have to identify with any of the groups to take part. We’ll be running multiple community hub sessions at KubeCon + CloudNativeCon NA 2026 in Salt Lake City this November; come find us.