When open source first started to become mainstream in the 90s, there was a good deal of debate about what 'free software' meant.
It wasn't just about something you didn't have to pay for, went the philosophy, it was also about being able to see the source code to understand what was going on, and to make your own changes.
'Free' as in speech, not 'free' as in beer, went the motto.
That's a good start, but it doesn't really go far enough; free speech has consequences but they're not the first thing people think of when you say that. The argument that 'all bugs are trivial when you have enough eyeballs' assumes that all those eyeballs belong to people who are looking, understanding, and contributing.
In a lot of cases, many eyeballs are shallow eyeballs, because everyone assumes that someone else has done the hard work of understanding the code. And as open source becomes widely used, there are many more people using open source code who aren't going to be expert coders in the language a particular project is written in -- if they're coders at all.
So I started saying that open source was also 'free as in puppy'. Yes, it looks cute, but when you bring it home you have to feed it, exercise it, clean up its messes and take responsibility for it. And when it grows up, that puppy may not be the small, cute, little project you saw in the window, so you need to look into the pedigree of that puppy.
As open source has become more important commercially, a lot more people have started talking about 'free as in puppy' -- because any software you pick up and incorporate into your business or your development workflow brings with it responsibilities. Key open source software that an entire industry relies on has been critically underfunded for decades; the Linux Foundation's Critical Infrastructure projects are an attempt to redress this, because it doesn't just happen on its own.
If you were using FoundationDB because you thought it was open source like the other NoSQL databases, because you'd never read the licence, you would have got a rude shock when Apple bought the company and pulled all the code from GitHub. Turns out it was only some code to help you use the proprietary database code that was actually open source.
If the open source puppy makes things sound too appealing, I sometimes say 'free as in mattress'. As in, there's a mattress leaning up against a wall, and anyone can take it home -- but without knowing where it came from, would you want to?
Now, open source is becoming so widely used that open source creators and maintainers are starting to feel the strain, not least because not all new open source users are polite, friendly, and considerate (nor indeed, are all experienced open source users).
It's great to report a bug in an open source project, or even write up some code to fix it and submit that as a pull request. But whether it's the sheer volume of reports, the users who are rude and demanding when they give feedback or criticize the direction of the open source project, the would-be contributors who offer code that doesn't fit the long-term direction of the project or just increases the maintenance work for the project, open source creators and maintainers are starting to talk about overload and burnout, self care, and prioritization.
It's a tragedy of the commons, because individuals don't scale the way technology does.
The usual answer is to suggest how important it is to have a community (formal or informal) around projects to share that load, but it's easy to forget how hard it is to build and nurture those communities. Look at the Node.js contribution policy to see how much work it takes to run a large community.
If you're working on building an open source community, take a look at Nadia Eghbal's (free) book, Roads and Bridges: The unseen labour behind our digital infrastructure.
Seeing the latest discussions about how widely unappreciated the work to maintain open source is made me add another free to my list: free as in 'night off'.
There's a reason that commercial software companies don't only have developers -- they have testers, support teams, marketers, and an entire ecosystem supporting the coders. A lot of larger open source projects are sponsored by or interlinked with commercial companies, because that ecosystem can be a thriving business, as well as taking a load off the coders.
Not everyone wants to add a commercial aspect to their open source project, so we need a wide range of models to make this work. But if we're not thinking about all the meanings of 'free' for open source, we're going to keep seeing unintended but very predictable consequences for code that we're all coming to depend on.