6 ms·

As an OSS maintainer for a large project I disagree. Sometimes people did fuck off and it didn't do the project any favors. I needed people to communicate clea

As an OSS maintainer for a large project I disagree. Sometimes people did fuck off and it didn't do the project any favors. I needed people to communicate clearly and with volume why I should change some opinions. Ultimately, my mistakes led to a competitor that was indeed unsuccessful but sucked a lot of the mindshare so we both got screwed. We're smart people but we all need to learn humility occasionally. I do agree we need manners but I don't agree that people should just fuck off. I want complaints. That's how I can gauge improvement. A culture of ignoring complaints is bad. I know that is not what the article is about exactly, but it's where these things lead.

Timshel 4y ago
Nowhere it said you can't argue for your fix/change in an open issue. Just that once the maintainer close the issue: `So should you get angry and start abusing them? No.` Edit: And nowhere it makes any comments on how much/little the maintainer should listen to issues just that once he closed it you need to respect it and move on.
- invalidname 4y ago
  I had that. It was unpleasant (to say the least) but on a different situation I rejected a direction. User went elsewhere and we all ended up losing. I disagree with the attitude expressed there. Don't like it. Build your own. Every maintainer has his style, I don't think that's a constructive style and as a maintainer I never use that style. I might disagree with someone, I will never say fuck off. Even if I think someone should fork, I will offer help with the fork, at least in advice. Writing the code isn't where it ends. I thank every user who uses my code. Otherwise it's just another code dump. The users are what makes the work worthwhile. To me.
  - deleted 4y ago
    [deleted]
Barrin92 4y ago
the list of abandoned open source projects because the maintainers burned out is I think a lot longer than the list of projects that ended because low quality complaints were ignored. Literally go through GitHub and look how few people contribute the source code to even large projects. If they lose it, it often does significant damage to a project because original creators are important. In a sense being rude is being humble. If I'm rude to bad complaints it's because I'm realistic about my limited capacity to deal with stuff. It's ironically often generous people who end up resenting what they're working on.
- Timshel 4y ago
  >In a sense being rude is being humble. If I'm rude to bad complaints it's because I'm realistic about my limited capacity to deal with stuff. It's ironically often generous people who end up resenting what they're working on. ??? I don't know how you define rude but I see no reason to go from something like `I'm sorry your suggestion do not align with my vision of the project` and close the issue to anything more insulting.
- invalidname 4y ago
  None of us measured this. Personally, I write code for the people. The good and the bad. It's very rare when someone is abusive (it happens). I'd say it's one in 1000. The ratio of people who disagree is much larger. The challenge is in creating a big tent environment that listens to everyone. This sort of "don't like it so get the fuck out" attitude is poisonous. It might not seem so in the short term but it is in the long term. As a maintainer you're a politician, not just a coder. I need to be able to take some reasonable level of abuse and stupidity. Because occasionally I'm the stupid person who didn't "get it".
- thrown_22 4y ago
  > the list of abandoned open source projects because the maintainers burned out is I think a lot longer than the list of projects that ended because low quality complaints were ignored. The list is the same, because a healthy project grooms people to take over if you're burning out.
Ygg2 4y ago
Hi. Another OSS dev here. Are you paid for maintaining that software? If not, and are doing another job on the side, then other people aren't entitled to your free time.
- mgbmtl 4y ago
  Even if you're paid, they're still not entitled to your time, unless they have a contract (support, hosting, etc). As an OSS dev on a small project, when I started getting paid (part time, for specific things), I tried being nice with everyone, but people didn't understand the limits of what I could do. They'd get frustrated and abusive. I'm more careful now. More thoughs here, but it's a bit of a hodgepodge of experiences: https://www.bidon.ca/random/2022-07-25-contributor-journey/ https://www.bidon.ca/random/2022-07-25-contributor-journey/
- bottled_poe 4y ago
  The thing about free time is we’re all free to choose how to spend it.
  - Ygg2 4y ago
    Right, but others don't have the right to free stuff, if you don't wish to give it up first.
    - lanstin 4y ago
      And it is better to opensource the code and never help anyone with any aspect of it at all, than to not release the code.
- invalidname 4y ago
  I formed a company around it. Entitlement is 100% true. But I don't ask people in the OSS project if they are paying customers or not. I also work on other projects where I don't make any money. I think entitlement sucks. When people phrase things as a "demand" it's pretty terrible. But keep in mind that the internet doesn't covey emotion properly. A maintainers job is a community service job. Even if you volunteer (which is this case), either do it with an open heart or just don't do it at all. Otherwise this will be pretty frustrating in the long run. You will burn out and fizzle because you think of all the time wasted where you could have made real money. If you think about it that way... Well. Answering kindly to someone whose abusive and communicating your perception can make a huge difference. I did run into the very very rare a*hole that couldn't be reasoned with. But this is extremely rare. Most people just need to be talked to and heard. We can then work together. I can't be everything to everyone but we need to form a community of people who might not agree on everything. Those IMHO are the most interesting and valuable voices in my community.
2muchcoffeeman 4y ago
You’re allowed to run your project any way you want to achieve your goals. But I think the post still applies. If I use your project, it’s up to me to communicate bugs clearly and in a manner useful to yourself if I want a chance of getting it fixed. Otherwise, I shouldn’t expect anything or go and do it myself.
- invalidname 4y ago
  That's true. I'm saying there should be a discussion and a positive attitude. At the end of the day there might be toxic problems where someone will get pushed out. But I think these are things we as maintainers should feel bad about. It happened to me once and I feel sad that I wasn't able to resolve those problems. OP seems to be flaunting/celebrating what to me seems like a failure to communicate and build the community.
  - 2muchcoffeeman 4y ago
    You can feel bad if your project doesn’t go that way you want. But don’t feel bad about trying to give away time and work for free!!!
    - invalidname 4y ago
      I feel bad about personal failure to communicate with a fellow engineer and come to a common understanding. I consider that a failure on my part.
barnabee 4y ago
Surely this depends on your goals? If you are an OSS maintainer who wants to build a succesful project used by a lot of people and companies and that has much mindshare, etc. etc. then yes, you will need to evaluate people's opinions, listen to them, and decide when it's in your interest to fix something or change the design or whatever. Because then keeping people interested in and using your project and in fact growing their numbers is your goal, so obviously you will need to attract and work with them. If you released some code you wrote that was useful to you and sometimes update it or fix it for others because the fix is easy or helps you too or you just feel nice, then the calculation might look a bit different.
- invalidname 4y ago
  IMHO That's not an OSS maintainer. That's a code dump. I don't mind those, but you don't need even an issue tracker for that...
  - scatters 4y ago
    An issue tracker on a code dump is useful for users to share information about bugs, workarounds and forks.
    - barnabee 4y ago
      Yeah, some code dumps aren’t entirely unmaintained, but that doesn’t make their owners beholden to anyone.
- disruptiveink 4y ago
  Then turn off the issue tracker and DON'T call yourself an "OSS maintainer". Or leave the issue tracker open but make it explicit on your readme this is just a personal project that's not being actively developed so people adjust their expectations. Personal projects or unfinished work on GitHub are perfectly fine and in most cases, better to the world than something stashed on your hard drive, but you're not running any OSS project there. Feels to me some people want to have their cake (claim they "contribute to open source" on their CV/interviews) and eat it too (not have to actually do any work that comes with running an OSS project).
O__________O 4y ago
>> “I needed people to communicate clearly and with volume why I should change some opinions.” This is not how real world works. People rarely intentionally communicate unclearly — or fail to add the “volume” they feel is necessary. Only aspects that are in your control are: how you allow people to communicate with you - and what you do with what they share. - Problem with how is that the more constraints you add, less likely they are to communicate; you’re basically increasing cost for them to reduce the cost for you. - Easiest way to increase the efficiency of what you do with the information is to have another set of eyes helping process the information; in doing so, you’re delegating control and adding overhead — but gaining a predictable interface to filter less predictable information. Communicating information takes energy, and there’s only so much efficiency that’s reasonable to expect, especially when dealing with random people via systems you do not fully control.
phoronixrly 4y ago
> ...my mistakes led to a competitor ... I will never understand the concept of competition in the context of open-source. I would love to have my projects be superseded by something better that is someone else's doing and responsibility.
- invalidname 4y ago
  This created fragmentation and both our projects ended up smaller than they could have been. They got a lot of attention but no money. Ended up closing source and dissolving. We're still running but lost a lot of mindshare during that time.
mannykannot 4y ago
You say you disagree, but you are actually discussing a separate (even though related) issue: the maintainers' options in these situations. The article does not say "just fuck off"; it says it is what you should do if you have exhausted all reasonable attempts to get your preferred outcome.
- invalidname 4y ago
  I disagree with the tone. I have never said to anyone to fuck off or even anything remotely like that. There was one case where I had a serious unreolvable conflict. I think that's a problem and very much not something to be proud of. I don't tell people to write the code on their own or fork. I think maintainer is a job. It's a volunteer job. Yes. I have allocated hours for this job. But I need to treat users as I would treat paying customers. That doesn't mean accepting their every whim. Never. But it does mean that the "job" is one of communication and community building. Not just of coding. OP seems a bit too focused on the code and too little on the people. To me the value of writing the code is the way people use it differently than I intended.
  - mannykannot 4y ago
    I take your point, as I thought it was a bit brusque myself. I attributed this to the author going for the alliteration, and perhaps also thinking of the final response to someone who is being unjustifiably and abusively demanding.
AndyMcConachie 4y ago
I agree. I gave a talk once on a piece of code I wrote and mentioned that an OSS library my project depended on lacked a feature. I wasn't so much complaining as just stating the fact that it didn't do X and it would be really awesome if it did X. Afterwards one of the maintainers came up and asked me to make a bug report on Github. So I did. I lack the expertise or time to implement this feature and the feature is still not implemented. But it's useful to have the feature request on Github because other people find and there are a few comments on it now. Documenting stuff like this is important for maintainers. It's when the documentation turns into a form of harassment that people need to fuck off.
disruptiveink 4y ago
I'm glad to see this attitude expressed in the current sea of "reluctant maintainers". I don't really get why so many people get stuck maintaining a project when they don't want to maintain it. Just step away? If someone else wants to take it, they'll take it. If no one wants to take it, it'll just peacefully die, and that's fine. Or if you want to run a project with no issue tracker, that's also fine. That's how most of the closed source Windows freeware programs were ran in the late 90s/early 2000s. Once it stops working for most people's use cases, people will just switch to something else. Granted, this model lends itself more to full products and not libraries or frameworks. But if you want to become the "Hot New Framework", one of the ones that all the devs talk about, one that will be picked by teams across the world, with all of the clout, prestige, speaker invitations to conferences and whatnot that will get you, I'm sorry, you need to hold your end of the bargain. The mindshare doesn't come for free, if you get upset and take your ball home every time someone points out a bug in your code or requests a feature, the other kids will just stop playing with your (formerly) fancy ball. And as you found out, if people don't come with the right feedback and said feedback isn't taken seriously, your project's popularity will dwindle and perhaps even die altogether if the flaws or missing features are serious enough. You'd think this much would be obvious, but the "Don't Talk to an OSS Maintainer Ever" doctrine keeps getting more and more popular and it's really bewildering. Being an OSS maintainer for a project out in the open means that your (volunteer) job is literally talking to people. Firemen may be volunteers in many regions, but if a random fireman randomly stopped putting out fires because "I don't owe you anything!", they'd be rightfully kicked out. Just because you're not getting paid, it doesn't mean you have no moral duty to anything in life. RMS would famously shout "YOU are the GNU Hurd maintainer!" at people who asked him what GNU's plan for Hurd was. That obviously turned out great. It's a good attitude to have if you don't want anything to happen and just want to claim the moral high ground, it's not great if you want your project to be successful and it pains me that we're teaching people that it's ok to be unprofessional at volunteer jobs because you're volunteering.
- geodel 4y ago
  > But if you want to become the "Hot New Framework", one of the ones that all the devs talk about, one that will be picked by teams across the world, with all of the clout, prestige, speaker invitations to conferences and whatnot that will get you, I'm sorry, you need to hold your end of the bargain. This part goes without saying. If some maintainer does not want to do this, the framework will not become popular.

Timshel 4y ago

Nowhere it said you can't argue for your fix/change in an open issue. Just that once the maintainer close the issue: `So should you get angry and start abusing them? No.` Edit: And nowhere it makes any comments on how much/little the maintainer should listen to issues just that once he closed it you need to respect it and move on.

invalidname 4y ago
I had that. It was unpleasant (to say the least) but on a different situation I rejected a direction. User went elsewhere and we all ended up losing. I disagree with the attitude expressed there. Don't like it. Build your own. Every maintainer has his style, I don't think that's a constructive style and as a maintainer I never use that style. I might disagree with someone, I will never say fuck off. Even if I think someone should fork, I will offer help with the fork, at least in advice. Writing the code isn't where it ends. I thank every user who uses my code. Otherwise it's just another code dump. The users are what makes the work worthwhile. To me.
- deleted 4y ago
  [deleted]

Barrin92 4y ago

the list of abandoned open source projects because the maintainers burned out is I think a lot longer than the list of projects that ended because low quality complaints were ignored. Literally go through GitHub and look how few people contribute the source code to even large projects. If they lose it, it often does significant damage to a project because original creators are important. In a sense being rude is being humble. If I'm rude to bad complaints it's because I'm realistic about my limited capacity to deal with stuff. It's ironically often generous people who end up resenting what they're working on.

Timshel 4y ago
>In a sense being rude is being humble. If I'm rude to bad complaints it's because I'm realistic about my limited capacity to deal with stuff. It's ironically often generous people who end up resenting what they're working on. ??? I don't know how you define rude but I see no reason to go from something like `I'm sorry your suggestion do not align with my vision of the project` and close the issue to anything more insulting.
invalidname 4y ago
None of us measured this. Personally, I write code for the people. The good and the bad. It's very rare when someone is abusive (it happens). I'd say it's one in 1000. The ratio of people who disagree is much larger. The challenge is in creating a big tent environment that listens to everyone. This sort of "don't like it so get the fuck out" attitude is poisonous. It might not seem so in the short term but it is in the long term. As a maintainer you're a politician, not just a coder. I need to be able to take some reasonable level of abuse and stupidity. Because occasionally I'm the stupid person who didn't "get it".
thrown_22 4y ago
> the list of abandoned open source projects because the maintainers burned out is I think a lot longer than the list of projects that ended because low quality complaints were ignored. The list is the same, because a healthy project grooms people to take over if you're burning out.

Ygg2 4y ago

Hi. Another OSS dev here. Are you paid for maintaining that software? If not, and are doing another job on the side, then other people aren't entitled to your free time.

mgbmtl 4y ago
Even if you're paid, they're still not entitled to your time, unless they have a contract (support, hosting, etc). As an OSS dev on a small project, when I started getting paid (part time, for specific things), I tried being nice with everyone, but people didn't understand the limits of what I could do. They'd get frustrated and abusive. I'm more careful now. More thoughs here, but it's a bit of a hodgepodge of experiences: https://www.bidon.ca/random/2022-07-25-contributor-journey/ https://www.bidon.ca/random/2022-07-25-contributor-journey/
bottled_poe 4y ago
The thing about free time is we’re all free to choose how to spend it.
- Ygg2 4y ago
  Right, but others don't have the right to free stuff, if you don't wish to give it up first.
  - lanstin 4y ago
    And it is better to opensource the code and never help anyone with any aspect of it at all, than to not release the code.
invalidname 4y ago
I formed a company around it. Entitlement is 100% true. But I don't ask people in the OSS project if they are paying customers or not. I also work on other projects where I don't make any money. I think entitlement sucks. When people phrase things as a "demand" it's pretty terrible. But keep in mind that the internet doesn't covey emotion properly. A maintainers job is a community service job. Even if you volunteer (which is this case), either do it with an open heart or just don't do it at all. Otherwise this will be pretty frustrating in the long run. You will burn out and fizzle because you think of all the time wasted where you could have made real money. If you think about it that way... Well. Answering kindly to someone whose abusive and communicating your perception can make a huge difference. I did run into the very very rare a*hole that couldn't be reasoned with. But this is extremely rare. Most people just need to be talked to and heard. We can then work together. I can't be everything to everyone but we need to form a community of people who might not agree on everything. Those IMHO are the most interesting and valuable voices in my community.

2muchcoffeeman 4y ago

You’re allowed to run your project any way you want to achieve your goals. But I think the post still applies. If I use your project, it’s up to me to communicate bugs clearly and in a manner useful to yourself if I want a chance of getting it fixed. Otherwise, I shouldn’t expect anything or go and do it myself.

invalidname 4y ago
That's true. I'm saying there should be a discussion and a positive attitude. At the end of the day there might be toxic problems where someone will get pushed out. But I think these are things we as maintainers should feel bad about. It happened to me once and I feel sad that I wasn't able to resolve those problems. OP seems to be flaunting/celebrating what to me seems like a failure to communicate and build the community.
- 2muchcoffeeman 4y ago
  You can feel bad if your project doesn’t go that way you want. But don’t feel bad about trying to give away time and work for free!!!
  - invalidname 4y ago
    I feel bad about personal failure to communicate with a fellow engineer and come to a common understanding. I consider that a failure on my part.

barnabee 4y ago

Surely this depends on your goals? If you are an OSS maintainer who wants to build a succesful project used by a lot of people and companies and that has much mindshare, etc. etc. then yes, you will need to evaluate people's opinions, listen to them, and decide when it's in your interest to fix something or change the design or whatever. Because then keeping people interested in and using your project and in fact growing their numbers is your goal, so obviously you will need to attract and work with them. If you released some code you wrote that was useful to you and sometimes update it or fix it for others because the fix is easy or helps you too or you just feel nice, then the calculation might look a bit different.

invalidname 4y ago
IMHO That's not an OSS maintainer. That's a code dump. I don't mind those, but you don't need even an issue tracker for that...
- scatters 4y ago
  An issue tracker on a code dump is useful for users to share information about bugs, workarounds and forks.
  - barnabee 4y ago
    Yeah, some code dumps aren’t entirely unmaintained, but that doesn’t make their owners beholden to anyone.
disruptiveink 4y ago
Then turn off the issue tracker and DON'T call yourself an "OSS maintainer". Or leave the issue tracker open but make it explicit on your readme this is just a personal project that's not being actively developed so people adjust their expectations. Personal projects or unfinished work on GitHub are perfectly fine and in most cases, better to the world than something stashed on your hard drive, but you're not running any OSS project there. Feels to me some people want to have their cake (claim they "contribute to open source" on their CV/interviews) and eat it too (not have to actually do any work that comes with running an OSS project).

O__________O 4y ago

>> “I needed people to communicate clearly and with volume why I should change some opinions.” This is not how real world works. People rarely intentionally communicate unclearly — or fail to add the “volume” they feel is necessary. Only aspects that are in your control are: how you allow people to communicate with you - and what you do with what they share. - Problem with how is that the more constraints you add, less likely they are to communicate; you’re basically increasing cost for them to reduce the cost for you. - Easiest way to increase the efficiency of what you do with the information is to have another set of eyes helping process the information; in doing so, you’re delegating control and adding overhead — but gaining a predictable interface to filter less predictable information. Communicating information takes energy, and there’s only so much efficiency that’s reasonable to expect, especially when dealing with random people via systems you do not fully control.

phoronixrly 4y ago

> ...my mistakes led to a competitor ... I will never understand the concept of competition in the context of open-source. I would love to have my projects be superseded by something better that is someone else's doing and responsibility.

invalidname 4y ago
This created fragmentation and both our projects ended up smaller than they could have been. They got a lot of attention but no money. Ended up closing source and dissolving. We're still running but lost a lot of mindshare during that time.

mannykannot 4y ago

You say you disagree, but you are actually discussing a separate (even though related) issue: the maintainers' options in these situations. The article does not say "just fuck off"; it says it is what you should do if you have exhausted all reasonable attempts to get your preferred outcome.

invalidname 4y ago
I disagree with the tone. I have never said to anyone to fuck off or even anything remotely like that. There was one case where I had a serious unreolvable conflict. I think that's a problem and very much not something to be proud of. I don't tell people to write the code on their own or fork. I think maintainer is a job. It's a volunteer job. Yes. I have allocated hours for this job. But I need to treat users as I would treat paying customers. That doesn't mean accepting their every whim. Never. But it does mean that the "job" is one of communication and community building. Not just of coding. OP seems a bit too focused on the code and too little on the people. To me the value of writing the code is the way people use it differently than I intended.
- mannykannot 4y ago
  I take your point, as I thought it was a bit brusque myself. I attributed this to the author going for the alliteration, and perhaps also thinking of the final response to someone who is being unjustifiably and abusively demanding.

AndyMcConachie 4y ago

I agree. I gave a talk once on a piece of code I wrote and mentioned that an OSS library my project depended on lacked a feature. I wasn't so much complaining as just stating the fact that it didn't do X and it would be really awesome if it did X. Afterwards one of the maintainers came up and asked me to make a bug report on Github. So I did. I lack the expertise or time to implement this feature and the feature is still not implemented. But it's useful to have the feature request on Github because other people find and there are a few comments on it now. Documenting stuff like this is important for maintainers. It's when the documentation turns into a form of harassment that people need to fuck off.

disruptiveink 4y ago

I'm glad to see this attitude expressed in the current sea of "reluctant maintainers". I don't really get why so many people get stuck maintaining a project when they don't want to maintain it. Just step away? If someone else wants to take it, they'll take it. If no one wants to take it, it'll just peacefully die, and that's fine. Or if you want to run a project with no issue tracker, that's also fine. That's how most of the closed source Windows freeware programs were ran in the late 90s/early 2000s. Once it stops working for most people's use cases, people will just switch to something else. Granted, this model lends itself more to full products and not libraries or frameworks. But if you want to become the "Hot New Framework", one of the ones that all the devs talk about, one that will be picked by teams across the world, with all of the clout, prestige, speaker invitations to conferences and whatnot that will get you, I'm sorry, you need to hold your end of the bargain. The mindshare doesn't come for free, if you get upset and take your ball home every time someone points out a bug in your code or requests a feature, the other kids will just stop playing with your (formerly) fancy ball. And as you found out, if people don't come with the right feedback and said feedback isn't taken seriously, your project's popularity will dwindle and perhaps even die altogether if the flaws or missing features are serious enough. You'd think this much would be obvious, but the "Don't Talk to an OSS Maintainer Ever" doctrine keeps getting more and more popular and it's really bewildering. Being an OSS maintainer for a project out in the open means that your (volunteer) job is literally talking to people. Firemen may be volunteers in many regions, but if a random fireman randomly stopped putting out fires because "I don't owe you anything!", they'd be rightfully kicked out. Just because you're not getting paid, it doesn't mean you have no moral duty to anything in life. RMS would famously shout "YOU are the GNU Hurd maintainer!" at people who asked him what GNU's plan for Hurd was. That obviously turned out great. It's a good attitude to have if you don't want anything to happen and just want to claim the moral high ground, it's not great if you want your project to be successful and it pains me that we're teaching people that it's ok to be unprofessional at volunteer jobs because you're volunteering.

geodel 4y ago
> But if you want to become the "Hot New Framework", one of the ones that all the devs talk about, one that will be picked by teams across the world, with all of the clout, prestige, speaker invitations to conferences and whatnot that will get you, I'm sorry, you need to hold your end of the bargain. This part goes without saying. If some maintainer does not want to do this, the framework will not become popular.