I think the biggest problem is the fundamental impedance mismatch between companies and independent open source projects, especially smaller ones. As any b2b s

I think the biggest problem is the fundamental impedance mismatch between companies and independent open source projects, especially smaller ones. As any b2b startup will tell you, the number one concern of a large client is "how do I know you'll still be here in a year?" They say nobody gets fired for buying IBM, but what they really mean is nobody gets surprised by IBM; nobody outgrows IBM and has to find a bigger vendor; nobody includes IBM insolvency in their contingency planning. IBM is predictable in the exact way an independent open source developer isn't. The mismatch is that an ideal vendor delivers a predictable result across a wide price range, and a small open source project just can't do that. Think AWS: you can spend $1 or $100,000 and you know exactly what you're going to get. It's not so hard to get $100,000 of value from an open source project: just hire the maintainer. But how do you get $1,000 worth? Or even $10,000? You can definitely get a result for that much money, but you can't get certainty. Unless you're paying that maintainer enough to live off, they're always just one really good coffee chat away from the loving arms of FAANG. I think the missing piece is a trustworthy intermediary to handle professional services contracts for open source projects. Rather than dealing with the overhead and uncertainty of a bunch of individual contributors directly, you just pay for one central service that covers your entire open source surface area. This organisation then contracts out to a network of interested open source contributors for maintenance and feature development. In many cases, this would mean the maintainer of the project, but it could also be someone on the team, a new maintainer if the project is abandoned, or even someone to keep a fork up to date if you need changes that upstream doesn't want. The point is you don't have to manage this in great detail: you just pay the money like you would with any other service. In this case, the service is "all my open source software works, continues to work, and will grow with my business" In order to be trustworthy, I don't think this could be a for-profit company. Many developers are skeptical of commercial interests in open source, and the larger independent projects often specifically limit the influence of any one company. For developers or companies to trust an intermediary, it would have to be provably acting in their interests. In other words: an independent non-profit with an open and transparent governance model. Further, I think it would need to be run by respected figures from various open source communities. Open source is fundamentally weird to people who don't deal with it regularly, and there are plenty of opportunities for boneheaded mistakes that destroy trust. Why contribute and engage with the community rather than fork everything? Why invest in existing contributors instead of paying the cheapest contract devs you can find? Why not use your leverage against contributors that don't agree with your decisions? The answer to all of those, as well as many similar scenarios it would be easy to imagine, is the same: it's bad for open source, which is bad for businesses that rely on open source. Businesses won't always know that or act accordingly, but an organisation working on behalf of the community will. And, of course, all of this only works if the projects and contributors in question trust it to do so. There is a fair bit of successful precedent for community-driven foundations (eg Linux Foundation), the professional services model (eg Red Hat), and project-agnostic funding (eg Google Summer of Code). But, as far as I know, no initiative that combines all three. That's not incredibly strong evidence that it'll work, but at least suggests it might, and it's not like we're exactly drowning in workable ideas for open-source funding.