Open Source does not mean “Includes Free Support” | Hacker News Reader

Open Source does not mean “Includes Free Support”

raccoon.onyxbits.de

305 pointsalexellisuk247 comments

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.

you can set a private github email: https://github.community/t/your-privacy-on-github/10206

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.

Personally I think we all lose in this situation, the community included. E-mail should always be an option.

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.

Why is it out of the question for you to create a GitHub account?

Because I'm trying to rid my life of the GAFAMs, not getting myself even more embedded into their ecosystems.

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.

> What is the opposite of damning with faint praise? Supporting with faint condemnation?

The "Puddy" :)

https://www.youtube.com/watch?v=NNOa5Uvjpwo

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.

It's gotten worse as FOSS has gone more mainstream.

Developers/maintainers are getting a lot more contact with a larger cross section of society, which is a catch-22.

I'm with you on ignoring parasites, but I also am in favor of offering 100% refunds to dissatisfied users to try drive the point home.

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.

Auto response is not politeness.

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.

>being rude in return is never a problem

Conceptually it is always a problem. This is how communication degrades and descends into chaos.

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.

Fully agree.

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.

> Ignoring leaves the loop open

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.

The parents are talking about ignoring as a method to (implicitily) say no.

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.

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 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).

Good luck and no offense

Repositories which will ignore you need to communicate and establish these clear goals in the README:

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.

>establish these clear goals in the README

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?

If someone takes the time to properly report a issue and follow up after I follow up, of course I take the time to try to help them, if I can.

But that doesn't mean you have to respond. It is nice if you do, but we should not add the expectation that you'll get help from maintainers.

I think all these conversations are about the expectation to get helped, not that it's nice if we do help.

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.

I agree with you.

As the author of a few popular open source projects [1] [2], it has been a fun ride, and I have learned a lot.

However, the honeymoon period is over for me. The vast majority of the time it’s a lonely, thankless effort.

The problem is that after several years and thousands of people and businesses using the software every day, very few actually take part in improving the project. Or even saying "thank you" to be honest.

I’m happy to work on my project and fix issues, but please don’t abuse it. Being open source means that you can change the code if you want to, not to get a developer to work for you “out of love”.

That’s why for my most recent project [3], I have decided to no longer start with an “open core” product. Instead it's a SaaS with a generous free tier. Price goes up the more value a customer gets out of it. Yes, people have already given me crap about not being open-source, but I do feel that so far it's a more sustainable model.

[1] https://github.com/anthonynsimon/bild

[2] https://traduora.com/

[3] https://panelbear.com/

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.

Yeah, if you know the bug is there, it's often easy to write around it. Even completely ignored issue queues are useful.

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.

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

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 like your modesty at a few more stars (more like 10 times more stars :p). Thank you for the advice, the README truly looks amazing.

I've settled with giving automated feedback using a GitHub app I've built [1] that posts a predefined message and closes the issue when a label is applied.

When it's hard to figure out what is being asked, or the bug report does not follow the issue template and there are no clear steps to reproduce the bug, I'll label the issue as `incomplete`, which asks the author to fill out the issue template properly, and closes the issue.

I've also configured labels with messages for common questions [2] or issues that are outside the control of the project, so I can inform people without repeating the same things over and over.

I agree that we should not be expected to provide support, though I find it acceptable for now to post automated messages, when it can help others.

[1] https://github.com/dessant/label-actions

[2] https://github.com/dessant/buster/blob/master/.github/label-...

And regarding the corporate exploitation of open source projects, I've just discovered that a Facebook employee reimplemented the app [1] using actions and published it using the same name and configuration syntax on the GitHub Marketplace [2], so I can no longer publish my app without renaming the project.

Facebook was using my app in the React Native repository, until they have replaced it with their own implementation [3].

It would be nice if they weren't jerks and at least not casually seize the project name, but here we are.

Meanwhile I'm still banned from Facebook for no reason, after I've recently signed up to use Wit.ai, and they illegally hold control of my personal data on Facebook and Wit.ai.

https://news.ycombinator.com/item?id=25033510

https://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...

Hey, I remember you! I linked to that story in the entry on Facebook in my shitlist (https://blake.instantfloppy.net/shitlist#facebook).

I like your list, and now you have yet another entry to add. :(

I've always thought about making a shitlist.

Maybe you've just inspired me to actually do it.

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!

Have you considered insisting they credit you as your MIT license requires?

I have opened an issue on the React Native repository, please share it and help me find a solution.

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.

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.

Why not just use the canned answers feature of github?

(Yes, looks like your software can do more)

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.

And you likely meant this, but I have often discovered, or provided, patches.

Upstream may not care about them, but they can help others with edge cases too.

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.

I share your loathing.

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.

Unfortunately, I imagine that GitHub would kill an anti-stale bot even faster than their stale bot kills issues.

I was recently thinking along the same lines. Would definitely use it!

I can't agree more. It's like the CADT model (https://www.jwz.org/doc/cadt.html) but on steroids.

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.

[1] https://github.com/jonathanhefner/verba-sequentur

I've gone the opposite way to this. I will usually answer as soon as I can, possibly immediately with some kind of response. The last thing I want is to have people announce my work is "dead" or "unmaintained"

Perhaps I've gone too far with it. Ignoring sounds like a powerful tool.

I'm also starting to offer alternatives to get "paid attention" and support https://www.openfaas.com/support/

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).

This attitude is horrifying to me.

As both a project maintainer and a contributor, this is part of the toxic new attitude that has resulted in me no longer spending my valuable time opening bug reports against projects. If my hard work is going to be looked at as an insult or entitled request, go to hell. That sort of rudeness is shocking to me.

In projects I maintain, I get my share of spammy low effort requests and I ignore them or reply with a polite "Need more info" or "no time for now". It's not really that big of a deal.

For other projects that I use and appreciate, I have also spent hours before gathering useful debug information, only for it to be completely ignored. If I spend hours building a nice report for you and you won't spend 5 minutes reading it and two minutes responding with "sorry but I'm too busy" then who is the entitled one here? Further for you to look at it as an insult?

I rarely even send PRs these days because those often rot for months or years.

This is not a user problem, this is a people problem. Please people, lets make these types of people into the minority in open source. Please, let's give each other the benefit of the doubt. Let's appreciate effort on both sides. Don't be a doormat, but don't lose your humanity either.

In short, let's be great to one another.

Something that I wish more people did when they don't have the time to do a bunch of debugging for an issue they don't experience is dropping a pointer for others. If the response was "I don't have time to work on fixing this. If you wanted to fix this I think it would be in $package and maybe $file. You can create unit tests for this in $place". Or even better "I've added a unit test into master as ignored that is failing right now, if someone can step through and debug this I'd merge it".

It takes a lot of energy but it's a great way to create a community.

I agree that it's bad. But not because the maintainer is an asshole. It's because the maintainer doesn't understand the real leverage he has when doing open source. So it's actually more sad than bad. Bad for him, in fact.

When you write something to solve your problem (which he correctly states), then publishing it "for free" just because the mere act of doing so comes at almost no cost and even consider it as some kind of philanthropy ("You are welcome, by the way"), that's all really missing the point. Of course you are free to do that, but you are really missing out on the big lever the open source approach hands you.

And that lever is that other people come and help the maintainer _for f*ing free_. They encounter a bug and report it -- that's free labor right there! They help him make his software better by pointing out a problem that he likely overlooked. And they help him document problems for other users to be aware of. And often times they help him by providing a patch or a suggestion. They do all of this for free. That's the whole point of open source. Not providing some piece of software for free. That was there already with "Freeware". But the real power comes from the lever. Put it out in the open and have the whole world help you.

Linus Torvalds understood that all too well, and still does. He's not a philanthropist. He's pretty rude and selfish (he admits that about himself), and that's exactly why the open source approach worked so well for him.

Totally agree. In fact,I do think of Linus Totvald,as a really great maintainer of project. he clearly know when to say no, and when to criticize someone who needed to be. people should read some of his reply in mailings, some of them are gems of communications.

That depends entirely on the intention with which an author decides to publish their code as open source. That intention could be to forge an active connection with a community of users, or it could simply be to just get it out there to anyone's benefit, rather then have it gathering dust in some private git repository, with no further engagements or obligations on the author's part.

The open source license included with the code doesn't say anything about the author's intentions at all.

> That's the whole point of open source.

The whole point of adding an open source license to your code is to share code with others with virtually no strings attached. That is, neither from the user's side, but also from the author's side. Everything else is just custom and market dynamics.

> Linus Torvalds understood that all too well, and still does. He's not a philanthropist. He's pretty rude and selfish (he admits that about himself), and that's exactly why the open source approach worked so well for him.

When Linus decided to push the GPL on his code, he couldn't possibly predict or foreshadow that his little hobby project would end up being this successful. His original intention was simply to gather as much feedback as he could to improve his project. In fact, it would take until version 0.12 before he'd add the "GNU copyleft" license. And that's only after some people pointed out to him "Have you considered adding a copyleft license?" [1]

[1] https://mirrors.edge.kernel.org/pub/linux/kernel/Historic/ol...

The open source approach worked well for him because it facilitated the spread of Linux towards key people in large public institutions and commercial organizations for whom Linux simply, accidentally happened to be a good, cost effective fit. Linux was released in 1991 and barely a few years later, with Dell, Red Hat, IBM offering commercial support and Red Hat and VA Linux having IPO's around 1999.

Linux wasn't just successful because "open source". It was successful because it turned out to be the right product at the right time at the right place. And that's what really drives development.

When you call it free labor, you’re missing the other side of the reality.

A coworker at a corporation might be working for free on the project I’m working on, but the fact that they make $0 salary doesn’t mean I do any less work when I have to interface with them and work off their contribution. Also, I’m paid $0 for the pleasure. It costed both of us.

So, no, free labor really isn’t the right way to see it. It’s more complex than that.

When I don’t keep up with PRs and issues, I’m deciding the pay off isn’t worth it in that moment. None of it is free. I have all sorts of projects on Github that you’d have to pay me $1000 to even clone again. I wrote them in one stage of my life that I’m not in anymore. That’s just life.

Feel free to fork(tm).

I don't think we are in disagreement about any of this.

> If I spend hours building a nice report for you and you won't spend 5 minutes reading it and two minutes responding with "sorry but I'm too busy" then who is the entitled one here? Further for you to look at it as an insult?

You? The other maintainer didn't ask you to do that. You're not entitled to even a minute of another person's time just because you unilaterally decided to dedicate hours of yours on something.

> I rarely even send PRs these days because those often rot for months or years.

Mind you, I've rarely sent PRs, but when I do, I do it with the intention to help. Only around half of the PRs I've ever sent were merged, and most of the others were left open without review. You know what I think about them? Nothing, I just conclude that the maintainer is probably too busy or my proposed changes are not within the goals of the project. I then move on and don't let it eat at me.

> let's be great to one another.

I think that includes giving other maintainers the benefit of the doubt. That includes not taking being ignored as a personal insult, I think.

> You? The other maintainer didn't ask you to do that. You're not entitled to even a minute of another person's time just because you unilaterally decided to dedicate hours of yours on something.

This is just basic human decency. If someone puts in effort to help you or contribute to something you've created, just be a decent person and respond to them. It costs you nothing. There's a difference between being entitled to something and just doing something because it's the right thing to do.

No one is entitled to my gratitude because they hold the door open for me. I didn't ask them to do that. But I say "thank you" anyway because it's the right thing to do and the world would be a worse place if we were all assholes to each other always worrying about what we are and aren't "entitled" to.

This is the whole spirit of open source software. If you don't want to be bothered by other people putting in effort to collaborate with you, then don't make your project open source, or just keep it closed to issues and PRs altogether.

Thank you, very well said. That example was exactly the kind of thing I had in mind.

If we just extended the same human decency that we all do in meat space to cyber space, these things wouldn't be problems.

The problem is, people are no longer extending these basic human decencies to one another in even just meat space.

It’s got nothing to do with basic human decency. A maintainer is donating their time to a project and can work on whatever they feel like. It’s perfectly reasonable to not include any contact information whatsoever or simply stop paying attention when people try and contact them.

OSS isn’t some ongoing obligation, and can freely be ignored for months or years at a time. If you’re not happy, feel free to fork the project.

If you dump some personal code of yours in a public place (which you would have written anyway) can it be really called a donation?

If you don't plan on even considering ongoing issues that are well documented, can you call oneself a "Maintainer"?

It would be very useful to a-priori distinguish the expectations for a given repo, is it "I dumped my personal code, don't bother me" or "this is a maintained project"?

Simply allowing people to see your code doesn’t give them any rights to use it. OSS provides a license that allows you to use software without paying the creator, that’s the donation.

As to being a maintainer, if you’re using that code for something and updating it whenever you personally have a problem that’s still a maintainer. Consider a geologist who created an absurdly accurate GPS for exactly the hardware they have. If’s it’s working for them they might go years without making an update, and that’s fine. Someone saying there is a bug when used on farm equipment simply is’t their problem. Even a different geologist seeing issues south of the equator isn’t their problem. The software is free and almost sufficient, feel free to pay someone if it’s not doing what you want.

The core issue is OSS is free to use and modify, but that also means the maintainer is free of all obligations.

I do not think anybody is making the _legal_ argument that consumers of publicly available software with an associated clear LICENSE file are granted any additional rights. Open Source is much more than what you are suggesting. It's like saying all there is to soccer/football is <first degree technical definition here>.

Just like most things, there is a very important and obvious people/social dimension on top of that.

It's not entirely surprising this is a problem in our industry. After all, Software Engineers are most definitely NOT known for their social skills. The emergent properties of human interactions over time is a very complicated problem.

I think you’re confusion is around the most well known OSS projects which try and increase adoption and generally request donations. That’s a relatively small chunk of the overall OSS community which is well known specially because maintainers have a personal desire or financial incentive to increase adoption.

Far more often projects are released as OSS because sharing a project is a net benefit to the world and costs the donator nothing. That’s really the central idea of the OSS movement, when copying is free it’s easy to be generous. Forcing a social obligation is therefore toxic to the OSS community as releasing software becomes expensive.

> This is just basic human decency. If someone puts in effort to help you or contribute to something you've created, just be a decent person and respond to them. It costs you nothing. There's a difference between being entitled to something and just doing something because it's the right thing to do.

The idea that this costs them nothing is, well, garbage. It costs time and energy, of which many have a very limited supply. What might take you 5 minutes might take another an hour and leave them utterly drained.

I get a dozen issues a day across my projects. I used to respond to all of them daily, then I was so burned out from that chore that I don’t even read my notifications anymore.

Funny how people here think it’s just basic human decency to spend an hour of my time each day responding to people who managed to click a submit button. For every HNer here bragging about how thoughtful their issues are, there are 100s of low effort issues from people who won’t even respond to a follow up.

Running popular projects has shown me there’s no “free” in open source just because literal money isn’t exchanging hands. It’s basically a ddos of your time.

Github needs a feature where you can attach a tip to your issue to compensate the maintainer. I get so much low effort garbage that I would set a $10 minimum on my most popular projects.

People here think bug reports are free labor. What they would know if they ran a project is that most bug reports, even with an issue template, are “it doesnt work wtf.”

To be clear, I was responding to the situation where someone clearly puts effort in creating a high-quality contribution (a PR or bug report) and the maintainer simply ignores them. I think it is the right thing to do to at least acknowledge it and say "Thank you for your contribution! I will review it when I have time".

I don't disagree with you or others on ignoring low-quality, low-effort contributions. I get that people have finite energy and time. Taking 5 seconds to say "thank you" when someone has clearly put in the effort, though, is a no-brainer.

Thank you for this.

I absolute despise this lowest common denominator argument that is so often reiterated in society today: “no one is entitled to my time or energy!!!”

Ok sure, that is technically true, but are you actually doing yourself or anyone else any good by just dissolving good faith like that?

No, what goes around comes around, and you are just contributing to the destruction of community.

That doesn’t mean just go be a doormat for everyone. But to do the opposite and just accuse anyone that even so much as points in your direction of being entitled to your attention, is beyond messed up.

In general, you're free to donate to the maintainers of a project. And arguably it would be "basic human decency" to do so, especially since the maintainers have to spend time reading your issues and PRs. The argument presented here smacks of the type of entitlement that led many other open source developers to leave

I think we are on different pages here. I don’t disagree with what you’re saying, maybe you can clarify please.

For a maintainer to say, or suggest, “don’t bother even opening an issue or PR in my project, because I will take it as an entitled offensive against me,” is just fostering an environment where nobody will open issues or push PRs. Why would they? There is no longer any presumption of good faith discourse there.

> “ The argument presented here smacks of the type of entitlement that led many other open source developers to leave”

Are you trying to say that I am presenting an entitled opinion, because I am saying that there is a give and take to healthy social interaction?

Ignorance over malice. If someone opens a shitty or entitled ticket, teach them why it is such and educate them on how to open a better ticket or steps to take to solve the problem themselves. If they do it again, ok, now you know they are not interacting in good faith. You as a maintainer have that responsibility, just like the user taking advantage of your work has a responsibility to not act entitled to it.

Yes you are taking an entitled opinion in assuming that open source maintainers should invest time in an interaction with your issues and PRs. IT is not a commercial relationship where you have already paid for a support contract. If you think about open source maintainers as the volunteers they usually are, then you'll understand why your argument is entitled.

If that is the stance that an OSS maintainer takes - then they are not a good OSS maintainer! Period.

It is part of the role of a maintainer to _maintain_ the project that they decided themselves to be a part of, or start. That project doesn't exist in a bubble.

If you dont want to maintain something as OSS - then don't push it to Github, or a package registry. Why would you put something on the internet - a social, public place - and then act like you are entitled to a private slice of the web just for you and your rules?

Sounds like quite the entitlement to me, actually.

If you volunteer to be a part of something public, whether you own it or not, you are welcoming the outside world in. Therefore, it is your own doing and responsibility to manage that relationship with the outside world.

> "open source maintainers should invest time in an interaction with your issues and PRs."

Do you not believe that is part of being a maintainer? That statement seems like a pretty accurate description of part of being a maintainer...

> > let's be great to one another.

> I think that includes giving other maintainers the benefit of the doubt. That includes not taking being ignored as a personal insult, I think.

While I wholeheartedly agree with this, and also want everybody to be nice, it's not necessary for open source to work. A maintainer who refuses gratis help in form of bug reports is just a maintainer who leaves gratis things on the table they could pick up. Other projects who take the gratis help will do better. Evolution will weed out the idiots who don't get it.

Think Linux would have gotten big if Linus had said "stupid people, they think I take their contributions for free"? No, he deliberately used a model where thousands of people worldwide contribute to his project for free!

Problem is picking up those gratis things from the table has a cost to the maintainer. And sometimes those gratis things are worth less than that cost. Multiply this hundreds of times and the cost to the maintainer for picking up free things can quickly add up.

And that's why the maintainer is free to ignore them, if they choose to. They should not be hanged for prioritizing their time. Others can pick all that up. Fork the project, use the reported issues and proposed patches, whatnot. Accusing the maintainer of being arrogant for ignoring contributions is as wrong as accusing the contributors for wasting somebody's time.

These recent open source related threads on HN are quite an eye-opener for me how much misunderstood the whole concept is. In that concept, nobody is committing or promising any of their time or energy, so should not get judged for it either. Neither maintainers nor users nor contributors.

He is not demanding you spend minute on his big report. He is asking you not to insult him and not to act as if he demanded salary for it.

In short, it's a matter of attitude.

No, you're not obligated to respond to bug reports, but bug reports do provide value to your project, and not acknowledging that value is just as rude as their expectation that you fix it.

The correct way to address this is an auto responder that says "Thank you for the bug report - we appreciate it; however, as this is a volunteer project, we do not guarantee a response, timely or otherwise. If you have a commercial, pressing need for this bug to be solved, we suggest filing a paid support ticket here: <link>."

An important point is that reviewing a PR is also a time-consuming effort, the only difference is that it requires time on the submitter's part as well; I would be wary of recommending submitting a PR without talking to me first, since I may not have time to review it either, and then you've just wasted your time.

I completely agree. I've had to turn away PRs that came out of the blue and went a direction I didn't want to take. It sucks when that happens.

But when it does, I thank the person and explain the decision. It's not what they want to hear, but it's a lot more respectful of their effort than silence or writing a blog post about how annoying they are.

I agree,its not a nice way. Rather repo owner should encourage people to submit it as bug report and not the support ticket. later they should add tags like "volunteer contribution required","Sponsor requested". such tags to bug will do both things implicitly.

It's not about "nice" even. It's about refusing help that others offer for free.

Being "nice" is a bonus, really. A welcome one, but not the main point.

yup, bug report itself is an open-source contribution.

This is like acting insulted when your favorite famous person doesn't feel like talking when you run into them on the street. It's nothing personal, they just don't have the mental energy to treat every fan interaction as something special. The analogy isn't perfect for open source, but do you get my point? The fact that your PRs go unnoticed is not meant to be an insult nor should it be seen as one. It's just the simple fact that one person doesn't have the resources individually to serve potentially thousands of users in a community. And they certainly won't prioritize anything that doesn't make them money like their day job. Why should they? Would you? All it takes is a moment's pondering to see that this is true.

I agree, but if a person is too busy to even look at project things, I think they should make that clear. It wouldn't take long to throw something into the README.md or CONTRIBUTING.md explaining the situation.

They don't though. My speculation is because if they did then nobody is going to use the project.

> I rarely even send PRs these days because those often rot for months or years

As an OSS developer myself, something I'm not keen on is getting PRs out of the blue - if it's something I don't want, or an approach I don't like, it's just really, really awkward.

I don't know if this is how you already approach PRs, but IME a good approach is to first open an issue outlining the problem/feature and how you intend to approach it. This starts a discussion with the maintainers, and may or may not later lead to a PR from you, depending on whether your plans fit in with the maintainer's.

Thanks, I wholeheartedly agree. It sucks to get a PR that was clearly work that you want to reject because it's a direction you didn't want to go, has big flaws, or would be hard to maintain.

I'm mostly talking about simple PRs, little bug fixes, even documentation improvements.

But even big PRs, all I ask is basic human courtesy that we provide each other in meat space. It's totally fine to say, "Thanks but I'm sorry we won't accept this." especially when it's out of the blue. What isn't fine is being rude. It's wrecking the community.

Also, reviewing the PR and doing the people management along with it is a lot of work. And more work than doing it yourself.

It’s certainly not free labor that costs maintainers nothing like people suggest in these comments. It’s more like having to work with a coworker who was employed for a couple days in difficulty and credentializing in what they left behind.

Totally agree. I think a "I'm sorry I don't have the bandwidth to look at this right now, but thank you for your contribution" would be perfectly fine IMHO. It's polite and decent, but still respects the maintainer.

This.

It feels like the "Old World" of open source was mostly about passionate people developing (and open sourcing) software for other similarly passionate people (think of some of the great projects on Freshmeat 20 years ago). I am not saying it was perfect but there used to be some sort of etiquette.

Now the demographic has changed drastically. On the "maintainer" side you have a lot more people just dumping their stuff on Github (public repos were the only one free) and only want to collect the positive ("feel good", resume padding).

On the "Consumer" side you have way more people that completely abuse online helping channels such as StackOverflow, or Github issues (how many times have I seen someone say "hello it does not work can you help me").

It reminds me on how IT departments evolved in Corporations where years of abuse lead IT departments to develop a very conservative defense mechanism that basically leads to the function being solely self serving.

I am shocked reading this thread that it has become completely ok to flat out ignore legitimate and well researched/documented bug reports. Feels like we are throwing the baby with the water here.

I'm seeing "x accepted pull requests" on resumes frequently now. Not every PR is made in good faith nor made with the same motivation as the maintainer. Someone making dozens of individual PRs for things like adding CONST to variables whose future use they do not understand is a drain on the maintainer's time. For the person making the pull requests, they get a low effort way to pad their number of accepted pull requests, many of which are not in alignment with the goals of the maintainer or the project.

Totally agree. I by no means think all PRs or issues are equal. That's basically what I'm irritated about with this post! The new attitude that I hate is treating everything as crap, spam, or entitlement. Politely refuse low effort and unuseful PRs. Don't throw the baby out with the bath water.

I think it is about how bugs are submitted. I see bugs on GitHub that are like

"BUG FIX IT NOW" (entitled)

"I noticed a bug when testing v1.17 on Ubuntu 16.04 while using Python 2.6" (constructive)

Totally agree, but the people complaining about bug reports rarely ever acknowledge the difference, and they often treat them all the same.

Take for example OP, who would say essentially "Pay me first" outright without even considering the bug.

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.

Wow, I've not seen codeshelter.co before but that is an amazing idea, thank you so much for putting that together!

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.

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!

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.

What do you mean by always on the developer?

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.

That's the right way to handle bug reports on commericially-supported (!) OSS when you get to work on OSS during your work hours.

> So seeing that this person is forcing people to pay to report bugs is absolutely wild.

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.

What's jarring is that he's refusing to look at the bug reports. Not that he doesn't want to act on them.

And, no, we don't fix "other people's bugs" either, just ours.

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.

What's weird about someone refusing to spend their limited time on things they don't want to deal with?

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 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.

Looking at bug reports (as in, really looking) takes time. Time costs money.

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 other people's bugs. It's your bugs.

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.

On a commercial development the bugs are free because you've paid a maintenance contract.

As the original article notes, "bug reports" are actually poorly worded "support tickets", which in all commercial software are not free.

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.

> I can tell you that all bug reports are always processed for free and on a high priority

Even if they come from someone who’s pirating your software instead of paying for it?

Sure.

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.

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.

[1] https://github.com/franciscop/picnic

[2] https://github.com/franciscop/picnic/pull/203

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.

Release notes are much more useful than the commit log for understanding what's getting done. Neither shows what isn't getting done.

Of course it's the project owner's prerogative. It's just a warning too.

> 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.

https://github.com/torvalds/linux

Linux has Bugzilla[1] and a mailing list[2] instead.

[1] https://bugzilla.kernel.org/

[2] https://lkml.org/

I am very sorry to break it to you but the only reason they disabled Github issue tracker is... https://bugzilla.kernel.org/describecomponents.cgi

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.

GitHub is just a mirror for Linux. We're discussing projects that use GitHub as their primary repository.

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.

I literally removed the "Issues" tab from Github, so IMHO it should be clear that issues are not accepted.

Sometimes that just means issues are hosted somewhere else.

Three things can be true at the same time:

1.) An end-user expecting free support for open source software is a jerk.

2.) A project maintainer expecting people to pay to submit actual bug reports is a jerk. bug report != support. You don't have to act on each bug report, but it's laughable to suggest that a bug report is a support request.

Support requests are requests for help in implementing or configuring something. Perhaps asking for an additional feature. A bug report is letting you know your code is broken.

3.) Miss me with the whole "I write open source software to solve my problem" attitude. That's why you write software. You open source it to so that others can use it. Some authors open source stuff to pad resumes, some to better the community, and some to stroke their own ego. But by publishing and open sourcing your software, the author implicitly broadens the scope beyond their own problem.

---

Reading that screed, I could feel the entitlement and ego dripping from the page. The author mentions the cost of a webserver. If the cost of a simple webserver is such a drain on your resources, then don't self-host. There's places to host open source projects for free.

The author made a choice to open source their software and self-host. That's a nice, egalitarian thing to do. But telling someone they have to pay to help you fix your broken code is... something else.

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.

That's just a limitation of English.

Parent clearly meant "gratis", while you clearly mean "libre".

> 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.

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.

From the post:

« 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’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 write Free Software. My users aren't leeches and I wouldn't insult them that way.

(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 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.

I'd say it's more

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.

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.

Here's my trick (maintaining a 15K star github project that gets a lot of issues filed): stay friendly and supportive, but encourage them to create a PR to fix the issue themselves (usually with me giving some hints how to).

It instantly filters out the low effort "I want you to work for me for free" people.

My aim is to turn as people as possible into contributors. You'd be surprised how often, especially with a few hints, go "hmm.. I guess a PR wouldn't be too hard and it be nice to contribute". And quite a few of these end up being repeat contributors, since a second PR is way easier than the first.

It also sends a signal: there's a gazillion things that could be improved about this project. Unless there is a contributor that is willing to make a PR, it is likely not going to happen.

And I spend a larger percentage of my time doing code review, which (as the BDFL) is more effective use of my time anyway.

This is terrible. Reporting a bug is not the same thing as asking for support.

Yes, its obnoxious when people misunderstand the difference between a bug and a user error. But that's the price of people reporting actual bugs. If you have no interest in learning about actual bugs in your software then be honest about it and admit that it's unmaintained so that someone who does care about the quality of the software can fork it.

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.

The way I see it, he (and any other maintainer who chooses to do the same) is perfectly within his rights to do this. They're his projects after all, it's up to him how to run them.

That said, if a contribution of mine is ignored in a project (and a few have been), that usually becomes my last contribution to the project. Afterwards, I often choose to instead invest my efforts in other projects.

Ultimately, by Linus's law, those projects that accept the most contributions and/or foster the most active communication ought to raise to the top. I think that we simply can ignore back the projects that ignore contributions; they're the ones who end up losing out, as far as I've seen anyway.

Yeah, I'm convinced OP's position is anti-fragile but he's got a right to run his project any way he wants. Strong agree with everything you said.

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..

Here's the text of an email we received recently:

    SO DAMN SHIET COMPONENT LIBRARY

    Hi all,

    Can you upgrade your library. Your fucking Datepicker 
    component is so stupid, so hard to use.
    Do you under stand UI-UX????
    How many year experience about Front end????

The component library in question is used by multiple fortune 500 companies, and has over 1.5M downloads a week from npmjs.

I replied with three :rofl: emojis, and "Kind regards, scoot". :D

"Open source" is a term intentionally created to do not mean anything about ethics.

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...

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.

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.

An alternative approach might be to create a way for the community of folks using the software to help each other, you might even get some users turn into contributors that way. This is how the user support for Linux distros works. For Debian at least, I have seen some of the more advanced users in the support channels move up to maintaining packages as a result of the support channel existing.

GitHub now has a discussions feature that could be used for this. Perhaps the right approach might be to open discussions for all GitHub users, open issues solely for project admins/maintainers and open PRs for all GitHub users. Folks who want to provide support can look at the discussions tab, reformulate valid bugs into issues and then maintainers/developers can turn those into patches.

https://github.blog/2020-05-06-new-from-satellite-2020-githu...

Wayback machine link: https://web.archive.org/web/20201115030921/https://raccoon.o...

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.

Something that helps here is distinguishing between bugs & features. As a maintainer of an open source project, I frequently have to say 'no' to features. Usually this takes the form of encouraging a plugin that implements the feature rather than adding it to the core library.

Bug reports on the other hard, even if they're as simple as someone misunderstanding a feature, are worth taking. If it's a real issue you can fix it otherwise it might be an opportunity to improve documentation. My only requirement is a reproduce provided. I'm not going to spend lots of time hunting down an issue based on something vague.

The intro conversation criticises the wrong thing, I think.

A bug report is good. I always want to know about bugs in my stuff, and if someone else points out that there is a bug, that is great. Letting people pay for reporting bugs is bad.

Now, fixing that bug is a different story, and that's what this should focus on. Bug fixing should not be taken for grated.

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.

From the title I was expecting something different.

I'm also an open source maintainer and I find his attitude ridiculous.

He is a Diva. The user contribute their tiny way by taking the effort to contribute a bug report instead of just ignoring what they could have found. And this guy ask them money just to fill a bug...

If he was asking money for investigating or fixing a specific bug I can understand, but here he just don't even want to see it!

Seriously, for his little size project, what is the cost of just having a few seconds look at incoming bugs even if not replying to it's author? He is probably missing some important info. Maybe someone was reporting that his crappy software was doing a 'rm rf' in some cases...

From my point of view, I'm very grateful for the bug reports I receive. Sure a lot of them are not really bug or already fixed. But very often I got very valuable feedback about bugs, incomprehension of the projects, or things that could be improved for that.

So on one side you can also consider that you have users ready to do free QA for you! That is invaluable!

In the case of this guy, I think that he is not really an OSS maintainer in the 'free software' movement but just the author of an abandonware with shared sources.

I have several projects on GitHub, and I have different experience depending on the target user of the project. For something that is library, or the thing which usually used by technical users, I generally have good experience with those, because I can get good bug report and quality PR.

In contrast, I also have some projects that can be used by nonprogrammers. I didn't have a good experience dealing with issues in these projects. It is usually just "not working", bad questions or some feature requests for their use case, so it is rare to have good bug report or quality PR. Examples: https://github.com/maple3142/aria2c-ariang https://github.com/maple3142/GDIndex

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.

That's just wrong and archaic.

> 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.

Nice way of handling it!

Unfortunate this side hustle probably won't fly with my employment contract.

I prioritize tasks how much they mean to me. It's not that i don't care about how the thing isn't working for you, it's that I have other things that are more urgent or more important to me. (Improving the world is important to me, and e.g. you getting my software to work in your weird special environment won't)

If you want me to care more, then do most of the work (or all of it, send a PR), because then the gain is better software and an encouraged OSS contributor. That, or pay me (but see above).

Fine, but at least have the courtesy to communicate this to your users.

When you publish open source, people don't want to fork and compete with you, partly out of laziness, sure, but also because it's just really bad manners.

If you're maintaining OSS and ghost your users, why act like you're the victim when people are confused and upset? Give me a break.

Sure, being in a relationship with somebody doesn't mean "I'm going to marry you and spend my life with you" but you should at least have the decency to communicate clearly with the ones who depend on you.

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.

> Yours truly

No need to charge money. Just tell them to "Fork off"

I have seen it on both sides.

Prima donna users who demand their problems be fixed yesterday, working for big corporations, said corporations having no intent whatsoever to sponsor the fix.

...And prima donna maintainers who somehow make themselves into bottlenecks around anything going on in their projects and then complaining about burnout.

The problem with entitled users is well-studied and well-known. Basically, the less a user pays for the goods, the more entitled they tend to feel.

The problem with entitled maintainers is this: while everything is good, they tend to ride on the wave of a successful project, though they might not be its sole author. Still, they enjoy the credit. They brag in blogs and READMEs about big name companies using the project, millions of downloads.

However, when proverbial shit hits the fan, the prima donna maintainers try to dodge any social responsibility by hiding behind excuses such as "I don't understand your use case, ergo it cannot exist", "It's open source so go fix it yourself" (but a PR that does just that will spend years in limbo), "it's open source so you're owed nothing, stop complaining", and finally, in their blogs: "I'm so tired and overworked, it's so thankless".

I don't know what is the true motivation of those people to get into maintainership in the first place. Maybe they unconsciously seek fame and recognition? Maybe, they do it consciously? I don't know, really. To me, it does look like it.

But there is also this thing about maintainership: if you do embark this burden for a project that a lot of things/companies/people happen to depend on, and you advertise the project as such, you implicitly tell you are responsible and trustworthy; if you reject an issue/PR on a whim that "you're owed nothing", you implicitly tell that you are not trustworthy on account of not giving a fuck. Personally, I'm ok with both as long as the maintainers are upfront with it.

Just fucking write upfront that you're not interested in contributions and that your software is a piece of art, not a tool. Or write upfront that contributions are welcome, but also be diligent about them, and also don't burst in tears because you broke things in a major release and people pointed it out to you.

When I read the post, I dismissed it as a complaint that someone on the internet was wrong. [0] But then it struck me after reading here that perhaps the (absolutely correct) complaints about open source software coming with no guarantee of support whatsoever misses something open source does come with that I consider far more important - the absolute right of repair.

I can't count the number of times I've gone down some rabbit hole with proprietary software and found myself without a clue, without documentation and been expressly prevented from bypassing that by a prohibition on reverse engineering in the licence. It leaves me with at best two options: ask the vendor's help (which inevitably requires me to leave the cheque book open until the solution is found at bleed at a rate determined by the vendor), or walk away from the software. At worst, the vendor has gone broke, so there is only one option. It's a pretty ugly position to be in. If I don't like the support on offer from open source authors then it's open source after all, so I can look at it myself or pay someone else to look at it for me. Hell, there are even companies out there that compete to sell me support, companies like Red Hat and Ubuntu.

[0] All open source licences I'm familiar with say the software comes with no support whatsoever. Naturally there will be people who politely ask you to support it anyway, and sadly as you've exposed yourself to billions on the internet there will be a small minority who attempt to connive, guilt trip or bully you. I'm not sure what the best way to handle that is, but console yourself there is a worse outcome than having to deal with the occasional arsehole - and that is no one cares enough about your software to complain.

I feel like some of the comments in this thread are making it painfully obvious who has actually been on both sides of that kind of conversation.

Open-source/free-software means that you can examine the code yourself, compile it by yourself, make changes by yourself, use it for any use, and to share it with or without modifications. It is independent of things such as:

- If they will give you a copy without payment

- If they will accept bug reports and/or patches

- If the author provides free support, or even any other support

- The quality of the software

Some will, and some won't.

We're adding to the hosting bills just by having this blog post on top HN

Maybe the author should add a stripe integration in front of their website

Hijacking this thread in a way, but for my uninitiated peers here is the kind of stuff you have to deal with as an open-source developer:

– https://github.com/devnoname120/vhbb/issues/75#issuecomment-...

Cool to see Onyx here. I liked his tools for Google Apps downloads so much that, a long time ago, despite seeing the open source version, I paid for the pro key. Highly recommend!

(We link to his site for the paid for version, so I will not dupe.)

https://github.com/onyxbits/raccoon4

The problem I see with allowing PRs but not issues (or locking the reporting of them behind a paywall) would be that there is no way for someone to discuss possible implementation details without having already potentially have gone down the "wrong" path and wasted time (i.e. Maintainer won't accept the PR without a significant rewrite), or spent money to discuss it when they already plan to contribute time and code to solve their own use case.

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.

It only relies on users outnumbering developers.

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.

>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).

Not all bugs are created equal.

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..

> The user didn't understand how to use the software and is confused.

This can be treated as a bug in the documentation.

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.

I'm being downvoted, but I don't understand why. I said it CAN be treated as a bug in the documentation, not that it SHOULD or MUST be.

Edit: more downvotes, on this comment asking for feedback, rather than providing feedback. O_o

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.

Wrong on all counts here.

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.

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.

What part of accepting bugs means you have to accept abuse?

Am I the only one that agrees with the author?

I think this is a very salient way of dealing with users efficiently on a small project that becomes popular. Perhaps they could implement a "refund user back" their cash if the ticket actually turns out to be a bug.

The example in this article is horrible. The author will not accept bug reports without payment for "support". I'd posit that no reasonable open source project has such a position.

Sure, without payment there may not be any expected turnaround time or immediate response, but being unable to submit a bug without paying is absurd.

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.

I don't see that part in the article.

> 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.

1.) Corporate entities don't care about your stint in issue tracker system. One small individual programmers do.

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.

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.

> Just because you made your source code available does not mean I'll do your QA for free.

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.

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.

You're right that the developer should make it clearer which case it is.

Reply on news.ycombinator.com