> I can't go to purchasing and say “we should donate $50,000 on these 139 projects”, and it will definitely raise questions if you're paying for something vague or not clearly linked to a business value but selling support puts the project in the critical path for actually having to deliver it.
That's basically the point I'm making. Paying $75 for printed documentation is easy to justify if your job involves Perl. If four developers work on Perl code, that's $300, which is nothing to the company and a lot better than the $0 they're getting now. Another example would be prioritizing bug fixes and new features.
The problem I’ve seen is that it often goes more like “do we really need 4 copies, can’t they share?”, “isn’t the 2020 version still enough for 2021?”, or “isn’t that all online anyway?”, and even if it works $300 after overhead isn’t much developer time. Trying to do it sideways like this can be frustrating at large companies because the same place which will pay an enterprise vendor 7 figures to have the privilege of training the vendor’s support contractors will nickel and dime you for less familiar arrangements.
The bigger problem to me is that maybe I could do that for Perl but it’d be even harder to say I need printed docs for every single CPAN module used on a project. Maybe if the core Perl team gets a ton of support they can spread some around but that’s tricky to match to the projects most in need.
I work on a number of projects but they're all relatively small so even if the money was coming in it wouldn't be enough to hire someone / quit my job and that means that you're in a dynamic where what'd help most is contributing developer time but that's a lot harder than making a purchase for most organizations. If I offered paid support (or sold books or trinkets) it'd almost certainly bring in 1-2 orders of magnitude less than it'd need to transform the project structure.