FOSSY (Free and Open Source Software Yearly) just wrapped its fourth year — this time at the University of British Columbia in Vancouver, BC. A few hundred developers, community managers, foundation staff, and advocates, people who care deeply about how free and open source software gets made and sustained.
I attended primarily for the Governance and Community Sustainability track. But as usual the hallway track was where I got the most value.
Here’s some of the talks that were particularly valuable.
Sustainability at the PHP Foundation
Elizabeth Barron from the PHP Foundation gave a talk that moved well beyond “we need funding” into specifics. The PHP Foundation (established 2021) now employs 13 contractors who produced 42% of all PHP commits in 2025. That was a pretty big surprise to me. At the ASF, we take the opposite approach – all code is by volunteers, but we staff infra and other operational things.
The PHP Foundation is at Open Collective, who, if you don’t know, are a fiscal hosting agency (ie, they just handle your money) and make both taking and spending money very easy for PHP.
One thing that she talked about that was particularly interesting to me was the idea of attempting to articulate how much it costs to run a project, and approaching sponsors with that number, so that they clearly understand where the money is going. This seems obvious in retrospect, but I don’t see many folks doing it.
She also mentioned thanks.dev which is a means to route funds down the dependency tree so that the less visible projects get some of the pie as well.
This felt like one of the more mature “here’s how it actually works” sustainability talks I’ve seen — less hand-waving, more spreadsheets.
The Art of the Fork
I gave a talk on planning for forks as a disaster recovery plan, and Edward Ly from NextCloud complemented it nicely with “Art of the Fork: Reclaiming Trust.” His framework for evaluating forks boiled down to three questions:
- What distinguishes my fork from the original?
- How hard is it to switch?
- How will the original project change in response?
Simple questions, but the kind you want written on a whiteboard before you commit engineering resources to either side.
Code of Conduct Research — With Actual Data
Shurui Zhou presented research on what happens after a project adopts a code of conduct — not opinions, but data from 100,000+ projects, comparing contributor patterns 3/6/9/12 months before and after adoption against matched control projects that did not adopt one.
Key findings:
- 77.4% of CoCs were never updated after initial adoption
- Both short and long term: increased new contributors
- Short term: some disengagement of existing contributors (quantitative only — reasons not investigated)
- Transparency reports (incidents, resolutions, response times) help signal accountability
The conversation in the room about why existing contributors leave short-term was interesting, if speculative. Based on anecdote, a number of people in the room suggested that the initial disengagement of existing contributors wasn’t necessarily a bad thing, but was people self-selecting to leave because they didn’t want to have to behave.
The data itself is valuable for anyone making the case to adopt or improve enforcement.
University OSPOs and the Student Pipeline
Stephanie Lieggi from UC Santa Cruz talked about lessons from running a university OSPO. Two things I noted:
- CURIOSS.org — a consortium spanning 30+ university OSPOs internationally
- UC Open Summit — an annual conference on a UC campus focused on academic open source
The persistent question: how do real projects get in front of students in a way that leads to sustained contribution?
AI + Free Software Development
A panel on generative AI in free software surfaced the tension well:
For: Help maintainers handle the overwhelming flood of inputs. Do the mundane so developers can focus on creativity. Lower the barrier for new contributors who historically were gated by coding expertise alone.
Against: Unearned confidence in wrong solutions. Massive walls of LLM-generated text are hard for humans to review. AI-generated PRs may be increasing maintainer burnout rather than reducing it. And while contributor numbers are at an all-time high, the number of maintainers isn’t budging — which raises the question of whether we’re creating contribution without creating ownership.
This lack of ownership is, IMHO, just an acceleration of the drive-by PR phenomenon that Github started, and must be addressed if we want longer term sustainability.
Encrypting your server
Romeo Solano gave a great talk on practical ways to encrypt your filesystem on a server that might not be physically accessible to you.
This was of particular interest to me because Romeo attended my “How to give a better presentation” talk last year at FOSSY, and we had talked some about ways to improve his stage presence. Romeo was funny, engaging, and informative, and his presentation was impossible to look away from. I was truly impressed.
I attend a LOT of conference presentations, and I don’t often add one to my list of “This is how presentations should be done.” This was one of them, for sure.
Overall
FOSSY is small and opinionated. That’s the feature. The conversations you have here — with foundation directors, long-time maintainers, university OSPO leads — happen because it’s 300 people, not 3,000. If you work on open source governance, sustainability, or community strategy, it’s worth your time.
FOSSY 2026 took place August 6–9 at UBC in Vancouver, BC. More at fossy.us.
Last week I was at the United Nations Headquarters in New York City for UN Open Source Week — a gathering that, even just by its name, tells you something about how far open source has come. This isn’t a developer conference. It’s not a vendor expo. It’s the United Nations convening governments, NGOs, academics, and technologists to talk about open source as a matter of global policy.
The event ran June 22–25 at UN HQ in the ECOSOC Chamber, then moved on June 26 to the IBM Building at 1 Madison Avenue for a community-led “Open Source Community Day” hosted by Red Hat. It’s not the kind of event I usually attend.
That’s not a developer complaining about vendor lock-in. That’s a government AI regulator saying the architecture of modern AI makes democratic oversight structurally impossible.
One of the more interesting ideas I encountered was the collapse of the distinction between Sovereign AI (nations controlling their own AI infrastructure) and Portfolio AI (diversifying workloads between hyperscalers and local compute). These are the same question at different scales. A country asking “how do we avoid dependence on foreign tech companies?” is asking the same question as an individual asking “can I run some of this locally?” The answer in both cases is open source — open weights, open models, open tooling. It’s the only path to that kind of independence.
The highlight of the event was the “OSPOs for Good” session, opened by Omar Mohsine (UN Open Source Coordinator) and featuring government ministers speaking about open source as a development instrument.
These are government ministers framing open source as national policy — as the tool that prevents their nations from becoming permanent technology colonies of whoever builds the largest proprietary models. The Next Einstein Initiative (“Will the next Einstein come from Africa?”) kept surfacing as a motif — talent exists everywhere; infrastructure and access don’t. Open source is positioned as the equalizer.

