17 ms·

Open Source does not mean “Includes Free Support”

305 points by alexellisuk 6y ago

AntiImperialist 6y ago
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.
- esquire_900 6y ago
  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.
- fxtentacle 6y ago
  I don't see that part in the article.
- mschuster91 6y ago
  > 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.
  - watwut 6y ago
    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.
    - mschuster91 6y ago
      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.
      - watwut 6y ago
        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.
- onion2k 6y ago
  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.
- einpoklum 6y ago
  > 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.
  - AntiImperialist 6y ago
    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.
    - einpoklum 6y ago
      You're right that the developer should make it clearer which case it is.
robjan 6y ago
Wayback machine link: https://web.archive.org/web/20201115030921/https://raccoon.onyxbits.de/blog/bugreport-free-support/ https://web.archive.org/web/20201115030921/https://raccoon.o...
watwut 6y ago
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.
- spockz 6y ago
  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..
capableweb 6y ago
As someone who done open source for a long time now, I think the newer generation of maintainers is missing one of the most powerful tools we have available as maintainers. Ignoring others. You don't like the question? Ignore them. You don't feel you have the time to support them right now? Ignore them. It feels like they are entitled? Ignore them. I don't think people asking others to work for free is anything new. The recent outrage about others asking you to work for free is relatively new though. You're publishing open source code because you feel like it. This also means you can run the project however you want. Tell people to fuck off if you don't like them. Or don't tell them anything if you don't feel like it. You'll feel much better as a maintainer once you act exactly like how you feel like it, no more and no less. Don't pay too much attention to what others say. Time is much too limited to be outraged at everything. Calm down, and ignore people you don't like.
- fxtentacle 6y ago
  In my case, I received most of the entitled requests via email to the address that I had used for the git commits. It's exhausting having your inbox flooded. But I agree. Delete + ignore is the right reaction in most cases. That said, I feel that the balance in open source has shifted from fellow developer users to companies leeching off your stuff to power their SaaS. So these days, I prefer offering a rate limited free API instead of local tools and / or source code. That also conveniently keeps non technical users away.
  - capableweb 6y ago
    > In my case, I received most of the entitled requests via email to the address that I had used for the git commits Same here. To avoid getting overwhelmed by this, I have setup a particular email address tied to my git commits, that gets re-sent to my main email address, where it gets filtered, marked as seen and tagged as "potentially spam". I look at this tag sometimes (maybe once a month), depending on my available time, but in most cases, I just receive automated spam that is not even worth opening.
    - kenniskrag 6y ago
josephg 6y ago
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.
- einpoklum 6y ago
  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.)
  - josephg 6y ago
    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.
- loopz 6y ago
  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.
eznzt 6y ago
>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.
- deleted 6y ago
  [deleted]
- scarygliders 6y ago
  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.
  - eznzt 6y ago
    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).
    - zimbatm 6y ago
      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..
franciscop 6y ago
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 https://github.com/franciscop/picnic [2] https://github.com/franciscop/picnic/pull/203 https://github.com/franciscop/picnic/pull/203
- smarx007 6y ago
  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).
  - growse 6y ago
huhtenberg 6y ago
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.
- voxl 6y ago
  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.
- smarx007 6y ago
  That's the right way to handle bug reports on commericially-supported (!) OSS when you get to work on OSS during your work hours.
- phoe-krk 6y ago
  > 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.
  - huhtenberg 6y ago
    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.
tlocke 6y ago
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.
- tux1968 6y ago
  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.
  - segfaultbuserr 6y ago
    > 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.
stared 6y ago
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.
- hutzlibu 6y ago
  " 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.
- zimbatm 6y ago
  > 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
seedie 6y ago
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.
anonymfus 6y ago
"Open source" is a term intentionally created to do not mean anything about ethics. https://www.gnu.org/philosophy/open-source-misses-the-point.html 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_of_moral_development#Pre-conventional https://en.wikipedia.org/wiki/Lawrence_Kohlberg%27s_stages_o...
deleted 6y ago
[deleted]
noir_lord 6y ago
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.
mjw1007 6y ago
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?
- deleted 6y ago
  [deleted]
- monkin 6y ago
  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.
- deleted 6y ago
  [deleted]
deleted 6y ago
[deleted]
ChrisMarshallNY 6y ago
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.
cool-RR 6y ago
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.
- smarx007 6y ago
  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).
  - StavrosK 6y ago
    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/ https://www.codeshelter.co/, which didn't really do very well. Turns out not as many people want to maintain projects as I thought.
    - freedomben 6y ago
      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.
ablekh 6y ago
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.
Kmaschta 6y ago
We're adding to the hosting bills just by having this blog post on top HN
- pacifika 6y ago
  Maybe the author should add a stripe integration in front of their website
alibarber 6y ago
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.
- wildmanx 6y ago
  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.
  - davesque 6y ago
    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.
    - wildmanx 6y ago
      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.
Guthur 6y ago
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.
- badsectoracula 6y ago
  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.
fefe23 6y ago
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.
einpoklum 6y ago
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.
2ion 6y ago
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.
- sofixa 6y ago
  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.
- deleted 6y ago
  [deleted]
pabs3 6y ago
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-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/ https://github.blog/2020-05-06-new-from-satellite-2020-githu...
indentit 6y ago
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.
xhruso00 6y ago
No need to charge money. Just tell them to "Fork off"
sizt 6y ago
You mean it's not a communist plot after all?
etimberg 6y ago
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.
knorker 6y ago
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).
greatgib 6y ago
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.
deleted 6y ago
[deleted]
616c 6y ago
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 https://github.com/onyxbits/raccoon4
noname120 6y ago
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-561500026 https://github.com/devnoname120/vhbb/issues/75#issuecomment-... – https://github.com/devnoname120/vhbb/issues/75#issuecomment-548123322 https://github.com/devnoname120/vhbb/issues/75#issuecomment-...
beeforpork 6y ago
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.
paultopia 6y ago
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.
freedomben 6y ago
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.
- julianmarq 6y ago
  > 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.
  - 6y ago
mr_woozy 6y ago
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.
davesque 6y ago
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.
whoknew1122 6y ago
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.
luord 6y ago
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.
- renewiltord 6y ago
  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.
Aardappel 6y ago
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.
warent 6y ago
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.
maple3142 6y ago
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/aria2c-ariang https://github.com/maple3142/GDIndex https://github.com/maple3142/GDIndex
zzo38computer 6y ago
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.
scoot 6y ago
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
WesolyKubeczek 6y ago
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.
rstuart4133 6y ago
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.
nanoscopic 6y ago
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.

305 points by alexellisuk 6y ago

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.

esquire_900 6y ago
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.
fxtentacle 6y ago
I don't see that part in the article.
mschuster91 6y ago
> 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.
- watwut 6y ago
  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.
  - mschuster91 6y ago
    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.
    - watwut 6y ago
      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.
onion2k 6y ago
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.
einpoklum 6y ago
> 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.
- AntiImperialist 6y ago
  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.
  - einpoklum 6y ago
    You're right that the developer should make it clearer which case it is.

robjan 6y ago

Wayback machine link: https://web.archive.org/web/20201115030921/https://raccoon.onyxbits.de/blog/bugreport-free-support/ https://web.archive.org/web/20201115030921/https://raccoon.o...

watwut 6y ago

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.

spockz 6y ago
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..

capableweb 6y ago

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

fxtentacle 6y ago
In my case, I received most of the entitled requests via email to the address that I had used for the git commits. It's exhausting having your inbox flooded. But I agree. Delete + ignore is the right reaction in most cases. That said, I feel that the balance in open source has shifted from fellow developer users to companies leeching off your stuff to power their SaaS. So these days, I prefer offering a rate limited free API instead of local tools and / or source code. That also conveniently keeps non technical users away.
- capableweb 6y ago
  > In my case, I received most of the entitled requests via email to the address that I had used for the git commits Same here. To avoid getting overwhelmed by this, I have setup a particular email address tied to my git commits, that gets re-sent to my main email address, where it gets filtered, marked as seen and tagged as "potentially spam". I look at this tag sometimes (maybe once a month), depending on my available time, but in most cases, I just receive automated spam that is not even worth opening.
  - kenniskrag 6y ago

josephg 6y ago

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.

einpoklum 6y ago
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.)
- josephg 6y ago
  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.
loopz 6y ago
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.

eznzt 6y ago

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

deleted 6y ago
[deleted]
scarygliders 6y ago
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.
- eznzt 6y ago
  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).
  - zimbatm 6y ago
    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..

franciscop 6y ago

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 https://github.com/franciscop/picnic [2] https://github.com/franciscop/picnic/pull/203 https://github.com/franciscop/picnic/pull/203

smarx007 6y ago
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).
- growse 6y ago

huhtenberg 6y ago

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.

voxl 6y ago
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.
smarx007 6y ago
That's the right way to handle bug reports on commericially-supported (!) OSS when you get to work on OSS during your work hours.
phoe-krk 6y ago
> 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.
- huhtenberg 6y ago
  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.

tlocke 6y ago

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.

tux1968 6y ago
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.
- segfaultbuserr 6y ago
  > 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.

stared 6y ago

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.

hutzlibu 6y ago
" 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.
zimbatm 6y ago
> 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

seedie 6y ago

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.

anonymfus 6y ago

"Open source" is a term intentionally created to do not mean anything about ethics. https://www.gnu.org/philosophy/open-source-misses-the-point.html 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_of_moral_development#Pre-conventional https://en.wikipedia.org/wiki/Lawrence_Kohlberg%27s_stages_o...

deleted 6y ago

[deleted]

noir_lord 6y ago

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.

mjw1007 6y ago

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?

deleted 6y ago
[deleted]
monkin 6y ago
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.
deleted 6y ago
[deleted]

deleted 6y ago

[deleted]

ChrisMarshallNY 6y ago

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.

cool-RR 6y ago

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.

smarx007 6y ago
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).
- StavrosK 6y ago
  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/ https://www.codeshelter.co/, which didn't really do very well. Turns out not as many people want to maintain projects as I thought.
  - freedomben 6y ago
    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.

ablekh 6y ago

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.

Kmaschta 6y ago

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

pacifika 6y ago
Maybe the author should add a stripe integration in front of their website

alibarber 6y ago

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.

wildmanx 6y ago
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.
- davesque 6y ago
  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.
  - wildmanx 6y ago
    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.

Guthur 6y ago

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.

badsectoracula 6y ago
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.

fefe23 6y ago

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.

einpoklum 6y ago

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.

2ion 6y ago

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.

sofixa 6y ago
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.
deleted 6y ago
[deleted]

pabs3 6y ago

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-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/ https://github.blog/2020-05-06-new-from-satellite-2020-githu...

indentit 6y ago

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.

xhruso00 6y ago

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

sizt 6y ago

You mean it's not a communist plot after all?

etimberg 6y ago

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.

knorker 6y ago

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

greatgib 6y ago

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.

deleted 6y ago

[deleted]

616c 6y ago

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 https://github.com/onyxbits/raccoon4

noname120 6y ago

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-561500026 https://github.com/devnoname120/vhbb/issues/75#issuecomment-... – https://github.com/devnoname120/vhbb/issues/75#issuecomment-548123322 https://github.com/devnoname120/vhbb/issues/75#issuecomment-...

beeforpork 6y ago

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.

paultopia 6y ago

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.

freedomben 6y ago

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.

julianmarq 6y ago
> 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.
- 6y ago

mr_woozy 6y ago

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.

davesque 6y ago

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.

whoknew1122 6y ago

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.

luord 6y ago

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.

renewiltord 6y ago
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.

Aardappel 6y ago

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.

warent 6y ago

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.

maple3142 6y ago

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/aria2c-ariang https://github.com/maple3142/GDIndex https://github.com/maple3142/GDIndex

zzo38computer 6y ago

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.

scoot 6y ago

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

WesolyKubeczek 6y ago

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.

rstuart4133 6y ago

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.

nanoscopic 6y ago

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.