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.
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."
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)
I feel like more and more developers are opting for the second form. I'm reminded of litestream (https://github.com/benbjohnson/litestream) for example that is closed to contribution
>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?
...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.
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?
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.
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)
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).
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.
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.
> 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.)
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.
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.
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.
GitLab also has all of these features, and it had many of them before GitHub, like built-in CI/CD. But for some reason I'm being downvoted for suggesting it on HN, curious why.
That would be a pretty easy thing for GitHub to fix, just add a prominent banner about reading the code of conduct files for the repo before sending issues/etc. Could you file a support request?
This is a result of the popularity of Github. Low barriers are good, but as a result of this you're getting also inexperienced/low-effort people alongside the rest. And they're the majority. Github is so popular that it has become almost a one-stop shop for some users, while explicitly _not_ catering to non-technical users at all.
One thing that worked pretty well for me was to move to Gitlab. Very few people currently bother to create an account on another website to report an issue, and as a result the quality of feedback and reporting has always been very high. Gitlab has also less gamification, which helps in keeping project popularity from skyrocketing just due to stars and network effects instead of actual project merits.
I initially moved a single project when GH was acquired by Microsoft. GH/GL are totally equivalent for me, but due to this I ended up moving all my public projects and never looked back.
About six months ago, I stumbled across a Github repository with zero stars, called 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.
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.
> If it was me, I'd just be happy that someone else is using the code I wrote!
Haha, seriously. As I was reading this article I was thinking to myself "well shit, at least people are bitching about this guy's projects; that means people are actually using 'em".
Not that I'm complaining, of course. I'm quite content in my obscurity :)
I think you should continue opening issues for bugs you find and try not to feel guilty about it. I know I'm personally delighted when someone opens an issue on any of my repositories with a similar amount of care you seem to put into your reports. The maintainer you're reporting to likely appreciates you and wants to continue discovering bugs and fixing them (you can always just outright ask if you're unsure).
> He's always thankful for the reports, but he usually apologizes (!), which makes me worry I'm just creating all this work for him
The maintainer appears to be Japanese. I suspect this is just a cultural thing surrounding apologies you're reading too much into.
Why not ask him? Maybe give him a call? You have already spent lots of time “together”. You are de facto some kind of companions. I’d definitely be delighted. Mostly it’s me reaching out to users.
I think pacing yourself can be important. Sometimes it does help to hold off on that request till the next day.
I have very little open source experience, but I am thinking of the experience of support engineer sending requests to development. If you hit them with too much too fast, you will tend to provoke worries or exhaustion.
That being said, making 3 issue reports when the repo had only 1 besides that doesn't seem like a problem. Developers do like to feel like their work is getting some attention.
> 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.
So, this is probably a cultural issue.
Have you tried heading this off by apologizing first, in the report? Alternately, being thankful in the report may work out better. Or you can try both.
Note that mirroring like this can come across as sarcasm or ridicule if you recycle their exact phrasing or exaggerate it, so don't do that.
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 - 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 - 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
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.
"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.
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.
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?
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.
> It shouldn't, but it amazes me that developers will do this to other developers.
I suspect your misunderstanding there is some misplaced assumption that "developers" are some sort of tribe who respect and look out for each other.
It's easy to exist in a small "developer tribe" bubble where that's true, but there's a universe full of "unpassionate devs" just scrabbling to get project managers or bosses off their backs, and who'll cut-n-paste from StackOverflow answers and harass open source maintainers just to get their next Jira ticket completed before whatever arbitrary time estimate/deadline has been imposed on them.
I think it is more that I would hope that folks who have an unfair or just not fun thing happen to them, wouldn't do the exact same thing to others in almost identical situation.
Granted years ago I once worked at a call center and a coworker, just after complaining that they just got yelled at by customer for something they didn't do and couldn't change, placed a personal call to a local pizza place, and did the same thing to them.
> "if this issue is not resolved shortly, we will move our company to use a different software."
No problem, there are other software projects that achieve similar goals to this one such as $ExpensiveOption from Microsoft or $outrageousLicenceClauses from Oracle - perhaps their support services are more in line with your company's expectations? Good luck, have a nice day...
I really respect this way of dealing with unreasonable complaints. I guess the term for this is "killing them with kindness", and it's much more healthy than escalating things with a rant about how "entitled" the complainer is.
Ideally the complainer will see how positive the developer is being and reflect on their own attitude, but even if they don't, it gives a good image to other people who read the messages and sets expectations for how people should behave, so that a project doesn't devolve into toxicity.
I'm glad you took the face-value interpretation there.
Sarcasm is easy to disguise in pure text communication.
Back in the day when I spent as much time on comp.lang.perl.misc and scarydevilmonastery as I do in HN these days, that sentiment was less ambiguously delivered as "HTH, HAND, FOAD"
Most people in most teams are pissed off, their projects are behind, and their software is a mess. No one in a well-functioning, high-morale team would write something like that. In such scenarios, people pursue greedy-like algorithms for any short term reprieve they can get. Coming from a place like that, maybe making a mild threat seems like a good idea at the time.
Last time I had some free software actively out there, I got that several times.
My response was "So if I follow your demands you'll stick around and maybe demand more, of I tell you to get stuffed you'll go away and bother someone else? In that case: feel free to get stuffed."
Some just went away, I got one "I'll make it so you'll never work in the industry again!", and one started to beg profusely that I implement what he wanted because he would lose his job without it (not sure how that worked, I assume completely made up, didn't care either way).
Of course that was long before current social media outlets made it relatively easy to create a made up shit-storm, I might be a bit more diplomatic (but no less definite) in the same position these days.
You train them. If you let people take advantage of you, they will take advantage of you, of course.
Most of the time is not on purpose. Thinking how something should work (or using it once done) is way easier than doing it(hundreds or thousand times easier actually), so the only person that really knows how much effort something takes is the person doing it.
Because they don't know how much something takes, they don't value it. Specially if it is given for free.
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.
"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?
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?
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.
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.
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.
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.
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.
>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.
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.
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.
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."?
>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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> “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.
"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."
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.
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.
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.
>As a user of something open source you are not thereby entitled to anything at all.
If I don't have the right to fork off, then it wouldn't be open source at all. And that might seem like a small thing, but it is a lot more than I get from e.g MS. Otherwise I would still be running WinXP.
> “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.
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.
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.
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.
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...
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.
156 comments
[ 2.4 ms ] story [ 224 ms ] threadNot 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.
(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)
But I'd make an effort to avoid any software that whines about "SJW's"
"Any suggestions are welcome, but I won't promise I'll implement them :-)" -- Linus Benedict Torvalds 25 Aug 1991
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?
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.
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?
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.
I haven't been paying attention but it looks like it was followed up with Reiser4 and Reiser5?
https://en.wikipedia.org/wiki/Reiser4
https://www.phoronix.com/scan.php?page=news_item&px=Reiser5-...
Reiser5 surprises me though. I didn't expect it to be that uncontroversial. Guess CW topics have skewed my perception.
People mostly get cancelled by committing the latest heresy.
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).
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.......
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.)
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.
One thing that worked pretty well for me was to move to Gitlab. Very few people currently bother to create an account on another website to report an issue, and as a result the quality of feedback and reporting has always been very high. Gitlab has also less gamification, which helps in keeping project popularity from skyrocketing just due to stars and network effects instead of actual project merits.
I initially moved a single project when GH was acquired by Microsoft. GH/GL are totally equivalent for me, but due to this I ended up moving all my public projects and never looked back.
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.
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.
"X is broken" is about the worst JIRA ticket you can ever get :/.
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 :).
Haha, seriously. As I was reading this article I was thinking to myself "well shit, at least people are bitching about this guy's projects; that means people are actually using 'em".
Not that I'm complaining, of course. I'm quite content in my obscurity :)
> He's always thankful for the reports, but he usually apologizes (!), which makes me worry I'm just creating all this work for him
The maintainer appears to be Japanese. I suspect this is just a cultural thing surrounding apologies you're reading too much into.
But now I have some money. I am not mega rich but it is time to give back, if not in time then in $.
I have very little open source experience, but I am thinking of the experience of support engineer sending requests to development. If you hit them with too much too fast, you will tend to provoke worries or exhaustion.
That being said, making 3 issue reports when the repo had only 1 besides that doesn't seem like a problem. Developers do like to feel like their work is getting some attention.
So, this is probably a cultural issue.
Have you tried heading this off by apologizing first, in the report? Alternately, being thankful in the report may work out better. Or you can try both.
Note that mirroring like this can come across as sarcasm or ridicule if you recycle their exact phrasing or exaggerate it, so don't do that.
- The unforgeable "WHERE HAVE YOU BEEN ALL MY LIFE" 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 - 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
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.
Did you ever get a Mac? I see from the page that it's now in Homebrew.
Holy shit, this is awesome. Thanks for sharing!
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.
(It often doesn’t work for either.)
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 ;)
I suspect your misunderstanding there is some misplaced assumption that "developers" are some sort of tribe who respect and look out for each other.
It's easy to exist in a small "developer tribe" bubble where that's true, but there's a universe full of "unpassionate devs" just scrabbling to get project managers or bosses off their backs, and who'll cut-n-paste from StackOverflow answers and harass open source maintainers just to get their next Jira ticket completed before whatever arbitrary time estimate/deadline has been imposed on them.
Granted years ago I once worked at a call center and a coworker, just after complaining that they just got yelled at by customer for something they didn't do and couldn't change, placed a personal call to a local pizza place, and did the same thing to them.
Bummer to see.
I'm not always sure I wouldn't rather be the second kind...
No problem, there are other software projects that achieve similar goals to this one such as $ExpensiveOption from Microsoft or $outrageousLicenceClauses from Oracle - perhaps their support services are more in line with your company's expectations? Good luck, have a nice day...
Ideally the complainer will see how positive the developer is being and reflect on their own attitude, but even if they don't, it gives a good image to other people who read the messages and sets expectations for how people should behave, so that a project doesn't devolve into toxicity.
Sarcasm is easy to disguise in pure text communication.
Back in the day when I spent as much time on comp.lang.perl.misc and scarydevilmonastery as I do in HN these days, that sentiment was less ambiguously delivered as "HTH, HAND, FOAD"
My response was "So if I follow your demands you'll stick around and maybe demand more, of I tell you to get stuffed you'll go away and bother someone else? In that case: feel free to get stuffed."
Some just went away, I got one "I'll make it so you'll never work in the industry again!", and one started to beg profusely that I implement what he wanted because he would lose his job without it (not sure how that worked, I assume completely made up, didn't care either way).
Of course that was long before current social media outlets made it relatively easy to create a made up shit-storm, I might be a bit more diplomatic (but no less definite) in the same position these days.
Most of the time is not on purpose. Thinking how something should work (or using it once done) is way easier than doing it(hundreds or thousand times easier actually), so the only person that really knows how much effort something takes is the person doing it.
Because they don't know how much something takes, they don't value it. Specially if it is given for free.
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?
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.
Thanks for the hard work boys and girls! You set an example of how the world should work.
Thanks!
Thanks!
Thanks!
Also, there should be more ways to "praise" a project.
What would you change to make that happen?
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.
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.
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.
It doesn't apply to everyone but I can see how to some people this would be really problematic.
For every company which does that, there's another whole bunch of companies who would rather prefer you not have a GH account.
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."?
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.
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.
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.
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.
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.
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.
release is the exciting moment "it's when it should work for you" :)
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.
"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/1563cddea1002958f96e7ba95...
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.
In that sense, I advocate documenting your response policy on the top of your README.
If I don't have the right to fork off, then it wouldn't be open source at all. And that might seem like a small thing, but it is a lot more than I get from e.g MS. Otherwise I would still be running WinXP.
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.
Why are your errors useless?
Or sometimes it's just more practical to have that information given to you than spend hours REing it.
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...
Seems straightforward for a lot of what this post is about.