As usual, FOSDEM 2025 was associated with a bunch of fringe events happening before and after the crowded conference. Among them this year was the FOSS license and security compliance tools workshop, which discusses software composition analysis, supply chain, and dependencies, and I had the opportunity to listen to Michael Winser, co-founder of the Alpha-Omega Project. He presented the project's work and provided very interesting - and valuable - feedback from their experience assessing the security of some well-known open source projects.
I believe that one of the missing blocks in the institutional funding of open source projects is the maintenance part -- it is relatively easy to get funding for feature-packed new versions and "innovative" solutions (see as an example the very successful NLnet grant scheme), but after the 2 or 3 years of innovative development, there is nothing left to actually do the maintenance. While we regularly hear about the importance of supply chain security and dependency health, this looks to me like a gaping hole in the funding of our ecosystem as a whole, effectively leading to unmaintained, or under-maintained, code that will be reused everywhere. No need to mention the usual xkbcd here (oupsy, too late) or the 2024 xz attack. So when it came to questions, I raised the point of maintenance funding and got a very good, and thoughts-provoking, answer. Let me share it with you.
The point I retained is that maintenance is not so much about funding, and is a lot about caring. He did put forward the 3F framework for dependency management for better handling of supply-chain dependencies in the open source ecosystem. At the end of the day, when you have a dependency that needs some fixes or improvement, there are three options: Fix it, Fork it, or Forget about it. In that order. There is a fourth F for funding, but it is a lot more complicated to achieve -- dependencies buried 6 layers under a mainstream product will never get the funding they deserve. Please go read this very insightful piece of thoughts, I highly recommend it.
One example provided during the discussion was about one deeply hidden dependency, for which the project author had not applied the automatically proposed security patch. So they reached out to them, proposing to have a look and start a conversation. The author's reaction was like: "Wow, a human coming to me and telling me about my software! Sure, I'll fix it immediately!". We are so much submerged by automatic emails, answers and PRs, that it has lost its sense. Having someone - a real person - letting you know that you are important to them and that they are ready to help obviously brings joy, answers, and efficiency. No doubt about that, I would do the same. And probably would you, right?
As an open source user and developer, I am guilty too: I have used dependencies without letting their author know about my reliance on (and gratitude for) their work. Even if I have made some occasional contributions to upstream projects (issues, comments, PRs), it has not been enough - and, as Michael pointed out, I have not really investigated my dependencies to know about, and getting in touch with, all the people who have contributed to my piece of software through their work.
It is a duty we all share, and as far as I can tell, many of us miserably fail on this. We need to take a greater care of the people who, silently and thanklessly, make our own work possible.
This line of thoughts also resonates deeply with another concept, developed by Ivan Illich in his book "Tools for Conviviality". In a nutshell (and from my understanding), Illich identifies a limit, or threshold, when science or progress becomes too omnipresent, too self-centered, and eventually becomes counter-productive with regards to the issues it was supposed to solve. When giving it some thoughts, it is quite easy to identify a couple of areas where that applies, from cars to medicine or computers.
Bringing some conviviality, through human relationships, is part of this effort to keep the beast at a human size. FLOSS (Free, Libre, Open Source Software) is definitely more about community than mere code -- it is our driving force, and it is how we, as a community, are so strong and resilient. Taking a step back, it makes a lot of sense, and speaks volumes about our relationship to technology, resources, and communities. And it turns out that, maybe unsurprisingly, it's also good for security.
I still believe that maintenance funding is an issue. But now I am convinced that it is not the main issue, and that we, the FLOSS community, need to think again our own consumption of our peer's work. After all, our community never has had the big money, and we have been thriving and steadily growing over the last 50 years or so -- or, from my own participation, half of it. But while I will keep fighting for big corps to contribute back to the ecosystem -- if not for the commons, at least for the sake of their own security and sustainability -- I will just take even better care of my fellow peers. Say thank you. Start a discussion. Contribute even more. Buy them a coffee.
