The first example is so much cringe that had to stop reading.
Just because you made your source code available does not mean I'll do your QA for free. I might, if I think it's worth it... but if you haven't made it worth it, just forget it.
I had the almost complete opposite reaction: the user is telling something isn't working, the author interprets that he needs to fix something for the specific use case of the user. The user might have found a bug or edge case that's useful for the authors own usage. Perhaps even something the user doesn't need to function, but just stumbled upon.
Not saying that this is often the case or the author should dive into every question (the author doesn't have any obligations at all) - there are just too many ungrounded assumptions in the interpretation.
> Just because you made your source code available does not mean I'll do your QA for free
Personally, I distinguish between projects by individuals running it as a hobby/side project and projects run by big organizations for profit.
If it's something like Docker, DC/OS or Kubernetes and elementary functionality is borked / documentation is flat out wrong/outdated, yes I'll rise a stink because obviously you managed to fuck up on QA and expect that the open-source community will find and even fix your most egregious bugs for free.
For individual projects I may if I have the time actually do a deep dive into an issue because it's likely that whatever I'm hitting is because I'm using the project in a manner that the original author doesn't and therefore if I want to get it running I can either pay the author a couple of beers or get a somewhat reasonable patch together so the author can either take it as-is or adapt to their coding style but at least doesn't have to think about the issue and its cause.
If you are raising stint (as opposed to politely report bug as most people do), you are in fact creating culture where people act the same way everywhere. Because other people see what you do and who imitate it.
And developers of something like docker are less free to answer in kind.
Since the advent of fast Internet, software quality has gone so far downhill it hurts. Unlike almost all current graduates I'm old enough to know the "old world" - back when I had my first computer, patches were either unheard of at all (cartridges with mask ROM programming) or had to be distributed on CD-ROMs - so software vendors were all but forced by the realities of the market to do proper QA and deliver a product / game that was reasonably bug-free.
These days? It's usual to have games that require multi-GB patches upon release day and for weeks if not months afterwards. It's common wisdom to avoid new OS X releases for at least half a year until Apple and the software vendors (Adobe!) ironed out the worst critical bugs - and that's despite many months of pre-release collaboration between Apple and the biggest vendors. The entire culture of making and delivering software is rotten because QA is seen as a pure "cost center" instead of avoiding actual cost of shipping physical replacement items to angry customers.
Sorry, but without raising a stink when corporate entities fail at basic QA the situation won't ever change and I'm sick of playing the free beta tester for multi billion dollars worth corporations that could afford proper QA.
The author isn't asking you to QA his app. He's saying that if the app doesn't work for you then you need to incentivize him to look at why and to change it so that it does. You're very welcome to just not use the app instead, or to fix it yourself.
I admire the principle behind his stance, because supporting people for free is horrible. I'm not sure I'd ever have the guts to do it myself though.
OR, you wrote the software that you don't need or use it yourself specifically with the intention to make money selling support and customization and released it as open source because you want to get users who use it for free to do the QA, Development and marketing for you for free.
I, as a random user, can't know which is which or care and most of the time can't be bothered.
I thought it is already difficult to make people report damm bugs? I could kind of see the point with demanding that bug is fixed or feature is made. But is reporting bug really same as "demanding free support"?
Also, maybe it is about culture of platform, but I regularly watch few java open source projectals and had one own. The insulting or super entitled exchanges were quite rare. So i don't know, if majority of those exchanges turn into name calling, then either local culture is awful or there is something else at play.
Reporting the bug would at least save someone else some headache trying to figure things out why it is not working as expected, or make them able to decide whether the piece of OS is useful for their use case. If you don’t want to receive this, disable the issues feature in your code sharing platform..
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.
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.
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.
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.
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.
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.
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.
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.
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.
I agree with this approach. Most people who don't want to do this cite the effort required, but you shouldn't have to put a lot of effort into a polite refusal - you can literally just create an email template or some other copy/paste mechanism to simplify the rejection. It shouldn't take that much longer to refuse in this way than it would just deleting it, and then possibly having to deal with continued pokes.
And who knows, if you actually _do_ refuse with a note about $very_high_price as an alternative, they might just buy!
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.
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).
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.
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.
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.
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.
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.
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.
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 ^_^
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...
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").
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.
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.
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.
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.
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 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.
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.
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).
I’ve started thinking about it like there’s 3 kinds of people who I interact with in my opensource work: collaborators, customers and leeches.
Collaborators contribute their time, energy and skill into the opensource ecosystem too - either by submitting good code to my project or donating their time to other projects I might reciprocally use.
Customers / benefactors make money using my project and pay me some of that money to keep the lights on.
Everyone else is a leech. They just want something for free and get irate when they get called out for it.
The trick with support requests / issues is they can be opened by anyone. You can tell the customers apart from everyone else easily, but is the person filing an issue looking to contribute in turn, or are they a leech wanting free support? A well written bug report is also a love note, after all. I still don’t have a good metric; but I’m definitely drawn to some filed issues more than others.
I worked at a company a few years ago which (like everyone else) uses a software stack packed full of opensource code. There was a simple indexing service in our infrastructure which I designed so we could opensource it in turn. When it was ready, the legal team refused to let me opensource it and that was that.
I felt really gross about that decision for awhile and it took me months to figure out why. My take now is that I was complicit in a parasitic use of opensource maintainers’ free support to fix issues we ran into. Despite that workplace choosing to never being part of the community, we pretended we were so we could get free support for our free software without giving back in any way.
In retrospect I wish I’d pushed harder on the legal team. Or suggested we sponsor some projects as an alternative.
A good bugreport and good followup on questions, is also collaboration. Those will only strengthen the code or documentation in some way.
When people ask you to fix their problem, without providing any useful information or relevance to the software, it's hoping for free support. For companies offering free support, it sometimes makes sense to dive that deep into userland.
For individuals you need a clear model what you're willing to do and how, as something that at first may seem fun and engaging, can quickly become too much and draining over time.
Depending on the project I fall into one of the first three, I might send a PR, I might suggest we buy/pay a maintainer or I might just be using your library as a dependency of a different package, I'm never the last one.
Well put - I'm going to start using this analogy myself.
The only people who matter to a project are contributors and customers, and mostly the former. A smart maintainer invests 100% of their energy into this group, and 0% into the leeches. The software will obviously be better if you invest your time and energy into the needs of people who give back to the project.
>From there it typically derails into a whiny tirade about me being a crappy two bit developer who doesn’t give a shit about his code (which is ridiculous, since, professional pride aside, I have every incentive to fix bugs, to prevent my inbox from getting flooded) and just wants to rip off his users.
If you really cared about fixing bugs then you'd take bug reports. Taking a bug report does not mean you are forced to fix it (which is work, which costs money), but at least you'd be aware about the existence of the bug.
So, charging for bug fixes, okay. But if you don't even want to be aware of bugs, then yes, you are a crappy maintainer.
But that ignores what the author said after that...
> Here’s the thing: I write open source software to solve my problem. I let you use my solutions because that comes at zero cost for me (well, almost, I still have to pay for the website, you are downloading from.
If I had written some code to solve a problem of mine, I'd want to know that it contains bugs; I would not want to wait until those bugs blew my systems up.
Even if it was past code that has run its course and I no longer use, if the code is posted somewhere such as github, future users might want to read the list of bugs reported by others to be aware of them (and to see workarounds potentially posted by others).
Some bugs are due to an esoteric setup of the user. There in a quasi infinite variation of those in the Linux world. Generally, supporting them makes the software more robust, but it's also very likely that you would never encounter that bug yourself.
Some bugs are just support requests. The user didn't understand how to use the software and is confused. Generally the report is quite lacking and it takes a few back and forth to get somewhere.
That's true to some extent. If you see a lot of users having the same issue it might be the case. Sometimes it's also people not bothering to read the documentation.
As a maintainer it's also your right to develop a tool just for yourself, and share it for the world. In which case, documentation is not necessarily the priority. And it's fine.
> Sometimes it's also people not bothering to read the documentation.
Yes, sometimes it is.
> As a maintainer it's also your right to develop a tool just for yourself, and share it for the world. In which case, documentation is not necessarily the priority. And it's fine.
Absolutely fine. Although I'll point out that it is usually a lot easier to get documentation PRs contributed than code PRs.
So there's a 0% chance that I might find an issue that affects the author's usage somehow? There's absolutely no possibility that I might notice some detail on some edge case that the author hasn't noticed and which affects his own use in some way? The author is infallible and has validated 100% if his use cases to 100% certainty?
Because if he's not infallible, he should want to at least be aware of bugs in the software. Not wanting to know about bugs is exactly equivalent to not being interested in the quality of your work.
If you're not interested in the quality of your work, then I don't want to use your software. And I'd hate to inadvertently cost you a tenth of a cent by downloading your crap, so please shut down your webserver and don't release any new versions publicly - save yourself the money and save everybody the time and effort of having to interact with you and your shitty software.
The author (and most FOSS maintainers), as they explicitly called out in their article, are making the software for themselves, and making it open source because it's the nice thing to do. It follows that any bug that doesn't personally affect them is not something they need to care about.
There's no greater good of "caring about fixing bugs" here. To quote the MIT license: the software is provided “as is”, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement.
I don't think maintainer is the right word for someone who isn't interested in maintenance.
The long tail of FOSS projects might be things people wrote just for themselves. The most used projects aren't. Most of the projects most people use aren't.
Almost all software has a warranty disclaimer. It would be irrational to assume it means the software is unsupported.
I've had tremendous success by removing the "Issues" tab on a couple of my more popular and beginner-friendly Github repos[1] and just leave the "Pull Requests" open! Support tickets have gone down to almost 0 (I still get the odd email from time to time, to which I promptly quote a price and never get an answer), and most who contribute actually give back value.
As Alex says in this blog post though "it typically derails into a whiny tirade about me being a crappy two bit developer". Luckily this only happened twice for me, but it's funny because in here you can see it on the open[2] as someone opening a PR adding this text to the README:
> If you spot a bug or any other issue you may go to hell because this software is officially Bug Free(TM).
On a very perverse way I am kind of happy that happened, since it ratified my decision and I became a lot more strict about when I help people. Any sense of "guilt" I had remaining after closing the Issues for not providing free support totally left after that incident.
While I feel bad that you had people treat you without respect, I don't think turning issues off is a sign of a serious project that should be used by many people in production (even if the project itself is nearly a work of art).
The recent example is Gitea which was forked by a community from Gogs because a single maintainer there was very picky about which issues to resolve, was refusing or taking very long to review PRs etc. I think both Gogs and Gitea coexisting is a very fine example of open-source working. But I think Gitea model is how a non-toy software is to be developed.
I often look at how many issues are labeled 'bug' before considering adding a new dependency to my project as well as check how many old issues are unresolved.
You don't have to resolve all open issues but closing an issue tracker the outright signals "I don't care if you have problems and I do not intend for this software to be maintained in any sense of collaborative fashion here on Github". Above all, such behaviour signals to me that there is only 1 person making commits / merging PRs and they are kind of tired of OSS (which is fine, by the way).
> While I feel bad that you had people treat you without respect, I don't think turning issues off is a sign of a serious project that should be used by many people in production (even if the project itself is nearly a work of art).
For some people, this is a good thing.
> You don't have to resolve all open issues but closing an issue tracker the outright signals "I don't care if you have problems and I do not intend for this software to be maintained in any sense of collaborative fashion here on Github". Above all, such behaviour signals to me that there is only 1 person making commits / merging PRs and they are kind of tired of OSS (which is fine, by the way).
I think it's more nuanced than that. It's perhaps more "I care if you have problems only if you have put in the effort to try and fix them. Then we can work together on getting it fixed for everyone".
"Issues closed, PRs welcome" is a perfectly reasonable way to run a healthy project.
Most projects on GitHub don't have a mailing list. Turning off issues makes it hard to tell if a project is in good shape. It prevents users who have relevant knowledge from helping users who don't.
Solving a problem together means agreeing on the problem and the solution before someone spends days working on it.
It's a trade-off, for sure. But it's on the project owner to make that call. It's not always the case that one model is best for any given project/maintainer/set of users.
As for project health, I treat the git log as a far more reliable indicator than the issues list. That shows me what's actually getting done.
> I don't think turning issues off is a sign of a serious project that should be used by many people in production
> Above all, such behaviour signals to me that there is only 1 person making commits / merging PRs and they are kind of tired of OSS (which is fine, by the way).
The linux kernel doesn't have an issue page and PRs receive a polite comment on how to send their PRs as patches outside of github.
Also, having a mailing list does mean to have a communication channel open and AWS SREs (for the sake of argument only) do not need to pay to join that mailing list and post some questions.
Finally, I think this one of the few instances where "You Are Not Google" fully applies.
You should at least mention your policy of not accepting any bug report/feature request in the "contributing" section of the readme. It's fair enough but at least say it, because it's not the norm.
Coming from the commercial software development side, I can tell you that all bug reports are always processed for free and on a high priority. Not talking about "your stuff doesn't work" sort of reports, of course, but the actionable "did X, got Y, was expecting Z" ones.
Moreover, if the reporter also helps us with resolving it, i.e. provides logs, stack traces, runs custom builds, etc., then we will always reciprocate with freebies.
So seeing that this person is forcing people to pay to report bugs is absolutely wild.
I understand that he's basically sharing his own tools with others for free and if it works for him that all that he cares about, but the bugs are always on the developer. The least you can do is accept a report and say Thanks. That's a complete no-brainer.
Do you mean that the developer caused them? Because that is _mostly_ true but not always (because you can have bugs reported to you that are upstream ones).
Do you mean that developers are responsible for fixing them? That is simply false, even in commercial software you have no moral imperative to fix bugs, and very often with good business strategy you ignore a lot of inconsequential bugs.
Just about any serious FOSS developer I know has commercial software development experience, so I don't think your opinion is as unique as you might imagine.
I can understand this behavior from the perspective where bug reports provide cost rather than value. If my piece of software works for me in my use cases and I am not interested in fixing it for other people (as is the case for the author), then bug reports are costs, rather than value. Minimizing costs in this scenario means refusing to accept costs (in this case, bug reports) unless something of value (in this case, money) makes this deal acceptable.
I understand the point of the original article, since I agree that most people are entitled whiny jerks much of the time, myself included. I’m not here to argue that anyone should be obligated to provide help or fixes for their open source software, paid or otherwise.
I do feel that’s an important point — paid or otherwise. There’s a similarly whiny attitude people have: “I paid $5 for your thing, so you have to do as I say!” I don’t really think the distinction is how much it cost. If you have a support contract that says “in exchange for paying me, I’ll help you with X, Y, and Z”, that’s a different story.
But what I really wanted to remark on: to the point of “activities that take no time at all”, when I report a bug, I often spend hours of my time trying to understand what’s broken, narrowing it down to specific conditions and observations, often a attempting to fix it myself, and then writing everything up and whenever possible including test cases, screenshots, videos, etc. By the time I hit send on that bug, I may have contributed hundreds or thousands of dollars of my time to the project.
It’s also possible to just take 5 seconds to fire off “your stupid app is broken your stupid too fix it”. All I’m saying is that painting all bug reports with the brush of “trying to get free support” discounts the amount of free QA open source projects can benefit from.
> I may have contributed hundreds or thousands of dollars of my time to the project
Sure, but that was you deciding to do it, and it's commendable.
This is very different from someone emailing you and telling you to (or expecting that you will) donate thousands of dollars of your time to a project.
It's not other people's bugs. It's your bugs. You created them in the first place, and somebody is offering to help you _for free_ by reporting them. Charging them for helping you is outright stupid.
It's not a bug if it doesn't affect my use-case. It's undefined behaviour at most.
It might even be a bug if you compare to my specification, but, again, unless I have some reason to care about it (money, wanting the project to be good) then it's not a bug.
That's of course a determination you can make once the bug report comes in. But rejecting all reports outright without even looking is really missing out on one of the key advantages that open source culture brings to the table.
This aspect is not specific to open source either. In my book, maintainers of proprietary software, and I'm one of those, are also making a huge mistake if they ignore bug reports from users. But in open source, it goes further, by inviting contributions even in form of patches for bugs or improvements. Not allowing any of those is what I call stupid in the above post.
It must be very strange that I write bug reports on software that I'm never planning to use again, or to even visit the website again after the bug report is closed or is clearly not seeing any action that would require me to respond.
Usually my deadlines aren't so far in the horizon that I can wait for an unpaid maintainer to come up with and release a fix. If the problem is that easy to fix, I've probably already fixed it on my end and am just tossing a patch over the wall as an afterthought: use it verbatim, use it as inspiration, throw it out - just please don't take it as an insult. If the problem is a very hard fix, while I was discovering how hard it would be I was simultaneously researching alternatives (including rolling my own), and the bug report is me delivering a summary of why I thought the problem might be hard to fix and some ideas, although there might be a criticism of a claim in there too. The criticism might be considered a request for support - not for the software, but for the webpage making the false claim. I've also probably already moved on.
Testing isn't free, either.
edit: when I really think about it, I never want to file bugs and always think of it as work. I do it out of a responsibility to contribute back to the software or because I like the maintainer. I do it because when I google problems I'm running into, bugtrackers come up with someone else describing the same problem I'm having and what they did to fix it. I would prefer not to file bugs and have to make myself do it by putting filing the bug into my schedule.
It is usually very easy to tell if the problem is caused by a half-assed cracking or if it's a genuine issue. If it's the latter, then, yes, we certainly act on it. Doesn't mean that we follow up with the submitter though.
Also, don't mistake bug reports for support queries. These are two completely separate things.
As an Open Source maintainer, I feel ambivalent about the issues filed against projects I maintain. While a particular issue may seem to be written with a sense of entitlement, it nevertheless often tells me something useful. I'd much rather someone file an issue than not, even if the tone was a bit off.
It's often easy to misinterpret people's tone in a bug report. A person might still be frustrated with the bug itself, not the developer. They may be venting exasperation at having to fight through the problem, rather than truly expecting the author to deliver a solution.
As long as someone files a productive report with enough information to reproduce the issue, i'd rather forgive any uncharitable tone.
> A person might still be frustrated with the bug itself, not the developer. They may be venting exasperation at having to fight through the problem, rather than truly expecting the author to deliver a solution.
+1. One time I spent an entire evening trying to configure a server that refused to work, I kept on tweaking the config files and restarting it repeatedly, at least 20 times or so, before finding out that the feature I needed was broken. I joined the IRC channel and ranted "I literally wanted to throw my computer out of the window". Someone said I was overreacting, I repied I don't have any problem with the software or its developer, just frustrated by the broken feature itself. One day later, I debugged it, submitted a patch and got it merged.
Sadly, it often happens with doing work on a volunteering basis, whether it is open source or organizing communities.
I do put in as much effort I want or have committed to. But then, people expect more, even if I explicitly say I am not for that (e.g. discontinued projects, expecting free consulting, and getting offended for even a suggestion of paid options).
For example, I used to run the biggest Data Science group in Poland. It was a lot of effort to grow it from nothing to 14k participants. Yet, after explicitly saying that I don't answer questions about moderation (and even worse: messages pushing me to review a post right now), it keeps happening. If I don't (and I try to keep my boundaries), people get offended.
I think there should be a message (regardless of the context): if someone is volunteering, DON'T EVER push them to do more than they committed to. Pushing for more is as reasonable (and kind, respectful, etc.) as telling a stranger to go and clean your dishes. For free. Right now.
" if someone is volunteering, DON'T EVER push them to do more than they committed to"
That should be a no brainer, but sadly people do it, becuse it works. People who volunteer have a tendency to help others beyound their own limits. And other people exploit that.
Setting up your boundaries is extremly important, not just in open source.
> Thanks for your request. Now that we are talking, do you mind swinging by and do my dishes? They have been piling in my sink as I was too busy fixing other people's lives.
If you see your open source project as your personal project and you don't want to spend time on it make it explicit in your README.
Community projects usually are more than happy to receive bug reports because they want to build the best software they can. If you want to build a community project being friendly works wonders.
How ist one able to distinguish one from the other if not from the README.
Over the years I've developed numerous libraries that would be useful to other devs and considered open sourcing them, then I look at the way open source developers are treat and thought "nope".
I've no interest in any of that mess if I'm honest.
«
User: I just want to tell you that your app is broken, so you can fix it.
Me: Yes, that's a support request, please open a ticket.
»
This is painful.
Maybe the user is being reasonable, maybe they're not.
Can't we do something to get (back) to a common understanding that reporting a bug is not the same thing as expecting the maintainer to fix the bug for you?
From my experience if someone starts a conversation about bug like that it’s not even a bug. Same thing is with “hey, can I ask a question?” on forums or IRC channels. ;)
If someone really informs you about a bug they are usually straight to the point.
I’m not willing to do the same as this developer (charge to file bugs), but I have the “luxury” of not being popular enough for it to be a problem.
The one project that I did create, which has become a worldwide standard, used by thousands (not millions), is also now maintained by an energetic and enthusiastic team, who react very well to questions and requests for support. They have a Facebook group, and a number of other interactive options (like a Slack workspace).
In that case, we also have the “luxury” of the system not being used (or useful) for making money. It’s a totally free system, customized to a fairly narrow demographic.
I feel that it’s important to do a good job, and maintain the highest possible quality; regardless of whether or not anyone uses my stuff (I am my own best customer. Most of my projects are dependencies for other projects I have written).
In that vein, I don’t see that making it difficult to report bugs is such a good idea.
If I am not interested in fixing a certain issue (like if it’s a bug that I don’t think affects my own projects, and would destabilize the system, if I tried to address it), then I’m more than capable of politely and respectfully saying no.
Maintainer of a few open-source projects here. I've seen some angry sentiment from other maintainers about people demanding they implement features without contributing back. There was a piece on hn recently where a maintainer went ballistic on GitHub about big corporations not paying him for his work.
It's pretty funny to me. I had a bunch of people ask me to implement features or fix bugs, and I just told them I don't want to spend time doing that. Very few had gotten entitled, and even those went silent when I told them I'm a volunteer.
I think it's still important to let people speak and ask for things, even if you're not going to give it to them. Also I have zero expectation of anyone ever paying me for my open-source contributions.
One nice thing about rude people is that at least they tell you what they want.
Exactly, I often say: yes, this seems like a valid bug report but I am currently focusing on other things at the moment, though I will be happy to review and accept a pull request if you figured out how to solve your problem. I have yet to see an entitled reaction to that (maybe I am lucky though).
Your experience matches with mine, if people request features I don't feel like working on, I reply with "yes, this is something I would merge if a PR were submitted, thank you!".
Then again, my experience with FOSS has been almost exclusively positive. People have never been entitled to me, they've always been helpful, and I've gotten people co-maintaining projects and submitting lots of PRs to me as well.
It was perhaps that optimism that led me to create https://www.codeshelter.co/, which didn't really do very well. Turns out not as many people want to maintain projects as I thought.
Thanks! I used to come across unmaintained projects that I'd be willing to merge some PRs for (they'd usually have them pile up), that's how I came up with the idea.
I think most people expect that they'd add their project and get immediate help, when the project is more a backup plan to straight up abandoning a project. I think you're the first person other than me to get excited by it, so thanks!
On one hand, the author's point is understandable. However, on the other hand, I highly doubt that the author have never ever requested any help / support from maintainers and/or core developers of any open source software (OSS) that the author most certainly uses and/or have used, e.g. Linux, Android, ADB, whatever. This is in addition to free improvements and bugfixes that most OSS projects provide thanks to relevant people who (surprise!) spend their time on that, too. So, virtually replying to the author on "my time is valuable" -- Guess what, others' time is valuable as well. Hence, your stance is questionable.
We are using two nice OS Python libraries on a project at work right now but I think I’ve found a bug in one of them. It has caused us lost time in development and could also trip us up again. I consider it part of my job to figure out how to fix it and send a PR if I think it’s good enough quality. The idea of saying ‘we can’t do this because of a bug in X’ didn’t really cross my mind - because that’s the whole point of open source is it not? I can open up the source and debug and figure out a workaround or a fix.
Just because you’re not paying for it doesn’t mean it’s free, you’re still going to have to do some work.
It is free. It's so free that you are not just not paying, you even have the freedom to fix the issue yourself.
And contributing the fix upstream is not selfless either. You don't want to keep dragging the patch along with every new release. You want it upstream so that you can forget about it.
Just as much as the maintainer can now fix a bug which somebody else for free reported and even contributed a patch. Refusing to even listen is mindbogglingly stupid.
Of course there can be disagreement about whether the bug is worth fixing or whether the patch is a good solution. But that's a different story.
It's not stupid. It's just a matter of how much time the maintainer has and how they wish to spend it. People who submit PRs forget that they are the only person, at the time of submission, who understands what their PR does without any further effort. Maintainers have to spend time (away from their day job or leisure time or whatever) understanding your work and not getting paid a cent for it. For a popular project, spread that effect across a thousand or so users.
What I called stupid is "refusing to even listen".
Of course you are not getting paid for it. Just as little as the guy sending you a patch. If you want you issue tracker to be pay-only, would you be fine with allowing people to submit patches that you can only open after paying?
The "not getting paid a cent for it" is just flipping the entitlement problem around. The person reporting a bug is not entitled to a fix, nor even to be heard (even though, as I claim above, ignoring them is usually not the smartest thing for a maintainer to do). Neither is the maintainer entitled to get fixes attached to bug reports, or even a certain quality in bug reports themselves. All of this is voluntary, nobody is entitled to anything.
But what you can do is foster a good culture. If you incentivize high quality bug reports, for example if somebody shows they made an effort when reporting the problem and you respond with a positive answer, then people see this and adjust their behavior accordingly. If you accept pull requests, especially high quality ones, especially those where everything is well-explained, well-structured and the maintainer's comments are addressed, people will tend to adjust and do it like that more.
Just as much as if you are and asshole about bug reports, you'll likely not get high quality ones or even fixes any longer. Likewise, if a bug reporter is just rude, they won't get attention from the maintainer any longer.
It's all reciprocal. Nobody is entitled to anything. If you play the game right, it's a very productive collaborative framework. And a lot of fun.
> I can open up the source and debug and figure out a workaround or a fix.
I use a lot of open source software I'm not even remotely capable of understanding, much less fixing. I figured I was at least an average coder but maybe I've been fooling myself.
You might well surprise yourself. The hardest part of the whole thing is accurately distilling exactly what was causing the failure. And this is also where you the user is the best placed.
Mine had to do with Python Datetimes and timezones and after figuring out how to reliably reproduce it with a minimal case I could step through the stack trace and see what the library was doing (not much, just 'adding' some times together) and could see what might be causing it. (I haven't actually got to the bottom of it yet - I had other stuff to do.) But really the hard and time consuming step is that first bit. Of course, like anything it's a cost benefit - if it'll take weeks to nail it down and fix, vs using something else - then of course, a new approach is needed.
What is so missed here is that the people asking you for help are not some faceless Corp they're actually salaried engineers looking to get their job done, potentially on the hook for some system they didn't even author.
You don't have to answer for sure if that's what you choose, but don't expect that pleb engineer on the other side to be able negotiate any remuneration for you as a individual contractor.
This is a problem that the "pleb engineer" will have to figure out though. You do not expect any other type of contractor to care if a "pleb engineer" can or cannot negotiate contracting him.
And also, even if said "pleb engineer" isn't some faceless corp, said faceless corp (assuming the engineer isn't themselves a contractor or self-employed) is still benefiting.
I am someone who both publishes and contributes to open source projects, and also regularly files bugs against other people's open source projects.
I start from the same intuitions as the OP but they lead me to the exact opposite conclusion.
I consider my time a limited resource and the most important currency I have. Spending my time on trying your piece of software is already an investment on my part. You aren't solving anything yet for me. Finding out that your software does not satisfy my needs is a financial loss for me. I have now sunk costs into your software and got no ROI.
So when I take the time to sink even more cost into you and your buggy software, to tell you what I tried and how it didn't work, then please recognize that is highly irrational of me. The sane response would be to cut my losses and maybe publish a one star review of your cruddy work somewhere. :)
This view holds for both paid and open source software, by the way.
So the very fact that I do take the time out of my day to tell you about bugs in your software can only be explained by my idealistic and altruistic nature. (I'm putting it on a bit thick here to drive the point home)
If I report a bug to you, I am not doing myself a favor.
I am doing YOU a favor. One that I have no expectation of getting paid for. Even if you go ahead and fix the bug I reported, that means I still sunk unnecessary cost into your enterprise. NB: I have no reason to expect the rest of your software to work. The very fact that I found a bug already makes it more likely that the rest of the software is just as deficient.
So the very least I expect is that you graciously acknowledge my bug report and the time I sunk into your project. I expect you to thank me for taking the time to file a bug with you. Why? Because if you fix your code, that improves your reputation, not mine. So I did something for free that helps you, not me.
Let me make this clear: The actor causing the cascade of fail here is you, not me. Had you published good software (or no software at all), we wouldn't be in this negative spot. I wouldn't have wasted time on you or your buggy software, and you wouldn't have to waste time deciding how to react to my bug report.
I think the way out of this dilemma is to document your software honestly.
If you wrote the software for yourself and had no plan for it to work for others, then SAY SO on the project homepage.
If you wrote the software to learn how stuff works, and are happy if it builds, but don't expect it to solve the general problem for others, then SAY SO on the project homepage.
I will then not download it if I was looking for a solution to anything, only if I also just wanted to learn how stuff works.
That said, my experience with reporting bugs has been very good all things considered. I would like to mention postgresql and llvm as being exemplary here. Their response to bug reports has been a shining beacon that led me to recommend their software even on paid projects I am involved in, where I feel crappy open source software I recommend could come back to damage my own reputation.
Also if all the bugs turn out being people using your software wrong, than maybe it's not them, maybe it's you. Consider making the UI more self-explanatory.
> I consider my time a limited resource and the most important currency I have.
The same applies to the developer of the software you are trying to see if it solves your problem. The rest of your conclusion relies on your assumption that your time is more precious than the time of the developers that wrote the software.
I hope you realize the posting was about how the same factual basis and assumptions can be used to support the opposite conclusion, not about me or my personal standpoint and the developer.
That said: Actually, if you think about it: It is. Both to me AND to the developer.
If the developer treats my time as precious, and enables me to skip his software altogether or to use it without having issues, then I will waste zero of his time. I will also waste less of my own time, but that is probably less important from their perspective. Since there is one of them and hundreds or more of me, this pays dividends very quickly for them.
The important difference is that the developer actually put effort in making the program you are talking about, so them not wanting to waste their time in supporting you is not equal to you feeling entitled to their time. Your only effort in the entire discussion would be to decide if you want or not to take advantage of the program to solve your problem, which is certainly less than the effort the developer put to create the program (otherwise you'd just be making the program yourself).
You are confusing infrastructure projects with enduser application projects. The former welcome your work because there is (usually) a monetization path for it and your bugreport actually IS a bugreport (what is the intended behavior, what is the actual behavior, how can the bug be triggered). The later ones typically get swamped with "it doesn't work, fix it!" which then turns into a game of twenty questions and the conclusion that the user was doing something stupid(TM).
Also, seeing your nickname, I'd like to mention "Medienkompetenzübung": The point of the article is not about not accepting bug reports, but support requests being disguised as bug reports in order to bypass the fee, to a point where the abuse greatly outweighted the benefits. The logical conclusion: shut the channel down at the risk of loosing some value. I believe, you have a similar policy with the killfile for your blog.
There are two kinds of authors of free software: Those who wrote something for themselves and are willing to let the public have the code (but no more than that; and those that want to want their software to be used by the public.
What the author is describing is users confusing the former for the latter.
I believe we should all be the latter rather than the former. But even if we aren't - the onus is upon us to make this clear to the users. It is perfectly reasonable for a user to assume developers will accept bug reports (which is not the same as assuming the bugs will get fixed promptly).
Also, as a FOSS developer - I believe the author is underestimating the significance of accepting bug reports from the public. This has saved me some embarrassment in the past and even got me some collaborators which I would otherwise not have had.
Always when management decides to attempt to replace $enterprise-solution with $foss-solution that cost "$0" I tell them:
* You need to maintain the system and manage the full life cycle
* You need testing
* You pay for all of the above
* There are very,very,very few world-case FOSS projects around (like: redis, clang, elasticsearch, linux, ...) that maintain themselves on an enterprise-quality level, so be prepared to upstream *a lot of bugfixes yourself*
* Where there's no money there's no priority
* Your $0 solution will cost $100,000 annually
It's why we use a proprietary git server appliance vs a self-hosted, self-managed version.
> You need to maintain the system and manage the full life cycle
Do your vendors maintain your systems? Maybe, if you pay them well enough.
> You need testing
Because "enterprise" software is bug free. Just because someone sells you software and pretends they test, or even if they do actually, you still have to test in your environment.
> You pay for all of the above
Yes, either in manhours of employees or cash to a vendor.
> There are very,very,very few world-case FOSS projects around (like: redis, clang, elasticsearch, linux, ...) that maintain themselves on an enterprise-quality level, so be prepared to upstream a lot of bugfixes yourself
There are many more, and even stuff like Hashicorp's projects are at a better level than say Atlassian's crap in terms of "enterprise quality".
> Where there's no money there's no priority
Are you under the impression that just because you're a paying customer you're somehow a priority to the vendor? You can tell that to all the people with stuck feature requests or unanswered/unfixed bug reports. At least with FOSS you can actually take a look yourself if nobody else wants to.
257 comments
[ 5.2 ms ] story [ 284 ms ] threadJust because you made your source code available does not mean I'll do your QA for free. I might, if I think it's worth it... but if you haven't made it worth it, just forget it.
Not saying that this is often the case or the author should dive into every question (the author doesn't have any obligations at all) - there are just too many ungrounded assumptions in the interpretation.
Personally, I distinguish between projects by individuals running it as a hobby/side project and projects run by big organizations for profit.
If it's something like Docker, DC/OS or Kubernetes and elementary functionality is borked / documentation is flat out wrong/outdated, yes I'll rise a stink because obviously you managed to fuck up on QA and expect that the open-source community will find and even fix your most egregious bugs for free.
For individual projects I may if I have the time actually do a deep dive into an issue because it's likely that whatever I'm hitting is because I'm using the project in a manner that the original author doesn't and therefore if I want to get it running I can either pay the author a couple of beers or get a somewhat reasonable patch together so the author can either take it as-is or adapt to their coding style but at least doesn't have to think about the issue and its cause.
And developers of something like docker are less free to answer in kind.
These days? It's usual to have games that require multi-GB patches upon release day and for weeks if not months afterwards. It's common wisdom to avoid new OS X releases for at least half a year until Apple and the software vendors (Adobe!) ironed out the worst critical bugs - and that's despite many months of pre-release collaboration between Apple and the biggest vendors. The entire culture of making and delivering software is rotten because QA is seen as a pure "cost center" instead of avoiding actual cost of shipping physical replacement items to angry customers.
Sorry, but without raising a stink when corporate entities fail at basic QA the situation won't ever change and I'm sick of playing the free beta tester for multi billion dollars worth corporations that could afford proper QA.
2.) Not a single massive game you mention is open source or have public issues tracker.
3.) You should know full well that multi GB of anything is all about art work and pretty pictures gamer dudebros pay for.
I admire the principle behind his stance, because supporting people for free is horrible. I'm not sure I'd ever have the guts to do it myself though.
I wrote some software to address a need; and made the source available. I made some effort to make it usable to others - but not a huge amount of it.
Now, it's your turn to do some free QA to make that software usable for you, and more-usable in general. So the motivations here are:
1. Your own need / self-interest.
2. The public benefit.
I, as a random user, can't know which is which or care and most of the time can't be bothered.
Also, maybe it is about culture of platform, but I regularly watch few java open source projectals and had one own. The insulting or super entitled exchanges were quite rare. So i don't know, if majority of those exchanges turn into name calling, then either local culture is awful or there is something else at play.
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.
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.
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.
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.
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.
The "Puddy" :)
https://www.youtube.com/watch?v=NNOa5Uvjpwo
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!
Just be respectful, post your question or request, and don't be upset if you get no answers.
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.
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.
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.
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 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.
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.
Conceptually it is always a problem. This is how communication degrades and descends into chaos.
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.
Ignoring: for the maintainer: open loop or maybe hidden closed loop (e.g. afraid of confrontation); for the requester: open loop.
The intention of saying no is a closed loop.
> Nobody should ever have the expectation...
Yes, but that's not a pragmatic solution. People sometimes DO have the expectation.
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 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.
And who knows, if you actually _do_ refuse with a note about $very_high_price as an alternative, they might just buy!
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).
Good luck and no offense
No feature requests: Author(s) do not wish to "politely refuse" every wild idea you might have.
No Support requests: Author(s) do not wish to "politely refuse" every time you need hand holding with your implementation of hello world.
No Pull Requests: Author(s) will collaborate within a restricted group and do not wish to "politely refuse" your t-shirt contest contributions.
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.
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.
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
[2] https://traduora.com/
[3] https://panelbear.com/
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.
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.
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.
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 ^_^
For those people I don't want to hide my code. Please consider a "source available" approach (at least for the "core").
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.
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.
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.
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
[2] https://github.com/dessant/buster/blob/master/.github/label-...
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://github.com/wit-ai/wit/issues/1946
[1] https://github.com/hramos/label-actions
[2] https://github.com/marketplace/actions/label-actions
[3] https://github.com/facebook/react-native/commit/f9c2157141b8...
Maybe you've just inspired me to actually do it.
https://github.com/facebook/react-native/issues/30395
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.
(Yes, looks like your software can do more)
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.
Upstream may not care about them, but they can help others with edge cases too.
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.
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.
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.
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.
[1] https://github.com/jonathanhefner/verba-sequentur
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/
Collaborators contribute their time, energy and skill into the opensource ecosystem too - either by submitting good code to my project or donating their time to other projects I might reciprocally use.
Customers / benefactors make money using my project and pay me some of that money to keep the lights on.
Everyone else is a leech. They just want something for free and get irate when they get called out for it.
The trick with support requests / issues is they can be opened by anyone. You can tell the customers apart from everyone else easily, but is the person filing an issue looking to contribute in turn, or are they a leech wanting free support? A well written bug report is also a love note, after all. I still don’t have a good metric; but I’m definitely drawn to some filed issues more than others.
(There are leeches who try to get you to solve their problems for them as opposed to reporting bugs, but that's a tiny minority.)
I felt really gross about that decision for awhile and it took me months to figure out why. My take now is that I was complicit in a parasitic use of opensource maintainers’ free support to fix issues we ran into. Despite that workplace choosing to never being part of the community, we pretended we were so we could get free support for our free software without giving back in any way.
In retrospect I wish I’d pushed harder on the legal team. Or suggested we sponsor some projects as an alternative.
When people ask you to fix their problem, without providing any useful information or relevance to the software, it's hoping for free support. For companies offering free support, it sometimes makes sense to dive that deep into userland.
For individuals you need a clear model what you're willing to do and how, as something that at first may seem fun and engaging, can quickly become too much and draining over time.
Collaborators, Customers, Users and Leeches.
Depending on the project I fall into one of the first three, I might send a PR, I might suggest we buy/pay a maintainer or I might just be using your library as a dependency of a different package, I'm never the last one.
The only people who matter to a project are contributors and customers, and mostly the former. A smart maintainer invests 100% of their energy into this group, and 0% into the leeches. The software will obviously be better if you invest your time and energy into the needs of people who give back to the project.
If you really cared about fixing bugs then you'd take bug reports. Taking a bug report does not mean you are forced to fix it (which is work, which costs money), but at least you'd be aware about the existence of the bug.
So, charging for bug fixes, okay. But if you don't even want to be aware of bugs, then yes, you are a crappy maintainer.
> Here’s the thing: I write open source software to solve my problem. I let you use my solutions because that comes at zero cost for me (well, almost, I still have to pay for the website, you are downloading from.
Even if it was past code that has run its course and I no longer use, if the code is posted somewhere such as github, future users might want to read the list of bugs reported by others to be aware of them (and to see workarounds potentially posted by others).
Some bugs are due to an esoteric setup of the user. There in a quasi infinite variation of those in the Linux world. Generally, supporting them makes the software more robust, but it's also very likely that you would never encounter that bug yourself.
Some bugs are just support requests. The user didn't understand how to use the software and is confused. Generally the report is quite lacking and it takes a few back and forth to get somewhere.
Some bugs are genuine logic bugs.
I'm sure there are more variations..
This can be treated as a bug in the documentation.
As a maintainer it's also your right to develop a tool just for yourself, and share it for the world. In which case, documentation is not necessarily the priority. And it's fine.
Yes, sometimes it is.
> As a maintainer it's also your right to develop a tool just for yourself, and share it for the world. In which case, documentation is not necessarily the priority. And it's fine.
Absolutely fine. Although I'll point out that it is usually a lot easier to get documentation PRs contributed than code PRs.
Edit: more downvotes, on this comment asking for feedback, rather than providing feedback. O_o
Because if he's not infallible, he should want to at least be aware of bugs in the software. Not wanting to know about bugs is exactly equivalent to not being interested in the quality of your work.
If you're not interested in the quality of your work, then I don't want to use your software. And I'd hate to inadvertently cost you a tenth of a cent by downloading your crap, so please shut down your webserver and don't release any new versions publicly - save yourself the money and save everybody the time and effort of having to interact with you and your shitty software.
The author (and most FOSS maintainers), as they explicitly called out in their article, are making the software for themselves, and making it open source because it's the nice thing to do. It follows that any bug that doesn't personally affect them is not something they need to care about.
There's no greater good of "caring about fixing bugs" here. To quote the MIT license: the software is provided “as is”, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement.
You were warned.
The long tail of FOSS projects might be things people wrote just for themselves. The most used projects aren't. Most of the projects most people use aren't.
Almost all software has a warranty disclaimer. It would be irrational to assume it means the software is unsupported.
As Alex says in this blog post though "it typically derails into a whiny tirade about me being a crappy two bit developer". Luckily this only happened twice for me, but it's funny because in here you can see it on the open[2] as someone opening a PR adding this text to the README:
> If you spot a bug or any other issue you may go to hell because this software is officially Bug Free(TM).
On a very perverse way I am kind of happy that happened, since it ratified my decision and I became a lot more strict about when I help people. Any sense of "guilt" I had remaining after closing the Issues for not providing free support totally left after that incident.
[1] https://github.com/franciscop/picnic
[2] https://github.com/franciscop/picnic/pull/203
The recent example is Gitea which was forked by a community from Gogs because a single maintainer there was very picky about which issues to resolve, was refusing or taking very long to review PRs etc. I think both Gogs and Gitea coexisting is a very fine example of open-source working. But I think Gitea model is how a non-toy software is to be developed.
I often look at how many issues are labeled 'bug' before considering adding a new dependency to my project as well as check how many old issues are unresolved.
You don't have to resolve all open issues but closing an issue tracker the outright signals "I don't care if you have problems and I do not intend for this software to be maintained in any sense of collaborative fashion here on Github". Above all, such behaviour signals to me that there is only 1 person making commits / merging PRs and they are kind of tired of OSS (which is fine, by the way).
For some people, this is a good thing.
> You don't have to resolve all open issues but closing an issue tracker the outright signals "I don't care if you have problems and I do not intend for this software to be maintained in any sense of collaborative fashion here on Github". Above all, such behaviour signals to me that there is only 1 person making commits / merging PRs and they are kind of tired of OSS (which is fine, by the way).
I think it's more nuanced than that. It's perhaps more "I care if you have problems only if you have put in the effort to try and fix them. Then we can work together on getting it fixed for everyone".
"Issues closed, PRs welcome" is a perfectly reasonable way to run a healthy project.
Solving a problem together means agreeing on the problem and the solution before someone spends days working on it.
As for project health, I treat the git log as a far more reliable indicator than the issues list. That shows me what's actually getting done.
Of course it's the project owner's prerogative. It's just a warning too.
> Above all, such behaviour signals to me that there is only 1 person making commits / merging PRs and they are kind of tired of OSS (which is fine, by the way).
The linux kernel doesn't have an issue page and PRs receive a polite comment on how to send their PRs as patches outside of github.
https://github.com/torvalds/linux
[1] https://bugzilla.kernel.org/
[2] https://lkml.org/
Also, having a mailing list does mean to have a communication channel open and AWS SREs (for the sake of argument only) do not need to pay to join that mailing list and post some questions.
Finally, I think this one of the few instances where "You Are Not Google" fully applies.
Moreover, if the reporter also helps us with resolving it, i.e. provides logs, stack traces, runs custom builds, etc., then we will always reciprocate with freebies.
So seeing that this person is forcing people to pay to report bugs is absolutely wild.
I understand that he's basically sharing his own tools with others for free and if it works for him that all that he cares about, but the bugs are always on the developer. The least you can do is accept a report and say Thanks. That's a complete no-brainer.
Do you mean that the developer caused them? Because that is _mostly_ true but not always (because you can have bugs reported to you that are upstream ones).
Do you mean that developers are responsible for fixing them? That is simply false, even in commercial software you have no moral imperative to fix bugs, and very often with good business strategy you ignore a lot of inconsequential bugs.
Just about any serious FOSS developer I know has commercial software development experience, so I don't think your opinion is as unique as you might imagine.
From your perspective, I can guess that it does seem wild. The issue is that you're getting paid for fixing other people's bugs. He's not.
And, no, we don't fix "other people's bugs" either, just ours.
Or do you think that reading and comprehension are activities that take no time at all, and therefore have no cost attached to them?
I do feel that’s an important point — paid or otherwise. There’s a similarly whiny attitude people have: “I paid $5 for your thing, so you have to do as I say!” I don’t really think the distinction is how much it cost. If you have a support contract that says “in exchange for paying me, I’ll help you with X, Y, and Z”, that’s a different story.
But what I really wanted to remark on: to the point of “activities that take no time at all”, when I report a bug, I often spend hours of my time trying to understand what’s broken, narrowing it down to specific conditions and observations, often a attempting to fix it myself, and then writing everything up and whenever possible including test cases, screenshots, videos, etc. By the time I hit send on that bug, I may have contributed hundreds or thousands of dollars of my time to the project.
It’s also possible to just take 5 seconds to fire off “your stupid app is broken your stupid too fix it”. All I’m saying is that painting all bug reports with the brush of “trying to get free support” discounts the amount of free QA open source projects can benefit from.
Sure, but that was you deciding to do it, and it's commendable.
This is very different from someone emailing you and telling you to (or expecting that you will) donate thousands of dollars of your time to a project.
It's not a bug if it doesn't affect my use-case. It's undefined behaviour at most.
It might even be a bug if you compare to my specification, but, again, unless I have some reason to care about it (money, wanting the project to be good) then it's not a bug.
This aspect is not specific to open source either. In my book, maintainers of proprietary software, and I'm one of those, are also making a huge mistake if they ignore bug reports from users. But in open source, it goes further, by inviting contributions even in form of patches for bugs or improvements. Not allowing any of those is what I call stupid in the above post.
As the original article notes, "bug reports" are actually poorly worded "support tickets", which in all commercial software are not free.
Usually my deadlines aren't so far in the horizon that I can wait for an unpaid maintainer to come up with and release a fix. If the problem is that easy to fix, I've probably already fixed it on my end and am just tossing a patch over the wall as an afterthought: use it verbatim, use it as inspiration, throw it out - just please don't take it as an insult. If the problem is a very hard fix, while I was discovering how hard it would be I was simultaneously researching alternatives (including rolling my own), and the bug report is me delivering a summary of why I thought the problem might be hard to fix and some ideas, although there might be a criticism of a claim in there too. The criticism might be considered a request for support - not for the software, but for the webpage making the false claim. I've also probably already moved on.
Testing isn't free, either.
edit: when I really think about it, I never want to file bugs and always think of it as work. I do it out of a responsibility to contribute back to the software or because I like the maintainer. I do it because when I google problems I'm running into, bugtrackers come up with someone else describing the same problem I'm having and what they did to fix it. I would prefer not to file bugs and have to make myself do it by putting filing the bug into my schedule.
Even if they come from someone who’s pirating your software instead of paying for it?
It is usually very easy to tell if the problem is caused by a half-assed cracking or if it's a genuine issue. If it's the latter, then, yes, we certainly act on it. Doesn't mean that we follow up with the submitter though.
Also, don't mistake bug reports for support queries. These are two completely separate things.
As long as someone files a productive report with enough information to reproduce the issue, i'd rather forgive any uncharitable tone.
+1. One time I spent an entire evening trying to configure a server that refused to work, I kept on tweaking the config files and restarting it repeatedly, at least 20 times or so, before finding out that the feature I needed was broken. I joined the IRC channel and ranted "I literally wanted to throw my computer out of the window". Someone said I was overreacting, I repied I don't have any problem with the software or its developer, just frustrated by the broken feature itself. One day later, I debugged it, submitted a patch and got it merged.
I do put in as much effort I want or have committed to. But then, people expect more, even if I explicitly say I am not for that (e.g. discontinued projects, expecting free consulting, and getting offended for even a suggestion of paid options).
For example, I used to run the biggest Data Science group in Poland. It was a lot of effort to grow it from nothing to 14k participants. Yet, after explicitly saying that I don't answer questions about moderation (and even worse: messages pushing me to review a post right now), it keeps happening. If I don't (and I try to keep my boundaries), people get offended.
I think there should be a message (regardless of the context): if someone is volunteering, DON'T EVER push them to do more than they committed to. Pushing for more is as reasonable (and kind, respectful, etc.) as telling a stranger to go and clean your dishes. For free. Right now.
That should be a no brainer, but sadly people do it, becuse it works. People who volunteer have a tendency to help others beyound their own limits. And other people exploit that.
Setting up your boundaries is extremly important, not just in open source.
> Yours truly
How ist one able to distinguish one from the other if not from the README.
https://www.gnu.org/philosophy/open-source-misses-the-point....
Notice how author's arguments are only about what is good for them personally, staying at pre-conventional level of moral reasoning:
https://en.wikipedia.org/wiki/Lawrence_Kohlberg%27s_stages_o...
I've no interest in any of that mess if I'm honest.
« User: I just want to tell you that your app is broken, so you can fix it.
Me: Yes, that's a support request, please open a ticket. »
This is painful.
Maybe the user is being reasonable, maybe they're not.
Can't we do something to get (back) to a common understanding that reporting a bug is not the same thing as expecting the maintainer to fix the bug for you?
If someone really informs you about a bug they are usually straight to the point.
The one project that I did create, which has become a worldwide standard, used by thousands (not millions), is also now maintained by an energetic and enthusiastic team, who react very well to questions and requests for support. They have a Facebook group, and a number of other interactive options (like a Slack workspace).
In that case, we also have the “luxury” of the system not being used (or useful) for making money. It’s a totally free system, customized to a fairly narrow demographic.
I feel that it’s important to do a good job, and maintain the highest possible quality; regardless of whether or not anyone uses my stuff (I am my own best customer. Most of my projects are dependencies for other projects I have written).
In that vein, I don’t see that making it difficult to report bugs is such a good idea.
If I am not interested in fixing a certain issue (like if it’s a bug that I don’t think affects my own projects, and would destabilize the system, if I tried to address it), then I’m more than capable of politely and respectfully saying no.
It's pretty funny to me. I had a bunch of people ask me to implement features or fix bugs, and I just told them I don't want to spend time doing that. Very few had gotten entitled, and even those went silent when I told them I'm a volunteer.
I think it's still important to let people speak and ask for things, even if you're not going to give it to them. Also I have zero expectation of anyone ever paying me for my open-source contributions.
One nice thing about rude people is that at least they tell you what they want.
Then again, my experience with FOSS has been almost exclusively positive. People have never been entitled to me, they've always been helpful, and I've gotten people co-maintaining projects and submitting lots of PRs to me as well.
It was perhaps that optimism that led me to create https://www.codeshelter.co/, which didn't really do very well. Turns out not as many people want to maintain projects as I thought.
I've already got a handful of projects I maintain, but I've got a little more bandwidth. I'll take a look at the list ;-)
Don't give up on that! Code Shelter will grow. We just need more awareness. I'll help with that.
I think most people expect that they'd add their project and get immediate help, when the project is more a backup plan to straight up abandoning a project. I think you're the first person other than me to get excited by it, so thanks!
Just because you’re not paying for it doesn’t mean it’s free, you’re still going to have to do some work.
And contributing the fix upstream is not selfless either. You don't want to keep dragging the patch along with every new release. You want it upstream so that you can forget about it.
Just as much as the maintainer can now fix a bug which somebody else for free reported and even contributed a patch. Refusing to even listen is mindbogglingly stupid.
Of course there can be disagreement about whether the bug is worth fixing or whether the patch is a good solution. But that's a different story.
Of course you are not getting paid for it. Just as little as the guy sending you a patch. If you want you issue tracker to be pay-only, would you be fine with allowing people to submit patches that you can only open after paying?
The "not getting paid a cent for it" is just flipping the entitlement problem around. The person reporting a bug is not entitled to a fix, nor even to be heard (even though, as I claim above, ignoring them is usually not the smartest thing for a maintainer to do). Neither is the maintainer entitled to get fixes attached to bug reports, or even a certain quality in bug reports themselves. All of this is voluntary, nobody is entitled to anything.
But what you can do is foster a good culture. If you incentivize high quality bug reports, for example if somebody shows they made an effort when reporting the problem and you respond with a positive answer, then people see this and adjust their behavior accordingly. If you accept pull requests, especially high quality ones, especially those where everything is well-explained, well-structured and the maintainer's comments are addressed, people will tend to adjust and do it like that more.
Just as much as if you are and asshole about bug reports, you'll likely not get high quality ones or even fixes any longer. Likewise, if a bug reporter is just rude, they won't get attention from the maintainer any longer.
It's all reciprocal. Nobody is entitled to anything. If you play the game right, it's a very productive collaborative framework. And a lot of fun.
Parent clearly meant "gratis", while you clearly mean "libre".
I use a lot of open source software I'm not even remotely capable of understanding, much less fixing. I figured I was at least an average coder but maybe I've been fooling myself.
Mine had to do with Python Datetimes and timezones and after figuring out how to reliably reproduce it with a minimal case I could step through the stack trace and see what the library was doing (not much, just 'adding' some times together) and could see what might be causing it. (I haven't actually got to the bottom of it yet - I had other stuff to do.) But really the hard and time consuming step is that first bit. Of course, like anything it's a cost benefit - if it'll take weeks to nail it down and fix, vs using something else - then of course, a new approach is needed.
You don't have to answer for sure if that's what you choose, but don't expect that pleb engineer on the other side to be able negotiate any remuneration for you as a individual contractor.
And also, even if said "pleb engineer" isn't some faceless corp, said faceless corp (assuming the engineer isn't themselves a contractor or self-employed) is still benefiting.
I start from the same intuitions as the OP but they lead me to the exact opposite conclusion.
I consider my time a limited resource and the most important currency I have. Spending my time on trying your piece of software is already an investment on my part. You aren't solving anything yet for me. Finding out that your software does not satisfy my needs is a financial loss for me. I have now sunk costs into your software and got no ROI.
So when I take the time to sink even more cost into you and your buggy software, to tell you what I tried and how it didn't work, then please recognize that is highly irrational of me. The sane response would be to cut my losses and maybe publish a one star review of your cruddy work somewhere. :)
This view holds for both paid and open source software, by the way.
So the very fact that I do take the time out of my day to tell you about bugs in your software can only be explained by my idealistic and altruistic nature. (I'm putting it on a bit thick here to drive the point home)
If I report a bug to you, I am not doing myself a favor. I am doing YOU a favor. One that I have no expectation of getting paid for. Even if you go ahead and fix the bug I reported, that means I still sunk unnecessary cost into your enterprise. NB: I have no reason to expect the rest of your software to work. The very fact that I found a bug already makes it more likely that the rest of the software is just as deficient.
So the very least I expect is that you graciously acknowledge my bug report and the time I sunk into your project. I expect you to thank me for taking the time to file a bug with you. Why? Because if you fix your code, that improves your reputation, not mine. So I did something for free that helps you, not me.
Let me make this clear: The actor causing the cascade of fail here is you, not me. Had you published good software (or no software at all), we wouldn't be in this negative spot. I wouldn't have wasted time on you or your buggy software, and you wouldn't have to waste time deciding how to react to my bug report.
I think the way out of this dilemma is to document your software honestly.
If you wrote the software for yourself and had no plan for it to work for others, then SAY SO on the project homepage.
If you wrote the software to learn how stuff works, and are happy if it builds, but don't expect it to solve the general problem for others, then SAY SO on the project homepage.
I will then not download it if I was looking for a solution to anything, only if I also just wanted to learn how stuff works.
That said, my experience with reporting bugs has been very good all things considered. I would like to mention postgresql and llvm as being exemplary here. Their response to bug reports has been a shining beacon that led me to recommend their software even on paid projects I am involved in, where I feel crappy open source software I recommend could come back to damage my own reputation.
Also if all the bugs turn out being people using your software wrong, than maybe it's not them, maybe it's you. Consider making the UI more self-explanatory.
The same applies to the developer of the software you are trying to see if it solves your problem. The rest of your conclusion relies on your assumption that your time is more precious than the time of the developers that wrote the software.
That said: Actually, if you think about it: It is. Both to me AND to the developer.
If the developer treats my time as precious, and enables me to skip his software altogether or to use it without having issues, then I will waste zero of his time. I will also waste less of my own time, but that is probably less important from their perspective. Since there is one of them and hundreds or more of me, this pays dividends very quickly for them.
Also, seeing your nickname, I'd like to mention "Medienkompetenzübung": The point of the article is not about not accepting bug reports, but support requests being disguised as bug reports in order to bypass the fee, to a point where the abuse greatly outweighted the benefits. The logical conclusion: shut the channel down at the risk of loosing some value. I believe, you have a similar policy with the killfile for your blog.
What the author is describing is users confusing the former for the latter.
I believe we should all be the latter rather than the former. But even if we aren't - the onus is upon us to make this clear to the users. It is perfectly reasonable for a user to assume developers will accept bug reports (which is not the same as assuming the bugs will get fixed promptly).
Also, as a FOSS developer - I believe the author is underestimating the significance of accepting bug reports from the public. This has saved me some embarrassment in the past and even got me some collaborators which I would otherwise not have had.
> You need to maintain the system and manage the full life cycle
Do your vendors maintain your systems? Maybe, if you pay them well enough.
> You need testing
Because "enterprise" software is bug free. Just because someone sells you software and pretends they test, or even if they do actually, you still have to test in your environment.
> You pay for all of the above
Yes, either in manhours of employees or cash to a vendor.
> There are very,very,very few world-case FOSS projects around (like: redis, clang, elasticsearch, linux, ...) that maintain themselves on an enterprise-quality level, so be prepared to upstream a lot of bugfixes yourself
There are many more, and even stuff like Hashicorp's projects are at a better level than say Atlassian's crap in terms of "enterprise quality".
> Where there's no money there's no priority
Are you under the impression that just because you're a paying customer you're somehow a priority to the vendor? You can tell that to all the people with stuck feature requests or unanswered/unfixed bug reports. At least with FOSS you can actually take a look yourself if nobody else wants to.