OSS + ELC EU 2026

Successful Open Source projects have always had to balance the need to work towards long term sustainability and growth with meeting shorter term issues such as immediate funding and human resourcing needs. Projects would generally work to an annual rhythm to align with budgeting and funding decisions made by corporate supporters, and annual planning cycles were in many places well established. However, this rhythm has been hugely impacted by the new age of AI and the pivots in focus of the commercial tech industry. Long term planning feels impossible, and funding work sustainably feels increasingly out of reach when projects are reliant on companies engaged in an AI arms race. Once-robust human processes now move too slowly to be effective, and the key individuals that still need to be a part of this new world increasingly feel like they are a day late and a dollar short for everything. This talk looks at how the human side of Open Source is being affected by these shifts, and how communities can consider how to respond to these challenges.

I'm a psychologist and researcher at the [Software Stewardship Lab](https://stewardshiplab.org/). Moved by the extent of burnout among Open Source developers, I have written what I believe to be the most comprehensive report to date on burnout in Open Source. This entailed a review of the academic literature, a qualitative analysis of online discussion in the OSS community, and interviews with OSS maintainers.

I present 5 factors my research identified that contribute to developer burnout: difficulty getting paid, workload and time commitment, maintenance work as unrewarding, toxic community behaviour and hyper-responsibility. I discuss 3 structural changes we can make to address developer burnout: make it easier for OSS developers to get paid, distribute maintenance responsibilities, and strengthen developer community, solidarity and capacity for advocacy. Finally, I preview the findings of a follow-up study I am currently undertaking exploring the impact of the rise of AI coding on OSS developer burnout, including where it is exacerbating existing causes of burnout, and where it might help alleviate them.

Whether you care about open source projects for the success of your business or to retain your basic human right to access digital technology, it is in your interest to understand the risks these communities face and what you can do to mitigate them.

This presentation will provide you with a list of risk factors, from bad practices to mindset, that imapct the sustainability of open source communities. The talk will provide details of studies and real-life experiences to outline why certain behaviors, practices and approaches, most often without any bad intentions, are harmful to the open source ecosystem.

You will also receive tools and actionable steps to improve the sustainability of the open source projects you care about. The session will also give you ideas how to implement practices into your workflow, whether you are relying on open source software as a buiness or as an individual.

X-Road started as Estonia's internal government data exchange layer. Today it is open source, deployed in over 20 countries including Finland, Iceland, and Japan, and maintained by a cross-border foundation. I build software on top of X-Road every day in Tallinn, so I interact with this system as a practitioner, not just someone who read about it.

This talk covers: the governance model that allows countries with different legal systems to contribute to the same codebase. How X-Road handles backwards compatibility when your users are governments that cannot afford breaking changes. The trust model that lets citizens see exactly who accessed their data. And what this journey from closed government software to open source infrastructure teaches other projects about sustainability.

I am not an X-Road maintainer. I am a software engineer who uses it in production and an HCI researcher who thinks about how people interact with systems like this. Most talks about X-Road come from the people who built it. This one comes from someone who lives with it.

Sovereignty rhetoric is creating new openings for commons-based approaches to organising around, governing, and investing in public digital infrastructure that works for a plurality of Member States. This is partly what is proposed via ongoing initiatives like the Digital Commons EDIC and the Open Internet Stack. That said, the European Commission risks absorbing them while adopting largely statist, protectionist, or purely industrial framings that hollow out their meaning.

This talk navigates that tension directly, drawing on research from the NGI Commons project to offer a clear-eyed account of where things stand and what communities, researchers, and advocates can do about it. This talk begins by mapping these concepts with precision: what each means, how they relate, and why the distinctions matter for anyone trying to advance a genuinely commons-based agenda as part of these existing initiatives.

From there, the talk examines the current EU policy moment: the sovereignty turn, the competitiveness and industrial policy logic now dominating digital debates, the AI race framing, and what these shifts mean for the digital commons and the EU’s broader tech sovereignty ambitions.

The enforcement window for the EU Cyber Resilience Act (CRA) is arriving, triggering corporate compliance panic. While individual open-source developers and volunteer maintainers have zero obligations under the CRA, their downstream commercial adopters face mandatory due diligence requirements. How do Maintainers survive being bombarded with manual security questionnaires and subtle attempts to shift regulatory liability upstream?

The co-chair of the OpenSSF Global Cyber Policy Working Group and co-creator of the CRA Readiness Guide for Maintainers will walk you through converting the OpenSSF voluntary checklist into automated repository-level defenses. Attendees will see how to deploy the open-source OSPS Baseline Scanner GitHub Action to perform security gap analysis, expose standardized project postures via machine-readable security-insights.yaml files, and anchor liability disclaimers into repositories to push due-diligence burdens back downstream.