Matrix.org proposal to DG CNECT to fund FOSS maintenance

Social Experience Design 🎭 Sustainable FOSS
,
#1

After changes in the course of VC-funded Element.io the Matrix.org organization is stretched in resources and tooted an article describing the situation:

In response to Simon Phipps follow-up, Matthew Hodgson of Matrix drops a Google doc outlining a proposal to DG CNECT for funding of maintenance of major FOSS projects that are in use by the EU. Here’s the text copied out of the Google doc:

Oxygen: a concrete proposal for EU funding maintenance of open source infrastructure.

matthew@matrix.org - April 6th 2024

  • We propose that the EU allocates €100M a year (via DG CNECT or similar) to fund maintenance of open source infrastructure that EU states depend upon.
    • (For reference, this compares to ~€2M/year at NLnet, or ~€3M/year for NGI)
  • This targets larger multi-person projects (e.g. Matrix, Mastodon, Python, Rust, etc) which are operationally used by EU states as open source infrastructure.
    • Typical funding levels would be €1-2M/year - funding ~10-20 full-time maintainers as a coherent existing team, as required to keep larger projects coherently maintained.
    • One way of thinking about this would be that it is equivalent to a set of 6-month €50K NLNet grants… except that it would provide long-term support to the whole core team for the project, keeping it stable and intact, rather than each individual having to re-apply every 6 months. It would also be maintenance-based rather than project-based funding.
  • Exclusively funds maintenance, not feature development:
    • Bug fixes
    • Handling security issues
    • Security audits
    • PRs
    • Refactoring
    • Performance improvements
    • Keeping pace with best practices
  • The alternative for funding these projects is either:
    • Donations from users/organisations/philanthropists to the project’s non-profit foundation (e.g. The Matrix.org Foundation) or umbrella organisation (e.g. The Linux Foundation).
      • However, in practice the vast majority of private (and public) entities who benefit from the foundations take it for granted, rather than contributing to support the commons. As a result, consciously funding the commons via taxpayer funds would solve the paradox that the more successful a project is, the more it is taken for granted.
      • Also, raising non-profit funding is a large full-time business in its own right, which
    • Funding via for-profit business (e.g. Element) - which risks creating incentives which harm the open source commons, e.g:
      • Selling support contracts which could encourage the open source project to deliberately be hard to support, in order to sell support contracts. In turn, work required to fulfil support contracts distracts from the core maintenance
      • Focusing on building features (because features are easy to sell), but make the maintenance problem even worse.
      • Adopting an open core model, which encourages limiting the capabilities of the core open source project in order to make valuable proprietary add-ons (thus taking them out of the open source commons)
      • Switching to less permissive open source licenses, in order to make it harder for competing for-profit businesses to build on the software, thus hindering usability of the commons.
  • The funds would be distributed by NLnet or similar, with the criteria that:
    • It funds non-profit software foundations, umbrella organisations or independent maintainers - not for-profit businesses.
    • It funds maintenance of established FOSS projects which EU states are operationally dependent upon for their infrastructure (using the OSI definition of FOSS)
    • It does not fund experimental new FOSS projects (NLnet is surely much better suited to projects which are getting up and running), and it does not fund non-FOSS work, obviously.
    • Recipients do not have to be in the EU - the criteria is that the EU is dependent upon their work.
    • It provides a dependable ongoing source of funding for maintainers to maintain larger open source projects, without the core maintenance team being at risk.
    • It does not fund feature work.
    • Recipients would have to apply for funding.
    • Recipients would have to demonstrate use of funds towards maintenance (i.e. days clocked against PRs, bug fixes, security issues, etc).
    • Grants would renew assuming use of funds is demonstrably being utilised.
  • Potential recipients (unsolicited suggestions):
  • Potential problems:
    • Does this reduce the competitiveness of open source projects? Substandard projects may be kept artificially alive via government funding, rather than being outcompeted by alternatives.
      • I’d argue no: substandard projects will be forked and improved even if they are well-funded, if they are stagnating or not performing. And then the funding should shift to the improved alternative. In other words, the free market of open source will keep itself optimal quality - and the injection of funding will accelerate this process.
    • Does this help the xz/liblzma problem? (Would funds have helped Lasse maintain the project more successfully?)
      • I’d argue yes: even if Lasse didn’t want to work on liblzma full time, this could have helped him work with an umbrella org to help find trusted and funded co-maintainers to share the load.
    • Does an umbrella like LF with a large established non-profit fundraising operation provide a solution to this problem already?
      • Perhaps, but at the expense of independence of the recipient projects, who may not wish to surrender their independence to a larger umbrella org.
    • Could this give the government political power over which projects it chooses to support and which it doesn’t (and potentially cause a conflict of interest on controversial issues such as encryption?)
      • I’d argue no: governments already have many ways to exert control over projects via legislation; being worried about losing funding due to being at odds with the government politics feels like a lesser concern. Presumably this can also be codified.
    • Could this be seen as simply funding the R&D of for-profits which build on that open source project?
      • Yes - but the fact that this benefits everyone (both for-profits, governments, non-profits, individuals etc) is the nature of the commons. In fact the positive economic benefits of accelerating both non-profit and for-profit usage of the commons FOSS project should be significant, rather than the growth of the FOSS project being sabotaged by the limitations of self-funding.
  • Prior art
3 Likes
#2

My response to the Google doc:

Looking at the doc, you may also formulate a section on “value for money”. You formulated a “what we’ll spend it on”, but not what it yields, and how the yield is measured.

Assuming weaknesses wrt the FOSS project’s long-term sustainability if maintenance isn’t funded… how does its health status look like in a report, what are KPI’s, and what QoS metrics are prime indicators of project health?

And more general observations:

My thinking is that professional organizations take on FOSS in their stack too easily, without doing the same due dilligence they’d apply to buying some (expensive) commercial enterprise product or service.

They should know in what way they cut corners here in order to be able to gauge in what way their cost saving (“free stuff”) comes at a cost (more risk).

This is tricky, as enterprise support is also a means to offload responsibility to a 3rd-party.

With the expensive support contract you buy guarantees for service quality, uptime and timely responses, expert help in case problems arise.

FOSS projects aren’t always capable (or willing) to deliver that. In part an umbrella organization can take care of that. In part the FOSS project needs to ‘professionalize’ its own processes and governance.

I’d argue that things go beyond maintenance alone, and more of the full SDLC should be considered wrt sustainable FOSS.

Wrt umbrella organizations I also have some thoughts (maybe slight critique)…

In choosing them you select an entity hierarchically above you to which rules you promise to stick. Why wouldn’t a FOSS project obtain SLDC services on an equal footing (as peers) instead.

Having to choose an umbrella creates “siloed castles” that compete on provided services and reputation. This does not fit the decentralized ecosystems that innovate on decentralized technologies.

1 Like