12 ms·

It Doesn't Work

• h2odragon 6y ago
  20 years ago, when I shared some code with the world, because it worked for me and i hoped others might benefit from it; that was all i was doing. Today, it seems, there's implied responsibilities to your users in that situation. Not only must the code be well organized, run perfectly, and handle all users needs; I myself must be of proper moral character, never have publicly uttered words that could be considered objectionable, and fully willing to endorse the fashionable fascism of the day. ... I don't buy it. I think that "hey this solves my problem" is viable and code doesn't carry the stain of its creators. We don't need to know or care who wrote our favorite text editor, they might be wonderful people or they might be gnarly gnomes dripping ichor; "here's the tool, it works" is sufficient knowledge to judge the tool.
  • bob33212 6y ago
    Github needs to let people set project status to "We Welcome any feedback, including asking how we feel about the latest SJW controversy" or "Comments are disabled, Merge requests may be looked at when possible."
    • yellowapple 6y ago
      On that note, it'd be nice if GitHub or other repo hosts had a way to leave project feedback that wasn't entirely around something that needs fixed.
      • detaro 6y ago
        Github is adding the discussions feature, which adds a sort-of forum to repos (needs to be enabled) (although generally a "just wanted to say thanks" "issue" is also well-received, even if thats not what issues are for. Or reaching out through any other channel, if the dev advertises one)
    • deepsun 6y ago
      You can always install your own GitLab and open it to the world.
    • IntelMiner 6y ago
      I know it goes against the grain, and probably doesn't contribute much to the discussion But I'd make an effort to avoid any software that whines about "SJW's"
    • rakoo 6y ago
      I feel like more and more developers are opting for the second form. I'm reminded of litestream (https://github.com/benbjohnson/litestream https://github.com/benbjohnson/litestream) for example that is closed to contribution
  • bigiain 6y ago
    I think the default GitHub README.txt template should end with this quote: "Any suggestions are welcome, but I won't promise I'll implement them :-)" -- Linus Benedict Torvalds 25 Aug 1991
  • perl4ever 6y ago
    >I myself must be of proper moral character, never have publicly uttered words that could be considered objectionable, and fully willing to endorse the fashionable fascism of the day. Your sentiment is increasingly common. However, Hans Reiser's conviction for first degree murder of his wife has not eliminated his name from various filesystem projects, let alone caused the code to vanish, so maybe there should be a bit of cognitive dissonance there?
    • TeMPOraL 6y ago
      ...yet. It persisted as an awkward anecdote in the industry. But more importantly, the story of Hans and Nina Reiser is of the kind that the various forms of fashionable fascism over the past two decades did not find interesting. It's not the act that makes people make other people remove references from software projects - it's how the act ties into current hot topics.
      • perl4ever 6y ago
        The story seems to me very easily tied into current hot topics - I'm not going to regurgitate the details which are on Wikipedia, but they are pretty disturbing and link to some key themes for MeToo. Possible alternative hypotheses I'd consider to your logic - maybe people don't care because it's old news? Maybe people just think of the comedian when they hear the name? Maybe people do care and it just hasn't hit HN?
    • FeepingCreature 6y ago
      Yeah but that's not a controversy - because nobody is defending him. So ironically it's "safer." If someone is a controversial figure, you can score points and grab attention and praise by removing their code from your project. If someone is uncontroversial - even uncontroversially bad - what are you indicating that way? That you, too, frown on murder? My impression is that ReiserFS was just sort of gently dropped due to disuse, disinterest and lack of maintenance. That's about what I'd expect - nobody wants to touch it, but nobody expects anyone to signal their disgust either, because it's not in doubt.
  • why_Mr_Anderson 6y ago
    I couldn't agree more. If I ever decided to make any of my work public, it would be under "Good luck with that" license (https://github.com/me-shaon/GLWTPL https://github.com/me-shaon/GLWTPL)
• H8crilA 6y ago
  Very real, also within corporations in proprietary code. One thing helps a lot: you don't owe "them" anything, also when working on proprietary code inside corporations. Don't feel like looking at it? Just ignore the bug report. Literally - don't even read the report. (If you haven't shuffled through hundreds of poorly formulated issues you may not realize just how much effort that is).
  • yaml-ops-guy 6y ago
    Don't feel like looking at it? Just ignore the bug report. Literally - don't even read the report. Presumably this is what product management is supposed to function and give attention to, isn’t it-at least to an extent? Or have I misunderstood what those staffers do? Seems lately I’ve seen developers frustrated about this because they want to be developers, but the company wants them to be everything and anything more (sometimes, maybe often-times because of poor resource allocation/chronic understaffing on the part of the business) from triaging feature builds to project managing entire releases. Maybe I’ve worked at shitty companies. In fact...now that I think about it.......
  • setpatchaddress 6y ago
    More broadly: always set boundaries for yourself. You may not have a choice to ignore the bug in a corporate setting, but you need to be willing to kick issues back to the originator for lack of information and /or lack of willingness on their part to help isolate a way to reproduce the problem.
  • deathanatos 6y ago
    > Very real, also within corporations in proprietary code. Yeah, I've fielded quite a few internal bug reports that amount to "it doesn't work". My stock response is becoming "what is the symptom you're actually experiencing when you say 'it doesn't work'?"; that usually gets more information. (The internal ones are perhaps worse, as you are beholden to respond to them, since it's from a coworker.)
• marcosdumay 6y ago
  We lost something when we centralized collaborative development and made it look like a social network (with even gamified activities). People used to glance over codes of conduct (as in RTFM first, post on such channel, and other practical stuff like that, not like the ones projects are creating today) before contributing, and did so with the intention of interacting for a while. Projects always tried to remove barriers for casual collaboration, but nobody managed to remove the long-term nature of it before. Now, well, too much of a good thing stops being good. Github finally fully succeeded, and this may be the main reason to abandon the platform.
  • too_root 6y ago
    Is there a decent alternative for open source projects?
    • leephillips 6y ago
      You can host a git repository on any server. The Linux kernel is not developed on github, is it?
      • rakoo 6y ago
        Github is far from just a git repository. It's a ticket tracking system, a discussion system, a release binaries host, a CI/CD component and a pastebin. The linux kernel has no CI/CD, no binaries, it doesn't even have a centralized server (only a copy of Linus' tree) and does everything through mailing lists.
        • leephillips 6y ago
          Well, if you want all of those things in one place, then that means github, practically by definition. But the example of the kernel shows that open source can carry on, on a massive scale, with no need for that.
          • deepsun 6y ago
• Wowfunhappy 6y ago
  About six months ago, I stumbled across a Github repository with zero stars, called Chromium Legacy (https://github.com/blueboxd/chromium-legacy https://github.com/blueboxd/chromium-legacy). A seemingly-unknown Github account, with no profile and no other notable projects, had single-handedly backported Chromium Canary to work on very old versions of OS X, alongside an automated build system to keep everything up-to-date. Due to my interests, I was delighted! The port had some major bugs, but I opened Github issues, and one by one, the developer fixed them. In a couple of cases, I helped track down the offending code, but he's done the vast majority of the work. At this point, I have definitely opened more issues on Chromium Legacy than anyone else. I opened two more just hours ago, and I was going to open a third... but then I didn't, because I was feeling guilty. He's always thankful for the reports, but he usually apologizes (!), which makes me worry I'm just creating all this work for him... so I don't quite know what to do.
  • bombcar 6y ago
    Be polite and unexpecting of any fix and do all you can in the report to make it easy to fix and you’ll be appreciated (even if just by others who find your report). People underestimate how valuable a good bug report is - with details, minimum examples, and workarounds. Especially workarounds - as you may be the only useful response people find.
    • virtue3 6y ago
      Any good bug report will save a developer HOURS of trying to understand the bug and where it's coming from. "X is broken" is about the worst JIRA ticket you can ever get :/.
  • ZephyrBlu 6y ago
    > but he usually apologizes I think this is very developer-esque thing to do. If it was me, I'd just be happy that someone else is using the code I wrote! I wouldn't worry too much if I was you :).
    • yellowapple 6y ago
• akavel 6y ago
  Hm; and yes, and no... in my case at least, I personally remember having more of those others - and for which I'm super grateful, they mean A LOT to me - i.e. the likes of, literally: - The unforgeable "WHERE HAVE YOU BEEN ALL MY LIFE" https://news.ycombinator.com/item?id=18295453 https://news.ycombinator.com/item?id=18295453 - my all time favourite comment that I don't stop mentioning when telling the story of my project, and that always makes my heart go warm. - The pure "Just wanted to give you a thumbs up!" 'issue' - no strings attached, no "but [could you do this or this for me]"... https://github.com/akavel/up/issues/14 https://github.com/akavel/up/issues/14 - plus, for some bonus love, a few follow-ups from other wonderful people... not even counting the people expressing their appreciation via the emoticons... - A person came back a couple years later and said, they use and like my tool so much, they decided in act of gratitude to give me not one but three logo sketches that I could choose from; then they had enough patience to bear my pickiness until I fortunately finally came back to senses and took the first one of the sketches, which was IMO the best one from the beginning. https://github.com/akavel/up/issues/48 https://github.com/akavel/up/issues/48 I still would say "yes, and no..." by which I mean, I'm still tired of this project enough that I can't muster strength to get back to it... sure, there were bug reports, and honestly, I understand and appreciate... I would open them too, and I treat them with respect... as I feel treated too (though also I have the fortune to be able to ignore or shut down occasional stupidity or demands). Yet I am still tired and drained of energy for now for this project. I sometimes muster a bit of it and improve some small parts. Sometimes. Maybe some day I'll get enough energy to again put more work in it. To finish some neglected PRs in need of love. So, as much as random demands can be part of the stress, and certainly don't make things easier, especially for some creators; as much as this, I think there must be also other psychological factors at play.
  • torstenvl 6y ago
    That's an amazing tool, never heard of it before, glad I ran across this. Did you ever get a Mac? I see from the page that it's now in Homebrew.
    • akavel 6y ago
      Nope, didn't; someone added it there, I just accepted the info into the readme.
• gwilikers 6y ago
  "It doesn't work" issues are bad for all the reasons described in the article, but the ones that really boggle the mind are the _demands_ people think they can make of maintainers they have zero leverage over. My favorite in recent history was a developer (who had never made any contributions to the repo, nor even filed the original issue) saying something to the effect of "if this issue is not resolved shortly, we will move our company to use a different software." Talk about threatening the maintainers with a good time.
  • bombcar 6y ago
    Many people use the same methods for commercial software and open source — and think threatening to move their non-existent purchases elsewhere will light a fire under someone. (It often doesn’t work for either.)
    • HomeDeLaPot 6y ago
      Your 50-person company is not going to move the needle on $BigCo's bottom line if you cancel because $BigSoftware doesn't have such-and-such a feature. And also, where you gonna go? Take a few months and migrate everything to $OtherBigCo, then do it again when you find out their product also isn't perfect and they also won't dedicate a dev team exclusively to you?
      • bombcar 6y ago
        Exactly. It’s like yelling at a cashier - I guess people do it because once in awhile it works.
  • nibsfive 6y ago
    I have generally always liked letting customers leave. Ultimatums can easily be two way. If they threaten to quit, I can always fire them :)
  • duxup 6y ago
    It shouldn't, but it amazes me that developers will do this to other developers. I was talking generally about JavaScript and another dev who likes to surf the web without JS enabled (more power to him) mentioned how in a given case there's no reason to use JS. I mentioned a side project that I felt kinda fit that use case (in a way). This is an entirely a casual project that has no intent to do much other than explore something myself and uses JavaScript, if folks like it, that's cool, it's free. I got litany of reasons that person would NEVER use my product that sounded a lot like an angry customer rant. Entirely free service, and I got a rant for it ;)
• bikamonki 6y ago
  Github and SO are the infinite source of good stuff that we devs need to solve our problems. I could not image my job w/out it. That being said, in so many years using OSS, I have never posted an issue or question. Digging around for a bit always shows the answers for "it doesn't work". Thanks for the hard work boys and girls! You set an example of how the world should work. Thanks! Thanks! Thanks!
• yuters 6y ago
  It's hard to imagine rolling into a car shop and telling the mechanic that your car "doesn't work", leave it at that and have him try to figure it out. Most people would at least try to describe the symptoms of what is going wrong, even if they don't understand a lot about cars. Imagine if the person who tells you "it doesn't work" is also a mechanic.
  • mberning 6y ago
    That exact thing happens all the time. People roll in to the shop with a CEL and bounce. It’s more common than you think.
    • yuters 6y ago
      I mean, that's still something to start with
    • rjmunro 6y ago
      "CEL" being "Check engine light"? As a customer, if that light comes on, but the car is otherwise fine, what exactly am I supposed to do apart from take it to the shop?
• slugiscool99 6y ago
  I've benefited tremendously from open source software and have used an open source library in virtually every project I've done. Totally grateful to the community for enabling me to build faster. However, I've always been curious - what motivates people to continue to maintain open source software? Why put up with rude people and improve a package for them, for free? Is the issue because monetizing it is too difficult? Or is there some other reward for doing this that I'm not seeing?
  • searchableguy 6y ago
    Rude people are rare. If your project is big, most users of it never even interact with the issue tracker. A desire to help those and provide something in return for OSS tools you use yourself.
  • sa46 6y ago
    My initial motivation for my (small) projects was always to scratch my own itch. Beyond that, it feels really good when someone else uses the code. For my current side-project, I keep up maintenance because it's interesting work and because I can plausibly benefit from bug fixes. It's neat to see how other people adapt the code and open up new use-cases. For that reason, I love high-quality bug reports and treat them with some urgency. For projects I lose interest in, I unsubscribe from everything and either mark the project as maintenance mode or try to find a maintainer. To find maintainers, I've had good success granting write access to anyone who lands a few good PRs and telling them they have free reign over the code.
• worldsayshi 6y ago
  I feel that the way that GitHub and others do social coding is a bit backwards in regards to this article. Issues shouldn't implicitly be owned by the owner of the repo but by the reporter. The reporter cares about the problem. The issue tracker should be a way to find others who care about the same problem. If the repo owner doesn't care they should feel no obligation. But the way the issue trackers are structured those issues implicitly becomes the repo maintainers problem. Also, there should be more ways to "praise" a project.
  • Wowfunhappy 6y ago
    > But the way the issue trackers are structured those issues implicitly becomes the repo maintainers problem. What would you change to make that happen?
    • worldsayshi 6y ago
      I don't have a "good" solution in mind but perhaps some partial solutions off the top of my head: Keep issues separate from the repos but allow tagging the repos in the ticket. Would allow multiple projects to get associated with one ticket. Community owned issues, a bit like stack overflow. GitHub projects are structured from the url to give the idea of total ownership by the the author of all the tabs of the project. So the issue tracker looks like it is "owned" by the author. Perhaps the author could choose to disown the tracker related to the project in some way. And then they could choose to own individual issues. Opt in instead of opt out and close.
  • deadbytes 6y ago
    >Also, there should be more ways to "praise" a project. Maybe github should implement a "feedback" tab where people can post their experiences of using the project. Perhaps some of those experiences would be negative too, but it would also allow people to give you neutral or positive feedback on what they like about the project, how they are using it, and what they have achieved with it.
• userbinator 6y ago
  The GitHub issue tracker made me cry more than once. I couldn’t get any sleep after having closed tickets without substantial justification. To be frank, that sounds like an addiction. It takes literally zero effort to just ignore the complaints. Let them complain all they want. You don't have to care about them.
  • worldsayshi 6y ago
    I don't think it's true for most people that ignoring complaints about something you've invested effort into requires zero effort. I would say it typically requires tremendous effort.
  • zmmmmm 6y ago
    This though is one of the terrible things about people adopting Github as a pseudo-resume for job applications. It's now routine to demand "Could I see your github respository" and strike out anybody who claims not to have one. Because of this just ignoring issues can create a huge amount of anxiety as you imagine your future employer's reading through the litany of complaints about your software and / or your failure to address them. It doesn't apply to everyone but I can see how to some people this would be really problematic.
    • userbinator 6y ago
      It's now routine to demand "Could I see your github respository" and strike out anybody who claims not to have one. For every company which does that, there's another whole bunch of companies who would rather prefer you not have a GH account.
• HomeDeLaPot 6y ago
  Man. I can't help but feel like some stories like this are caused entirely by pressure that the project maintainer is putting on themselves. Like the solution in this article was, "Finally, I learned to say no..." But maybe I would be the same way, diving deep into some obscure issue out of a sense of obligation to fix the thing I built and made available for others to use, and not realizing how much it was affecting me until reaching a breaking point. I'm glad articles like this exist and are getting shared around. Maybe more maintainers will start with a healthy attitude of "I'm not going to address every issue." Maybe we'll get a technical solution... Make it possible to close all channels? Find ways to encourage satisfied users to leave positive feedback? Buttons to close an issue with "Sorry, but I don't have time to provide support for free, but feel free to contribute your own solution to the project!" or "This might not be related to the software and I don't have time to address it, advise doing more research on your own."?
  • marcinzm 6y ago
    >I can't help but feel like some stories like this are caused entirely by pressure that the project maintainer is putting on themselves. Most people dislike getting tons of negative unconstructive feedback on something they put effort and love into. Detachment can easily turn into indifference about the project itself. That's not even getting into the more aggressive feedback that some people will casually throw at you if you tell them no.
    • HomeDeLaPot 6y ago
      Yeah, the more I think about it, the more I can understand that. Something is needed to prioritize and filter the queue of issues without causing too much detachment on the maintainer's part.
      • marcinzm 6y ago
        I feel the generally remote or solo work of open source developers makes it even harder. I talked to the customer support people at work and it's the shared team bonds that keep them from burning out. They can commiserate and provide mutual emotional support if a bad customer berates one of them. They can share and reinforce positive comments amongst each other to lift morale. That is all much harder for most open source projects.
• e-clinton 6y ago
  The problem really is that it’s difficult to get help on open source projects. When I’m using a piece of free software that doesn’t do what I want it to do, I’m happy to pay anywhere from 15 mins to several hours of someone’s time to help me fix it. I’d rather pay for an hour of your time than to wrestle with the problem for 8 hours. Just recently I reached out to a maintainer on Gitter and offered $600 for something that would’ve taken an hour of their time or less (I know that because I eventually solved it myself). The maintainer didn’t take me up on the offer which isn’t a big deal, but it’s just a miss opportunity overall. I’m sure someone could’ve help, there just isn’t a system in place to pay for casual help.
• rmccue 6y ago
  You’re under no obligation to offer support for your projects, but vice versa is also true: no one’s under any obligation to use them. I’ve maintained a lot of (reasonably popular) open source projects, and the ones I supported I do so because I wanted people to use them. Offering a quality product is part of that, and I was willing to dedicate my time and effort to it because I wanted that success from it. The difficulty with open source is not so much in doing this, but in scaling it. Unlike commercial (i.e. paid) projects, there’s no built-in incentive that really scales with usage. Once you get past the point of “I made something people want to use”, it easily becomes a victim of its own success, and it can become overwhelming to deal with. Your best hopes are either that you find a business model (if you even want to!) or find people willing to help in the community. But nothing stops you from creating projects that you don’t want to support. I throw tonnes of code out there (particularly since writing it isn’t my primary job anymore) with fairly explicit disclaimers that I’m not going to support it, and I think the article’s advice on this is pretty good. You need to be willing to say no sometimes. I find it’s best to know which sort of project you’re creating going into it, and try to communicate this clearly to your users but also to yourself.
• too_root 6y ago
  As a maintainer for an open source repo that is "owned" by a big corporation I feel this but on both ends. I empathize with reporters and I would love to be able to help them all (when sufficiently detailed reports come in) but the reality is that simply ingesting the issue and queueing for prioritization still means it'll likely sit for many months before someone gets to it. I suppose my point is that whether you're running an open source repo for a personal project or for a corporation, the problems persist. I wish more people saw documentation and source code as a gift rather than cause for free, on-demand support.
  • HomeDeLaPot 6y ago
    Maybe whenever you navigate to the repo of an open-source project, GitHub should have a fancy animation of a gift box opening. "Ta-da! This project is open-source and FREE for you to use AS-IS, without any guarantees!" Then they can play it three more times whenever you try to open an issue.
    • too_root 6y ago
      If only it was that simple. But obviously the corporation has an incentive in open source as most do. There is pressure to present as open but internally the priority is not on reported issues, unless they are security related or something is broken.
  • deleted 6y ago
    [deleted]
  • bjourne 6y ago
    > I wish more people saw documentation and source code as a gift rather than cause for free, on-demand support. But it goes both ways. Bug reports and feature requests are gifts that you and your corporation receive from the software's users.
    • too_root 6y ago
      Of course! It's the way users can alert us to issues and provide feedback. That's why I feel stuck in the middle -- overwhelmed from the incoming issues and unable to move the needle by myself or with whatever support were allocated from corporate. My experience is clearly different from the author's, who seems to have complaints about solo project maintenance. I just wanted to share my perspective.
• zelienople 6y ago
  If someone posts something on GitHub, I will appreciate it for what it is, whether it "works" or not. Maybe I will adapt it to my needs. Maybe I will open an issue. Whatever. If someone promotes something that doesn't work, they can expect the feedback you have described. Many developers suffer from lack of empathy: they can't understand how their work will look to others, and, if there is documentation, it doesn't answer the obvious questions others will ask. Fine, so long as they don't waste my time with self-promotion of something that they are unable to see through the eyes of others. The negativity is fair payback for my wasted time getting sucked into something that the developer falsely promoted as fit for some purpose.
• op00to 6y ago
  Dude, just ignore the issues you don’t want to fix. You don’t owe anyone anything.
• ExcavateGrandMa 6y ago
  no release, no meant to work (at least for you which seem limited by an error or more)... :) release is the exciting moment "it's when it should work for you" :)
• ohazi 6y ago
  > “Thank you, this is exactly what I needed” would be a heartwarming thing to read, but you will never see such a comment ever. FWIW, when I find a tool that I really like, or that solves a problem I'm having, I try to send the maintainer a (very) short email. Something like: > Hi $person, just wanted to say thanks for writing and maintaining $tool. I just used it for $purpose, and it worked really well! Sometimes I get a reply, but I don't expect one. I don't want to add clutter or be a burden to someone who probably gets a lot of email, but hopefully this can be a nice gesture to counter the endless onslaught of bug reports and complaints.
• raspasov 6y ago
  I will just defer to Rich Hickey in this case: "The only people entitled to say how open source 'ought' to work are people who run projects, and the scope of their entitlement extends only to their own projects. Just because someone open sources something does not imply they owe the world a change in their status, focus and effort (...) As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation. If you have expectations (of others) that aren't being met, those expectations are your own responsibility. You are responsible for your own needs. If you want things, make them." Emphasis mine: ** If you want things, make them ** From "Open source is not about you" https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
  • agumonkey 6y ago
    it's a weird bouncing effect that open-source was a way to unlease more collaboration by sharing the source but it turned into a MMO-feature-request tsunami.
  • nayuki 6y ago
    The essay you shared, "Open Source is Not About You", is excellent. Another one that I highly recommend is "Open Source Is Free As in Baby", with quotes like: > I think of someone releasing open source software as a gift to the world, not as claiming a responsibility to maintain it for you. Some projects do claim that responsibility, but it’s not automatically conferred just because someone released a project on GitHub. I think much more of the responsibility falls on the person using it. It’s your code that will be using it, your code that will need to be upgraded, and your code that will break.
  • FeepingCreature 6y ago
    I do think there is an obligation, but it's one of expectation management. If you have an issue tracker, it affords filing issues - then there is some expectation that those issues will be looked at. If you're visibly giving people an opportunity to talk to you, and then don't respond, that's rude. In that sense, I advocate documenting your response policy on the top of your README.
• Sniffnoy 6y ago
  > “I don’t know” and “I don’t care” would be honest answers. The former is not a valid justification for closing the issue. The latter would backfire. Nah, you can totally say that you don't care, you just gotta phrase it right. "Sorry, we have no plans to support that use case." Or -- if you don't mind leaving the issue open -- "I don't think fixing this is a priority right now, but feel free to submit a PR yourself!" Really, it just sounds to me like the person writing this hadn't yet learned how to say no. Going by the end, they've since gotten better at this, so good for them. But the point is, there absolutely are polite ways to convey that you have no interest in solving a particular problem.
  • kelnos 6y ago
    Right, there are many ways to convey that you are not going to offer your help. Most of them do not make you sound like an asshole.
  • phendrenad2 6y ago
    Then you get labeled an "uncooperative maintainer" and people write scathing blog posts about you. There's no way to avoid the PR trap here.
• hughmustbejoke 6y ago
  The thing that bothers me the most are the users of your code that are not able to create a reproducible test case and instead post a useless error without the conditions that led to it. Bonus points for the laziest bug reporters with a screen shot of the error with a red circle painted around it - like that "emphasis" would help. Seriously, the programming profession cannot be taken seriously when the vast majority of github users cannot make a proper bug report. They cannot place themselves in your shoes and ask themselves "What would I need to solve this problem if I were running the project?". No amount of issue template creation will help - they won't read it anyway and erase the template.
  • Avamander 6y ago
    > instead post a useless error without the conditions that led to it. Why are your errors useless?
    • dj_mc_merlin 6y ago
      It's impossible to fully print out the environment and state of the program. There's an infinity of combinations of hardware and software a user may have. Also, different mistakes may lead to the same error. This is a reality since it's impossible to predict every error state in a program of any complexity. Or sometimes it's just more practical to have that information given to you than spend hours REing it.
      • Avamander 6y ago
        You're mostly correct, but I was poking at the fact that a tremendous amount of software has errors akin to "Something happened (0xcafebabe)" with all the documentation hidden. Error messages common in the industry are the reason most don't bother reading them - they're useless, unactionable and vague.
  • thrower123 6y ago
    If you get a screenshot, you're doing better than I typically am with my paying customers. It's usually not more than a vague two sentence email, and a meeting invite for 7:30 AM sent at 3 AM my time... It usually takes me one or two days of back-and-forth to get the basic set of information to be even able to diagnose a problem. And this is with people that I've worked with for years, and have hammered and hammered on the kind of details I need, and have even built features to collect all the diagnostics with a single click...
• djoldman 6y ago
  "At this time the only supported platform is ____" [closes issue] Seems straightforward for a lot of what this post is about.
• mberning 6y ago
  To be fair, software in general is a complete shit show. The amount of things that don’t “just work” are staggering. Then we built 10 or 20 shaky layers of abstraction, one upon the other, until we ended up with the computing landscape of 2021. I tried gettin a Radeon driver to work on a laptop running ubuntu recently. What a disaster. Getting stuck in dependency hell, strange compiler errors, seg faults. Bleh. I gave up after 3 days of messing with it. Sadly this is a very common experience. It was more economical to just buy a macbook and move on with my life. So I do feel bad for this guy and see where he is coming from. But software and the ecosystems around them are just so bad.
• agumonkey 6y ago
  Could this be addressed by a new language ? seriously asking.. a paradigm that put the social variable first.
• pabs3 6y ago
  Probably GitHub needs some way to allow projects to have projects define how they want their defect workflow to look. For eg discussion -> triage -> debugging -> issue -> code change, with each of these layers accessible to a different set of people.
• mradmin 6y ago
  (deleted)
  • kelnos 6y ago
    Maybe the author doesn't want community engagement in the way that you want it. You decide how to manage your projects; allow others to decide what will best help them maintain their sanity.
    • deleted 6y ago
      [deleted]
• bachmeier 6y ago
  > I take a quick glance at my GitHub notifications via Octobox The term "GitHub" appears nine times on that page. One way to resolve this problem, if it is a problem for you, is to not use GitHub. If you use a tool that was designed to incentivize exactly the scenario described in this article, you shouldn't be surprised when that scenario is realized. Post your code in another form, such as on a website as source.zip. If this doesn't work - often because the developer feels there are personal benefits to being the maintainer of a highly visible project - I'm less sympathetic. Even releasing your project on GH with a readme that says you're posting your code but don't have time to deal with issues will solve the problem. The real problem is buried within the text: "Failing to handle it directly affects your online reputation." That is the motivation for the project. This person wants to enhance their online reputation (for whatever personal reasons). This is all fine if that's your thing, but online reputation doesn't come for free, just like a YouTube channel with 100k subscribers doesn't come for free.
  • mrweasel 6y ago
    > Even releasing your project on GH with a readme I wouldn't expect people to read that. The real issue, I think, is still that many fail to understand that open source software is free, in multiple ways. The worst of the examples in the article is the: "We are waiting for a solution". If you pick open source software for critical infrastructure, then you need to be prepared to provide solutions for your own problems. Sometimes that means fixing stuff yourself, sometimes it means paying external developers to do it for you. People/companies forget that part. The OpenBSD approach of just shutting down request with a the comment: "Show us the code." is a little hard, but not unreasonable.
    • ninjin 6y ago
      > The OpenBSD approach of just shutting down request with a the comment: "Show us the code." is a little hard, but not unreasonable. I feel as if many have not been exposed to this approach and without questioning it buy the concept of your open source projects being advertising for you as an individual and that lest you provide support for each operating system (and their many versions…), etc. you are unworthy of the honour of giving away your labour of love free of charge and deserve to be scorned publicly. Maybe this is because I entered the community in the early 2000s and things were “different” back then, but I have never understood this perspective. Did it rise to dominance with the likes of GitHub? Note that I am not suggesting that GitHub et al. are a “source of evil” here. OpenBSD is an operating system made by its developers for its developers. If you can not “handle” Theo [1], dislike the fact that there is for example no Bluetooth stack because they were happy with the code quality, or zero tolerance for binary blobs, it is perfectly fine! Want the codebase to steer a new course? Fork it! Want something else? I am sure there are other communities out there better aligned with your goals and maybe they are open source ones too? “It does not work” or “We are waiting for a solution” is to me akin to marching down to your local volunteer orchestra and insisting on them changing their repertoire or perhaps incorporating your accordion this very moment or you will throw a tantrum. It is silly, it is childish, and it frankly pretty much deserve the response that people that behave like this get from the OpenBSD community. [1]: https://en.wikiquote.org/wiki/Theo_de_Raadt https://en.wikiquote.org/wiki/Theo_de_Raadt “Why are you guys so fork paranoid? Do you want everyone to vote for the same political party, too?” – Theo de Raadt
• kungito 6y ago
  The problem is that expectations are not communicated correctly. There are projects with devoted maintainers and there are projects where someone did something one time. Here is my stupid proposal: If you (the company or person or team) do not want to devote serious time to maintaining your project, take it off the package manager listing. Let's try at least keep the package managers with sane, up to date and maintained projects. What often happens (especially with old languages or god forbid languages which had breaking changes) is that most of the things you find is no longer maintained and worked at some point on some older version of the language/framework. As language evolves and matures, the original package manager listing if more and more full with things which no longer work. This is horrible experience. Can we agree to keep the package manager up to date and have a simple mechanism to have the hobby projects sideloaded directly from github I am totally ok with you no longer wanting to support something but please do not take our time. This is especially a problem where people chose a hobby project whose scope is way too big for them and it's impossible for a single person to maintain it. Could you please split it up into multiple projects and try to finish at least a part of it? We are all wasting each other's time and feeling horrible at the same time
  • phendrenad2 6y ago
    Exactly. I think a few people have called for Github to allow disabling PRs and Issues, but considering that it would destroy their business model, I don't think it'll happen. Oh well, there's always Sourceforge.
    • romseb 6y ago
      Disabling issues is possible.[1] Telegram's official Android client repository disabled issues a few years ago.[2] [1] https://docs.github.com/en/github/managing-your-work-on-github/disabling-issues https://docs.github.com/en/github/managing-your-work-on-gith... [2] https://github.com/DrKLO/Telegram https://github.com/DrKLO/Telegram
• shp0ngle 6y ago
  I was thinking, surely the author might overstate this... then I looked at his biggest project, libsodium, and this is the second most recent bug https://github.com/jedisct1/libsodium/issues/1038 https://github.com/jedisct1/libsodium/issues/1038 ``` invalid usage on desktop chrome when running crypto_pwhash Error: invalid usage at h (sodium.js:formatted:17589) at Object.qA [as crypto_pwhash] (sodium.js:formatted:19328) ``` (this is the whole issue, no more information provided.) OK I feel the author now.
• thrower123 6y ago
  If people are being assholes, you might as well politely tell them to take a flying fuck at a rolling donut. It's not like they are paying customers, so there is no justification for taking their abuse. Even in actual businesses, people are generally too eager to follow the "customer is always right" mantra, rather than getting rid of bad customers that generate more work and stress than they are worth.
• StavrosK 6y ago
  I created and/or maintain various semi-popular open source projects (please join codeshelter.co!) and I always feel like I'm in a different universe from people like the author here. Yes, people file bugs, but I want to hear about the bugs so I can fix them. They're always polite, often file PRs and fix the bugs themselves, and always thank me in the end and I thank them back. I've either never had a rude/demanding user, or don't remember one if I did. Is it because I mostly write developer libraries? Is it end users that are terrible?
• graderjs 6y ago
  As an aside: this person's photography is really good. Looks like they could easily have a side business in commercial / editorial photography. https://www.prettysimpleimages.com/ https://www.prettysimpleimages.com/
• bumbada 6y ago
  In some way it is self inflicted damage. Remember Murphy was an engineer, and "if you let something go wrong, it will go wrong" means as an engineer it is your responsibility not letting people shoot their feet, because if you do, they will(and blame you). As an engineer if you leave a manhole cover open and people fall down, it is your responsibility. If you leave your code incomplete, people will discover your bugs. When I was young I made that mistake: Leaving too much code to document and open that we had no time to make perfect(it was impossible,there was no physical time on our entire life for that). Today we create a library, and a program with limited functionality but PERFECT and make people shooting on their feet impossible(limiting the functionality too). Very few things to document. It works as it should. I learned that from Steve Jobs "saying no to things". Deciding who is your customer, deciding what is your problem is essential. People don't want to do that. They don't want to select a customer and make a decision that could be wrong. So they leave it open.
  • elnygren 6y ago
    > As an engineer if you leave a manhole cover open and people fall down, it is your responsibility. In an OSS project, you can just provide it as-is without any kind of warranty and clearly tell this in the license. Maybe you are confusing OSS with actual paid work and paid software (services)? Of course sometimes the business has OSS components that customers expect to have a certain quality but still... nobody is obliged to work for free, especially if the end user is a for-profit corporation.
• alwayshasbeen 6y ago
  One of the big mistakes we the OSS developers made is to give people the impression that software is not associated with costs. Be it personal time you put into developemnt, be it the time you spend fixing problems someone else has. All these things are costs for yourself and people don't value that.
• elnygren 6y ago
  Engineers are quite choosing beggars (https://www.reddit.com/r/ChoosingBeggars/ https://www.reddit.com/r/ChoosingBeggars/) when it comes to OSS libraries. Most of the time OSS libraries are completely free and provided as-is without warranties of any kind. Still people act as if they were a customer who has signed an SLA with the maintainers. It's OSS, fix it yourself. Or pay someone real money to fix it. Or just buy a SaaS version or paid library. Or DIY. Why would anyone be obliged to work for free for you? (yes, some businesses have an OSS product, it changes things a little bit but even still it's as-is without any warranties)
  • pjmlp 6y ago
    Not only that, is the expectation that someone works for free, while naturally not wanting to work for free for themselves.
• tomcooks 6y ago
  Just ignore issues, and delete the ones clearly written without having tried to work around problems or read documentation. Make it very clear in the README and give a paid option to offer paid customer service. No need to stress.
• another-dave 6y ago
  Github could tweak the tools available to make this easier for maintainers to manage I think, for example: — a setting to allow PRs but only if they already pass all tests & linting (using a Dockerfile supplied by the source repo). You're PR doesn't show up on the radar for the maintainer until it's already some way mergeable (and you can't edit the build agent). — allowing issues only in the form of a PR with a new failing test case (again, ran through the pipeline created by the maintainer). Also, allowing a repo maintainer to have required fields in an issue form rather than having a template that may or may not get followed. — some type of settings that maintainers can turn on to enable "Kudos" or thank you posts, separate to the issue tracker. Maintainers could ask for/enforce all of those things at the moment manually, but it's putting all the friction onto their plate (rather than the people offering fly-by criticism).
• EVa5I7bHFq9mnYK 6y ago
  Facebook and G$$gle don't provide user support, and they have billions. Why should you, for free? Just disable the issue tracker for outsiders.
• deleted 6y ago
  [deleted]
• valand 6y ago
  It is never the author's responsibility to provide support, unless somehow a contract is formed and agreed upon beforehand. Even one of the most permissive and popular open source software license, MIT, states: "IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE." You can write, in a file linked you README.md (e.g. CONTRIBUTION.md, github issue is a contribution instead of a request after all) that all contributions in the form of github issues must ticks a certain criteria in order to be prioritized, e.g. issues title must be specific in describing the problem, issues with proposed solution will prioritized, etc. Also, for the article author, thank you for making an effort to help. To help others solve problems you have encountered and triumphed over is a very generous gesture.
• johbjo 6y ago
  There are various implicit contracts involved. Using your software is lending you reputation, power, and influence. In high profile projects, this mindshare is more valuable. If your software would be unreliable, the trust and reputation would be misplaced. For example, if an update script in a major "stable" distribution would clobber user data, the tone in these comments might be justified. But mostly, this is bad form.
• thenoblesunfish 6y ago
  Related question - is there an organization with a clearly formulated “issue bankruptcy” policy? That is you periodically close all issues, announcing that anyone who cares even a little bit can re-open? I dream of it..
• not_the_nsa 6y ago
  I've experienced this from the opposite side (positive feedback) and wanted to share that the tone and structure of the rOpenSci community seem to foster positive feedback and community interactions. I maintain an R package, an API wrapper for a popular electronic data capture framework, which was peer-reviewed by rOpenSci (https://ropensci.org/ https://ropensci.org/). They put extreme care into making software as accessible and inclusive as possible, which I like a lot. Especially the rOpenSci community (see their CoC (https://ropensci.org/code-of-conduct/ https://ropensci.org/code-of-conduct/)) is full of considerate, caring human beings. One could call them the Anti-SO. Through the peer review process, community requests and GH issues, there's probably a year's worth of spit-polishing added on top of the "works for me" level. This is my first publicly used software package, so I'm taking this as a learning curve and I'm bending over backwards to making this package as inviting and usable as possible. I get away with this as I'm a public servant and paid to deliver value to the general public. And I must say, every improvement over my initial "good enough" version has paid off against the main project I'm using this package for. So my experience with this tiny, niche, package is overwhelmingly positive. I blame the audience - R programmers, rOpenSci members, and members of the community of the software I'm API-wrapping, which all are stressed out researchers grateful for help. These communities have also a good code of conduct. Maybe also issue templates with friendly guidance to give me very precise feedback (and the advice to take common sense over my guidance) help. Maybe they also repel low effort "could you please do my homework for me" queries.
• shrx 6y ago
  > After 30 days of inactivity, issues are closed with a timeout label. If there hasn’t been any activity for that long, it is unlikely that leaving the ticket open is going to change anything. Maybe it was a feature request that no one is interested in implementing. Maybe the reporter was asked for details but is never going to provide them. Maybe nobody knows how to answer the question or what it even means. I don't agree with this part. An issue should stay open _until it is resolved_. A timeout is not a resolution. It is extremely disappointing from the issue author's perspective to see their issue closed without any feedback from the developer. The developer should either provide a solution, or manually close the issue with a specified reason, e.g. "wontfix", so at least the issue author knows what to expect.
  • Epskampie 6y ago
    The article explains exactly about how a growing list of issues, with every ticket needing time and effort to figure out is bad for their mental health. Then your response is: "no, every ticket should stay open until it gets a response"? That is the exact mindset that drove the original author to tears.
  • b3kart 6y ago
    Doesn’t sound like a bad way to weed out less important work. If an inactive issue is closed an nobody cares: good, that’s the intention. If someone does care enough to re-open/open a new issue: no harm done, and maintainers have clear signal that someone still cares.
  • bla3 6y ago
    For personal spare time projects, the only way it won't spiral into what's described at the top of this post is if the burden for making an issue useful is on the reporter, not the author. There's one author and millions of possible users.
• InfiniteRand 6y ago
  While I know the maintainer of an open source project has no real obligations to random developers, I have also spent a lot of time struggling with getting open source projects to work as advertised in the documentation. So I can understand the frustrations that users might have. But that is a reason to be careful in the projects you use, not to harass the developers. My rule of thumb is not to pick up random open source projects unless I am confident they have a stable user base and some active maintenance. I may take code from a random open source project if I understand it well, but I'm not going to rely on some packaged solution unless I know that their is some community behind it.
  • cpfohl 6y ago
    I think that third option is my primary one. For small dependencies I'll often use code by copying the relevant source into my project with links back to the original source. It forces me to understand the code base better. Usually I find I can fix the issue. _Sometimes_ i contribute it back.
    • cpfohl 6y ago
      Contributing code back is tricky for a lot of the same reasons that leaving your open source repo's issue track open is...fwiw I don't use code with licenses that require contributing back.
• yakubin 6y ago
  > The issue tracker may quickly start to fill in. “Thank you, this is exactly what I needed” would be a heartwarming thing to read, but you will never see such a comment ever. As a counterpoint, I'd never wish to see such comments made in GitHub issues for my projects. To me it's just spam. I also feel really awkward replying to such comments. A bug report (if it is an actual bug) is however welcome to me, because it lets me see that there is an issue in something I wrote. The first time someone filed a bug against my program (not a thank you, but an actual bug report), I was really happy that someone made the effort to let me know about a flaw in my insignificant creation. That said, when the volume of tickets filed on the bug tracker is big enough, I'd consider having the bug tracker open only for paying users. Handling those tickets is real work and the author is entitled to payment for it when someone demands it. Doing it right from the start regardless of volume is also totally reasonable. Alternatively, the author may decide that they just don't care about bug reports from others. In this case, GitHub doesn't seem to be the best platform for their project. A basic cgit instance should suffice or a tarball on a website - no place to file bugs. From yet another perspective, when I want to contribute to a project, I outline on the bug tracker a potential contribution, ask whether that would be welcome, if I should start working on it or maybe there are some changes needed, and then I don't get any kind of response for months, it's off-putting. A "no", "I don't care" or "I don't have time for it" would suffice. It's comparable to ghosting in the world of dating. Just say "no" and everyone will be better for it.
• zabil 6y ago
  > However, what is often overlooked is the psychological impact this can have. Absolutely. It's hard to explain this. I maintain a mildly popular open source project. There's a strange dread when I think of reading my Github notifications. An issue or question influences my mood for the entire day. I can only imagine what maintainers of popular open source project go through.
• meltedcapacitor 6y ago
  Not publishing on github probably removes 99% of the entitled crowd who think github is some sort of google/facebook thing you get some free service from in exchange of losing your privacy or something. Having a couple of projects on gitlab, with proprietary naugthiness like issue trackers duly disabled, I don't think any human, entitled or not, has noticed them. It's a quiet life at the end of the long tail.