So on some level, I agree, and in particular I think that having these meta-organizations and middleperson organizations that essentially act as money-pits and then put in more of the hard work to distribute funds or support -- that's a great idea, and I'd love to see more stuff like that.
And I am grateful for companies that are putting the work in to try and solve these problems, we need more of that, so thanks for the work you have done and thanks for your thoughts on the problems.
I still have a couple of specific, narrow objections overall:
----
> Companies have budgeting and legal solutions laid out, its pretty much a first year problem.
> The issue is finding and getting money to these developers in accordance to tax code, jurisdiction/etc, its basically a regulation issue.
Who's more equipped to solve those problems, companies or unfunded developers building stuff in their spare time? Who has more lobbying resources to change tax laws, Microsoft or Open Source developers? Saying that this is a corporate/business problem is not necessarily the same as saying it's an easy problem, it's just saying that the stuff you you bring up above are company issues, not problems with Open Source. Open Source isn't broken, companies are broken in that they struggle to interact with or support the ecosystem in productive ways.
It's a business problem that budgeting is so rigid that companies can't on-the-fly budget (or never thought to budget in the first place) resources to maintaining infrastructure that they rely on. It's a business problem that businesses don't understand their supply chain well enough to know what they're relying on or how to get in contact with or support the projects that they're relying on to remain stable and secure. These are complicated problems to solve, but let's be clear about where they lie.
Yes, there are tax complications, there are regulations. These are also problems that companies are more equipped to solve than developers are; companies have legal departments that can help navigate taxes, and individual developers do not. It's a business problem that companies don't have mechanisms/infrastructure to distribute support to things they rely on without falling into complicated legal holes. Yes, there are problems of finding the projects that need funding, but once again, businesses are more equipped to examine their own dependencies than developers are to try and figure out everyone who's relying on them and how important their libraries are to those companies.
And yes, you are absolutely correct that not all developers want to get paid traditionally (or even paid at all), and that's a choice we should preserve. But in some ways, that's exactly why this is a corporate problem: it's good that people get into Open Source with different motivations and needs, and it is better for the tech industry to evolve and figure out how to support those developers through nontraditional means (QA volunteering, patches, documentation, attention/promotion, one-off donations, etc), than it would be to try and "professionalize" Open Source. Even in the scenarios where people want literally nothing, and they don't want to be critical infrastructure at all, it's still kind of the company's responsibility to figure that out and to figure out if they're comfortable taking on the risks, or if they need to either use something else or fork the project.
For all of its faults, Open Source works pretty well, that's why companies rely on it. And I think part of that is the messy non-commercial aspects, the accessibility of contributing that means a company might be using a library built by someone who's only 15 (which for sure makes corporate funding complicated), the lack of hard requirements or contracts that mean a developer might walk away from something a company is relying on -- these are not accidents, they're deliberate parts of the system that allow non-professional people to take part in building the commons and solving their own problems. And yet for all of that messiness, Open Source produces software that's good enough that businesses rely on it. So when we have a system that is producing good software that people rely on, but the funding methods and support methods that businesses are capable of engaging with don't always line up with that system -- this is a case where businesses and the surrounding tech industry that should change, not the system that's producing good software that people rely on.
I will note that in the case of log4j, the developers are interested in normal funding -- this specific situation isn't a problem with figuring out in what way to support developers, it's a problem stemming from the fact that businesses don't know how to analyze their dependencies and figure out which parts need support (which is why they didn't realize that log4j devs wanted funding), and that businesses don't know how to donate to those dependencies or that the businesses aren't flexible enough to make those donations using the payment systems that many Open Source developers prefer. So there are broader questions about what projects want support, but log4j is kind of one of the easier examples; if businesses can't figure out how to donate to this project without an invoice process (even if the reason why is complicated and protracted and multifaceted and hard to solve), then businesses really are just broken in this regard.