Simbiosi.org

What the EU Cyber Resilience Act Means for Open Source

2026-03-30T00:00:00+00:00

The EU Cyber Resilience Act (Regulation 2024/2847) is a regulation (not a directive: it applies directly in all member states) that entered into force on December 10, 2024. By September 11, 2026, manufacturers must report actively exploited vulnerabilities within 24 hours, with detailed reports within 72 hours. Full compliance is required by December 2027.

A Linux Foundation survey from March 2025 found that 62% of respondents were “not familiar at all” or only “slightly familiar” with the CRA. Only 28% correctly identified 2027 as the target year. 50% of stewards cited funding as their biggest gap.

September 2026 is five months away. This matters for open source right now.

Steward vs. manufacturer

The CRA introduces a distinction that matters a lot for foundations and maintainers.

A manufacturer places a product with digital elements on the EU market in the course of a commercial activity. They have the heaviest obligations: security requirements, conformity assessments, SBOMs, vulnerability handling, incident reporting.

An open source steward is a legal person (not an individual) that systematically provides sustained support for open source software intended for commercial activities, but does NOT place it on the market themselves. The CRA’s treatment of open source clarifies this distinction.

The FreeBSD Foundation is a good example. It employs developers, manages infrastructure, governs the project. FreeBSD itself is used in commercial products by Sony, Netflix, Juniper, and others. But the Foundation doesn’t sell FreeBSD: it supports an OS that manufacturers integrate into their products. Foundation = steward. Sony, Netflix = manufacturers.

Stewards have lighter obligations than manufacturers, but they’re not zero. Depending on the level of involvement (the draft guidance describes three tiers), stewards may be required to report actively exploited vulnerabilities within 24 hours and severe incidents within 72 hours.

Individual contributors are explicitly excluded from CRA obligations (recital 18). If you submit a patch to FreeBSD or the Linux kernel, the CRA does not apply to you.

Who’s working on this

I want to be clear: I’m not the only one who noticed these problems. There’s a large and active community working on CRA and open source, and I’m a small part of it.

The ORC Working Group (Open Regulatory Compliance) coordinates much of this work. Their Cyber Resilience SIG brings together people from foundations, companies, and policy organizations to review the regulation and draft guidance. The cra-hub repository tracks open issues, and the orcwg/orcwg repo collects formal feedback on the EC guidance. The Eclipse Foundation, Linux Foundation, Apache Software Foundation, Python Software Foundation, and others are involved.

There are also resources worth knowing about. The Linux Foundation published a free course on the CRA (LFEL1001). The OpenSSF has working groups on vulnerability disclosures and SBOM tooling. NLnet Labs has been contributing on upstream reporting. The Eclipse Foundation’s CRA page tracks their compliance approach. And the EC’s own consultation page is where formal feedback goes before the April 13 deadline.

Gaps I helped identify

Through the ORC WG’s Cyber Resilience SIG, I reviewed the EC’s 75-page draft guidance from a FreeBSD perspective (consultation deadline: April 13, 2026). Most of the gaps below are now tracked as GitHub issues with input from multiple contributors. I raised some of them, supported others, and in several cases the ORC WG had already flagged the same concerns independently.

Non-EU stewards have no clear CSIRT (orcwg #256). The CRA requires stewards to report vulnerabilities to a “designated CSIRT.” The rules for identifying the right CSIRT depend on where the steward is established. But the FreeBSD Foundation is in Delaware, the Apache Software Foundation in Delaware, the Python Software Foundation in Delaware, Mozilla in California. The guidance says nothing about which CSIRT applies to non-EU stewards.

Documentation language is unspecified (orcwg #255). The regulation requires documentation “in a language which can be easily understood by the market surveillance authority.” Most open source projects publish in English. National MSAs operate in German, French, Italian, Polish. For small foundations with limited staff, maintaining documentation in multiple EU languages is not realistic. And if a 24-hour clock is ticking on a vulnerability report, translation delay is not a minor concern.

The three-tier steward model is ambiguous (orcwg #258). The draft guidance creates three levels of steward involvement: non-technical support, IT infrastructure, engineering resources. The idea is that obligations scale with involvement. The problem is that most real foundations span all three tiers simultaneously. The FreeBSD Foundation does branding AND runs infrastructure AND employs developers. Which tier applies? The most demanding one, presumably, but the guidance doesn’t say.

The clock-start for stewards is undefined (orcwg #261, cra-hub #350). When does the 24-hour reporting window start for a steward? For manufacturers, the guidance discusses “reasonable degree of certainty” and the moment they “become aware” of an exploited vulnerability. But that language is entirely framed around “a product.” A steward doesn’t have “a product”: it supports software that shows up in many products. The trigger mechanism is different, and the guidance doesn’t address it.

Steward definition assumes publishing (orcwg #257). The guidance frames steward responsibility around “publishing” and “exercising primary control.” Many foundations meet the steward definition without directly publishing: publishing is handled by project governance. If publishing becomes central to the definition, some foundations could paradoxically fall outside it.

The funding problem

CRA compliance is not free. It requires dedicated staff time, tooling (SBOM toolchains, vulnerability tracking, reporting infrastructure), and probably legal counsel. The Sovereign Tech Agency funded EUR 686,400 for FreeBSD CRA readiness work, but that grant ended in December 2025.

Red Hat already has CVE Numbering Authority status and CSAF/VEX infrastructure. Canonical is marketing CRA compliance as an Ubuntu Pro feature. These companies absorb compliance costs as business expenses.

Foundations can’t do that. They rely on donations and grants. And the companies shipping products built on their software are classified as manufacturers under the CRA: their compliance spending goes toward their own obligations, not back to the foundations.

The CRA turns a chronic funding problem into an acute one. More money, more people, more structure needed, at the exact moment when all three are already stretched thin.

Where I fit in

I completed the Linux Foundation’s LFEL1001 course on the CRA in March 2026. I volunteer with the ORC Working Group’s Cyber Resilience SIG, where I review draft guidance, comment on GitHub issues, and bring the perspective of someone who’s been doing compliance work for 16 years and knows what it’s like to maintain an open source project.

I’ve contributed to several of the issues linked above, both on the ORC WG GitHub and on the EC’s consultation document. Some of my points were independently raised by others. Some I raised first. The important thing is that they’re being tracked and discussed, and the April 13 deadline gives us a concrete window to get this feedback into the EC’s hands.

If you work in open source and care about this, the best thing you can do right now is read the draft guidance and contribute your perspective before April 13. The ORC WG’s cra-hub and orcwg repositories are where the coordination happens.

Sources: EU Cyber Resilience Act (Regulation 2024/2847), EC Draft Guidance consultation, Linux Foundation CRA Readiness Report, ORC Working Group, ORC WG GitHub, FreeBSD Foundation CRA Readiness, LFEL1001 CRA Course. This post is part of the simbiosi.org open source sustainability research.

Your Donation Page Is a Checkout Form

2026-03-22T00:00:00+00:00

I’ve been looking at open source donation pages as part of a case study on the FreeBSD Foundation. What I found applies to most projects, not just FreeBSD.

The typical open source donation page has: a “Donate” heading, a payment form, a tax ID, maybe a mailing address for checks, and a note about employer matching. That’s it.

It answers “how do I give?” but never “why should I give?” or “what happens when I give?”

That’s a checkout page, not a fundraising page. It converts people who already decided to donate. It does nothing to create or increase motivation.

The behavioral research on charitable giving is pretty clear on what works. Most of it has been studied for decades. And most of it is absent from open source donation pages.

What’s missing (and what the research says)

1. Suggested amounts with impact framing

Most donation pages show an empty field. No presets, no context.

Tversky and Kahneman’s anchoring research (1974) showed that the first number people see shapes their decision. Fundraising professionals have known this forever: preset amounts with a “most popular” nudge increase average donation size.

But the bigger problem is the lack of context. “$50” means nothing. “$50 funds one day of CI infrastructure” gives the donor a concrete picture of what their money buys.

Before

Donate to the Foundation

Amount: $

Submit

After

Support the Project

$25

1 hour of CI

$50

1 day of build infra

Most chosen

$100

1 hour of release engineering

$250

1 security advisory

$500

1 day of dev salary

Other

Donate Now

The “most chosen” label is social proof and anchoring combined. The impact descriptions make the donation feel concrete.

2. Progress toward a goal

Most open source projects have a fundraising target. Almost none show it on the donation page.

A progress bar does two things: it shows the donor their contribution matters (the bar moves), and it creates urgency when the gap is visible.

Before

All of our work is funded by donations.

After

$730,000 of $2,000,000

$0$500K$1M$1.5M$2M

The Foundation is investing in CRA compliance and hardware support. Your donation helps fund this work without drawing further on reserves.

The reserve context note is important. It turns “we need money” into “here’s specifically what’s at stake.” People give more when they understand the consequence of NOT giving (loss aversion, Kahneman & Tversky, 1979).

3. Financial transparency on the page

Foundations publish financial reports. Almost nobody reads them. But if you put three key numbers on the donation page itself, the donor sees them at the moment of decision.

Before

(Financial reports linked somewhere in the footer)

After

$4.0M

Net Assets (2024)

$2.6M

Annual Investment

~18 mo

Runway at Current Pace

With your help

Reserves stabilize

Development, security, and compliance continue.

Without enough support

Hard choices ahead

Some programs may need to be scaled back.

Two scenarios, side by side. The “without” scenario is what actually happens when nonprofits run deficits for 4 years.

When you donate to a cause and you’re the only one, it feels uncertain. When you can see that 214 other people donated this year, and someone gave $500 twelve minutes ago, it feels normal.

Before

(nothing)

After

214

individual donors in 2025

Kirk M. donated

$500

12 min ago

Anonymous donated

$100

47 min ago

Sarah L. donated

$250

2 hours ago

This is the bystander effect in reverse. Instead of “someone else will donate,” you see that real people already did.

5. The headline

This one is small but it matters.

Before

Donate to the Foundation

After

The Project Needs Your Support

The first is a transaction. The second is an appeal. Research on prosocial behavior consistently shows that appeals framed around the recipient’s need outperform transactional framing.

A concept mockup

I built a concept redesign to show what this looks like when you put it all together. Zero JavaScript, pure HTML and CSS, using real financial data from public reports. A proof of concept for the Foundation or anyone else to adapt.

The mockup includes a campaign progress bar, preset donation amounts with impact framing, a revenue vs. expenses chart, budget allocation breakdown, corporate sponsor tiers, a value gap table showing companies that use the project vs. what they donate, and a recent donor feed for social proof.

All of this built with numbers already public. No new data collection needed.

This is not a criticism

The foundations and projects with bare-bones donation pages are not doing anything wrong. They’re engineering organizations run by engineers. Fundraising UX is not their expertise, and they have a hundred other things competing for their time.

That’s exactly why this matters. These are small changes. A volunteer with UX experience could implement most of them in a weekend. The behavioral research behind them is well-established. And for projects running persistent fundraising shortfalls, even a modest increase in conversion rate or average donation size compounds over time.

If you maintain an open source project, look at your donation page. Ask yourself: does it answer “why should I give?” or just “how do I give?”

If you have UX skills and want to contribute to an open source project, this is one of the highest-impact things you can do that doesn’t involve writing code.

The concept mockup uses FreeBSD Foundation data because that’s the case study I’m working on. The principles apply to any project. This post is part of the simbiosi.org open source sustainability research.

Why I'm Relaunching Simbiosi.org

2026-03-10T00:00:00+00:00

I maintained Remmina from 2014 to 2023. A GTK remote desktop client, 150,000+ users, 8,000+ commits from 200+ contributors. CI/CD pipelines, releases, bug triage, PR reviews, community management. On top of a full-time job, unpaid, for 9 years.

Total donations over that period averaged about 1,000 CHF per year.

That’s not a complaint. I chose to do it. But it taught me something that no conference talk or blog post about “open source sustainability” ever could: the people doing this work are invisible, and the companies building billion-dollar products on top of it have zero structural incentive to support them.

Everyone knows, at some level. The system just makes it easy to take and hard to give back.

The beginning

In the early 2000s I started Simbiosi.org with an idea: build a flat company, entirely based on Free and Open Source software. The concept caught the attention of Richard Stallman, who pointed me to the Free Software Foundation Europe. I co-administered GNU Herds, a not-for-profit association that aimed to bring together people and businesses for whom Free Software was more than just a development model: a job matching platform for the Free Software community. Then the FSFE had more urgent battles, and those plans went on pause.

That was over 20 years ago. The idea stayed with me.

What changed

The Remmina years changed how I think about open source. At some point the frustration almost got to me: bug reports from companies deploying the software on hundreds of machines, zero contributions back, and the feeling that nobody cared. I was close to hating the whole ecosystem, which would have been the wrong conclusion. Instead I started paying attention to what was actually happening: studying the projects that managed to get funded vs. the ones that didn’t, reading the behavioral research, looking at the economics behind the gap.

The incentives are set up so that nobody has to think about it. The software is free, the license doesn’t require anything, and someone else is probably funding it. Except nobody is.

Mancur Olson described this in 1965 as the free rider problem. Darley and Latane called it the bystander effect. Nadia Eghbal, in her 2016 Ford Foundation report Roads and Bridges, applied it directly to open source. The behavioral research has understood this for decades. The open source community is still catching up.

What simbiosi.org is now

Simbiosi.org is back as what it was always meant to be: advocacy for the people doing the work, backed by data. Not a business, not a consultancy. A community project.

Right now it’s mostly me: 30 years in IT, from GNU projects to cloud governance, former FSFE associate, currently volunteering on FreeBSD CRA compliance. But this is meant to grow. Bring your expertise to:

Case studies. Financial analysis of real foundations and projects. Public numbers, 990 filings, donor lists, behavioral research. Data, not opinion.
Fundraising and UX. Donation page redesign, grant writing, behavioral research. Skills that help projects get funded.
Policy and compliance. CRA analysis, regulatory impact, documentation. The EU is creating new obligations for open source stewards starting September 2026.

The first case study is on the FreeBSD Foundation. More coming.

Why “simbiosi”

Symbiosis. Two organisms that benefit from each other. That’s what open source should be: companies benefit from the software, maintainers benefit from the support. Right now, it’s closer to parasitism in too many cases. The value flows one way.

The name is a reminder of what we’re working toward.

What’s next

I’m starting with what I know best: real numbers, real analysis, real projects. If you’re a maintainer struggling with sustainability, or you work at a foundation trying to make the numbers work, I want to hear from you.

Find me on Reddit or LinkedIn. The project lives on GitLab.

Simbiosi.org

What the EU Cyber Resilience Act Means for Open Source

Steward vs. manufacturer

Who’s working on this

Gaps I helped identify

The funding problem

Where I fit in

Your Donation Page Is a Checkout Form

What’s missing (and what the research says)

1. Suggested amounts with impact framing

2. Progress toward a goal

3. Financial transparency on the page

4. Social proof

5. The headline

A concept mockup

This is not a criticism

Why I'm Relaunching Simbiosi.org

The beginning

What changed

What simbiosi.org is now

Why “simbiosi”

What’s next