Stepping Down as Libxml2 Maintainer

Original Article ↗ Hacker News Discussion ↗

Open source maintenance and burnout

  • The maintainer is stepping away after a decade of largely unpaid work, citing sanity and dignity, not a desire to abandon the code.
  • Many see this as another example of “critical infrastructure maintained by one tired person,” echoing the common XKCD metaphor.
  • Commenters note that other XML-related libraries (e.g., expat) are similarly underfunded and understaffed.

Corporate responsibility and “software building codes”

  • Some argue for regulations or “software building codes” for critical and commercial systems: SBOMs, declared specifications, basic QA, active maintainers, and vulnerability requirements.
  • Others counter that open source licenses already disclaim all warranties, placing responsibility squarely on integrators and vendors.
  • EU’s Cyber Resilience Act is mentioned as a light version of this idea: unpaid hobby OSS is exempt, but companies must take responsibility for OSS components they use.
  • There is debate over whether such regulations would lead companies to sponsor OSS or simply push them further toward proprietary ecosystems.

Licensing strategy and AGPL fork

  • The maintainer plans an AGPL fork; many expect corporate users to prefer maintaining permissive forks rather than adopting GPLv3/AGPL code.
  • Several commenters advocate strong copyleft (GPL/AGPL) “from day one” plus paid commercial exceptions, arguing permissive licenses enable “beggar barons” to profit without funding maintenance.
  • Others note practical complications: CLAs, copyright assignment, contributor resistance, and corporate GPL aversion.

libxml2’s future and ecosystem risk

  • libxml2 is deeply embedded in many stacks (XML standards, SAML, HTML tooling, libraries like lxml/nokogiri/xsltproc), so abandonment poses real risk.
  • Some expect a large company to fork and minimally maintain it for security patches; skepticism remains that they will pay the current maintainer instead.

XML complexity, alternatives, and scope reduction

  • One camp urges reconsidering whether full XML feature sets are needed, proposing smaller, subset-based parsers or DOM-only libraries for many use cases.
  • Others respond that standards (SAML, RSS/Atom, various industry formats) rely on broad XML features, and each user needs a different subset, which tends to recreate large, complex libraries.
  • Streaming parsers (SAX-style) and alternative libraries exist, but large or legacy XML datasets still demand robust, feature-complete implementations.

XSLT and browser support

  • XSLT (especially 3.0) is seen by some as an underfunded but powerful technology for templating and text markup on the web.
  • Others say browser vendors are moving to drop XSLT support, partly due to libxml2 security/maintenance issues and a belief that XML/XSLT are dated and niche.
  • There is disagreement on whether browsers or vendors should invest in fixing XSLT or let it wither and reduce web-platform complexity.