Libxml2's "no security embargoes" policy

I empathize with some of the frustrations, but I'm puzzled by the attempts to paint the library as low-quality and not suitable for production use:

> The viewpoint expressed by Wellnhofer's is understandable, though one might argue about the assertion that libxml2 was not of sufficient quality for mainstream use. It was certainly promoted on the project web site as a capable and portable toolkit for the purpose of parsing XML. Open-source proponents spent much of the late 1990s and early 2000s trying to entice companies to trust the quality of projects like libxml2, so it is hard to blame those companies now for believing it was suitable for mainstream use at the time.

I think it's very obvious that the maintainer is sick of this project on every level, but the efforts to trash talk its quality and the contributions of all previous developers doesn't sit right with me.

This is yet another case where I fully endorse a maintainer's right to reject requests and even step away from their project, but in my opinion it would have been better to just make an announcement about stepping away than to go down the path of trash talking the project on the way out.

I think Wellnhofer is accurate in his assessment of the current state of the library and its support infrastructure institutions. Software without adequate ongoing maintenance should not be used in production.

(Disclosure: I'm a past collaborator with Nick on other projects. He's a fantastic engineer and a responsible and kind person.)

Recall similar things were said about OpenSSL, and it was effective at getting corps to start funding the project.

It was not however effective at getting the project to care about quality or performance.

A large part of the problem is the legacy burden of libxml2 and libxslt. A lot of the implementation details are exposed in headers, and that makes it hard to write improvements/fixes that don't break ABI compatibility.

I think it's a way to say: "if you don't like what I'm doing, go fuck yourself"

The crux is these seemingly bogus security “bugs”. If there were quality issues, the amount of software and people using libxml by virtue of testing in production/wild would have found most issues by now.

There is plenty of software today that is tested within cost and schedule that’s closed source and it’s running in production. I get the point but libxml is not one of those cases