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.
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.
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.
For me it started as a bookmarks folder because I could never remember why I hated [thing]. It takes more time than I'd like to add entries (especially in bulk and especially to make archive links for them). If you make one you're welcome to take my entries so long as I can take yours!
Hopefully they will be helpful, and I don't have to take legal action regarding the project name, nor file a GDPR complaint for the loss of control over my personal data.
I did submit your issue to HN and now it's on the front page. I hope Facebook rectifies and I also hope Facebook engineers who hang around HN finally realize what harm their shitty employer does to the ecosystem of open source.
I agree with GP that you don't need to answer anything you don't want to, and ignoring is a valid approach. And I think closing issues is also a valid approach, it's your project after all and you can do what you want. That said, I would prefer maintainers didn't close issues that aren't actually resolved, and instead just ignored them. Maybe apply a label like "Needs more info" or "too busy to investigate" or "help needed" and just filter them out of your view.
The reason for this is that it allows others to chime in and add to the issue, and for users to discuss it among themselves and even find solutions and workarounds. I can't say how many times I've had an issue with some open source project and I find related thread in the github issues. And often the solutions or workarounds are suggested by community members, not the maintainers. But I find it soooo frustrating when the issue has been closed by a "stale bot" because it hasn't been active for 30 days.
This is the spirit of open source, IMO. The creator shares their work with the world, with no commitment or obligation, and the world makes of it what they can. Maybe the maintainer volunteers to help people troubleshoot their issues, or maybe the maintainer is too busy. That's ok. Let the issue sit there, and maybe another kind soul will happen across the issue and answer the question. There isn't enough info to reproduce? That's fine, it's quite possible - even likely - that someone else experiencing the same problem will find the issue and be able to add more context.
I loathe, I despise the stale bot on GitHub. It’s a horrible idea that should never have been implemented, and should be ripped out and thrown away with prejudice in every single case. There is simply no genuine use case for it where it does less harm than good. It is honestly the single thing that I interact with on a meaningfully regular basis that infuriates me the most.
The stale bot will unhelpfully ask if "this is still an issue" or if something is being waited on for a pull request. You take the time out to reply, so that stale bot keeps the issue open. Repeat this meaningless back and forth, for months as the maintainers ignore the issue or pull request. Eventually lose the will to continue and let the bot close the issue or pull request.
Net outcome: A potential contribution or solution lost.
Stale bot only exists for aesthetic reasons, to keep issue lists clean and to close issues that maintainers don't want to deal with directly by abstracting away the interaction.
More maintainers should understand that it's OK to just ignore an issue but leave it open.
I'm tempted to make an anti-stale bot that comments on every open Terraform issue to force a human to deal with them. I find new bugs in Terraform providers at least once a week, and invariably they're bot-closed with no resolution. There's no justification for it at all.
As the maintainer of a moderately popular project on GitHub I'm torn in this. I often get issues where I try to solve the user's problem and think I have answered the question or provided a solution, but don't get any reply from the reporter when asking if it is solved, sometimes for years. I configured Stale Bot with a IMO generous delay so the user has enough time to at least give a short reply if the issue persists. If it does, I'll gladly add a 'pinned' tag to keep Stale Bot away from it. But in the end the bot just does what I'd do by hand anyway.
If it's configured with a short timeout and with preventing further comments, I totally agree. That's rally annoying. But maybe there are circumstances where it's actually useful.
Who owns the issue tracker — the maintainer or the user base?
If the maintainer is using the issue tracker to prioritize development, they should feel fine about closing issues, especially when those issues are underspecified, ignore the project's contribution guidelines, or are otherwise incomplete.
> That's fine, it's quite possible - even likely - that someone else experiencing the same problem will find the issue and be able to add more context.
That's not my experience with issue trackers. It's far more likely that underspecified and otherwise problematic issues accumulate until the issue tracker becomes borderline useless.
The issue is still there if it is closed, including any contributed but unapplied patches.
I like your bot and have implemented similar rules in Derek to help out with the openfaas project. It's not quite as configurable as your version, but if folks are interested they can find out more at: https://github.com/alexellis/derek/blob/master/USER_GUIDE.md
There are automated actions when people delete the issue/PR template, and when they don't sign off commits for the DCO. This saves me a lot of time personally having to go and comment and explain every time. I'm going to take a closer look at your bot going forward. Thanks for sharing it.
Very cool bot! I was looking for that kind of bot a few months ago, but I couldn't find one that was still maintained, so I created my own[1]. But if you're going to continue maintaining yours (despite the FB debacle), I may just use yours instead.
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.
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.
Has your friend blogged about this approach? I'd be super interested to hear more!
I'm one of those annoying people with a donate button. Despite my project's size (~10.5k stars on Github), it pulls down only about $60/month. While awesome, and I'm legit thankful for the people who back open source, it's obviously not yet at an amount where I could devote my time to open source entirely or even part time (which would be the dream!).
My recent minor release took about 45 hours to prepare, then another 8 for a quick followup tacking on some additional functionality. Which is to say, open source gets me about $1/hr ^_^
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.
> 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.
Note: the two approaches aren't mutually exclusive. You may even find that the folks who prefer to self-host the open-source version are leads to even more lucrative on-prem enterprise plans.
The hard part to think about is segmentation of features between the open-source/free tier and the paid plan/enterprise versions.
Of course, this is all becomes dramatically easier if you decide there is no difference feature-wise, and the differentiation is solely in volume of use and level of support.
Very sensible conclusion. I like open-source products, but they're not sustainable business models and require huge community effort. If you're a solo maintainer trying to make money, then a pure SaaS business is probably a better choice for everyone involved...
It's funny how open-core gets berated on Hacker News and Reddit, as if it's somehow evil to make a living, with with decent OSS chops on you, someone is ready to call that an advertisement or self-promotion. As an industry we need to get a grip.
I completely understand the sentiment and I'm mostly there too to be honest. The one thing I fight to keep sight of is that there have to be more people just like me out there. People who deeply appreciate FLOSS work, who use it all the time, who's life has been greatly improved by it, who are willing to pay for it when they find something that is valuable, who learn lots of valuable design/implementation lessons from it by studying/hacking on the code.
For those people I don't want to hide my code. Please consider a "source available" approach (at least for the "core").
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.
> 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.
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.
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.
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.
I find ignoring requests/emails etc. perfectly fine and point about person emailing being rude in the first place is spot on. Specially in context of asking for help with things that are in FAQ.
I think parent poster was never in a position where he really has to set priorities and never tried to be polite to 1000 people in a single day.
> never tried to be polite to 1000 people in a single day
Funny, I thought this was a software orientated site. /s
Seriously though, copy/paste is fine. Autoresponders are fine, especially if noted as such in the email response. An automated response is better than no response.
Automated response is better if one expects confirmation of delivery and then more specific response.
I would be mad at a person that sets "will get back to you soon" as auto reply and never follows up. On the other hand what would be auto response when you don't want to respond? Something like "Hi, we got your message, don't expect hearing from us. Have a nice day!" that is even more rude.
Quite the opposite. Learning can only happen, if there is some kind of feedback. If the other side doesn't notice that something is off in our communication, because I do not signal displeasure about their rudeness by being rude myself, they cannot change their behaviour.
Most of the communication in the internet degrades, because information flow is lacking. If you answer politely, you can, when meeting in person, still convey an air of annoyance. You can signal the other person more than just what is being said. In written communication, this doesn't work. All the polite subtleties will be missed. All the cultural cues, like being overly polite or formal to signal distance, don't work because there are just too many cultures meeting, and you can't calibrate your interpretation to the other side like you do "at home".
This means that in the internet, you need to be more direct. You need to say what you mean. And if you need to dismiss somebody, you need to be explicitly dismissive. If somebody is rude, you need to be rude and tell them about their rudeness. Being polite for the sake of politeness is misleading, inducing the other side to continue their errorneous behaviour up to the point where things really degrade into an unpleasant situation.
From a technical perspective: Ignoring leaves the loop open. I don't know:
- if you ignore it on purpose
- or if you don't want to solve it or
- or if you don't have time or
- or if you just missed it
...
That's when I would re-send the message or do something else. A Win-Win would be sending a small "won't-fix" or whatever.
Often that's what you want! Maybe I don't want to reject your bug report outright, maybe I'll get around to it in a few weeks or months or years. Or not, I dunno.
I've had my own issues and bugfix PRs on small projects ignored, that's fine. Nobody should ever have the expectation of a response on that kind of project.
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.
It's because you are too sensitive, and haven't been in a semi-public position or vaguely popular.
When you are in a semi-public position or vaguely popular, you can have 1000 persons a day asking you for stuff. No you can't politely refuse because not only you don't have time to write the refusal, but you don't have time to even consider the offer. Ask any pretty girl what happens on tinder. It's the literall same in a professional setting if you have a semi-valuable or public position.
Then you will realize being ignored is the default behavior as you get into more "valuable" circles or look for more "valuable" ressources in general, and that it's the burden of the "asker" to make himself interesting to the person he wants an answer from. No one owes you his time because you exist. You will understand that because there will be 100s of candidates looking for the same ressource than (speaking very generally). That's when you will become less sensitive (or you will become frustrated as why the world is soo not nice with you).
Nah. If it is ok to ignore unsolicited mails and requests. It is not necessary to put effort into them.
I an strongly in camp of "it is OK to ask for features and report bugs", but it is only as long as it does not create dutys on the side of maintener. If it would create such duty, then I would think prior should not send those unless super important.
Pls, it is easy for many people to overwhelm one maibtennar.
Ignoring people is absolutely fine, especially if you make aware of the policy.
Making some software public does not mean that they are entitled to any operational or emotional consideration on your part. Having to 'refuse' costs emotional energy and karma, that bank is not infinite.
If you don't want to take inquiries, put that on the front page and ignore everything.
I don't think there's anything particularly rude about ignoring unsolicited communications in any scenario. Yes, much nicer to politely refuse, but I wouldn't say it's rude to simply ignore it if it is truly unsolicited.
Sadly, there's a type of people that will keep coming back to you as long as you reply. They won't accept what you are telling them, they will endlessly keep rephrasing what they want from you, coming up with endless explanations how it's very bad of you to not do what they are requesting. And once your patience finally runs out after 20 emails back and forth, they will throw a massive tantrum, that sometimes includes false complaints, reviews, and takedown requests. Ignoring them in the first place saves you the trouble. I guess, they quickly pick another victim instead.
No amount of README pleading, CONTRIBUTING.md or issue templates can stop the class of people which don't read and don't care. If you open an issue on my project, at the top, you'll get a message explaining that, as shocking as it may be, "debugging requires information." Then there's a checklist of 5-6 items which are the bare minimum required for me to start debugging this app which runs on numerous operating systems and platforms.
Despite all of this, about 20% of all issues ever opened in the project have blanket ignored the expectations of the project. The coding part of open source I still love. The administration of the project, and endlessly begging people to follow the guidelines, necessitates occasional sabbaticals to recover my sanity.
I delete probably 50% of my email, unread, based on subject line alone. I don't have time to read all the email I get, let alone politely respond to it.
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.
> 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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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
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.
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!
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.
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 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).
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?
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.
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.