As someone who worked for a large organization maintaining an OSS project, one issue I faced was how do you show impact? We used to have many organizations really love and use our project , but they would hardly give anything back to the project, including writing blogs where they could have shared some success stories. IMO github stars/pip downloads etc are not good metrics and these are even worser metrics in today's agentic AI world. Its so easy to fake these nowdays.
What do you mean? Do you mean that automated agents will needlessly download your code for no reason to bump up your numbers? Or do you mean that you can't compare your own project to other ones because they might be faked?
- https://boost-like.store/category/github-services/github-sta...
- https://www.socialplug.io/services/buy-github-stars
- https://buy.fans/buy-github-stars/
If any end user can have an effect on something, then it is not a useful signal of quality.
The real question, is if a project is "worth it" for your own fun. =3
> 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:
- People yelling at me in DM's when I didn't edit a podcast for community meetups in time
- Alcoholics joining in on FOSS meetups because they wanted attention
- People in the community getting spammed with crypto scams impersonating me that I had to answer to
- My work being whitelabeled and sold to investors to raise money to the extent people accuse me of stealing from others
- Smear campaigns making their way to my employer when I decided not to work on a particular open source project anymore
- I gave away hardware to community members; the reward was tech support requests
- Suicidal community members using me as a therapist (they claim I "saved their life"), followed by taking private (non FOSS) source code and giving it to to my competitors to advance their own tech careers
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.
> 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.
Echos a well known pattern in consulting that higher-paying clients cause less headaches than lower-paying ones.
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.
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 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.
I'd shut the project(s) down after a fraction of that. Karens can keep developing it themselves.
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!
> 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
First is who is going to pay? OSS is popular because it can be adopted without any payment, removing a key piece of friction. And companies are in the business of maximizing their profits, which is often done by minimizing their expenses. Perhaps this can be implemented by the government as a tax, but then borders enter the equation, both for where businesses incorporate, and where OSS developers live, making it a nontrivial matching challenge.
But the bigger issue with payments I see is trying to allocate money to the right OSS maintainers. Once money is distributed, scams will appear pretending to be a worthy OSS project, LLMs would be churning non-stop flooding the ecosystem with knockoff projects, people will dispute contributions to take credit for the work of others, and a flood of attempts to collect payments will arrive from overseas locations where the cost of living is low and any payment can be a windfall.
My own fear is the result of the latter problem would be a disaster for OSS maintainers. The workload to collect payments, proving the contributions are worthy and not a scam, would dramatically increase the burden on OSS maintainers, in a way that could destroy the ecosystem.
As a maintainer, the biggest major issue is that I don't want their money.
Even before you get to the broader ecosystem, I wouldn't want daily standups, weekly 1:1s, on-call rotations, weekly business reviews, monthly business reviews, quarterly reports, "emergency" all-hands meetings, mandatory compliance training, constant IT churn, zero-based budgeting, fighting for headcount, constant interviewing, fighting for management buy-in (and against active attempts at management sabotage), managing up, managing down, peer reviews, performance reviews, promotion boards...
I also don't want to spend six months negotiating a contract, sign an NDA, disclose tax records to prove I have other clients, maintain liability insurance, and etc., for one week's worth of work, during which I must track every fraction of an hour and itemize everything I do, followed by two months of dealing with some archaic billing system and another three months wondering if accounts payable will ever actually send the money.
I just want to apply my decades of domain experience in a community of deserved trust and feel like someone actually gives a damn.
And as soon as it's merged, an issue would be opened: it is critical that you immediately push a release and tag it as an emergency security fix so that everyone upgrades ASAP.
That's not how it works. Rather, very nice people will insert themselves into already established projects and start siphoning the money to themselves, their friends, their businesses and so forth. You have a problem with that? Then you are toxic and probably several different "-ist", and should be removed from contributing.
Likewise, in the open-source world, after a certain number of things start depending on your work, people often say it "should be considered a public good" - which is particularly confusing because public good seems something entirely different from its other well-known definition.
I think this whole idea of "if you make something nice that other people like, you are obligated to serve people forever" is totally bogus. I (well Claude+Codex) write a lot of LLM code these days and many of the base libraries are open source. If I had to write ratatui it would take a long time. But if someone decided to bully the ratatui maintainer I wouldn't ever know. And there's no way to un-bully someone anyway.
I wouldn't actually put this forward as an argument for the concept of "community ownership", but I will point out that there are many circumstances where the ownership of trees on your yard is actually significantly decided by the community you live in. Whether that's your HOA, or city regulations, or tree law, what you do on your own personal property is often not just your own isolated thing.
I like the approach ngrok took - made a v1 that remained open source, but once realized it had high demand, built v2 closed as a paid service.
Another approach is to offer professional services around it.
Basically it's very optional to accept the attitude of others that you should provide them value for free.
Personal opinion, I think western society at large has a ton of brain rot. People are increasingly falling onto monkey instincts. They'll gaslight you to death that you owe it to help but then try to almost murder you if you don't.
We’re talking about code that users can modify themselves to solve their own problems. That’s it. I don’t need to hear about the struggle.
That's exactly the kind of attitude that this discusses.
You create something that solves your problems, you put it up on GitHub, free, and open... Suddenly it turns out others have the same problems you did, your software solves them.
It starts ok. People are nice. But as it gains traction, a certain kind of toxic person becomes more and more common. The "YOU FIX IT NOW! I DONT KNOW" Kind of person.
You wake in the morning, look at your email, and it's a stream of being screamed at. That takes a toll.
All because you had an idea one time to build something that solved your problem you thought "hey I might just open source this".
> That's it. I don't need to hear about the struggle.
> This is an Open Source project that gets developed at the author's discretion. We provide paid work services for urgent fixes, cost is $500 per day with a minimum of 4 days.
Put that in the README, under a header that can be linked to in bug reports from entitled people. Worst thing that could happen is that the maintainer ends up earning a couple grand.