Your only obligations are the promises you make
One of the realities of creating open source software is that people will come along and say you must do something. Often, this happens to be a something that’s very valuable to them. If you’re lucky, they’ll help you do it. Much of the time, though, that’s not the case. But no matter what users or best practices say, the “O” in “FOSS” still does not stand for “obligation”. Unless you’ve committed to doing something, you don’t have to do it.
One good example is having a process for people to privately report security bugs. This is widely accepted as a best practice because it allows for vulnerabilities to be fixed before they’re broadly known. Although this doesn’t entirely eliminate the possibility of a bad actor taking advantage of the vulnerability, it reduces the risk. But that process adds overhead for maintainers, and it puts them in a position to make a fix by a particular deadline. For volunteer maintainers in particular, this can overwhelm the rest of the project work.
This is the conclusion that Nick Wellnhofer, the (sole) maintainer of libxml2, recently reached. He decided to no longer treat security reports as special. Instead, they will be treated just like any other bug report.
The reactions that I’ve seen are almost universally supportive. This is the right approach, especially considering that libxml2 “never had the quality to be used in mainstream browsers or operating systems to begin with.” Just because big companies decided to start using a project, that doesn’t mean the maintainers suddenly have to produce production-quality software. Wellnhofer set the expectations clearly, and that’s the only obligation that he has to meet. If that’s not acceptable to downstreams, they are free to use another library or to make their own.
This post’s featured photo by Andrew Petrov on Unsplash.
