The “O” in “FOSS” does not stand for “obligation”
This post is inspired by the months-long temper tantrum thrown by Matt Mullenweg, but it could just as easily apply to any number of conversations that happen in the FOSS ecosystem. Software users get mad when a bug isn’t fixed. Companies get mad when competitors make money off of “their” FOSS projects.
Apart from license terms like reciprocity or attribution, FOSS licenses do not place obligations in either direction. We have to stop pretending like they do. We have to expect that when we release software under a license that allows people to use it to make butt loads of money as a downstream product or a competitive offering that some people will. We have to expect that software provided “as-is” will sometimes not get bug fixes or improve their security. We have to expect that bags labeled “Dead dove. Do not eat” will, in fact, contain a dead dove.
None of this is to say that is to say that those are the ideal choices. Supporting upstream projects with labor and/or money is important to the sustainability of the project. Fixing vulnerabilities and other bugs — or better yet: preventing them in the first place — is a net benefit for computing. But unless they actually made a commitment, don’t be upset when they don’t meet it.
This is, perhaps, a vestige of FOSS’s roots. FOSS started in small, collegial circles. In the early days, implicit obligations could be socially enforced. We could depend on people’s good behavior. FOSS has long since grown into a global phenomenon with many different community cultures. And it’s Big Business™, too. Implicit obligations no longer work. We need to motivate the behavior we want to see instead of being upset when it doesn’t happen. In a post where I mentioned this dependency on good behavior, my friend Ruth quoted Robert Heinlein: “Never appeal to a man’s better nature. He may not have one.”
This post’s featured photo by krakenimages on Unsplash.