If a company is basing their livelihood on your library, they should (in my opinion) be supporting it somehow -- either by paying you, or paying someone to keep an eye on new versions.
The other choice is they are trusting you to fix bugs and not be malicious, which isn't (in my opinion) reasonable, as you get nothing in return.
Anyone can choose this strategy, and I don’t quite understand why more OSS maintainers don’t.
I'm very grateful for OSS projects and maintainers but this is an interesting question: is doing something for free a free pass for false promises (advertising)? If I commit to help someone for free I then have a responsibility to show up. If an OSS developer advertise their projects as production ready then they have a responsibility to honor what is promised. Otherwise it should be stated plainly that the project should not be used in production ("This is a hobby project, use it at your own risks"). Sure it's less attractive and can be incompatible with success and resume building, but it's not possible to have it both way.
Maybe it's important to you and maybe people you support -- but that has nothing to do with your right to make demands against someone who put their work out there for free.
If you need a guaranteed support model, you either do it yourself or hire a company to provide that for you. I've used _supported_ commercial software that's garbage, and I've used FOSS software which has been absolutely rock solid. Also, commercial or not, just because it's supported doesn't mean the problem will be fixed or a feature added.
If you aren't directly paying someone to be there for you, then you're trusting goodwill and/or the community at large to fill that role for you. If you need that assurance, pony up to one of the consultancies like IBM which will support "X" for price "$Y". That support you're referring to is available, at a price -- but doesn't necessarily involve the original contributors.
I've had far better luck with FreeBSD on servers for the past 20 years than I have with Microsoft Windows, but I also understood the deal: "Fix it yourself, or submit a bug report and see if anyone else wants to work on it."
The corporate software method: "Pay us lots of money to look into the bug report, and maybe we'll fix it, maybe we won't -- but you'll need to pay hourly until we determine if its a bug. Then MAYBE we'll refund your money."
The primary difference is that OSS gives you the source and the ability to fix problems on your own, without any involvement from the original contributors/projects. You can also hire any number of other companies to provide support. With a traditional commercial model, you're entirely at the mercy of the company which originated the software, and you likely have no rights to the source or tools which would enable you to fix the problem yourself.
… PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
I think it’s particularly clear, and that part is even in all capitals.
If you have a specific project in mind, have you read the license under which that project has been made available to you?
If it is under most of the common open source licenses, you will find that it already states very clearly what applicability and support you can expect (none).
You are free to pay for a support contract if you need anything beyond what the free license guarantees you.
Take it or leave it. Which works for the other side complainers too. The worm is available to be used for free by companies, because license said so.
But commercially this is unpopular because it means that companies have to actually account for the cost of maintaining a complex software stack instead of pretending all the open source dependencies maintain themselves.
Long ago at Sun the practice was that all code had to have an internal team maintaining it. If the code was brought in from outside that's fine, but some team internally still had to be where the buck stops for fixes. If all bugs can be fixed by bringing in updated version from open source, that's great. But if not, there's still a customer with a bug and it must be fixed by the internal team if that's what it takes.
Of course, this wasn't too popular with some management, since they wanted to bring in all the free code but offload all the work to unpaid volunteers, instead of budgeting for maintenance.
And I agree with you, that these people as their software ascends in use & importance, need support.
The term professionalization is dangerous to apply here though. There's a lot of baggage & constraint, power/hieraechy dynamics, employer/employee relationships that are no fun, are against the spirit of the thing. To have this vibrant, radical, free spirited altermative, & to turn around & try to consume the spirit of the thing, digest it into the the dun, boring, mundane mediocre shit-show world is a sure & sad way to wreck the thing. Yet these people deserve & need support somehow. Finding innovative ways to support those doing vast social good without binding & restricting them, without entailing them into your projects & curtailing their potential.
That all said, at this point, we just need to start funding these people far far better, step 1. These concerns about whether professionalization see destroys our golden vibrancy are abstract when so few (& only such select industrially useful) projects garner any support at all.
