8 ms·

As someone who done open source for a long time now, I think the newer generation of maintainers is missing one of the most powerful tools we have available as

As someone who done open source for a long time now, I think the newer generation of maintainers is missing one of the most powerful tools we have available as maintainers. Ignoring others. You don't like the question? Ignore them. You don't feel you have the time to support them right now? Ignore them. It feels like they are entitled? Ignore them. I don't think people asking others to work for free is anything new. The recent outrage about others asking you to work for free is relatively new though. You're publishing open source code because you feel like it. This also means you can run the project however you want. Tell people to fuck off if you don't like them. Or don't tell them anything if you don't feel like it. You'll feel much better as a maintainer once you act exactly like how you feel like it, no more and no less. Don't pay too much attention to what others say. Time is much too limited to be outraged at everything. Calm down, and ignore people you don't like.

fxtentacle 6y ago
In my case, I received most of the entitled requests via email to the address that I had used for the git commits. It's exhausting having your inbox flooded. But I agree. Delete + ignore is the right reaction in most cases. That said, I feel that the balance in open source has shifted from fellow developer users to companies leeching off your stuff to power their SaaS. So these days, I prefer offering a rate limited free API instead of local tools and / or source code. That also conveniently keeps non technical users away.
- capableweb 6y ago
  > In my case, I received most of the entitled requests via email to the address that I had used for the git commits Same here. To avoid getting overwhelmed by this, I have setup a particular email address tied to my git commits, that gets re-sent to my main email address, where it gets filtered, marked as seen and tagged as "potentially spam". I look at this tag sometimes (maybe once a month), depending on my available time, but in most cases, I just receive automated spam that is not even worth opening.
  - kenniskrag 6y ago
    you can set a private github email: https://github.community/t/your-privacy-on-github/10206 https://github.community/t/your-privacy-on-github/10206
    - capableweb 6y ago
      Yeah, I was talking about Git in general, not specifically GitHub. I'm contributing to a few projects that are not on GitHub, and my solution works everywhere, not just on GitHub.
- BlueTemplar 6y ago
  What about the developers that insist on using Github ? It's out of the question for me to create an account there, and Github doesn't allow anonymous posts. So email is often the only way to reach them.
  - AndrewDucker 6y ago
    You're choosing to not use the system they use to run the project. If that means you can't communicate with them then that is your problem, not theirs.
    - Lammy 6y ago
      Personally I think we all lose in this situation, the community included. E-mail should always be an option.
      - ghaff 6y ago
        For projects that want to cast the widest net, they should arguably engage with community (broadly) wherever they are/want to be. For small projects/individuals? It can absolutely make sense to insist on a specific workflow that reduces their work.
  - gsujsgwuaja 6y ago
    Why is it out of the question for you to create a GitHub account?
    - BlueTemplar 6y ago
      Because I'm trying to rid my life of the GAFAMs, not getting myself even more embedded into their ecosystems.
roenxi 6y ago
What is the opposite of damning with faint praise? Supporting with faint condemnation? That is a little bit outside the usual norms of the OSS maintainers that I've seen. If that is the strategy adopted in a repo then it would be polite to document it somewhere obvious when users try to submit bugs. Like a paragraph on support policy or something. But yeah that is the only strategy that makes sense to me. If they want a guaranteed professional response, they can pay professional rates for it.
- capableweb 6y ago
  > If that is the strategy adopted in a repo then it would be polite to document I disagree. This is the default assumption in open source. "You want something fixed? Fix it yourself!" If you're adopting a different strategy than that, feel free to document that, but let's not start defaulting to offering people free support, because that'll make no one happy once maintainers start burning out. I think something that has perverted the way we see open source is big companies doing open source. Of course the people who get paid by Google to work on Kubernetes has the time for answering support questions, as it's probably a part of the reason they get paid. But for us who individually do open source, or as part of non-profit work, we've never defaulted to providing free support to people who don't support us back. Let's not change that.
- Lammy 6y ago
  > What is the opposite of damning with faint praise? Supporting with faint condemnation? The "Puddy" :) https://www.youtube.com/watch?v=NNOa5Uvjpwo https://www.youtube.com/watch?v=NNOa5Uvjpwo
0df8dkdf 6y ago
Exactly! Developers publish code because they interest them. The market rate for developer are expensive. If people are too lazy to learn them self then pay the developer to do more work. Mostly open source are code that interest developer period. If you want some code that cater to your business or person need then pay for it!
- ehsankia 6y ago
  On the other hand, while I agree that users who feel entitled are definitely annoying, I don't think there's anything wrong with users posting their questions and requests. As a user you can't really predict how motivated the author is. There has been days where I've gotten a feedback I really did care about, then the next day I got another feature request that was very interesting and relatively easy, so I just did it. Just be respectful, post your question or request, and don't be upset if you get no answers.
pengaru 6y ago
It's gotten worse as FOSS has gone more mainstream. Developers/maintainers are getting a lot more contact with a larger cross section of society, which is a catch-22. I'm with you on ignoring parasites, but I also am in favor of offering 100% refunds to dissatisfied users to try drive the point home.
pizza234 6y ago
Ignoring other people is rude, and terrible, terrible advice, both in the virtual world as in the real one. There is a better approach and it's simply: politely refuse. People intruding the private email? No problem. Politely refuse, and offer private consultancy at $very_high_price, with alternative, to open a bug in the bug tracker, making explicit that there is no commitment. Something important to keep in mind is also that by establishing ignoring as a policy, one will never learn to politely refuse. I'm a maintaner as well, and I speak for personal experience.
- capableweb 6y ago
  You can write in big letters "We're volunteers working on this project for free, don't request things, ask nicely", have a notice to ask people to never write us in private, more notices about "if you don't pay, we probably won't prioritize you" and "we don't have unlimited time, if you really want something fixed, fix it yourself or pay someone to fix it" and STILL people will ignore all the notices. After a couple of years of politely declining, it gets tiring. It's OK to ignore people. It's not rude at all! I care more about my own free time (that I spend writing open source software) than I care about being polite to people ignoring instructions and expecting us to work for free FOR THEM.
- corty 6y ago
  Refusing politely takes time and effort. Ignoring less so. And about the rudeness: The person emailing was rude in the first place, being rude in return is never a problem. They didn't read the README or FAQ and ignored the official channels and means. Of course it is possible to be "nice" and earn a few bucks on the side by making it a paid request. But i.m.e. it is rarely worthwile, most start an argument after receiving the consulting offer which can only be ended by ignoring them after all. And those people are usually the bad kind of customers, complaining about rates, hours, wanting free side requests, "tax-free" invoices, etc. I've tried this (for a short while) and will never do it again. Ignoring them is actually the kindest way to do things, to them (you prevent them from wasting their time) and mostly to yourself.
  - ozim 6y ago
H8crilA 6y ago
This is a simple trick that I use at work (my project suffers from a similar problem, tons of small requests, far outstripping our capacity to fix them): ask the requester to file a bug, verify and acknowledge the problem, and then usually ignore it for a loooong time. It is actually a somewhat useful thing to have all the bugs in one place even if nobody is working on them, sometimes you can look at all the bugs together and find a common problem.
augustk 6y ago
Isn't it better to treat people the same way as you want to be treated. If you take the time to write to a maintainer, I'm sure you would appreciate a reply. Why not just politely explain why you wont spend time on the issue, maybe using a standard answer?
- capableweb 6y ago
  If someone takes the time to properly report a issue and follow up after I follow up, of course I take the time to try to help them, if I can. But that doesn't mean you have to respond. It is nice if you do, but we should not add the expectation that you'll get help from maintainers. I think all these conversations are about the expectation to get helped, not that it's nice if we do help.
- johannes1234321 6y ago
  One issue is that this often enough triggers people to think "got you" and then you get "reminders" about their problem being important and special and whatnot.
amzans 6y ago
I agree with you. As the author of a few popular open source projects [1] [2], it has been a fun ride, and I have learned a lot. However, the honeymoon period is over for me. The vast majority of the time it’s a lonely, thankless effort. The problem is that after several years and thousands of people and businesses using the software every day, very few actually take part in improving the project. Or even saying "thank you" to be honest. I’m happy to work on my project and fix issues, but please don’t abuse it. Being open source means that you can change the code if you want to, not to get a developer to work for you “out of love”. That’s why for my most recent project [3], I have decided to no longer start with an “open core” product. Instead it's a SaaS with a generous free tier. Price goes up the more value a customer gets out of it. Yes, people have already given me crap about not being open-source, but I do feel that so far it's a more sustainable model. [1] https://github.com/anthonynsimon/bild https://github.com/anthonynsimon/bild [2] https://traduora.com/ https://traduora.com/ [3] https://panelbear.com/ https://panelbear.com/
- greggman3 6y ago
  Have you thought about advertising $$$$$ for features? I suspect that's not something you have time for (nor do I) but I just brought it up because I have a friend that runs a semi-successful open source project and has managed to find companies willing to pay for support and new features to the point that he's fulltime on his project and has told me he was planning to hire one more person (I didn't follow up to see if he hired someone) On the converse, I hate the new culture of put up an open source project and ask for money, especially when that project is often very small and/or really just an assembly of 2-4 other open source projects. This seems especially common in npm/node projects now-a-days. Every repo I look at has a donate button for even the smallest of things.
  - amzans 6y ago
    Hey thanks for the input. I haven't tried that approach yet, but I'll consider it for future endeavours. So far I'm quite happy with the SaaS approach as I'm able to prioritize my effort on improving the product for customers who support it via paid plans. As a one-man team it's important to reduce operational efforts. I like very much the idea of having monthly subscriptions with predictable cash flows. Let's see how it goes.
White_Wolf 6y ago
Ignoring is one tool. Another one I have to (sometimes/more often than I'd like) resort to (especially at work) is a simple "No". The "No" is especially fun to use with people have the wrong impression that if you know how/can to do something you actually have to do it for them whenever they request it. That being said: For FOSS stuff: I do want to know if anyone finds any bugs and how to reproduce them. Doesn't mean I'll fix them though. It only means that If I think I'll end up in a scenario where that applies (or I'm bored one day) I will fix it.
- MaxBarraclough 6y ago
  > For FOSS stuff: I do want to know if anyone finds any bugs and how to reproduce them. Doesn't mean I'll fix them though. It only means that If I think I'll end up in a scenario where that applies (or I'm bored one day) I will fix it. Also, your project is better off for having the bug reported, even if it's never fixed. Known bugs are less of a problem than unknown bugs, especially if clearly documented. With legacy systems, it might even be impractical to fix the bug, as other code may rely on the original buggy behaviour.
  - pessimizer 6y ago
    Yeah, if you know the bug is there, it's often easy to write around it. Even completely ignored issue queues are useful.
  - phkahler 6y ago
    Bugs can also be categorized over time. Sometimes the solution becomes clearer over time with multiple related examples. In other words, it's easier to fix by accumulating issues instead of digging around with a debugger. This is facilitated by having no obligation to fix it now.
ricc 6y ago
This probably started with those memes by illustrators and/or graphic designers who complain about "clients" who only pay with "exposure".
darkhorse13 6y ago
I have been doing open source for 4-5 months now (main project has 1.8k stars on Github so far), so I am a newbie. However, I have always found ignoring people to be difficult. I immediately get a sense of guilt when doing it.
- alexellisuk 6y ago
  Likewise, although a few more stars and a little longer doing it. If you're interested in peering into the future, you could look at my story over at GitHub's README project for maintainers - https://github.com/readme/alex-ellis https://github.com/readme/alex-ellis Keep it up and good luck. The most you invest in community, the more you can delegate and find "co-developers" who can help you in ways you couldn't imagine.
  - darkhorse13 6y ago
    I like your modesty at a few more stars (more like 10 times more stars :p). Thank you for the advice, the README truly looks amazing.
dessant 6y ago
I've settled with giving automated feedback using a GitHub app I've built [1] that posts a predefined message and closes the issue when a label is applied. When it's hard to figure out what is being asked, or the bug report does not follow the issue template and there are no clear steps to reproduce the bug, I'll label the issue as `incomplete`, which asks the author to fill out the issue template properly, and closes the issue. I've also configured labels with messages for common questions [2] or issues that are outside the control of the project, so I can inform people without repeating the same things over and over. I agree that we should not be expected to provide support, though I find it acceptable for now to post automated messages, when it can help others. [1] https://github.com/dessant/label-actions https://github.com/dessant/label-actions [2] https://github.com/dessant/buster/blob/master/.github/label-actions.yml https://github.com/dessant/buster/blob/master/.github/label-...
- dessant 6y ago
  And regarding the corporate exploitation of open source projects, I've just discovered that a Facebook employee reimplemented the app [1] using actions and published it using the same name and configuration syntax on the GitHub Marketplace [2], so I can no longer publish my app without renaming the project. Facebook was using my app in the React Native repository, until they have replaced it with their own implementation [3]. It would be nice if they weren't jerks and at least not casually seize the project name, but here we are. Meanwhile I'm still banned from Facebook for no reason, after I've recently signed up to use Wit.ai, and they illegally hold control of my personal data on Facebook and Wit.ai. https://news.ycombinator.com/item?id=25033510 https://news.ycombinator.com/item?id=25033510 https://github.com/wit-ai/wit/issues/1946 https://github.com/wit-ai/wit/issues/1946 [1] https://github.com/hramos/label-actions https://github.com/hramos/label-actions [2] https://github.com/marketplace/actions/label-actions https://github.com/marketplace/actions/label-actions [3] https://github.com/facebook/react-native/commit/f9c2157141b8fcddcb2d2c576c952f2ce7daedda#diff-5d2241a2aa7c8754bda9b7ce7ea952e4e3313afebfedfc40d4274298ba11765e https://github.com/facebook/react-native/commit/f9c2157141b8...
  - devenblake 6y ago
    Hey, I remember you! I linked to that story in the entry on Facebook in my shitlist (https://blake.instantfloppy.net/shitlist#facebook https://blake.instantfloppy.net/shitlist#facebook).
alexellisuk 6y ago
I've gone the opposite way to this. I will usually answer as soon as I can, possibly immediately with some kind of response. The last thing I want is to have people announce my work is "dead" or "unmaintained" Perhaps I've gone too far with it. Ignoring sounds like a powerful tool. I'm also starting to offer alternatives to get "paid attention" and support https://www.openfaas.com/support/ https://www.openfaas.com/support/
blargmaster42_8 6y ago
Linus cucked to the SJW mob, there is no "go fuck yourself" any more. If you ignore them you will be removed for violating the community guidelines.
eqtn 6y ago
I have seen several times that the author of Calibre is bashed here on hacker news when he said he won't switch the codebase from python2 to python3 (later he did this).

fxtentacle 6y ago

In my case, I received most of the entitled requests via email to the address that I had used for the git commits. It's exhausting having your inbox flooded. But I agree. Delete + ignore is the right reaction in most cases. That said, I feel that the balance in open source has shifted from fellow developer users to companies leeching off your stuff to power their SaaS. So these days, I prefer offering a rate limited free API instead of local tools and / or source code. That also conveniently keeps non technical users away.

capableweb 6y ago
> In my case, I received most of the entitled requests via email to the address that I had used for the git commits Same here. To avoid getting overwhelmed by this, I have setup a particular email address tied to my git commits, that gets re-sent to my main email address, where it gets filtered, marked as seen and tagged as "potentially spam". I look at this tag sometimes (maybe once a month), depending on my available time, but in most cases, I just receive automated spam that is not even worth opening.
- kenniskrag 6y ago
  you can set a private github email: https://github.community/t/your-privacy-on-github/10206 https://github.community/t/your-privacy-on-github/10206
  - capableweb 6y ago
    Yeah, I was talking about Git in general, not specifically GitHub. I'm contributing to a few projects that are not on GitHub, and my solution works everywhere, not just on GitHub.
BlueTemplar 6y ago
What about the developers that insist on using Github ? It's out of the question for me to create an account there, and Github doesn't allow anonymous posts. So email is often the only way to reach them.
- AndrewDucker 6y ago
  You're choosing to not use the system they use to run the project. If that means you can't communicate with them then that is your problem, not theirs.
  - Lammy 6y ago
    Personally I think we all lose in this situation, the community included. E-mail should always be an option.
    - ghaff 6y ago
      For projects that want to cast the widest net, they should arguably engage with community (broadly) wherever they are/want to be. For small projects/individuals? It can absolutely make sense to insist on a specific workflow that reduces their work.
- gsujsgwuaja 6y ago
  Why is it out of the question for you to create a GitHub account?
  - BlueTemplar 6y ago
    Because I'm trying to rid my life of the GAFAMs, not getting myself even more embedded into their ecosystems.

roenxi 6y ago

What is the opposite of damning with faint praise? Supporting with faint condemnation? That is a little bit outside the usual norms of the OSS maintainers that I've seen. If that is the strategy adopted in a repo then it would be polite to document it somewhere obvious when users try to submit bugs. Like a paragraph on support policy or something. But yeah that is the only strategy that makes sense to me. If they want a guaranteed professional response, they can pay professional rates for it.

capableweb 6y ago
> If that is the strategy adopted in a repo then it would be polite to document I disagree. This is the default assumption in open source. "You want something fixed? Fix it yourself!" If you're adopting a different strategy than that, feel free to document that, but let's not start defaulting to offering people free support, because that'll make no one happy once maintainers start burning out. I think something that has perverted the way we see open source is big companies doing open source. Of course the people who get paid by Google to work on Kubernetes has the time for answering support questions, as it's probably a part of the reason they get paid. But for us who individually do open source, or as part of non-profit work, we've never defaulted to providing free support to people who don't support us back. Let's not change that.
Lammy 6y ago
> What is the opposite of damning with faint praise? Supporting with faint condemnation? The "Puddy" :) https://www.youtube.com/watch?v=NNOa5Uvjpwo https://www.youtube.com/watch?v=NNOa5Uvjpwo

0df8dkdf 6y ago

Exactly! Developers publish code because they interest them. The market rate for developer are expensive. If people are too lazy to learn them self then pay the developer to do more work. Mostly open source are code that interest developer period. If you want some code that cater to your business or person need then pay for it!

ehsankia 6y ago
On the other hand, while I agree that users who feel entitled are definitely annoying, I don't think there's anything wrong with users posting their questions and requests. As a user you can't really predict how motivated the author is. There has been days where I've gotten a feedback I really did care about, then the next day I got another feature request that was very interesting and relatively easy, so I just did it. Just be respectful, post your question or request, and don't be upset if you get no answers.

pengaru 6y ago

It's gotten worse as FOSS has gone more mainstream. Developers/maintainers are getting a lot more contact with a larger cross section of society, which is a catch-22. I'm with you on ignoring parasites, but I also am in favor of offering 100% refunds to dissatisfied users to try drive the point home.

pizza234 6y ago

Ignoring other people is rude, and terrible, terrible advice, both in the virtual world as in the real one. There is a better approach and it's simply: politely refuse. People intruding the private email? No problem. Politely refuse, and offer private consultancy at $very_high_price, with alternative, to open a bug in the bug tracker, making explicit that there is no commitment. Something important to keep in mind is also that by establishing ignoring as a policy, one will never learn to politely refuse. I'm a maintaner as well, and I speak for personal experience.

capableweb 6y ago
You can write in big letters "We're volunteers working on this project for free, don't request things, ask nicely", have a notice to ask people to never write us in private, more notices about "if you don't pay, we probably won't prioritize you" and "we don't have unlimited time, if you really want something fixed, fix it yourself or pay someone to fix it" and STILL people will ignore all the notices. After a couple of years of politely declining, it gets tiring. It's OK to ignore people. It's not rude at all! I care more about my own free time (that I spend writing open source software) than I care about being polite to people ignoring instructions and expecting us to work for free FOR THEM.
corty 6y ago
Refusing politely takes time and effort. Ignoring less so. And about the rudeness: The person emailing was rude in the first place, being rude in return is never a problem. They didn't read the README or FAQ and ignored the official channels and means. Of course it is possible to be "nice" and earn a few bucks on the side by making it a paid request. But i.m.e. it is rarely worthwile, most start an argument after receiving the consulting offer which can only be ended by ignoring them after all. And those people are usually the bad kind of customers, complaining about rates, hours, wanting free side requests, "tax-free" invoices, etc. I've tried this (for a short while) and will never do it again. Ignoring them is actually the kindest way to do things, to them (you prevent them from wasting their time) and mostly to yourself.
- ozim 6y ago

H8crilA 6y ago

This is a simple trick that I use at work (my project suffers from a similar problem, tons of small requests, far outstripping our capacity to fix them): ask the requester to file a bug, verify and acknowledge the problem, and then usually ignore it for a loooong time. It is actually a somewhat useful thing to have all the bugs in one place even if nobody is working on them, sometimes you can look at all the bugs together and find a common problem.

augustk 6y ago

Isn't it better to treat people the same way as you want to be treated. If you take the time to write to a maintainer, I'm sure you would appreciate a reply. Why not just politely explain why you wont spend time on the issue, maybe using a standard answer?

capableweb 6y ago
If someone takes the time to properly report a issue and follow up after I follow up, of course I take the time to try to help them, if I can. But that doesn't mean you have to respond. It is nice if you do, but we should not add the expectation that you'll get help from maintainers. I think all these conversations are about the expectation to get helped, not that it's nice if we do help.
johannes1234321 6y ago
One issue is that this often enough triggers people to think "got you" and then you get "reminders" about their problem being important and special and whatnot.

amzans 6y ago

I agree with you. As the author of a few popular open source projects [1] [2], it has been a fun ride, and I have learned a lot. However, the honeymoon period is over for me. The vast majority of the time it’s a lonely, thankless effort. The problem is that after several years and thousands of people and businesses using the software every day, very few actually take part in improving the project. Or even saying "thank you" to be honest. I’m happy to work on my project and fix issues, but please don’t abuse it. Being open source means that you can change the code if you want to, not to get a developer to work for you “out of love”. That’s why for my most recent project [3], I have decided to no longer start with an “open core” product. Instead it's a SaaS with a generous free tier. Price goes up the more value a customer gets out of it. Yes, people have already given me crap about not being open-source, but I do feel that so far it's a more sustainable model. [1] https://github.com/anthonynsimon/bild https://github.com/anthonynsimon/bild [2] https://traduora.com/ https://traduora.com/ [3] https://panelbear.com/ https://panelbear.com/

greggman3 6y ago
Have you thought about advertising $$$$$ for features? I suspect that's not something you have time for (nor do I) but I just brought it up because I have a friend that runs a semi-successful open source project and has managed to find companies willing to pay for support and new features to the point that he's fulltime on his project and has told me he was planning to hire one more person (I didn't follow up to see if he hired someone) On the converse, I hate the new culture of put up an open source project and ask for money, especially when that project is often very small and/or really just an assembly of 2-4 other open source projects. This seems especially common in npm/node projects now-a-days. Every repo I look at has a donate button for even the smallest of things.
- amzans 6y ago
  Hey thanks for the input. I haven't tried that approach yet, but I'll consider it for future endeavours. So far I'm quite happy with the SaaS approach as I'm able to prioritize my effort on improving the product for customers who support it via paid plans. As a one-man team it's important to reduce operational efforts. I like very much the idea of having monthly subscriptions with predictable cash flows. Let's see how it goes.

White_Wolf 6y ago

Ignoring is one tool. Another one I have to (sometimes/more often than I'd like) resort to (especially at work) is a simple "No". The "No" is especially fun to use with people have the wrong impression that if you know how/can to do something you actually have to do it for them whenever they request it. That being said: For FOSS stuff: I do want to know if anyone finds any bugs and how to reproduce them. Doesn't mean I'll fix them though. It only means that If I think I'll end up in a scenario where that applies (or I'm bored one day) I will fix it.

MaxBarraclough 6y ago
> For FOSS stuff: I do want to know if anyone finds any bugs and how to reproduce them. Doesn't mean I'll fix them though. It only means that If I think I'll end up in a scenario where that applies (or I'm bored one day) I will fix it. Also, your project is better off for having the bug reported, even if it's never fixed. Known bugs are less of a problem than unknown bugs, especially if clearly documented. With legacy systems, it might even be impractical to fix the bug, as other code may rely on the original buggy behaviour.
- pessimizer 6y ago
  Yeah, if you know the bug is there, it's often easy to write around it. Even completely ignored issue queues are useful.
- phkahler 6y ago
  Bugs can also be categorized over time. Sometimes the solution becomes clearer over time with multiple related examples. In other words, it's easier to fix by accumulating issues instead of digging around with a debugger. This is facilitated by having no obligation to fix it now.

ricc 6y ago

This probably started with those memes by illustrators and/or graphic designers who complain about "clients" who only pay with "exposure".

darkhorse13 6y ago

I have been doing open source for 4-5 months now (main project has 1.8k stars on Github so far), so I am a newbie. However, I have always found ignoring people to be difficult. I immediately get a sense of guilt when doing it.

alexellisuk 6y ago
Likewise, although a few more stars and a little longer doing it. If you're interested in peering into the future, you could look at my story over at GitHub's README project for maintainers - https://github.com/readme/alex-ellis https://github.com/readme/alex-ellis Keep it up and good luck. The most you invest in community, the more you can delegate and find "co-developers" who can help you in ways you couldn't imagine.
- darkhorse13 6y ago
  I like your modesty at a few more stars (more like 10 times more stars :p). Thank you for the advice, the README truly looks amazing.

dessant 6y ago

I've settled with giving automated feedback using a GitHub app I've built [1] that posts a predefined message and closes the issue when a label is applied. When it's hard to figure out what is being asked, or the bug report does not follow the issue template and there are no clear steps to reproduce the bug, I'll label the issue as `incomplete`, which asks the author to fill out the issue template properly, and closes the issue. I've also configured labels with messages for common questions [2] or issues that are outside the control of the project, so I can inform people without repeating the same things over and over. I agree that we should not be expected to provide support, though I find it acceptable for now to post automated messages, when it can help others. [1] https://github.com/dessant/label-actions https://github.com/dessant/label-actions [2] https://github.com/dessant/buster/blob/master/.github/label-actions.yml https://github.com/dessant/buster/blob/master/.github/label-...

dessant 6y ago
And regarding the corporate exploitation of open source projects, I've just discovered that a Facebook employee reimplemented the app [1] using actions and published it using the same name and configuration syntax on the GitHub Marketplace [2], so I can no longer publish my app without renaming the project. Facebook was using my app in the React Native repository, until they have replaced it with their own implementation [3]. It would be nice if they weren't jerks and at least not casually seize the project name, but here we are. Meanwhile I'm still banned from Facebook for no reason, after I've recently signed up to use Wit.ai, and they illegally hold control of my personal data on Facebook and Wit.ai. https://news.ycombinator.com/item?id=25033510 https://news.ycombinator.com/item?id=25033510 https://github.com/wit-ai/wit/issues/1946 https://github.com/wit-ai/wit/issues/1946 [1] https://github.com/hramos/label-actions https://github.com/hramos/label-actions [2] https://github.com/marketplace/actions/label-actions https://github.com/marketplace/actions/label-actions [3] https://github.com/facebook/react-native/commit/f9c2157141b8fcddcb2d2c576c952f2ce7daedda#diff-5d2241a2aa7c8754bda9b7ce7ea952e4e3313afebfedfc40d4274298ba11765e https://github.com/facebook/react-native/commit/f9c2157141b8...
- devenblake 6y ago
  Hey, I remember you! I linked to that story in the entry on Facebook in my shitlist (https://blake.instantfloppy.net/shitlist#facebook https://blake.instantfloppy.net/shitlist#facebook).

alexellisuk 6y ago

I've gone the opposite way to this. I will usually answer as soon as I can, possibly immediately with some kind of response. The last thing I want is to have people announce my work is "dead" or "unmaintained" Perhaps I've gone too far with it. Ignoring sounds like a powerful tool. I'm also starting to offer alternatives to get "paid attention" and support https://www.openfaas.com/support/ https://www.openfaas.com/support/

blargmaster42_8 6y ago

Linus cucked to the SJW mob, there is no "go fuck yourself" any more. If you ignore them you will be removed for violating the community guidelines.

eqtn 6y ago

I have seen several times that the author of Calibre is bashed here on hacker news when he said he won't switch the codebase from python2 to python3 (later he did this).