> I've learned to draw much stricter boundaries.
Could you elaborate on what has worked for you?
I imagine people who work in customer service have strategies too.
ie JS/Node seems to attract more newbie users, so I wonder if that correlates with higher incidents of this
That's with the thought that maybe it's newbie users mostly being that source.
> I gave away ... the reward was
You're expecting a reward for your charitable work. A grocer faces its own hardship too (the late night alcoholic who trashes one of your aisle), but it's made bearable by the flow of income this provides.
Get paid. Like seriously. At least make the companies pay. You seem to be in exceptionnally successful with your project and well connected, why not try to start a kind of open-source consortium with other maintainers and companies to try to get some momentum into normalizing the fact companies should pay for the libraries they use. Surely, any company can throw 10k a year into open source projects, there must be a solution that doesn't leave people like you disgruntled.
especially under capitalism
At this time the amount of toxic bile spewed at the OSS project I work on outpaces any good coverage by about 2:1.
I'd shut the project(s) down after a fraction of that. Karens can keep developing it themselves.
I agree the key is boundaries. You will not be famous with them but you will enjoy your hobby and have a greater chance of forming real connections with them.
Once chat bots started yelling at me to update my repos, or submitting trash PRS, I made a new rule for myself. If someone wants a change I will let them make a pr and will read it when I want too.
So sorry to the million dollar teams making tens of million off my work but won't hire me for a job but my life is way more important no matter how much you yell.
I had someone pretend to interview me. During the interview they used vague language about one of my more tightly licensed packages asking if they could use it. I said no but if they gave me a role I liked I could agree with it. They cut off the "interview" immediately.
I also had multiple job offers not let me fill out my prior art.
It's slimy out there. Now that people can send code into LLMs and launder it I don't think it's very hopeful for individuals to enforce a license against any company making any money, and it's not worth it if the company isn't.
Echos a well known pattern in consulting that higher-paying clients cause less headaches than lower-paying ones.
It's very long and poorly structured, but it's valuable from my standpint. Don't read if you value your time.
---
Your article only covers the most well-known, largest, and established projects that meet both the technical definition of open source (open source code, under a free license) and the social definition (code is publicly available to everyone, free of charge, with both bug fixes and simple bug reports encouraged), and are also economically attractive to businesses (more on that later). There may be a couple of hundred such successful projects. A drop in the ocean of open source.
From my experience, I believe that the lack of mention of this distinction between technical and social open source is the main cause of disagreements, disputes, and, ultimately, burnout due to misaligned social expectations.
---
FFmpeg vs. AWS (spoiler)
https://x.com/FFmpeg/status/2024934828961923514
This can even be seen in your screenshot of AWS vs. FFmpeg in the article: the author of the FFmpeg Twitter account repeatedly believes that corporations owe something since they use open source code, even though the license doesn't obligate them to do so. Moreover, when Google launched its fuzzing program (objectively the most advanced in the industry), which automatically identifies and reports security issues (which is a significant contribution in itself), FFmpeg wanted not just code fixes but also Google to pay them for the maintainers' time!
We came up with LICENSE.md, but we didn't think of SOCIAL.md.
---
In other words, it's a digital version of the tragedy of the commons, in which the cycle repeats itself from project to project:
* Initially, some technical open-source software is created, under a free license, to solve a specific problem, either for oneself or for a limited number of people.
* First, a few users appear, saying it would be nice to have such-and-such a feature—the authors implement it, since it's not that difficult and generally useful.
* Then, as users grow, handling their requests becomes tedious—often, features are offered that the author will never use, or support for a platform requires a significant amount of code that the author isn't interested in, and they can't test the software on.
* The worst thing is when the software becomes popular (especially if it works reliably and is unique in its kind) and some other large project starts using it. Congratulations, your project is now a public good. In a single day, the burden of social responsibility for any bug or security issue falls on the shoulders of the author/maintainer, because it now affects not only the initial limited user base, but potentially millions of users of other software that relies on both your code and you directly.
Until the final stage, you could sit down, think, and determine what exactly you're doing, and take steps to prevent this or that scenario (or, conversely, develop deliberately toward that scenario). But once that happens, it's too late to do anything. You've effectively become a provider of social software, with all its advantages and disadvantages, and it will be very psychologically scary to say "no" to people and somehow get out of this situation in the short term.
FFmpeg, for example, still refuses to recognize itself as social software, despite being used by hundreds of large projects and being the default distribution on desktop Linux systems.
---
How is this expressed? (spoiler)
FFmpeg's stated mission on its website is as follows:
FFmpeg is the leading multimedia framework, capable of decode, encode, transcode, mux, demux, stream, filter, and play pretty much anything humans and machines have created. It supports the most obscure ancient formats to the cutting edge. It doesn't matter if they were designed by some standards committee, the community, or a corporation.
This conflicts with the security needs of a wide range of users: the more multimedia formats supported, the wider the attack vectors available for users of any software that uses ffmpeg: video players, browsers, instant messengers, preview generators, etc. A security flaw in an old codec could lead to browser compromise if a user simply visits a page with a malicious video.
This isn't a hypothetical danger—errors in file format demuxers and multimedia codecs are among the most commonly exploited. Here's a very recent example (Dolby decoder on Android), and here's a more high-profile and complex one (JBIG2 to PDF on iOS/macOS).
It's assumed that programmers in third-party projects using the library have sufficient knowledge to correctly and securely configure the library in their software, as FFmpeg's primary goal is to ensure playback of a wide range of files, not to address the needs of developers who use the library as a dependency or the end users of that third-party software.
According to the ffmpeg Twitter account, its use on AWS isn't a sign of the library's success or quality, something to be proud of, but rather a significant psychological burden for the project, as the company provides neither funding nor human resources. One can only expect even more tickets in the event of problems, and a lack of fixes for bugs, which Amazon fixes only internally, rather than contributing back to the project.
---
If a project doesn't have any obvious distinguishing features that indicate it's not social, it's assumed to be so by default.
If a project is on GitHub, has a readme and an issues section, the average user or programmer will assume the author is writing for people, for society, for everyone around them, interested in developing the project, adding new features (especially those I need), and improving it in every way for the benefit of all users. After all, if that's not the case, why even publish it?
I used to have to explain the problem and the difference to an outraged public, but recently I came across an article by Jeffrey Paul https://sneak.berlin/20250720/the-agpl-is-nonfree/ comparing open-source code to a gift! My explanation boiled down to:
"Don't like the gift, it doesn't suit you? Throw it out and forget it!"
Money.
If you're making something that doesn't feel like a product (for example, a library that solves a specific problem that a non-programmer wouldn't be able to use, or even need), it would be a great success to get anything at all.
Have you ever considered donating (money, improved documentation, or code fixes) to such widely used and significant projects as glibc (a C library), FriBidi (a library for working with right-to-left scripts: Arabic/Hebrew), or libusb (a cross-platform low-level library for working with USB devices)?
Each of these libraries is extremely popular and has a user base of billions of devices. They're usually the ones people think about when something isn't working.
When I read articles like this one (remember the title: "How Can an Ordinary Developer Get Into Open Source and Is It Worth It?" The examples include free products created by corporations, or commercial products initially oriented toward open source, but open source), and I always wonder: what does open source even mean to the author? It seems to me that today it's analogous to an "open source business," with a hierarchy a la the cream of society (whom we'll be writing about, where it's prestigious to contribute your code) and some homeless people with their libraries at the bottom, who aren't even worth touching.
>>(quote from the article) I personally met someone who dragged out a PR for a week because he didn't understand what a CLA was or how to sign it.
Do you understand what a CLA is? Perhaps you should explain it to the reader, otherwise they might not want to contribute to such a project after the explanation? Perhaps the idea of transferring their copyrights to a corporation isn't appealing to them at all? Or maybe there's a code maintenance obligation for X years, and they're not even aware of it?
The presence of a CLA, if it mentions transfer of rights, usually means that for once, it's safe to shift responsibility for solving your problem to the maintainers by creating an issue, rather than digging around in the code. People won't complain, because they're working on the project for money and that's their job!
> One source of toxic behavior is entitled users.
It's hard to explain to people how insane things can get when you give away your work and time for free, in the hope that it will benefit people. Some things I've experienced:
This is just scratching the surface of the things I've had to deal with in my open source work. I've learned to draw much stricter boundaries.If you are going to get into open source communities you should go in with a plan for how you're going to deal with these kinds of things when they happen to you.