9 ms·

This is a good description of what life is like working on almost any significant open source project. The only thing not included was the comments from overly

This is a good description of what life is like working on almost any significant open source project. The only thing not included was the comments from overly entitled users that saps whatever morale and energy you have left. Probably best he did not include that though as that is what all discussion would be about. I am not sure what to do about the burnout problem. The way he described it is very on point though. Since everyone working on the project is overloaded there is a great feeling of things only get done if you do them. Most of my open source work was in the pre-GitHub days when we used mailing lists, not pull requests, to build community. I do think there was something better about that for the project itself as it encouraged a lot more discussion and community building. PR's and Issues become silos and are not great for general discussion. I think they also encourage drive-by contributions which honestly are intoxicating initially but once you see people are not coming back become defeating.

oaiey 3y ago
Not only open source. Also anyone taking ownership in companies end up like that. The difference is: The person gets paid and is ideally not emotional involved.
- markphip 3y ago
  It is a fair point, but I think your last sentence hits on the problem. People that contribute regularly to OSS projects are nearly always emotionally invested. It brings a lot of pleasure initially which I think also contributes to the eventual burnout. These are hard problems.
- tristor 3y ago
  Unfortunately, people who take ownership and accountability are often the same people that take pride in their work, which means they aren’t emotionally detached. As long as you're emotionally attached to your work, burnout is a real risk whether you get paid or not. Ironically, the solution from my perspective is the opposite of most advice. It’s not for everyone to become drudging zombies apathetic about their work and just kicking the can, it’s that more people take pride, ownership, and accountability in all aspects of their lives. Having gone through burnout and a lot of therapy, my conclusion was that my burnout (and I think others too) was caused by being a caring decent person in an uncaring world. There are far too many people who surround all of us who are apathetic and/or incompetent, yet are entrenched, and being “forced” to carry their burden has an amplified effect on the misery we feel when doing that work. When you work with a team that only has accountable, competent, engaged people it becomes energizing rather than draining. Realistically even if I am entirely correct above, this isn’t a solution. This is just a confirmation that in my experience the old adage “hell is other people” is true and the primary driver of burnout.
  - jynelson 3y ago
    i think this is partially true, but i hesitate to call people zombies. the vast majority of people in the rust project are competent and engaged. the problem is they have different priorities and collaboration is hard when everything is bottom up. i have some more thoughts on this here: https://tech.lgbt/@jyn/111771440884089084 https://tech.lgbt/@jyn/111771440884089084
    - tristor 3y ago
      > i think this is partially true, but i hesitate to call people zombies. To clarify, I was more responding from the perspective of the workplace rather than the Rust project. That said, I have been an open source contributor off and on since 2003 and my observation has been the situation isn’t much different. In a project, rather than apathetic coworkers, you deal with users of the project that have complaints and expectations but without the ability or motivation to contribute themselves. I imagine Rust has slightly less of this than the consumer-focused projects I have worked on, but people are people at the end of the day. Contributing to any large project is largely thankless because there will always be one more complaint/demand issue, or one more PR from someone that didn’t read the contribution guidelines. It can turn what you’re passionate about into a slog, and while the form may differ, it’s not meaningfully different from having apathetic or incompetent coworkers dragging you down. To be honest, dealing with open source slog is slightly worse, because it takes much longer for the hope to die. Somebody that submits a bad PR seems to care somewhat, it’s not total apathy. Somebody that submits a whiny issue at least demonstrates that they used the project and cared enough to write. But both demand your attention without demonstrating competent contribution in and of themselves. It’s somehow worse than the coworkers that are on an in-office vacation.
      - jynelson 3y ago
        i agree! i hadn't realized you were talking about people who weren't already team members. they're usually well-meaning, but it's true that some drain a lot of contributor time on things that aren't important. rust has a conflict avoidance problem. i think rust could be much more effective at saying no, and saying it more quickly. i want to talk about that in my next blog post.
markphip 3y ago
Following up on my previous comment, I managed to never become fully burned out, but it required changes to myself, not the project. I had to become less emotionally invested in the project, realize I could not solve everything and step back a bit and do some other things. I guess it would be great if the project were reinforcing these ideas to its contributors to prevent burnout, but that also does not seem realistic. And "the project" is made up of others going through the same problems. The large OSS project I contributed to thankfully had other contributors that were good role models for these behaviors and it helped seeing them disengage to do other things for a while.
- jynelson 3y ago
  this is a wonderful comment, thank you for writing it <3 i am trying to model these behaviors; this post was primarily intended for other people working in the project. i feel pretty strongly that this is a cultural issue moreso than an individual one. i have seen too many of my friends burn out to say it was all their fault individually.
MrBuddyCasino 3y ago
This generalises to any idealism. You would not think veterinarians to be at elevated risk of suicide, but they are [0], and I think the reasons are similar: a moral dilemma caused by the mismatch between expectation and grim reality which ultimately leads to burnout and desperation. The other extreme is a "bullshit job", work that you don't enjoy and which serves no meaningful purpose. [0] https://www.bbc.com/worklife/article/20231010-the-acute-suicide-crisis-among-veterinarians-youre-always-going-to-be-failing-somebody https://www.bbc.com/worklife/article/20231010-the-acute-suic...
- thomascgalvin 3y ago
  I 100% understand why veterinarians are in a crisis. We had to let our pupper go a few weeks ago. The vet had to basically sit there and watch us while we processed the fact that we were about to pay her to kill our best friend. For us, it was the worst day we had experienced in years. For her, it was Tuesday. She had other people waiting in the room next door, and had to go from solemn to bright and cheery over the span of ten footsteps, and she has to do that every day. Her job is often to put a very real price tag on the life of a beloved companion. "I'm sorry, but keeping him alive will be $10,000... or we can humanely put him down for much, much less." It's grim business. Necessary, but grim.
  - yencabulator 3y ago
    This is why you need to bring your joy & love of the dog to your vet when things are going well, when you're there for routine things. It really improves their day. We finally found the right medications for my 10-year old loyal potato (she's had low thyroid function, immune system trouble caused by the low thyroid function, a rattlesnake bite on the nose, arthritis, and so on) -- she's now acting half her age and happily jumping on rocks to pose for treats, and it's so nice to share her story with the vet. Everyone at the vet visibly brightens up when they interact with a happy well behaved dog.
  - MrBuddyCasino 3y ago
    My condolences, loosing a pet is hard. May he frolic in pile of leaves and cherish his favourite bone.
Waterluvian 3y ago
> I am not sure what to do about the burnout problem. Pacing and self-regulation. It’s a marathon not a sprint. Set an hours-per-week budget. Beyond that things just don’t get done. That’s okay. If the community needs faster pace, they can consider supplying hours or dollars to fund more developers to work full-time.
- markphip 3y ago
  I should have clarified, I meant I am not sure what an OSS Project can do about it. I think this ultimately has to be managed by the OSS contributor.
  - Waterluvian 3y ago
    Ah yes. I wonder if an OSS project should set forth a time budget in some way? Hard to “enforce” though. And goes counter to wanting contributors to feel free to contribute on their terms.
    - bombcar 3y ago
      The best I’ve seen is have additional contributors (often who just like the project but aren’t coders themselves) who run interference for the dev team. They can triage feature requests, filter out the spam and repeat issues, etc. Also, and this can be the hard part, is sometimes you have to have someone who (even politely!) can be a bit of a dick when necessary. People scan be quite entitled and want to boss everyone around and tell them the project is run wrong - if you don’t actively run at least some of them off the devs will curl up and disappear. Also having a defined procedure for “hiatus” helps quite a bit - make it easy for a dev to say “I’m off” and it can be indeterminate - this allows them to easily come back later. Encourage devs to use it liberally.
      - pdimitar 3y ago
        > People scan be quite entitled and want to boss everyone around and tell them the project is run wrong - if you don’t actively run at least some of them off the devs will curl up and disappear. As an Eastern European I always found fascinating how many Westerners are struggling hard with this. To me and many of my peers (and apparently to Linus Torvalds and a good chunk of the entire Nordic culture, probably?) it's the easiest thing in the world to say something like: "Listen up dickhead, I do this in my free time. If you don't like the direction of the project or the urgency with which your issues are [not] being addressed, you are free to not use it, and it also costs you nothing to not comment at all. I got better things to do than to reply to entitled cunts, now piss off." It's very amusing what a huge drama many Westerners make out of just... being direct. Honest. Straight to the point. "But he won't ever contribute and he might infect others with the opinion that the project leaderships is toxic!" OK. That's a price I am willing to pay. My mental health > the second-hand opinion of people who were only 0.1% likely to contribute anyway. The math is very easy yet so many Westerners struggle so much with these [to me and many] mega obvious solutions, like "be a bit of a dick when necessary". This is really very similar to the discussions I had with a lot of women long time ago. It goes like this: they tell me: "I have to go tell X and Y about event A because otherwise Z will tell them lies and they'll think something wrong about me." To which I reply with a cold expression: "Then you don't need X and Y in your life, if they can be so easily influenced by lies and won't even ask you about what truly happened." Their expressions were priceless. The cognitive dissonance can hit us all VERY hard. Back to the topic at hand, yes, I firmly believe all open-contribution projects need a Linus type of person. It's also a fact that many devs are introverted and can be chased away by entitled and insolent loud people. So somebody must put a shield in front of the devs.
vmfunction 3y ago
> Most of my open source work was in the pre-GitHub days when we used mailing lists, not pull requests, to build community. I do think there was something better about that for the project itself as it encouraged a lot more discussion and community building. PR's and Issues become silos and are not great for general discussion. I think they also encourage drive-by contributions which honestly are intoxicating initially but once you see people are not coming back become defeating. Glad some said it. When things are too organised or categorised it just becomes another business/todo list.
- janoc 3y ago
  The problem *is not the organization/categorization*. Any larger project is completely unsustainable if it is a disorganized chaos, with issues falling through the cracks because they can't be kept track of as the scope and team grows. These tools are a great help there. The problem is this tooling is used for the wrong job. If the only "discussion" about an issue is the bug report/pull request, that's wrong. That should be only the first/last step. Unfortunately, for many projects there is no other communication channel anymore. So then people use what exists and is available - PRs and issues on Github. Which are both very poorly adapted to any sort of discussion. But if all you have is a hammer ... It used to be that the first things a new project got set up was a mailing list, then maybe an IRC channel, perhaps a shared code repository (likely CVS or Subversion) and only then an issue/bug tracker (usually Bugzilla, Track) when the project grew large enough to need it. In that order. This culture of project community discussion has been largely lost with the younger generation of contributors that don't use e-mail and many don't even have an e-mail account (or don't use it except for signing up for services). Mailing lists have been seen as "old school" and poor UX, so have been largely replaced first by silos in the form of web forums and then later by Discord, Reddit, etc. All that makes it great and easy for anyone to come in and post something there (the signal to noise ratio is usually not great) - and absolutely terrible to find anything, to actually coordinate work of a distributed team or to track multiple busy projects. E-mail comes to you and can be automated - forums, Reddit, Discord, etc. you have to actively seek out, follow and manage. Poor project maintainer having to deal with that ... There are good reasons why projects like Linux kernel still use mailing lists for coordination or even sending patches (!), despite the huge size of the project - it simply makes the life of the maintainers (i.e. the people doing most of the actual work!) easier.
sph 3y ago
> This is a good description of what life is like working on almost any significant open source project. Open contributions project. An open source project does not necessarily have to accept random contributions, issues or hatemail from the general public. [1] They just need to make the source available with a permissive licence, period. I believe that Linux with its idiosyncrasies in its communication model (mailing list vs the ease of Github, strong dictator running the show) works as a great filter from entitled users, and that's an underrated feature in open source. See also sqlite. --- 1: Yet hell will freeze over before Github lets maintainers turn off the PR tab which would lessen this problem a bit.
- berkes 3y ago
  I strongly believe GitHub has the same dynamics as most "big tech social media". Where anything that drives "engagement" gets prioritized. From algorithms that make alt-right/neo-nazi's more visible because the controversy drives "eyeballs" to features that are removed or never implemented because they would lower engagement. I'm confident that GitHub has a good prediction on what will happen if they roll out features that lower the burden of maintaining a FLOSS repo. And am rather certain that several of these features also lower the engagement. And therefore will not be implemented. In other words: the needs and goals of GitHub/MSFT and those of Open Source maintainers don't align perfectly. Yet the power balance is way off, so open Source maintainers will experience pain to a level that they almost walk away in great numbers.
  - ninkendo 3y ago
    It would be a baffling decision for GitHub to make any product decisions based on engagement. They don’t even serve ads, what benefit do they have to an engaged user?
    - throwaway17_17 3y ago
      I would assume, in the context of Microsoft encouraging engagement (specifically the PR feature of GitHub), the more engagement they have the more code is put into their system, thereby allowing them more data to train Copilot and other ML models.
mjw1007 3y ago
I think, from observation, that the Rust project has worse burnout problems than most other similarly-sized open source projects. I'm not sure whether it's more to do with the way the project is organised, the state of the codebase, or the sort of person that's attracted to working on Rust in the first place.
- jynelson 3y ago
  i have some thoughts on it here: https://tech.lgbt/@jyn/111771280764615511 https://tech.lgbt/@jyn/111771280764615511. i'm planning to make this the subject of my next blog post.
- pdimitar 3y ago
  > the sort of person that's attracted to working on Rust in the first place What's that even supposed to hint at?
  - mjw1007 3y ago
    I was thinking something along the lines of people who tend to set unusually high standards for themselves. Rust has something of a self-image of always being best-of-breed in everything it attempts, so I could believe that it might be particularly attractive to those sorts. Other possibilities might be that Rust developers skew younger than average (I don't know whether that's true), or that its six-week release cycle attracts people who think that a year is a long time.
    - jynelson 3y ago
      rust definitely skews younger than average. i don't have statistics on hand, but almost all people i know working on the project are younger than 35, and a surprising number are 17-25
      - deleted 3y ago
        [deleted]
    - 3y ago
Dalewyn 3y ago
>I am not sure what to do about the burnout problem. Get paid for it, and don't do anything more than you are paid to do. I've done volunteer work, per se. My biggest takeaway has been that humanity overall is not worth giving away my free time to. When I volunteer my time now, I do so only for individuals who I know will sincerely appreciate it.
- deleted 3y ago
  [deleted]
Loxicon 3y ago
If I understand you properly, in the mailing list days, did EVERYONE get the email when someone sent in patches?
- coldpie 3y ago
  Yes. Usually there's either two lists, one for discussion and one for patch submission and review; or users use filters to divide them out (if $h_Subject contains "PATCH" -> send mail to "patches" dir). For large projects, you can use deeper filters to entirely drop mails in areas of the project that you don't care about.
- mpol 3y ago
  Yes. The way to make it work is to use fiters in your mailclient. All mail to dev@ goes to its own folder, all mail to discussion@ to its own folder, all mail to support@ to its own folder. You only look there when you feel like it. Your inbox is not having all this noise.
gray_-_wolf 3y ago
> I think they also encourage drive-by contributions I realize I am in minority, but for me, if project uses a mailing list I am more likely to do a drive-by contribution (compared to no contribution at all). Just doing git send-email is much easier compared to figuring out how to create whatever pull request is called in whatever forge the specific project is using.
- humanrebar 3y ago
  I'm the opposite. There's no clear notion of status, remaining concerns, priority, etc. in an email thread.
  - gray_-_wolf 3y ago
    > There's no clear notion of status, remaining concerns, priority, etc. in an email thread. Which, for drive-by contributions, does not really matter. It is a problem for long term contributions and project managements in general, true, but there often is some tracking system present (patchwork, debbugs, ...).
TheCleric 3y ago
Amen. Especially on open source projects where just enough people use it to have an active user base, but not enough where you have a good stable of contributors. I’ve burned myself out on a handful of projects like this and also why I haven’t started any new ones lately. It’s very tiring (doubly so if maintaining open source isn’t part of your paid job, so you’re doing it on your free time).
hinkley 3y ago
None of this is unique to open source. Something that would be readily apparent to people who do volunteer work on things besides software. Which is essentially moonlighting on doing your day job. All volunteer organizations have to fight burnout. Any time you start feeling like things won’t get “done” unless you do them, you’re on that road.

oaiey 3y ago

Not only open source. Also anyone taking ownership in companies end up like that. The difference is: The person gets paid and is ideally not emotional involved.

markphip 3y ago
It is a fair point, but I think your last sentence hits on the problem. People that contribute regularly to OSS projects are nearly always emotionally invested. It brings a lot of pleasure initially which I think also contributes to the eventual burnout. These are hard problems.
tristor 3y ago
Unfortunately, people who take ownership and accountability are often the same people that take pride in their work, which means they aren’t emotionally detached. As long as you're emotionally attached to your work, burnout is a real risk whether you get paid or not. Ironically, the solution from my perspective is the opposite of most advice. It’s not for everyone to become drudging zombies apathetic about their work and just kicking the can, it’s that more people take pride, ownership, and accountability in all aspects of their lives. Having gone through burnout and a lot of therapy, my conclusion was that my burnout (and I think others too) was caused by being a caring decent person in an uncaring world. There are far too many people who surround all of us who are apathetic and/or incompetent, yet are entrenched, and being “forced” to carry their burden has an amplified effect on the misery we feel when doing that work. When you work with a team that only has accountable, competent, engaged people it becomes energizing rather than draining. Realistically even if I am entirely correct above, this isn’t a solution. This is just a confirmation that in my experience the old adage “hell is other people” is true and the primary driver of burnout.
- jynelson 3y ago
  i think this is partially true, but i hesitate to call people zombies. the vast majority of people in the rust project are competent and engaged. the problem is they have different priorities and collaboration is hard when everything is bottom up. i have some more thoughts on this here: https://tech.lgbt/@jyn/111771440884089084 https://tech.lgbt/@jyn/111771440884089084
  - tristor 3y ago
    > i think this is partially true, but i hesitate to call people zombies. To clarify, I was more responding from the perspective of the workplace rather than the Rust project. That said, I have been an open source contributor off and on since 2003 and my observation has been the situation isn’t much different. In a project, rather than apathetic coworkers, you deal with users of the project that have complaints and expectations but without the ability or motivation to contribute themselves. I imagine Rust has slightly less of this than the consumer-focused projects I have worked on, but people are people at the end of the day. Contributing to any large project is largely thankless because there will always be one more complaint/demand issue, or one more PR from someone that didn’t read the contribution guidelines. It can turn what you’re passionate about into a slog, and while the form may differ, it’s not meaningfully different from having apathetic or incompetent coworkers dragging you down. To be honest, dealing with open source slog is slightly worse, because it takes much longer for the hope to die. Somebody that submits a bad PR seems to care somewhat, it’s not total apathy. Somebody that submits a whiny issue at least demonstrates that they used the project and cared enough to write. But both demand your attention without demonstrating competent contribution in and of themselves. It’s somehow worse than the coworkers that are on an in-office vacation.
    - jynelson 3y ago
      i agree! i hadn't realized you were talking about people who weren't already team members. they're usually well-meaning, but it's true that some drain a lot of contributor time on things that aren't important. rust has a conflict avoidance problem. i think rust could be much more effective at saying no, and saying it more quickly. i want to talk about that in my next blog post.

markphip 3y ago

Following up on my previous comment, I managed to never become fully burned out, but it required changes to myself, not the project. I had to become less emotionally invested in the project, realize I could not solve everything and step back a bit and do some other things. I guess it would be great if the project were reinforcing these ideas to its contributors to prevent burnout, but that also does not seem realistic. And "the project" is made up of others going through the same problems. The large OSS project I contributed to thankfully had other contributors that were good role models for these behaviors and it helped seeing them disengage to do other things for a while.

jynelson 3y ago
this is a wonderful comment, thank you for writing it <3 i am trying to model these behaviors; this post was primarily intended for other people working in the project. i feel pretty strongly that this is a cultural issue moreso than an individual one. i have seen too many of my friends burn out to say it was all their fault individually.

MrBuddyCasino 3y ago

This generalises to any idealism. You would not think veterinarians to be at elevated risk of suicide, but they are [0], and I think the reasons are similar: a moral dilemma caused by the mismatch between expectation and grim reality which ultimately leads to burnout and desperation. The other extreme is a "bullshit job", work that you don't enjoy and which serves no meaningful purpose. [0] https://www.bbc.com/worklife/article/20231010-the-acute-suicide-crisis-among-veterinarians-youre-always-going-to-be-failing-somebody https://www.bbc.com/worklife/article/20231010-the-acute-suic...

thomascgalvin 3y ago
I 100% understand why veterinarians are in a crisis. We had to let our pupper go a few weeks ago. The vet had to basically sit there and watch us while we processed the fact that we were about to pay her to kill our best friend. For us, it was the worst day we had experienced in years. For her, it was Tuesday. She had other people waiting in the room next door, and had to go from solemn to bright and cheery over the span of ten footsteps, and she has to do that every day. Her job is often to put a very real price tag on the life of a beloved companion. "I'm sorry, but keeping him alive will be $10,000... or we can humanely put him down for much, much less." It's grim business. Necessary, but grim.
- yencabulator 3y ago
  This is why you need to bring your joy & love of the dog to your vet when things are going well, when you're there for routine things. It really improves their day. We finally found the right medications for my 10-year old loyal potato (she's had low thyroid function, immune system trouble caused by the low thyroid function, a rattlesnake bite on the nose, arthritis, and so on) -- she's now acting half her age and happily jumping on rocks to pose for treats, and it's so nice to share her story with the vet. Everyone at the vet visibly brightens up when they interact with a happy well behaved dog.
- MrBuddyCasino 3y ago
  My condolences, loosing a pet is hard. May he frolic in pile of leaves and cherish his favourite bone.

Waterluvian 3y ago

> I am not sure what to do about the burnout problem. Pacing and self-regulation. It’s a marathon not a sprint. Set an hours-per-week budget. Beyond that things just don’t get done. That’s okay. If the community needs faster pace, they can consider supplying hours or dollars to fund more developers to work full-time.

markphip 3y ago
I should have clarified, I meant I am not sure what an OSS Project can do about it. I think this ultimately has to be managed by the OSS contributor.
- Waterluvian 3y ago
  Ah yes. I wonder if an OSS project should set forth a time budget in some way? Hard to “enforce” though. And goes counter to wanting contributors to feel free to contribute on their terms.
  - bombcar 3y ago
    The best I’ve seen is have additional contributors (often who just like the project but aren’t coders themselves) who run interference for the dev team. They can triage feature requests, filter out the spam and repeat issues, etc. Also, and this can be the hard part, is sometimes you have to have someone who (even politely!) can be a bit of a dick when necessary. People scan be quite entitled and want to boss everyone around and tell them the project is run wrong - if you don’t actively run at least some of them off the devs will curl up and disappear. Also having a defined procedure for “hiatus” helps quite a bit - make it easy for a dev to say “I’m off” and it can be indeterminate - this allows them to easily come back later. Encourage devs to use it liberally.
    - pdimitar 3y ago
      > People scan be quite entitled and want to boss everyone around and tell them the project is run wrong - if you don’t actively run at least some of them off the devs will curl up and disappear. As an Eastern European I always found fascinating how many Westerners are struggling hard with this. To me and many of my peers (and apparently to Linus Torvalds and a good chunk of the entire Nordic culture, probably?) it's the easiest thing in the world to say something like: "Listen up dickhead, I do this in my free time. If you don't like the direction of the project or the urgency with which your issues are [not] being addressed, you are free to not use it, and it also costs you nothing to not comment at all. I got better things to do than to reply to entitled cunts, now piss off." It's very amusing what a huge drama many Westerners make out of just... being direct. Honest. Straight to the point. "But he won't ever contribute and he might infect others with the opinion that the project leaderships is toxic!" OK. That's a price I am willing to pay. My mental health > the second-hand opinion of people who were only 0.1% likely to contribute anyway. The math is very easy yet so many Westerners struggle so much with these [to me and many] mega obvious solutions, like "be a bit of a dick when necessary". This is really very similar to the discussions I had with a lot of women long time ago. It goes like this: they tell me: "I have to go tell X and Y about event A because otherwise Z will tell them lies and they'll think something wrong about me." To which I reply with a cold expression: "Then you don't need X and Y in your life, if they can be so easily influenced by lies and won't even ask you about what truly happened." Their expressions were priceless. The cognitive dissonance can hit us all VERY hard. Back to the topic at hand, yes, I firmly believe all open-contribution projects need a Linus type of person. It's also a fact that many devs are introverted and can be chased away by entitled and insolent loud people. So somebody must put a shield in front of the devs.

vmfunction 3y ago

> Most of my open source work was in the pre-GitHub days when we used mailing lists, not pull requests, to build community. I do think there was something better about that for the project itself as it encouraged a lot more discussion and community building. PR's and Issues become silos and are not great for general discussion. I think they also encourage drive-by contributions which honestly are intoxicating initially but once you see people are not coming back become defeating. Glad some said it. When things are too organised or categorised it just becomes another business/todo list.

janoc 3y ago
The problem *is not the organization/categorization*. Any larger project is completely unsustainable if it is a disorganized chaos, with issues falling through the cracks because they can't be kept track of as the scope and team grows. These tools are a great help there. The problem is this tooling is used for the wrong job. If the only "discussion" about an issue is the bug report/pull request, that's wrong. That should be only the first/last step. Unfortunately, for many projects there is no other communication channel anymore. So then people use what exists and is available - PRs and issues on Github. Which are both very poorly adapted to any sort of discussion. But if all you have is a hammer ... It used to be that the first things a new project got set up was a mailing list, then maybe an IRC channel, perhaps a shared code repository (likely CVS or Subversion) and only then an issue/bug tracker (usually Bugzilla, Track) when the project grew large enough to need it. In that order. This culture of project community discussion has been largely lost with the younger generation of contributors that don't use e-mail and many don't even have an e-mail account (or don't use it except for signing up for services). Mailing lists have been seen as "old school" and poor UX, so have been largely replaced first by silos in the form of web forums and then later by Discord, Reddit, etc. All that makes it great and easy for anyone to come in and post something there (the signal to noise ratio is usually not great) - and absolutely terrible to find anything, to actually coordinate work of a distributed team or to track multiple busy projects. E-mail comes to you and can be automated - forums, Reddit, Discord, etc. you have to actively seek out, follow and manage. Poor project maintainer having to deal with that ... There are good reasons why projects like Linux kernel still use mailing lists for coordination or even sending patches (!), despite the huge size of the project - it simply makes the life of the maintainers (i.e. the people doing most of the actual work!) easier.

sph 3y ago

> This is a good description of what life is like working on almost any significant open source project. Open contributions project. An open source project does not necessarily have to accept random contributions, issues or hatemail from the general public. [1] They just need to make the source available with a permissive licence, period. I believe that Linux with its idiosyncrasies in its communication model (mailing list vs the ease of Github, strong dictator running the show) works as a great filter from entitled users, and that's an underrated feature in open source. See also sqlite. --- 1: Yet hell will freeze over before Github lets maintainers turn off the PR tab which would lessen this problem a bit.

berkes 3y ago
I strongly believe GitHub has the same dynamics as most "big tech social media". Where anything that drives "engagement" gets prioritized. From algorithms that make alt-right/neo-nazi's more visible because the controversy drives "eyeballs" to features that are removed or never implemented because they would lower engagement. I'm confident that GitHub has a good prediction on what will happen if they roll out features that lower the burden of maintaining a FLOSS repo. And am rather certain that several of these features also lower the engagement. And therefore will not be implemented. In other words: the needs and goals of GitHub/MSFT and those of Open Source maintainers don't align perfectly. Yet the power balance is way off, so open Source maintainers will experience pain to a level that they almost walk away in great numbers.
- ninkendo 3y ago
  It would be a baffling decision for GitHub to make any product decisions based on engagement. They don’t even serve ads, what benefit do they have to an engaged user?
  - throwaway17_17 3y ago
    I would assume, in the context of Microsoft encouraging engagement (specifically the PR feature of GitHub), the more engagement they have the more code is put into their system, thereby allowing them more data to train Copilot and other ML models.

mjw1007 3y ago

I think, from observation, that the Rust project has worse burnout problems than most other similarly-sized open source projects. I'm not sure whether it's more to do with the way the project is organised, the state of the codebase, or the sort of person that's attracted to working on Rust in the first place.

jynelson 3y ago
i have some thoughts on it here: https://tech.lgbt/@jyn/111771280764615511 https://tech.lgbt/@jyn/111771280764615511. i'm planning to make this the subject of my next blog post.
pdimitar 3y ago
> the sort of person that's attracted to working on Rust in the first place What's that even supposed to hint at?
- mjw1007 3y ago
  I was thinking something along the lines of people who tend to set unusually high standards for themselves. Rust has something of a self-image of always being best-of-breed in everything it attempts, so I could believe that it might be particularly attractive to those sorts. Other possibilities might be that Rust developers skew younger than average (I don't know whether that's true), or that its six-week release cycle attracts people who think that a year is a long time.
  - jynelson 3y ago
    rust definitely skews younger than average. i don't have statistics on hand, but almost all people i know working on the project are younger than 35, and a surprising number are 17-25
    - deleted 3y ago
      [deleted]
  - 3y ago

Dalewyn 3y ago

>I am not sure what to do about the burnout problem. Get paid for it, and don't do anything more than you are paid to do. I've done volunteer work, per se. My biggest takeaway has been that humanity overall is not worth giving away my free time to. When I volunteer my time now, I do so only for individuals who I know will sincerely appreciate it.

deleted 3y ago
[deleted]

Loxicon 3y ago

If I understand you properly, in the mailing list days, did EVERYONE get the email when someone sent in patches?

coldpie 3y ago
Yes. Usually there's either two lists, one for discussion and one for patch submission and review; or users use filters to divide them out (if $h_Subject contains "PATCH" -> send mail to "patches" dir). For large projects, you can use deeper filters to entirely drop mails in areas of the project that you don't care about.
mpol 3y ago
Yes. The way to make it work is to use fiters in your mailclient. All mail to dev@ goes to its own folder, all mail to discussion@ to its own folder, all mail to support@ to its own folder. You only look there when you feel like it. Your inbox is not having all this noise.

gray_-_wolf 3y ago

> I think they also encourage drive-by contributions I realize I am in minority, but for me, if project uses a mailing list I am more likely to do a drive-by contribution (compared to no contribution at all). Just doing git send-email is much easier compared to figuring out how to create whatever pull request is called in whatever forge the specific project is using.

humanrebar 3y ago
I'm the opposite. There's no clear notion of status, remaining concerns, priority, etc. in an email thread.
- gray_-_wolf 3y ago
  > There's no clear notion of status, remaining concerns, priority, etc. in an email thread. Which, for drive-by contributions, does not really matter. It is a problem for long term contributions and project managements in general, true, but there often is some tracking system present (patchwork, debbugs, ...).

TheCleric 3y ago

Amen. Especially on open source projects where just enough people use it to have an active user base, but not enough where you have a good stable of contributors. I’ve burned myself out on a handful of projects like this and also why I haven’t started any new ones lately. It’s very tiring (doubly so if maintaining open source isn’t part of your paid job, so you’re doing it on your free time).

hinkley 3y ago

None of this is unique to open source. Something that would be readily apparent to people who do volunteer work on things besides software. Which is essentially moonlighting on doing your day job. All volunteer organizations have to fight burnout. Any time you start feeling like things won’t get “done” unless you do them, you’re on that road.