> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
What you choose to put into your production environment is on you. Full stop.
There is plenty of good software out there, that is only useful in limited.
I wrote code for small drone. If you don't know what you are doing you can easily burn down your house, with one of those (lipo are no joke).
SQLlight is great software, but if you try using it in wrong situation, you are going to have a problem.
In my experience for most of the software, the only answer is: it depends on what you are doing.
And sometimes even not so good software is best solution for a problem.
Having had a professional career as programmer now for about a decade and a half, it's my considered opinion that about nine out of ten people getting paid to write software today really shouldn't be [paid to write software]. In other words, 90% of programmers or "software engineers" (what a sick joke that title is!) should be fired; the quality of software would improve dramatically.
As-is is a term used in warranty law to disclaim the seller's liability for faults in the item sold. The buyer accepts the item in the present condition, whether the faults are apparent or not
If you want to take it for free, then it is 100% on you to figure out if it's going to meet your needs and all the consequences (fixing any problems that may arise) are on your shoulders.
If you don't prefer that, you have the option to try to negotiate a support contract with the authors, for suitable payment.
What you can't get is assurance of production readyness for free.
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE ...
"Production-ready" means different things to different people. For many, "production-ready" means "we have a support contract with the software vendor". In that case, the project would never be usable in production. To others with higher risk tolerance, a 1.0.0 release is all you need! You'd have to consider each user before making a recommendation about production-readiness.
Instead the author offers the software AS-IS and you can decide for yourself. The author doesn't owe anyone anything, least of all a personal consultation about whether using the software is prudent.
An open source project (in most licenses) offers zero assurance of it being usable for production and that's what it means. If you want to use it for production you need to either (a) do whatever evaluations you feel necessary to ensure it will be stable for production for your needs, or (b) pay the authors for a signed support contract so they take on that responsibility.
Beyond what people have pointed out about the license:
Why should "production ready" be the default, and they have to put an explicit "Not production ready" if it isn't? Why not the other way round? Given that probably over 95% of projects on Github are not even close to production ready, the expectation should be the other way round: If they don't make claims it is production ready, then you should assume it isn't.