8 ms·

Mental Health in Open Source

104 points by misonic 3y ago

PhilipRoman 3y ago
I'm fairly sure that it's possible to be a maintainer and not have to bend over backwards for some imagined "community". For the most part you can just accept patches, make decisions regarding the scope of the project and help with development on a best-effort basis. The default reply to a feature request should be "patches are welcome". If the software is useful, people won't hesitate to contribute fixes.
- matheusmoreira 3y ago
  > patches are welcome 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.
  - PhilipRoman 3y ago
    Yeah of course, if someone has sent a patch I would consider it a duty of the maintainer to review it, maybe rework a little if needed and commit with the necessary attribution. But I don't think it's the end of the world if a patch isn't accepted by the upstream. Assuming the pace of development isn't too fast it is not too much effort to maintain a friendly fork and occasionally rebase it. 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.
    - jrochkind1 3y ago
      And that's what makes it not neccessarily less work at all to say "patches welcome", if you take that approach. 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.
      - matheusmoreira 3y ago
        > 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.
        jrochkind1 3y ago
        I agree and disagree with you. * 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.
  - deleted 3y ago
    [deleted]
  - LtWorf 3y ago
    If they said they are welcome, it means they are. 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.
    - matheusmoreira 3y ago
      > If they said they are welcome, it means they are. 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.
      - LtWorf 3y ago
        > Actually working with the people who do provide those patches? Patches welcome means "Send me a patch and I can run git am", not "let me teach you".
        matheusmoreira 3y ago
        Really? Just a git command, a button press on GitHub? So why don't they just do it? Why don't they apply the patches when people send the code in then? 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.
  - sesm 3y ago
    If the patch works for you, then the time is not wasted. In JS I ecosystem applying personal patches is easy with patch-package.
- smcleod 3y ago
  Yeah I agree with this. You can only do want you can do and what you want to do. If there's more than you can or want to do - either pass it over to someone who wants to do it or don't do it. 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.
  - lukan 3y ago
    "Yeah I agree with this. You can only do want you can do and what you want to do" "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.
    - smcleod 3y ago
      If you’re the only person - and it’s just one of your projects - it doesn’t matter. It’s just a problem if you one person in a group of maintainers of shared code. Usually a forum comes with your VCS tooling (GitHub / GitLab etc…) for free.
      - lukan 3y ago
        It is also a problem, if people use my code for their stuff - and run into problems, that I for whatever reasons won't fix in time. But not my problem. Unless I make it mine.
- deleted 3y ago
  [deleted]
- Aurornis 3y ago
  > I'm fairly sure that it's possible to be a maintainer and not have to bend over backwards for some imagined "community" 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.
  - sevagh 3y ago
    Great take. You can't have it both ways - "let's build a community lalala!" but hostile and rejecting of the majority of issues and pull requests.
matheusmoreira 3y ago
The worst part of programming for me is the loneliness. AI has been a huge help. Just having someone to bounce ideas off of is amazing. It's also been helping me quickly learn the internals of massive repositories so I can do what I want to do.
- polymatter 3y ago
  How do you use AI to learn internals of massive repos? Surely the context is too big and/or it requires opening org code up and I'd never get approval for that. What LLM do you use?
  - pama 3y ago
    Not GP. Context length for chatGPT enterprise is 128k tokens. By pasting the repo tree and readme file and maybe a couple entry points you can get help from ChatGPT to find out what parts of the codebase are more useful to you, or you can simply paste a lot of it and ask questions.
  - LtWorf 3y ago
    [flagged]
    - matheusmoreira 3y ago
      I used AI to add features to GCC. Would've taken me way too much time to learn the absolutely gigantic repository without it. Talking to the AI was like having an experienced maintainer guiding me towards the proper path to make the changes I wanted to make.
      - LtWorf 3y ago
        Please include this information when you send the patch.
        matheusmoreira 3y ago
Lammy 3y ago
GitHub makes this unnecessarily worse by refusing to let you disable Pull Requests like one can disable the other social features (Wiki etc) of a repository: https://github.com/dear-github/dear-github/issues/84 https://github.com/dear-github/dear-github/issues/84 The workaround is to use GH Actions to auto-close PRs: https://github.com/marketplace/actions/repo-lockdown https://github.com/marketplace/actions/repo-lockdown
- heyoni 3y ago
  You kinda can if you archive the repo. Not sure if that stops other things like releases though.
  - TingPing 3y ago
    It stops all changes.
- e40 3y ago
  Yeah, would love to invite someone to a private repo and not give them complete control.
doubloon 3y ago
yup. it can be dangerous to mental and physical health like anything, if it is overdone. people have a hard time talking about it but i think the younger generations are thank god much more open to discussing this type of thing in public.
deleted 3y ago
[deleted]
jart 3y ago
> So, to say, I usually pick Quality and Velocity. 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.
- zarathustreal 3y ago
  Idk which project you’re talking about but thank you again for your work on the various APE, Redbean, etc!
  - ode 3y ago
    Cosmopolitan Libc - https://justine.lol/cosmopolitan/index.html https://justine.lol/cosmopolitan/index.html
  - jart 3y ago
    It's my pleasure.
- marc_abonce 3y ago
  I'm also wondering to what extent does the stack or framework force you into prioritizing velocity. For example, I've never worked with Vue but if it's anything like React, I can imagine that a library could quickly become "outdated" after a year or so unless you constantly keep the dependencies up to date and maybe even change any dependency that becomes deprecated.
  - deleted 3y ago
    [deleted]
globalnode 3y ago
How does one become a full time open source dev? do they get paid? who pays them? I mean it makes sense that if lots of people/companies depend on the project that they SHOULD get paid.
- deadbabe 3y ago
  I’ve had some success funding my open source work through Patreon, I post regular updates on what I’m working on and take some feature requests from members, along with the occasional nsfw pics.
  - vegetablepotpie 3y ago
    What? I have some questions. 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?
    - iamflimflam1 3y ago
      3. My read was that they receive the occasional nsfw pic, not that they provide them.
      - jhanoncomm 3y ago
        Whatever it is, it sure sounds creepy.
  - Qiu_Zhanxuan 3y ago
    ahah i'm confused, do they pay for your open source contributions or your artistic inclinations ?
- tison 3y ago
  My first job was developing and maintaining a streaming system based on Apache Flink. Thus, it's normal to me that a "full-time opensource developer" can get paid. 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#sustainability https://www.tisonkun.com/blog/greptimedb-community-report#su....
deadbabe 3y ago
If newer generations are less willing to sacrifice mental health for open source work could we soon enter an era of far less ambitious open source projects?
log101 3y ago
Amazing timing, I was just getting into open source these days and I have the same feelings you described in the beginning when I make a contribution. The essay kindly tells us how you feel right now, proud but tired and contemplating. IMHO That’s always going to be the case for hard working people like you, but still it is interesting that you kept pushing even though you didn’t feel comfortable and confident doing all those things you were unprepared for. And even though you were able to overcome all those challenges, you still doesn’t sound satisfied with you current situation. Maybe that’s because you have even bigger dreams? I think you’ve done an amazing work and deserve a long rest. I’m sure it’ll be bit harder for people depending on you, but they’ll get used to it eventually and you’ll feel more relaxed and maybe more fulfilled by giving yourself some space and time.
tbwriting 3y ago
fat (Jacob Thornton) has a great metaphor that makes this simple to understand. Cute puppy dog syndrome. 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.
richrichie 3y ago
> This blog you are reading took me roughly a week to write (that’s a pretty long time for me), fragmented into multiple sessions. 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.
bruce511 3y ago
Given the headline, there are some points not raised, which I'd love the poster to cover. 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.
- AlienRobot 3y ago
  Regarding A, one point I've seen raised about open source, specially the idea about checking someone's github activity as part of a hiring process, is that making open source contributions, or more specifically, contributing for free, is a privilege the poor can not afford. 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.
  - LtWorf 3y ago
    Everybody benefits from free software.

104 points by misonic 3y ago

I'm fairly sure that it's possible to be a maintainer and not have to bend over backwards for some imagined "community". For the most part you can just accept patches, make decisions regarding the scope of the project and help with development on a best-effort basis. The default reply to a feature request should be "patches are welcome". If the software is useful, people won't hesitate to contribute fixes.

matheusmoreira 3y ago
> patches are welcome 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.
- PhilipRoman 3y ago
  Yeah of course, if someone has sent a patch I would consider it a duty of the maintainer to review it, maybe rework a little if needed and commit with the necessary attribution. But I don't think it's the end of the world if a patch isn't accepted by the upstream. Assuming the pace of development isn't too fast it is not too much effort to maintain a friendly fork and occasionally rebase it. 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.
  - jrochkind1 3y ago
    And that's what makes it not neccessarily less work at all to say "patches welcome", if you take that approach. 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.
    - matheusmoreira 3y ago
      > 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.
      - jrochkind1 3y ago
        I agree and disagree with you. * 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.
- deleted 3y ago
  [deleted]
- LtWorf 3y ago
  If they said they are welcome, it means they are. 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.
  - matheusmoreira 3y ago
    > If they said they are welcome, it means they are. 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.
    - LtWorf 3y ago
      > Actually working with the people who do provide those patches? Patches welcome means "Send me a patch and I can run git am", not "let me teach you".
      - matheusmoreira 3y ago
        Really? Just a git command, a button press on GitHub? So why don't they just do it? Why don't they apply the patches when people send the code in then? 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.
- sesm 3y ago
  If the patch works for you, then the time is not wasted. In JS I ecosystem applying personal patches is easy with patch-package.
smcleod 3y ago
Yeah I agree with this. You can only do want you can do and what you want to do. If there's more than you can or want to do - either pass it over to someone who wants to do it or don't do it. 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.
- lukan 3y ago
  "Yeah I agree with this. You can only do want you can do and what you want to do" "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.
  - smcleod 3y ago
    If you’re the only person - and it’s just one of your projects - it doesn’t matter. It’s just a problem if you one person in a group of maintainers of shared code. Usually a forum comes with your VCS tooling (GitHub / GitLab etc…) for free.
    - lukan 3y ago
      It is also a problem, if people use my code for their stuff - and run into problems, that I for whatever reasons won't fix in time. But not my problem. Unless I make it mine.
deleted 3y ago
[deleted]
Aurornis 3y ago
> I'm fairly sure that it's possible to be a maintainer and not have to bend over backwards for some imagined "community" 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.
- sevagh 3y ago
  Great take. You can't have it both ways - "let's build a community lalala!" but hostile and rejecting of the majority of issues and pull requests.

matheusmoreira 3y ago

The worst part of programming for me is the loneliness. AI has been a huge help. Just having someone to bounce ideas off of is amazing. It's also been helping me quickly learn the internals of massive repositories so I can do what I want to do.

polymatter 3y ago
How do you use AI to learn internals of massive repos? Surely the context is too big and/or it requires opening org code up and I'd never get approval for that. What LLM do you use?
- pama 3y ago
  Not GP. Context length for chatGPT enterprise is 128k tokens. By pasting the repo tree and readme file and maybe a couple entry points you can get help from ChatGPT to find out what parts of the codebase are more useful to you, or you can simply paste a lot of it and ask questions.
- LtWorf 3y ago
  [flagged]
  - matheusmoreira 3y ago
    I used AI to add features to GCC. Would've taken me way too much time to learn the absolutely gigantic repository without it. Talking to the AI was like having an experienced maintainer guiding me towards the proper path to make the changes I wanted to make.
    - LtWorf 3y ago
      Please include this information when you send the patch.
      - matheusmoreira 3y ago

Lammy 3y ago

GitHub makes this unnecessarily worse by refusing to let you disable Pull Requests like one can disable the other social features (Wiki etc) of a repository: https://github.com/dear-github/dear-github/issues/84 https://github.com/dear-github/dear-github/issues/84 The workaround is to use GH Actions to auto-close PRs: https://github.com/marketplace/actions/repo-lockdown https://github.com/marketplace/actions/repo-lockdown

heyoni 3y ago
You kinda can if you archive the repo. Not sure if that stops other things like releases though.
- TingPing 3y ago
  It stops all changes.
e40 3y ago
Yeah, would love to invite someone to a private repo and not give them complete control.

doubloon 3y ago

yup. it can be dangerous to mental and physical health like anything, if it is overdone. people have a hard time talking about it but i think the younger generations are thank god much more open to discussing this type of thing in public.

deleted 3y ago

[deleted]

jart 3y ago

> So, to say, I usually pick Quality and Velocity. 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.

zarathustreal 3y ago
Idk which project you’re talking about but thank you again for your work on the various APE, Redbean, etc!
- ode 3y ago
  Cosmopolitan Libc - https://justine.lol/cosmopolitan/index.html https://justine.lol/cosmopolitan/index.html
- jart 3y ago
  It's my pleasure.
marc_abonce 3y ago
I'm also wondering to what extent does the stack or framework force you into prioritizing velocity. For example, I've never worked with Vue but if it's anything like React, I can imagine that a library could quickly become "outdated" after a year or so unless you constantly keep the dependencies up to date and maybe even change any dependency that becomes deprecated.
- deleted 3y ago
  [deleted]

globalnode 3y ago

How does one become a full time open source dev? do they get paid? who pays them? I mean it makes sense that if lots of people/companies depend on the project that they SHOULD get paid.

deadbabe 3y ago
I’ve had some success funding my open source work through Patreon, I post regular updates on what I’m working on and take some feature requests from members, along with the occasional nsfw pics.
- vegetablepotpie 3y ago
  What? I have some questions. 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?
  - iamflimflam1 3y ago
    3. My read was that they receive the occasional nsfw pic, not that they provide them.
    - jhanoncomm 3y ago
      Whatever it is, it sure sounds creepy.
- Qiu_Zhanxuan 3y ago
  ahah i'm confused, do they pay for your open source contributions or your artistic inclinations ?
tison 3y ago
My first job was developing and maintaining a streaming system based on Apache Flink. Thus, it's normal to me that a "full-time opensource developer" can get paid. 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#sustainability https://www.tisonkun.com/blog/greptimedb-community-report#su....

deadbabe 3y ago

If newer generations are less willing to sacrifice mental health for open source work could we soon enter an era of far less ambitious open source projects?

log101 3y ago

Amazing timing, I was just getting into open source these days and I have the same feelings you described in the beginning when I make a contribution. The essay kindly tells us how you feel right now, proud but tired and contemplating. IMHO That’s always going to be the case for hard working people like you, but still it is interesting that you kept pushing even though you didn’t feel comfortable and confident doing all those things you were unprepared for. And even though you were able to overcome all those challenges, you still doesn’t sound satisfied with you current situation. Maybe that’s because you have even bigger dreams? I think you’ve done an amazing work and deserve a long rest. I’m sure it’ll be bit harder for people depending on you, but they’ll get used to it eventually and you’ll feel more relaxed and maybe more fulfilled by giving yourself some space and time.

tbwriting 3y ago

fat (Jacob Thornton) has a great metaphor that makes this simple to understand. Cute puppy dog syndrome. 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.

richrichie 3y ago

> This blog you are reading took me roughly a week to write (that’s a pretty long time for me), fragmented into multiple sessions. 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.

bruce511 3y ago

Given the headline, there are some points not raised, which I'd love the poster to cover. 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.

AlienRobot 3y ago
Regarding A, one point I've seen raised about open source, specially the idea about checking someone's github activity as part of a hiring process, is that making open source contributions, or more specifically, contributing for free, is a privilege the poor can not afford. 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.
- LtWorf 3y ago
  Everybody benefits from free software.