Essential insights from Hacker News discussions

Libxml2's "no security embargoes" policy

The Tragedy of Neglected Open Source Infrastructure

A central theme revolves around the unsustainable funding model for critical open-source projects like libxml2, which are heavily relied on by large corporations. The initial sentiment expresses concern for the project's future and the lack of awareness of its importance within companies.

  • "Very sad read. Much of the multi-billion dollar project I work on is built on top of libxml2 and my company doesn't have a clue. Fuck, even most of my colleagues working with XML every day don't even know it because they only interface indirectly with it via lxml." - zppln

This leads to a discussion about the ethics of using open-source software without contributing back financially or through code contributions.

  • "Well, they need to pony up around $150k or so to keep it alive rather than freeloading off the work of others." - burnt-resistor
  • "It’s not freeloading to accept a gift given freely." - sneak
  • "> Ariadne Conill, a long-time open-source contributor, observed that corporations using open source had responded with ""regulatory capture of the commons"" instead of contributing to the software they depend on." - kibwen

Some argue that accepting freely given software doesn't constitute freeloading, while others contend that large corporations have a moral and practical obligation to support the open-source projects they depend on, drawing parallels to social norms of reciprocity.

The Burden of Security Reports and Maintenance

Another significant theme is the overwhelming burden placed on open-source maintainers by low-quality or impractical security reports, and how to balance security rigor with maintainer burnout.

  • "It'd be great if some of these open source security initiatives could dial up the quality of reports. I've seen so so many reports for some totally unreachable code and get a cve for causing a crash. Maintainers will argue that user input is filtered elsewhere and the "vuln" isn't real, but mitre don't care." - DeepYogurt

The debate considers the value of Proof-of-Concept (PoC) exploits and the question of who should be responsible for fixing reported vulnerabilities.

  • "At what rate though? Is it worth burning out devs we as a community rely upon because maybe someday 0.000001% of these bugs might have real impact? I think we need to ask more of these "security researchers". Either provide a real world attack vector or start patching these bugs along with the reports" - DeepYogurt
  • "“PoC or GTFO” is an entirely reasonable response." - bigfatkitten
  • ""PR or payment to fix or GTFO" is also a reasonable response" - duped
  • "I wouldn't bother to write PoC because it is a waste of time and it is faster to fix the potential bug rather than figure out what conditions are necessary to turn it into a vulnerability. I think that we all should stop writing PoCs for bugs and spend the lifetime for something more useful." - codedokode

Funding Models and the "Public Good" Argument

The discussion explores potential funding models for open-source projects, including government subsidies and corporate contributions. Several commenters argue for the importance of funding critical open-source infrastructure.

  • "IMHO, at least the foundations of what makes the Internet tick - the Linux kernel, but also stuff like SSL libraries, format parsers, virtualization tooling and the standard libraries and tools that come installed by default on Linux systems - should be funded by taxpayers." - mschuster91
  • "It's not the government's job to subsidize people's bad business models." - charcircuit
  • "They should be funded by the companies using them. Do you believe any of the fortune top100 would be greatly impacted by funding libxml2? They probably all rely on it, one way or the other." - chronid

Some suggest dedicated taxes/budget allocations within governmental bodies using farm subsidies as one practical example, while others believe the onus rests on corporations profiting from these tools. The challenges of scaling open-source as a "public good" is also raised.

The Motivations Behind Open Source and Licensing

The motivations behind open-sourcing software are also examined, with varying perspectives on attracting users and contributors.

  • "Why bother open sourcing if you're not interested in getting people to use it?" - xxpor
  • "So that if they find it useful, they will contribute their own improvements to benefit the project. I don’t think many projects see acquiring unpaying corporate customers as a goal." - bigfatkitten
  • "A decent part of my job is open source. Our reason for doing it is simple: we would rather have people who are not us do the work instead of us...Guess which projects stay open source." - gizmo686

The discussion touches on the role of licenses like the GPL in deterring corporate freeloading and encouraging contributions.

  • "I'm only half-joking when I say that one of the premier selling points of GPL over MIT in this day and age is that it explicitly deters these freeloading multibillion-dollar companies from depending on your software and making demands of your time." - kibwen
  • "We have a solution to this. It's called the (L)GPL. If people would stop acting like asking for basic (zero cost) decency in exchange for their gift is tantamount to armed robbery, we could avoid this whole mess." - OkayPhysicist

Finally, some contributors express personal satisfaction in making their software available for others to learn from and improve, regardless of widespread adoption or corporate use.

  • "You can want to be helpful without wanting to have power or responsibility. I'm interested in people (not companies, or at least I don't care about companies) being able to read, reference, learn from, or improve the open source software that I write." - lelandbatey