Mental Health in Open Source
antfu.me
antfu.me
Velocity is what you choose when you have a runway. The most successful open source projects like Emacs and GNU Make have been sitting around for about 40 years now, being slowly and steadily maintained by their owners. I've been working on a C library of my own for the past 6 years and it's only started to gain traction in recent months. If I was doing it as a startup my project would have been laid to rest in a charnel house long ago. But since it's open source, the only thing it's really cost me is time.
The workaround is to use GH Actions to auto-close PRs: https://github.com/marketplace/actions/repo-lockdown
The default reply to a feature request should be "patches are welcome". If the software is useful, people won't hesitate to contribute fixes.
That can get tiresome quite quickly. Sometimes you do submit patches but they still don't give you the time of day. Sometimes they don't actually want your code. Sometimes they only accept code from some inner circle you're not part of. You might end up wasting a lot of time only to hit these walls and end up with zero results to show for your efforts. Then one day you might discover that the maintainer committed some suspiciously similar feature to the repository all by himself.
People gotta stop acting like submitting code somehow elevates us above simple users. It really doesn't.
There is a fundamental difference between the duties of a maintainer and a developer. Just because some people are both doesn't mean they are the same thing.
Reviewing patches is real work, and often turns into mentoring/helping/directing the code, if you want to keep the software from turning into a ball of mess.
(Or saying "no, patches not welcome for this one we won't be doing it", or "not unless you can find an elegant way to implement it, according to me")
I don't find that reviewing patches (with all it entails as above) is often even less work than doing it yourself.
And that's why it's offensive when you request some feature but they just brush you off by saying "patches welcome". Let's say you show up with a patch. Now they'll engage with you, right? Nope. They can just as easily brush you off.
Maintainers know their projects and could have gotten it done in a fraction of the time it takes external contributors to do it. Truth is they probably don't really care about your feature or your contribution. Instead of just saying that they don't want it, they put up these barriers in order to subtly tell people to go away.
Wouldn't be so bad if it wasn't for the generally dismissive attitude. You ask for something, they imply it's beneath them and pretty much challenge you to show them the code. Does it mean they are prepared to accept your code should you rise up to their challenge? No.
* If people really don't want the feature and don't have time to review/work with you on a patch, they SHOULD just say so, instead of saying "patches welcome". Part of this is cultural, it's hard to say no.
* The other end of this bargain is we have to accept a "no", have to realize that the reason the package is good is because the maintainers keep it from becomming spagetti by saying no sometimes too, and by making priorities.
* EVEN THOUGH it can take maintainers time to work with a patch, there is STILL reason to ask for a patch. Sometimes it WILL take LESS time. But ALL the time it's part of how you develop new collaborators -- the person you work with on a patch may later be a co-maintainer or later take over as maintainer. You are increasing the bus factor by mentoring additional developers in the project.
Of course if your patch breaks the entirety of the testsuite (it has happened to me) and you get angry when you get asked to fix it… well not a big problem to lose such a contributor.
No. Talk is cheap, actions speak louder. It's incredibly easy to brush off users with that patch talk. Actually working with the people who do provide those patches? That takes some serious effort from the maintainer: evaluating and testing their contributions, providing constructive feedback, making sure they are credited, generally helping them help you so that they can accomplish their goals without compromising your goals.
When you straight up challenge someone to show you the code and they respond by doing just that, it reflects very poorly on maintainers if they can't even muster a reply.
Patches welcome means "Send me a patch and I can run git am", not "let me teach you".
Turns out it's actually pretty difficult to get people to run that command. Once I reported a bug and sent the fix. Something like a month later the guy just rewrote the patch without even engaging with me. Yeah, that made me feel like shit. Another patch I sent was a simple feature. This time I made sure to ask if there was anything wrong with the code. Some refinements were suggested and I was even told I could expect it to get merged. It's still languishing there unmerged in the mailing list over a year later despite multiple follow ups.
Sorry but maintainers don't have the moral superiority to demand free labor if that's how they treat people when actual code is written and sent in. I'd rather have a Linus Torvalds type shit all over my code and me personally than be treated like that. I never expected them to teach me but I absolutely did expect them to merge the code I wrote if they didn't have any objections to it.
I've had many great experiences in open source that offset all that, one such maintainer even commented in this thread. The brain never forgets the negative experiences though. It's a survival mechanism that stops us from stepping on the same nail twice.
Because the patch was bad.
> Something like a month later the guy just rewrote the patch without even engaging with me.
Do you think he'd have done that if the patch was good? Was his version completely identical to yours?
> Yeah, that made me feel like shit
At least it didn't introduce a new bug to every user… I'm sure collective feelings of the userbase were less harmed in this case.
> Sorry but maintainers don't have the moral superiority to demand free labor
But you have the moral superiority to demand free labour from maintainers, to review, improve, test your patch?
Look at this pull request for example: https://github.com/ltworf/localslackirc/pull/387
How could a thing like that be merged?
When asked to split it, he just proceeded to open tens of pull requests that were all based on the previous one, in a chain. And every commit contains thousands of lines of unrelated changes with what the description is.
Then he got upset.
> Do you think he'd have done that if the patch was good?
Who knows? You posted an example where you explained your rationale for not merging. You told the guy exactly what was wrong, he just refused to listen. I didn't get the same courtesy.
Maybe he didn't want my name to show up in the commit log. Maybe he just hated my guts. Could be anything. I don't know why the other patch wasn't merged either. Maybe they discussed it on IRC or something and decided against it. Maybe they forgot about me. Who knows.
> But you have the moral superiority to demand free labour from maintainers, to review, improve, test your patch?
You're the maintainer. If there's a problem or deficiency, people generally just create issues in the tracker and leave it at that. You asked for the code. You actually got the code. Now we ask you to do your part which is reviewing the code on its merits and letting us know what you think of it. If it's accceptable, then merge it. If not, then let us know why so we can make it acceptable to you.
That's exactly what you did in your example PR so I'm not even sure why we're disagreeing here.
> How could a thing like that be merged?
I wouldn't have merged that either. Nothing wrong with your conduct. He did not address the issues blocking the merger. When maintainers give me feedback like that, I take it seriously and address the issues raised. I try very hard not to submit shoddy work to begin with.
If people really want something beyond you means / energy they can submit a PR for it or fork your project.
If you're tired of replying to everyone simply have a bot close duplicate issues and let people discuss among themselves in a forum to provide peer assistance.
If its your baby and while you want to open source it you don't have any energy or desire to provide support/maintenance - just lock creating issues all together (not ideal, but if people have a community forum they'll be fine).
If you're the only person that can review/fix/maintain something then you're part of the problem, not the solution and you might need to hand over to a wider audience or flat out remove yourself as a maintainer.
"If you're the only person that can review/fix/maintain something then you're part of the problem, not the solution and you might need to hand over to a wider audience or flat out remove yourself as a maintainer."
How do those 2 parts go together?
Because the first part is correct, I don't need to do anything. But if I open source something, meaning making a gift to the world, I totally can choose to maintain with as little effort as I want to. I also don't have to provide a forum - that is a project in itself and comes with legal liabilities.
Usually a forum comes with your VCS tooling (GitHub / GitLab etc…) for free.
There's really no need for that. An active fork will eventually show up if people care enough. If it keeps improving, it becomes the new upstream and the original gets left behind. That's the way it should be.
In recent years I’ve noticed more than a couple projects that have been aggressive about building a community, but uninterested in accepting patches or fixing bugs themselves. It’s frustrating when the GitHub project has prominent links to join their Discord and the author is constantly pushing their project on social media, but then you open the Issues and see 2-3 year old simple issues with multiple pull requests from people desperate to fix it, but the maintainers aren’t actually interested in anything other than collecting more GitHub stars and expanding their community.
A) income. A chunk of mental health comes from the security of a steady income stream. To what degree does the poster have this?
B) environment? Another chunk of mental health comes from interacting with others. Ideally in person, but online is also good. Human contact, meet ups, conferences, are all good ways to feel connected and appreciated.
C) Content? Do you feel like you're doing enough? Do you feel like your projects are meaningful? Are you content with the users you have? My own mental health benefited from becoming content with my place, my work, my reach. I measure my reach in hundreds not millions, and for me that's OK.
Mental health is important, Open Source or not. But the above 3 factors seem to me to be the big hurdles for those in that space particularly.
It's ironic, but exactly the people who benefit from free software wouldn't spend their time making free software because they need money to eat.
Writing is hard. A good essay takes days if not weeks (sometimes months) of iterations. The author’s blog post is well written and a week of effort is fair, IMO.
1. What do you consider success? Is this less than, equal to, or greater than the amount you pay on rent/mortgage?
2. Are you building user-facing applications for a non-technical user base, or infrastructure code for a technical user base?
3. How much of your success, do you think, is based on the novelty you offer through occasional nsfw pics?
Of course, there are some in-house tasks. But still, I spent a lot of time participating in the upstream community and became a committer after about one year's contribution.
That said, after I changed my job, my engagement decreased considerably. But my following jobs are mostly still full-time OSS developers:
* PingCAP for TiDB and TiKV. I wrote its dev guide and built its (new) governance.
* StreamNative for Apache Pulsar.
* Greptime for GreptimeDB.
Many (infra) software MUST BE open source today. You may see my explanation at https://www.tisonkun.com/blog/greptimedb-community-report#su....
> How much do you know about GCC internals?
> I have a solid understanding of GCC (GNU Compiler Collection) internals, including its architecture, optimization techniques, and various components such as the front end, middle end, and back end. If you have specific questions or need detailed information, feel free to ask!
> Can you break down for me what I have to do to add a builtin function that generates some code following a specific calling convention?
> To add a built-in function to GCC that generates code following a specific calling convention, you'll typically follow these steps: ...
> I've gotten as far as step 4 already. Got stuck because I'm not familiar with the internal data structures and APIs. Can you show me how such a thing could be accomplished with example code?
> Certainly! Here's a simplified example of how you might add a built-in function to GCC that generates code following a specific calling convention. This example assumes you're targeting the x86 architecture, but the principles can be adapted for other architectures. First, let's define...
And I just kept asking it questions, drilling down into the complexity until I felt like I understood enough to attempt it on my own. It showed me the files I had to modify and introduced me to the internal compiler APIs needed to accomplish my goal. At some points it generated some insane code but it still saved me a ludicrous amount of time and effort.
Sadly it was a lot less useful for QEMU:
> How extensive is your knowledge of QEMU source code and its internals?
> My knowledge of QEMU source code and its internals is limited. While I can provide some general information and insights based on publicly available knowledge up to January 2022, I may not be able to provide in-depth details or specific code-level explanations.
Someone adopts a cute puppy. A bunch of people like playing with it and feeding it. It gets really big like Clifford. More and more people want to play with it. Not enough of them want to put in the work to feed it anymore. The person who adopted it gets burnt out trying to do so.
We’re incentivized to take as much and give as little as we can get away with (companies especially) “because profit.” If you’re like “but socialism is worse!!1!” just know that you can either parrot that line or fix the problem but not both.