The Community Devroom co-organizers will welcome attendees and give an overview of the day’s sessions.
What happens when your project grows up faster than you do?
The dynamics of the FOSS world allow for young and passionate developers to make real, lasting contributions; sometimes in places where they would otherwise never be taken seriously. As The Register put it, Rhino Linux was started by a "teen dream team". We had a bold, fast-paced start that threw us headfirst into the world of Linux maintainership. But while we shared the common goal of 'growing and improving' the distribution, our individual visions often diverged.
Being taken seriously has its burdens, too. It's easy to get in over your head - to lose direction, burn out, or stop communicating altogether - especially when there are no adults in the room to offer guidance. We banded together by chance, and had to discover our own limits through trial and error. Saying 'no' isn't easy, especially under the internal pressure to keep delivering at a steady pace, when everyone is deeply passionate about the project.
FOSS is no stranger to ever-shifting team dynamics, or to developers biting off more than they can chew; challenges that are only accentuated when all involved are still growing up. It's easy to lose sight of when to step back, and when to recognize the need to scale. As we have come to learn, if you want to be a systems maintainer, you need to maintain your own systems, too.
Join us as we retrace the human side of Rhino Linux - how we learned to build a team as young developers, what this project taught us about maturity, communication, and sustainability, and the lessons we hope others like us can take from our journey.
The four essential freedoms defined by the Free Software Foundation — freedom 0: the freedom to run the software; freedom 1: the freedom to study and change it; freedom 2: the freedom to redistribute; freedom 3: the freedom to distribute modified versions — are widely cited as the foundation of free software. https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms
But what does “freedom” mean when people with disabilities cannot meaningfully use, extend, and share software? Digital sovereignty is hollow unless the tools and communities respect accessibility. If a user interface or workflow excludes a segment of users, then the right to “run” or “modify” the software is in practice restricted.
This talk argues that accessibility (in code, UI, documentation, communities) is not an optional add-on — it is essential for the exercise of the four freedoms, and thus for true digital sovereignty. We will explore how CMS projects can embed accessibility into their governance, workflows and contributions so that every user can exercise the freedoms of use, study, share and collaborate.
It is great to see GitHub making significant efforts to improve their accessibility, and that of the tools that they give to the community. https://accessibility.github.com/
https://github.blog/open-source/social-impact/our-pledge-to-help-improve-the-accessibility-of-open-source-software-at-scale/
We will cover: • How exclusion of users with disabilities limits freedom of software use and modification. • The link between accessibility and community inclusivity: if you cannot participate fully, you cannot help shape the software. • Practical steps for CMS ecosystems (Drupal, WordPress, etc) to make accessibility a governance norm rather than a compliance afterthought. • A call to action: build tools, policies and default workflows so that accessibility becomes part of the infrastructure of freedom.
Open source communities thrive when every contributors can participate fully and safely. Neurodivergent contributors bring unique strengths such as pattern detection, hyperfocus, creativity, and non-linear problem-solving. But they also face invisible barriers that can limit their access and growth. This talk explores practical scenarios for fostering neuroinclusive communities from onboarding and mentorship to culture-building and leadership. Attendees will leave with lessons they can apply in their teams, projects, and meetups and welcome every mind within their communities.
In the last several years, a number of open source companies have attracted significant attention after announcing license changes. Not surprisingly, these shifts sparked backlash from open source enthusiasts, prompting some to create community-driven forks under open source foundations.
Now there is growing skepticism toward (single) company backed open source projects, with many arguing that open source projects should be run by neutral foundations to prevent future bait-and-switch tactics. But is foundation backing really the answer?
Drawing on over a decade of experience in both open source foundations and companies, Fatih and Ray will compare foundation-backed and company-backed projects across key areas such as governance, roadmap planning, community, and funding. They’ll explore real-world examples of successful—and not-so-successful—projects in both models.
Finally, Fatih and Ray will discuss why funding models should be just one of several factors in assessing the long-term viability of open source projects. They’ll offer a holistic approach for evaluating open source projects, helping developers and decision-makers make informed choices about which projects to adopt, support, or contribute to.
Ten years, 1,600 release votes, and a clear lesson: open collaboration works. Discover how Apache Incubator projects turned release reviews from rule-checking into mentoring, and what this decade of data reveals about building healthier open source communities. Description: What can we learn from a decade of release votes in open source communities? From 2015 to 2025, over 1,600 Apache Incubator release vote threads showed how project collaboration and growth have changed. In this talk, I’ll share practical lessons from analysing votes across more than 160 projects. You’ll see how better documentation, mentoring, and automation changed a stressful compliance process into a positive learning experience. You’ll learn about the changes: fewer rejections, quicker reviews, and a shift from a strict to a more collaborative tone. I’ll also discuss how release cadence reflects community health and what early warning signs to watch for before a project slows down. Whether you’re a maintainer, mentor, or contributor, you’ll come away with ideas to improve release workflows and help build stronger, more confident communities.
As open source became mainstream, companies started to allow or even encourage their employees to get involved upstream and even started to open source their projects. Having more people being paid to work on open source software sounds great at first. However, when people don’t get the education and support to integrate upstream work and mindset into their daily work the open source projects, and eventually the boarder ecosystem, suffer.
This phenomenon affects everyone from single-vendor projects to diverse communities, and from small projects to large communities, and eventually contributes to maintainer shortage and burnout. Addressing this is the responsibility of both individuals and corporations. So, where should they start?
This presentation will outline the different ways how corporate mindset and priorities harm open source projects today, including tasks and responsibilities in open source projects that fall short and obstacles that maintainers face on a daily basis. Attendees will learn what individuals can do to improve their own and their communities’ experience. Last, but not least, the talk will provide tools to educate employers about why and how maintaining key open source dependencies is strategic for a successful business strategy.
Many open source contributors, maintainers, and communities are anxious about the Cyber Resilience Act (CRA) and its potential impact on open source. It’s easy to feel that these obligations aimed at commercial vendors will somehow end up falling on volunteer maintainers, community projects, and the broader open source ecosystem. But that's not the whole story.
Thanks to strong, coordinated advocacy from the community, the European Commission actually understands the open source ecosystem far better than many believe. The CRA not only clarifies where responsibility lies—squarely on the vendors who profit from open-source components, as it should—but also introduces meaningful tools to improve sustainability, including the new attestation program, which has real potential to channel support back into the ecosystem.
A well-designed law, however, doesn’t mean there will be no impact.
Drawing on direct involvement in the CRA implementation process through the ORC WG and the CRA Expert Group, Tobie will walk through how these changes will affect open source communities in practice, why the underlying structure of the CRA makes sense, and how the open source communities can position themselves to benefit from it if they so wish to deliver more secure software more sustainably.
AI-assisted contributors can now produce patches that appear senior at first glance: fast, polished, and surprisingly complex. But many of these contributions arrive without the context, intent, or architectural understanding that maintainers rely on during review. This emerging pattern — the rise of the “Synthetic Senior” — is reshaping expectations around mentorship, review culture, and long-term project sustainability.
Maintainers face a growing dilemma: welcoming new contributors while navigating an influx of high-volume, low-context PRs that demand deep review time. Traditional mentorship doesn't scale to this volume, and without new guardrails, it’s a recipe for burnout. While platforms, including GitHub, iterate on systemic solutions to filter this noise, communities need immediate, practical strategies to protect their maintainers today.
Drawing on discussions with seasoned maintainers and data from AI tooling pilots across open source foundations, this talk offers community-centered strategies for adapting to the AI era without losing what makes FOSS resilient. We’ll explore:
This session isn’t about banning AI. It is about building the guardrails that protect human mentorship and keep free software communities healthy.
No community grows in isolation. This talk explores how intentional partnerships can amplify the reach, visibility, and sustainability of open-source and developer communities. Drawing from experience building collaborations for community-driven tech initiatives and contributing to Mautic, I’ll share how to design partnership models that are mutually beneficial, helping communities gain resources, new contributors, and event support while offering partners authentic engagement aligned with FOSS principles. Attendees will walk away with a framework for identifying, pitching, and maintaining partnerships that strengthen both community and corporate allies without compromising values.
Has the once vibrant and much-loved cloud-native community lost its spark? What was once an ecosystem fueled by collaboration and curiosity now feels increasingly defined by Slack channels, swag drops, and conference booths.
Despite an explosion of meetups, and events, audiences are thinning. Community fatigue is real and vendor influence often overshadows genuine grassroots participation.
Contribution activity has slowed, and several once-thriving open-source projects are experiencing a contributor drought. End-user organizations and sponsors that once championed community contributions are now scaling back, leaving critical projects struggling to sustain.
This talk takes a candid look at the past, present, and possible future of the open source community. Through data and insights from a few popular OSS projects we’ll explore the patterns behind this shift and what it means for the sustainability of open collaboration in the years ahead.
Headscale began as a learning project to work out “what was needed” to re-implement a Tailscale control server and unexpectedly exploded in popularity in the self-hosted and open source community as a home-labbers alternative to Tailscale.
Headscale has a vibrant community, about 6000 members in our Discord community and our Github repo has more stars than Tailscale’s open source client, but who's counting.
Three years ago I was hired as a member of technical staff at Tailscale, spending half of my time contributing and driving Headscale, ensuring the future of the project.
Headscale is a clone of Tailscale’s closed-source SaaS control plane, and it would be easy to consider it a competitor. Tailscale supporting Headscale this way is an unusual arrangement and sometimes raises eyebrows with "the internet".
It turns out that letting Headscale be autonomous and trusting it to run its own community complements Tailscale in a variety of ways. It helps people stay in the ecosystem. Homelabbers and self-hosted will use it at home, but bring Tailscale to work. Sometimes it even solves problems Tailscale can not.
Of course, it has not only been smooth sailing, and being a paid contributor has caused a lot of skepticism with some users fearing an “embrace, extend, extinguish” strategy, fueling conspiracy theories about our roadmap.
In this talk, I will share how the projects exist in symbiosis, the challenges of being a paid contributor, and how the stability of a corporate payroll has enabled Headscale to reach its current scale.
Before April 2014, OpenSSL was a backwater open source project with fewer than 10 regular contributors and 1 1/2 maintainers. Meanwhile its code had become a pillar of secure communication and data privacy in the industry. This was an unstable situation that was exposed when the Heartbleed bug became global news.
The way the OpenSSL project responded to this crisis was informed by the principles of open source. Jon Ericson, the Community Manager for the OpenSSL Foundation, explains how a security bug ignited community growth and how the open source community provides ongoing stability to the OpenSSL project.
Nearly every tech event has a Code of Conduct these days, but too often it’s treated as boilerplate, or as a box to tick. But what happens when someone breaks it? Like incident response, success depends on rehearsal, not documentation.
In this talk we’ll share practical lessons from over a decade of experience running events like DevOpsDays, Cloud Native Days and PostgreSQL conferences. How to set the stage for a safe event, talk through potential incidents, and what conversations will need to be had with different stakeholders.
Most importantly, it’s hard to build trust, but easy to lose trust. We will cover how to openly and iteratively develop your community’s Code of Conduct.
All Contributors is a project which helps us recognise all the types of contributions that build our open source communities and make them flourish. It defines a specification for acknowledging community members' work, whatever they contribute, as well as tools for easy management and presentation of this information. All Contributors is used by a wide range of communities, particularly those where key contributors are not well recognised by metrics more easily extracted from version control history.
Recently these communities noticed signs of poor health in All Contributors. When the website went offline, a group of users were catalysed in to action. Coordinated by Leah Wasser (pyOpenSci Executive Director & Founder, PSF Fellow) they committed to adopting the project and forming a new, sustainable team of maintainers.
With the context of All Contributors, I will tell a story of the decline and rise of an open source project. There will be a scattering of challenges maintainers face such as, burnout, technical debt, and lottery factor. However, it is also a hopeful story about how open source software can play critical roles, cultivate deep affection from its users, and, with community support, rise again.
Open source is suffering from its own success. Our community solved problems with minimal attention from the rest of the world for almost 30 years, slowly becoming the foundation of nearly every piece of software critical to everyday life. Now with increasing regulation around the world, evolving cybersecurity requirements, and changing corporate participation and funding, how do we ensure the ecosystem's continued success? The things that have worked for the first decades will not be the things that keep us going. We will look at sustainability not only as a funding problem, but also from the perspectives of global policy movement, security, and other intertwined issues that face open source in the coming years.
I'm a psychology researcher that has been moved by the extent of burnout in Open Source, and I've written what I believe to be the most comprehensive report to date on burnout among OSS developers. I reviewed the academic literature, conducted a qualitative analysis of online discussion in the OSS community, and interviewed OSS developers. I identified 6 factors that contribute to developer burnout: difficulty getting paid, workload and time commitment, maintenance work as unrewarding, toxic community behaviour, hyper-responsibility and pressure to prove oneself. I recommend 4 structural changes to address developer burnout: pay OSS developers, foster a culture of recognition and respect, grow the community and advocate for maintainers.
Open source communities depend on a steady influx of newcomers who ask questions, seek help, and build relationships. Future heroes have to start somewhere as newbies. But across the ecosystem, those early engagement signals are dropping—sometimes sharply. Generative AI is changing how people learn, troubleshoot, and participate.
This talk synthesizes new research and real-world data to explore how AI is reshaping contributor pipelines—and what open source projects can do to adapt before downstream participation suffers.