18 ms·

Fix it, Fork it, Fuck off (2019)

421 points by ran5kpd 4y ago

xPaw 4y ago
> Heck even a tweet at the owner might be good enough. I disagree with this, don't spam people. Sometimes people even go out of their way to contact you using multiple channels and it gets even more annoying.
- red_trumpet 4y ago
  Later on, the article contains > There is no need to abuse the maintainer, repeatedly post the bug, harass them over twitter. So I think the sentence you quote is meant as a first approach.
- tracker1 4y ago
  Kind of depends... I'm listening to so many github repos that I often don't pay enough attention to the notices or even keep up regularly... if it's important/urgent, I'd almost preferred that they reach out via side channel. It's a rare case for me at least. I know it can be annoying if there's too much of it, or there's too many vectors or if you or the repo are popular. I'm not.
have_faith 4y ago
> Always remember you are talking to a real human being Too easily forgotten these days it seems.
- nailer 4y ago
  I made the mistake of making the Python module that handles Microsoft Word files (python-docx) about a decade ago. Despite including a bunch of examples for making, reading, and modifying documents, right in the README, I received a bunch of emails from India demanding I help them. I eventually passed the project onto someone else (not entirely because of this, I also started more involved with node at the time, but this was definitely part of it).
  - Topolomancer 4y ago
    I think I know the type of interactions you mean, and I wonder whether it's a cultural thing or a language issue of which I am not aware: I have received a bunch of e-mails from strangers telling me something along the lines of "I request you to do X", where X is something related to a project of mine. I always tried to see this as a sample of "inexperienced person not expressing themselves politely." It's the most charitable explanation, but maybe someone else with more knowledge about the cultural differences can comment on this?
  - jillesvangurp 4y ago
    Some people are just completely shameless about demanding that somebody else fixes their problems for free. I maintain a few small OSS projects and most of the interactions I have with people are pretty pleasant and respectful. However, my inbox is a dumpster fire of recruiter spam (both trying to recruit and offering their services to me), and incompetent idiots trying to sell me whatever. And indeed the occasional support request. It's infrequent enough that I usually reply if people are articulate and coherent enough (which is a problem with some of this). Otherwise, I have a pretty simple strategy for all this: I don't dignify people with a response unless I understand what they want and it adds value for me. Simply, not worth my time and energy. Repeat offenders get blocked and marked as spam. There's no point in me getting upset or angry about any of this. Just the price of doing business these days. In the same way I ignore the dozens of attempts at connect attempts on linkedin. If I don't know who you are and you don't have a coherent reason as to why we should connect, I'm going to ignore you. Buzzword compatibility doesn't count.
rblion 4y ago
A good philosophy for a happy life to be honest.
- blueflow 4y ago
  The secret ingredient is in "fuck off" - not caring. If you don't bother with the bad things in life you can focus on the good things better.
implements 4y ago
Fix it, Fork it, Fuck it! scans better. (“Fuck it!” is “I give up!” in British English)
- dorkwood 4y ago
  I politely disagree. I'm sure you can figure out how this reads for anyone who isn't British.
  - nsteel 4y ago
    I (British person) agree with you. "Fuck it" is better. Especially considering "Fork it" could already be considered ambiguous: https://www.urbandictionary.com/define.php?term=fork%20it https://www.urbandictionary.com/define.php?term=fork%20it
    - remram 4y ago
      > I agree with you. "Fuck it" is better. Which is it? You replied to somebody who said it wasn't better.
      - nsteel 4y ago
        Sorry, messed this up. Ironically in an edit to make it clearer. I meant to say that "fuck off" is better than "fuck it".
  - laumars 4y ago
    I’m British and I still think the original title reads better. “Fuck it” is ambiguous without context. “Fuck off” isn’t.
- mnd999 4y ago
  Yes, but everyone else in the world is going to need a new liquid ingress sticker for their laptop.
- RF_Savage 4y ago
  Find it, Fuck it, Forget it. Who knew KMFDM lyrics could also be applied to OSS development? https://youtu.be/PhS_t0sou_4 https://youtu.be/PhS_t0sou_4
chrisseaton 4y ago
What are the other requests that the author receives? This list seems to still include every option of interaction over an issue as being acceptable, so I’m not sure what behaviour they’re tying to discourage?
- ndhlms 4y ago
  Basically the assumption that by sharing your work, you become inherently beholden to the wishes of those that use your work. Some time over the last ten years or so, much of the open source community acquired the belief that they deserve to be treated as a customers despite the fact they don't pay for squat.
  - chrisseaton 4y ago
    What were people doing based on that assumption? The article says contacting the author to ask for a fix over bug trackers, Twitter, etc is still ok in their mind. What else were people doing?
    - ndhlms 4y ago
      "Ask for a fix" is euphemism what often happens. It's commonplace to receive reports to the tune of: * "Can we get an ETA on this? Some of us need to get real work done" * "How you can justify leaving out such a basic feature?" * "This project is unusable without this feature" * "Why waste people's time by releasing software with bugs like this" * "This kind of mistake is totally unprofessional" * "The developers must not have the skill to fix this" These sorts of interactions can be more exhausting than outright abuse, because they're designed to bait/provoke the developer rather than just insult them. And to be clear, this isn't particular to this developer. There was a whole study done on this that made the rounds awhile back[1]. [1]: https://www.cs.cmu.edu/afs/cs.cmu.edu/Web/People/ckaestne/pdf/icse22_toxicity.pdf https://www.cs.cmu.edu/afs/cs.cmu.edu/Web/People/ckaestne/pd...
- Aeolun 4y ago
  I assume some of the people do not understand either of these steps, and just keep pestering the author after they say no.
invalidname 4y ago
As an OSS maintainer for a large project I disagree. Sometimes people did fuck off and it didn't do the project any favors. I needed people to communicate clearly and with volume why I should change some opinions. Ultimately, my mistakes led to a competitor that was indeed unsuccessful but sucked a lot of the mindshare so we both got screwed. We're smart people but we all need to learn humility occasionally. I do agree we need manners but I don't agree that people should just fuck off. I want complaints. That's how I can gauge improvement. A culture of ignoring complaints is bad. I know that is not what the article is about exactly, but it's where these things lead.
- Timshel 4y ago
  Nowhere it said you can't argue for your fix/change in an open issue. Just that once the maintainer close the issue: `So should you get angry and start abusing them? No.` Edit: And nowhere it makes any comments on how much/little the maintainer should listen to issues just that once he closed it you need to respect it and move on.
  - invalidname 4y ago
    I had that. It was unpleasant (to say the least) but on a different situation I rejected a direction. User went elsewhere and we all ended up losing. I disagree with the attitude expressed there. Don't like it. Build your own. Every maintainer has his style, I don't think that's a constructive style and as a maintainer I never use that style. I might disagree with someone, I will never say fuck off. Even if I think someone should fork, I will offer help with the fork, at least in advice. Writing the code isn't where it ends. I thank every user who uses my code. Otherwise it's just another code dump. The users are what makes the work worthwhile. To me.
    - deleted 4y ago
      [deleted]
- Barrin92 4y ago
  the list of abandoned open source projects because the maintainers burned out is I think a lot longer than the list of projects that ended because low quality complaints were ignored. Literally go through GitHub and look how few people contribute the source code to even large projects. If they lose it, it often does significant damage to a project because original creators are important. In a sense being rude is being humble. If I'm rude to bad complaints it's because I'm realistic about my limited capacity to deal with stuff. It's ironically often generous people who end up resenting what they're working on.
systemvoltage 4y ago
It reads Fix it (or Pay for it), Fork it (or Pay for it), Fuck off (Free). I am glad we're realizing that paying for something is a good thing. Rarity in today's entitled attitudes people have for free things.
bakugo 4y ago
> If your project becomes better it will naturally gain more attention and be more inclusive Unfortunately, things don't really work this way. Maybe for niche software with a handful of users, but once a piece of software has gained enough traction it can be very hard to convince users to switch to a fork, it's not enough to just "be better". This post sounds like it was written more out of spite than anything else.
- seqizz 4y ago
  Might be out of spite. But I wouldn't dismiss the idea. This sounds like redirected to the people who wants a certain thing in the app, and non-stop complaining after a WONTFIX under all slightly related tickets. Rights of the owner has to be respected, even if they're wrong in the eyes of users.
bluenose69 4y ago
This is sensible advice. But I'd add an "R" as a separate and important item: report it. In your report, provide a clear explanation of why you think this is a bug, perhaps speculate on ways to fix it, and perhaps volunteer to help, in a way decided upon by the author. "Cold-call" patches and pull requests can be quite disruptive to an author who might be busy with other parts of the code, or (quite likely) with this part. They may be fine for trivial bugs with simple solutions, because the author can then tell at a glance whether they are going to cause problematic ripple effects. But for more trickier bugs with complex solutions, stitching in a patch/PR can be quite a hassle for the author. This is especially so if the new code is formatted differently than the old code, or uses a different "style" with respect to variable naming, etc. Start by reporting the bug clearly and respectfully. Let the author know, if you see the solution. Perhaps they will ask for a patch or PR. Or perhaps they will say they need a few days to look at it. Either way, start with a conversation.
- chrisseaton 4y ago
  That’s what the article already says is the first option - ‘Raise the issue in the bug/request tracker of choice.’
- TazeTSchnitzel 4y ago
  Also, if you're putting a lot of work into a pull request and it's important to you that it get merged, knowing whether you don't have a good chance of success, in advance, is going to save you and the maintainer potential sadness about your wasted effort.
nextlevelwizard 4y ago
My experience with open source is that I find an issue, I fix it, and submit a fix, but the fix isn't good enough and the maintainers ask me to write it better, but at that point I am no longer interested since I already fixed my issue. It is not like I'm going to start maintaining a fork over it. I am just not going to update the software or I'm just going to keep my patch in.
- dschuetz 4y ago
  If it's "not good enough" then it's the maintainers problem. I mean, come on, somebody fixed it for you and when you as the maintainer complain about the quality of the fix then the FFF rule applies also! I also have nothing against occasional little personal forks, but methinks that keeping track of the issues upon each update could be painful.
  - ElCheapo 4y ago
    Imagine you ran a personal twitter account where you posted your jokes but allowed people to send theirs via email and occasionally publish them. Would you find inappropriate to tell people "yeah this joke almost kinda works but it's not funny enough for my account maybe send me a better version"?
    - ZeroGravitas 4y ago
      It also puts you in that weird area, where if you take the half-finished joke and polish it, then you're stealing and/or ruining their idea. Meanwhile, if you were looking for a long-term joke-writing collaborator, then you want to encourage even the people with enthusiasm but sub-par jokes to try harder in the hope they grow into the role.
      - ElCheapo 4y ago
        The code maintainer (or owner) makes the code available to the world without asking for anything in return, but if you send him a patch he is somehow obligated to implement it? (I'm not saying this is what you're implying) Open Source goes both ways: nobody forces you to use some rando's code off of github but also nobody forces said rando to to use some rando^2's patch for his own code
tamsaraas 4y ago
Another example: You contribute for 10 years for opensource project. Familiar with code, all of you fixed dozens of bugs. Community grows, opened issues - shrinks. Dynamic to close all major problems very soon. And when you feel absolutely the safe, some motherfucker comes to a place, and offer: "Guys guys, let's switch our codebase from C to C++, because there are easier to work with strings, easier to work with pointers, easier to work with everything". And big community without listening anyone by decision of 2 guys from community of 100 devs - moving code base from C to C++. All that they doing - changing extension for files, and adding `extern C {` to files. Since that amount of bugs - increased dramatically. Instead of fixing problems, there comes another dev and saying: "guys guys, lib-json too old, let's switch to modern and nice YAML". Yea, does not need to care, that we already have GUI for working easily with ANY data in the repo, all perfectly tuned, and everyone used too. and boom - devs decide to switch to this bullshit. 5 years pass since these changes (since switching to CPP) What do we have now? Community big slice of the communiy leaves from the scene. Because this is impossible to maintain such mess Another slice of community which is left - stay on codebase from 2017 without these changes. Project semi dead, impossible to revive it. Why all of that happened? Because of idiots who have permission to apply final decissions to repo. Repo of community driven project. Where all things done by a community, but merged by owner of the repo. The project do not belong to the owner of the repo, the project belongs to community, the owner just in 2011 made a switch from SVN to github, and uploaded data there. Sometimes - douche-bags = owners of open source repos. And as a guy who contributed to dozens of such projects, this is not "sometimes". This is - usually thing when guys on what rely community project - let the project die by doing nothing or doing wrong actions.
- turtleyacht 4y ago
  > the project belongs to community I'm sorry to hear about your experiences. It sounds painful to see project(s) pivot like that, especially since you contributed so much to them. What do you do now when you consider contributing to open-source projects? What guidelines do you use to evaluate the maintainer's "ability to keep things on an even keel?"
LtWorf 4y ago
> There is no need to abuse the maintainer, repeatedly post the bug, harass them over twitter. I see. The mistake was letting people know your twitter account.
- ndhlms 4y ago
  Or using the same the account name on multiple sites, u/LtWorf ;)
  - LtWorf 4y ago
    I never said I don't make mistakes!
brunooliv 4y ago
To be honest, I think the real issue with OSS is the whole masquerading of acting like a corporate project and almost red tape attitude that some maintainers have that can block a PR for weeks or months. Unless you are a very important client who is paying money to the maintainers or unless the project is OSS but let's say, backed by/open sourced by a company like Google (as in, not some unknown person who kind of answers to no one) the chances of meaningful contributions landing are effectively zero. If you are a client of a given library working for "Unknown company 8965688" and you are using a library and make a PR with a change you need or request it, in my experience, you'll simply be ignored. Then comes the original post: we'll fork the library to an internal repository, make it our own, and stop depending on the whims of the maintainers who care absolutely nothing for the people who request features precisely _because they are actively using the library_ and need an improvement. OSS has become a really, really bad place to be when it comes to actively depend on something that is managed by someone who simply doesn't care about you in the slightest. Then, as we have people competent enough in the technology, forking becomes the natural thing to do.
- andrepd 4y ago
  Why do maintainers owe you support? I assume by your comment that you're a company, in that case, since you're making money off the value added by that OSS project, financially support the developers to get support in return. Then you can act entitled :)
  - alias_neo 4y ago
    I often have to use open source projects in my work (Backend Software Engineer), there are projects that are popular, many of them backed by companies themselves and there are small one-person projects. As an engineer/developer, you may have an issue with one of these libraries, tools, etc and you'll put in a ticket with all of the details your development expertise can coax out; sometimes you'll get responses of thanks for a clear report, sometimes you'll be ignored, and other times they'll disagree or be unwilling, and now you're stuck. You'll go to management and ask if they'll pay said company/developer to fix it and they might, or they might not. You either look for an alternative, write something yourself, or you fork it internally, fix the issue and move on; now you and your peers have another piece of code to maintain because nobody on either side of you would budge. I've never been abusive to an OSS developer, I've certainly been frustrated, and I'm an FLOSS advocate myself. Some projects I've worked with, and I won't name names, have turned around fixes in literally an hour, are greatful for a good thorough report and want their software to work for you (and I'm talking large internationally used enterprise grade tools), and others will just be rude or dismissive, but you still have to solve that problem, it's your job. When I have a job to do I'll just move on from projects that make it harder, and I'll advocate harder for the projects that make it easier, if it's small and generally unmaintained, we'll just fork internally, improve 8t all we want and move on, now nobody in the wider community benefits. There are other projects that are larger, and we pay them decent recurring sums to be able to ask for a fix or feature to be turned around quick, and it'll end up in their open source code, so everyone benefits from that money this company spent. When you're a small start-up developer you have far fewer options available to you compared to a large company who can or will throw money at people inside and out to get things done.
ducktective 4y ago
The actual reason of this friction is that essentially, FOSS developers are working for free. FOSS devs and maintainers don't have _any_ monetary incentives to continue working on a project unless it helps them getting their desired job. Yeah, you may say some devs have so much passion about their software that they are willing to donate their time for free. But the interest may dwindle after a couple of months and years and that's when the whole thing becomes somehow a burden. It may not even come down to that. One bad morning + constant pings of "any updates yet" by an entitled user may trip the dev off for good.
frou_dh 4y ago
elihu 4y ago
I think there's another side to this, which is that if you're the maintainer of some open-source project and you actually want your software to be successful and widely used and generally to make the world a better place, you're going to need to maintain a good relationship with your users. When people report a bug, that's actually valuable. They're telling you something for free that you would otherwise have had to devote time and effort on validation / quality assurance to find. If someone requests a feature, that's telling you something about what users want (even if you might have perfectly valid reasons to decline the request). For every random email you get, there's probably a hundred more people thinking the same thing but didn't write the email. I think if I were to contact a maintainer of some project and they sent me to this page, my thought would be: "oh, I guess this project is just a hobby project someone uploaded to github for posterity and they're not actually interested in maintaining it." That's okay! Not everyone has time for that.
- detaro 4y ago
  The first paragraph is important: > I quite often get bug fixes, patches, requests and questions regarding the things I have published. Most of the feedback is respectful and helpful. However occasionally there are other requests. This page is where I plan to redirect them as a final warning before I block and ignore them.
  - veltas 4y ago
    I will say that in my own experience with online diplomacy, you should just block and ignore them before sending them something that in context is telling them to "fuck off". As soon as you engage with language like that the civility is already over and not worth talking. Honestly, the title is catchy, but this article is not phrased diplomatically enough to send to a difficult person.
    - imtringued 4y ago
      When a reckless driver is on the road, the worst thing you can do is retaliate and aggravate the reckless driver. No, you should just let the lunatic drive by and hope he forgets you were even on the road.
dschuetz 4y ago
I see it as an attempt to bring a perpetual and painful discussion to an end. I agree, would like to add that: The FFF rule also applies to submission of fixes to maintainers. If it fixes a problem, but not the way you like it to, you can go and FFF.
Andrew_nenakhov 4y ago
Very much this. The most unpleasant part of running an open source project is feedback from some toxic users. Many of them behave as if you work for them, and demand all kinds of privileges, or else they'll give you 1 star rating on Google play!
- avg_dev 4y ago
  Daniel Stenberg, the lead maintainer of cURL, has some interesting tweets about this topic. In fact several of the toxic comments he posts are from people who seem to lack a basic understanding of what the project even provides. https://twitter.com/bagder/status/1561459354431275009 https://twitter.com/bagder/status/1561459354431275009 https://twitter.com/bagder/status/1535188747427405824 https://twitter.com/bagder/status/1535188747427405824 Just to provide some counterbalance there's also this: https://twitter.com/bagder/status/1552414274101940225 https://twitter.com/bagder/status/1552414274101940225 He has an interesting guide on his thoughts on maintaining open-source as well. Here's the People section: https://un.curl.dev/people https://un.curl.dev/people
pdpi 4y ago
There's (at least) four Fs, and the first in the list should be "File it". Not every open source user is a developer who can Fix it or Fork it, but a well-written bug report (and other forms of high-quality feedback) is a godsend. Even as a developer, everybody benefits if I file a bug and then spend my energy on my own open-source work rather than spending that same amount of time trying to learn the codebase of every piece of software I use.
- obert 4y ago
  Add “Find it”, eg try debugging and provide some starting points about where/what the root cause might be
- sixhobbits 4y ago
  That's literally the first sentence of TFA > your first option is to make a request to fix it. Raise the issue in the bug/request tracker of choice.
  - pindab0ter 4y ago
    I'm sorry, what's "TFA"?
    - Doctor_Fegg 4y ago
      The Fabulous Article
    - tdrgabi 4y ago
      The fine article
    - dmolony 4y ago
      Presumably 'The Fucking Article'
    - tpoacher 4y ago
      The Fantastic Article
- 4y ago
stupidcar 4y ago
I agree with the article in general, but the wrinkle comes when you encounter a bug in a large, popular open source project (naming no names, but any of the major web frameworks for example) that you're using for a work project. Fix it? Sure, except despite their ostensibly open nature, many of these projects are run as internal projects of large tech corps, and the bandwidth and interest of the team in reviewing and merging external PRs is limited to nonexistent. I've submitted small, obvious bug fixes, complete with test coverage, to projects and had them sit unreviewed for years. Fork it? Well there is a big, big difference between spending an hour fixing a bug and submitting a PR, and forking a large and complex dependency. You're committing yourself and your team and employer to the ongoing maintenance of the fork and merging of upstream changes, just so you can merge a bug fix. Usually, that's just not practical. Fuck off? Many third-party dependencies in mature projects are non-negotiable. Removing them would require a complete rewrite. You may not even have been the person who chose them, but you're stuck with them, and then your boss asks you to implement a feature or fix something that relies on a change or fix in a dependency. Being blocked due to upstream intransigence is very frustrating, and there is often a professional cost to saying "no" to a request, especially a bug fix, no matter how convincing you argue that it's not your fault or under your control.
- account42 4y ago
  If you are relying on unpaid open source code for commercial work, you should fully understand what that means for you: > This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. (from the zlib license, but others have similar disclaimers) If that is a problem for you, negotiate a different contract up front - with the maintainer or someone else willing to do the work. That probably means paying them. If you don't then no, the maintainer is not required to invest the time and money you are unwilling to into maintaining your pet feature or "fix".
  - danwee 4y ago
    You are right, but in practice that's not what happens. Companies do not rely on open source libraries, the developers working for such companies do. I can give you a realistic example. If you want to use Kafka and Go, your probably only option is to use https://github.com/confluentinc/confluent-kafka-go https://github.com/confluentinc/confluent-kafka-go. Its LICENSE explicitly says "no warranty". Now, what if I find a bug in the library? Only two realistic solutions from my side: 1. I submit the issue and hope for the maintainers to fix it 2. I dig deeper and try to fix the issue. I submit the PR None of the above scenarios are guaranteed to have a happy ending. The issue could be ignored, or piled up among thousand of other (maybe higher prio) issues. My solution may not be optimal and could be rejected (or if it's optimal, nobody is taking a look at it, and it could remain open for weeks/months). > If that is a problem for you, negotiate a different contract up front - with the maintainer or someone else willing to do the work. That probably means paying them. In the real world that would mean that I go to my manager and asks them to pay money to the maintainers of confluent-kafka-go to fix the issue I found. I don't think my manager would approve that, but let's imagine he does. The guys at confluent-kafka-go may not want money to fix the issue. These guys have probably already jobs that pay them well, and they work on the library at will. Note: I'm talking about confluent-kafka-go, which I know is behind the Confluent software company. But I could as well be talking about libraries maintained by individuals like https://github.com/edenhill/librdkafka https://github.com/edenhill/librdkafka
isitmadeofglass 4y ago
Would have been better worded as fix it, fork it, forget about it.
oezi 4y ago
If Github would highlight popular forks better that would be a tremendous help. It currently is annoying to uncover if there are any relevant forks and what they contain.
- tracker1 4y ago
  It will vary... there's times I've created the PR myself, but cannot wait for the patch to make it in... so I'll reference my fork to start with, then go back and re-reference to upstream and delete my downstream once it's accepted. I usually discover existing forks when looking for a bug/issue fix and see there's already a PR, that may have been sitting for a while, or rejected but the issue remains. Sometimes that means creating my own fork of the downstream for ongoing use. YMMV, I usually do try to update the README to indicate it's a fork for personal use until upstream approves/integrates.
  - oezi 4y ago
    I think single issue forks should be presented in the Fork overview in a special way (for instance with the linked issue), but I was mostly talking about actively developed forks which are hundreds of commits further than the original project/upstream. Github should be doing more to advertise these for instance by showing the top 5 forks in terms of activity. Also too many forks are just user interface mistakes where somebody wants to look at the lists of forks but accidentally forks the projects by clicking on the Fork counter in the top right corner rather than the Fork counter in the "About" box of the project.
avg_dev 4y ago
A fine article. > There is no need to abuse the maintainer, repeatedly post the bug, harass them over twitter. All this results in is people wanting to not contribute their time and expertise for free. > [...] > Always remember you are talking to a real human being, and just because their ideas of how to implement a project are not in line with your own does not mean you have any right to abuse them. I do not believe there is ever anything that gives one person the right to abuse another. > https://en.wikipedia.org/wiki/List_of_software_forks https://en.wikipedia.org/wiki/List_of_software_forks An excellent list! The once dominant Apache httpd is a fork. Never knew it. Postgres is a fork! Never knew it. Microsoft SQL Server is a fork! OpenSSH is a fork. The list goes on. I am sure that Wikipedia page, like many I have seen on code/tech, is under-maintained. I bet the reality of forking is much more extensive. Finally, the title of the article makes me laugh. I knew it was gonna be good before I started.
musically_ut 4y ago
The post resonates with me as an OSS user and a contributor. Many a brave souls have taken to forking the project to fix the bugs but those forked projects almost always suffer from a discoverability problem. I have tried making fixes and tried forking projects only to discover that someone else has done it better elsewhere. I've been burned by this problem often enough that I wrote a Chrome extension which would _tell_ me if there are any notable forks of the project I'm currently looking at on GitHub: https://github.com/musically-ut/lovely-forks https://github.com/musically-ut/lovely-forks </self-plug>.
oh_my_goodness 4y ago
Here's a modest proposal. Your employer can no longer pay you, but they have a big code base that you wrote. You are now obligated to maintain that code for free. Think it through. How else can your employer get what they need? You might say that they should pay consulting rates, or that you're busy with your new job. But how is that your former employer's problem? They used your code in good faith, they ran out of money, and they were forced to lay you off. None of this is under their control. *** IRONY NOTICE: THIS COMMENT CONTAINS IRONY ***
oxplot 4y ago
Disclaimer: I write open source software and I use open source software. It's a non-useful and self-damaging trait that most people seem to have: yell at others to try to make them behave in a certain way where they can instead take actions on their own to ignore/avoid those behaviors. This shows up all the time at work where people complain that they are getting too many slack messages or emails. You are not some hopeless caveman who has no idea what a computer is. Set up a filter and send everything you don't like to trash. Silence your notification. Mute/leave channels. Oh right, you are also a software developer. Write code to automate the above. > There is no need to abuse the maintainer, repeatedly post the bug, harass them over twitter. Block the user on GH/Twitter! Lock the conversation. Write a script to do the blocking for you automatically (Twitter and Github both have APIs for that - that should be a hint that this is an intended use case!). If you have already identified someone as an abuser, any response, negative, positive, dismissive or otherwise, is only going to encourage the behavior - that is a well studied pattern. Writing a post and having it end up on HN does the exact opposite of what you hope it would. Someone reading your post is going to specifically go out of his/her way to fuck with you. Instead, just ignore.
viridian 4y ago
Viscerally understand the sentiment as someone who handles vague technical feedback here and there, but I've also seen this attitude kill off project enthusiasm almost completely, specifically with D&D/pathfinder character sheet manager PCGen: https://en.wikipedia.org/wiki/PCGen https://en.wikipedia.org/wiki/PCGen In an era before github issues, the project got a lot of requests via the Yahoo groups mailing list that were often of suspect quality, but usually addressing a real flaw with the software. At some point near the end of the mailing group's life cycle, the most active maintainers really took a shift in the angry direction, and I think that led to a lot of people on Reddit, rpg.net, giantitp, etc no longer recommending it. This might not seem like a problem, but over a long enough long frame, low user interest for a formerly popular piece of software does seem to inevitably lead to a loss of maintainers.
hk__2 4y ago
(2019)
jarek83 4y ago
I must admit that I used to be a harassing parasite. Then I realized how foolish I was being this way. I changed into just a parasite, but I feel urge to contribute and sometimes I do. I also learned that those who harass, will learn one day the same lesson as I did, so I don't bother too much with them.
pacifika 4y ago
Swearing in the same paragraph as talking about respect. That detracts from the article
tpoacher 4y ago
The author of this post conveniently neglects the fact that the third F also has a payment option: Pay someone to bug/sue/harrass the developer on your behalf until they succumb to preserve their sanity. Out of all the payment options, this is likely to be the cheapest and most effective. Be careful what you wish for.
andix 4y ago
It’s also okay to just report a bug. But don’t expect it to be fixed by the community.
kweingar 4y ago
I know this isn’t a one-to-one comparison, but there’s an interesting discrepancy in how HN views free-to-use products. In this situation, there is a prevailing attitude of “You are not paying for this, so you are not entitled to fixes or support. Any suggestion otherwise is entitlement on your part. I don’t care that you’ve grown to rely on this service. Pay me or figure it out yourself.” When it came to Gitlab considering deleting old free-tier repos, however, people were incensed and insisted that there is an obligation to continue providing free service for users. Similarly, with Gmail and YouTube, people often invoke the argument of “this is people’s lives and livelihoods, so of course there is an obligation to provide fixes and support.” So is the difference here that one endeavor is done for profit and the other isn’t? If an open source project becomes profitable for the maintainers, do they now have a obligation to fix and support their software?
- samsquire 4y ago
  You're uncovering this visceral reaction to paying for things people use or want and expecting people to do things on their behalf that only benefit them. Also the free rider problem. Also examples of the 1% rule and Pareto principle where most value must be produced by a very small number of people and used by lots of people. https://en.m.wikipedia.org/wiki/1%25_rule https://en.m.wikipedia.org/wiki/1%25_rule
- naasking 4y ago
  > So is the difference here that one endeavor is done for profit and the other isn’t? If an open source project becomes profitable for the maintainers, do they now have a obligation to fix and support their software? Yes, doesn't that seems reasonable? Presumably Gitlab became as popular as it did only because they offered free-tier repos, and generated revenue another way. YouTube only became popular because they offered free content and generated revenue another way, and so on. Suppose you managed to start a company with a couple of loyal customers, and then as you grow bigger you ignore those loyal customers' needs in deference to newer customers that pay more. Maybe it's "good business" to pursue more profit, but kind of shitty to spit in your original customers' faces no?
  - 4y ago
geenew 4y ago
Politeness is free. 'Fuck off' is unnecessary, just drop it and say there are only two F's. Users shouldn't be jerks, neither should maintainers.
williamtrask 4y ago
There should be a fourth option, “Fund it”
qwerty456127 4y ago
"Fork it" means a whole lot of additional problems: backport fixes from new upstream versions, build packages for your distro, maintain your repos etc.
keybored 4y ago
> If you find a bug, notice missing, incorrect or misleading documentation, or want an enhancement, your first option is to make a request to fix it. So then the first step is Forward issue. Not Fix it.
darepublic 4y ago
I can't argue with the basic argument of OP but if the project is still active but in the wrong ways (adding new features, add hype, etc) and still not fixing recurring issues then I have to put some blame on the maintainers in how they wish to spend their time. They are busy doing work to get their dep in the codebase you have to work on, but not enough time making it work well in said codebase. And as others have pointed out you often do not have a choice about these matters when not in ownership of the project. Of course none of this is an excuse for any kind of harassment. But public criticism of the library? Sure.
sylware 4y ago
The devil hides in the details: it is all about how much "critical" the set of components is, and what is the core of the pb being reported. Because, as my experience goes, often the pb lies with the "dev" of the set of components itself, not the issue reporters. Software (open source or not) is plagued with planned obsolescence and software Rube Goldberg machines, and on components where it is accute, there is no reasoning of anybody, the "dev" is a scammer, not to mention the "dev" is often a corpo or an organized network of ppl (pulling the strings in the shadows). On critical, big and/or complex sets of components, and those would be well established ("financing" is kind of "secured", and those components are used a lot), the "dev" knows that hardly nobody will be able to provide real-life alternatives, then "dev" may give you a bit of attention but will send you to hell if you start to threaten their scam (namely the "financing" of their network of ppl). Usually, you will get partially true responses missing out the "disturbing" parts, all that with a ton of "mauvaise foi", like a troll. Fighting this can only by done on case by case basis since we are talking about complex component systems. Not to mention, mistakes can happen because it is easy to be fooled in complex matters. Sometimes, you may have to "follow the money" and go legal.
birdmanjeremy 4y ago
So if I find a WebKit bug in the latest iOS beta, file it with both Apple and WebKit, and get ignored, I should just fuck off? I can't fork it (Apple won't use my fork) and it's unlikely my fix would be complete and accepted for upcoming releases, so I guess you're right. "Fuck off" and let iOS devices crash is my only option. This is purely hypothetical (e_e)
dmz73 4y ago
I don't understand why open source developers think they are owed anything by anyone. They chose to work for free and give away that work. In the process they killed any proprietary competition and therefore a chance for anyone to get paid for the equivalent work. Now there are users who demand that these developers fix the bugs they introduced during development or add missing features, and rightly so, since there is no other choice. Users cannot just hire someone to do the work since that is going to be too expensive, more expensive than if they asked proprietary developers to fix the same issues since proprietary developers work would have been paid by many users. Should open source developers be forced to work for free? On the one hand the answer seems to be obviously no. On the other hand, these developers killed all the competition that could have provided cheaper development alternatives for the user so maybe they do owe some free work to these users. Compare this to other professions, electrician can install the wiring for free but they are still liable for any work they do that is not compliant with the relevant standards. They don't have to install more wiring for free but they have to fix any mistakes they made. Software development is still a wild West of professions and it is in dire need of regulation. Then if it costs too much to work for free and release certified code, developers won't do it and users will pay to get a quality product.
pookha 4y ago
Great article. That final F sentiment is EXACTLY what the open source world needs. There's too many free loaders and mega-corp vampires taking advantage of peoples' free time. Some of this is beginning to feel slave-like. Billions in profits and vast fortunes are all on the backs of unpaid maintainers (slaves) toiling nights and weekends (cheap labor). And I'm just as much of the problem...Not giving back (financially or in other ways) makes you a douchebag and most of us are in that boat.
cranky908canuck 4y ago
The only problem I see with the original post is a matter of diplomacy. As the saying goes, the trick is to tell someone to go to hell in a way that makes them eagerly anticipate the vacation. (Or using the original post's terminology, they're eagerly up for it...). I would have expected that the discussion here should be taking that as a given. No paying business is required to take on all suggestions from all customers [1] [2], why would anyone be expected to do that for free? [1] Paying businesses have whole departments dedicated to translating "tell them to go f--k themselves" to "Dear Sir/Madam: We would like to extend our deepest sympathy for your concerns with our product ... ". [2] Another popular HN topic is "the client from hell". Would be interesting to have a thread to discuss this thread in that context.

421 points by ran5kpd 4y ago

xPaw 4y ago

> Heck even a tweet at the owner might be good enough. I disagree with this, don't spam people. Sometimes people even go out of their way to contact you using multiple channels and it gets even more annoying.

red_trumpet 4y ago
Later on, the article contains > There is no need to abuse the maintainer, repeatedly post the bug, harass them over twitter. So I think the sentence you quote is meant as a first approach.
tracker1 4y ago
Kind of depends... I'm listening to so many github repos that I often don't pay enough attention to the notices or even keep up regularly... if it's important/urgent, I'd almost preferred that they reach out via side channel. It's a rare case for me at least. I know it can be annoying if there's too much of it, or there's too many vectors or if you or the repo are popular. I'm not.

have_faith 4y ago

> Always remember you are talking to a real human being Too easily forgotten these days it seems.

nailer 4y ago
I made the mistake of making the Python module that handles Microsoft Word files (python-docx) about a decade ago. Despite including a bunch of examples for making, reading, and modifying documents, right in the README, I received a bunch of emails from India demanding I help them. I eventually passed the project onto someone else (not entirely because of this, I also started more involved with node at the time, but this was definitely part of it).
- Topolomancer 4y ago
  I think I know the type of interactions you mean, and I wonder whether it's a cultural thing or a language issue of which I am not aware: I have received a bunch of e-mails from strangers telling me something along the lines of "I request you to do X", where X is something related to a project of mine. I always tried to see this as a sample of "inexperienced person not expressing themselves politely." It's the most charitable explanation, but maybe someone else with more knowledge about the cultural differences can comment on this?
- jillesvangurp 4y ago
  Some people are just completely shameless about demanding that somebody else fixes their problems for free. I maintain a few small OSS projects and most of the interactions I have with people are pretty pleasant and respectful. However, my inbox is a dumpster fire of recruiter spam (both trying to recruit and offering their services to me), and incompetent idiots trying to sell me whatever. And indeed the occasional support request. It's infrequent enough that I usually reply if people are articulate and coherent enough (which is a problem with some of this). Otherwise, I have a pretty simple strategy for all this: I don't dignify people with a response unless I understand what they want and it adds value for me. Simply, not worth my time and energy. Repeat offenders get blocked and marked as spam. There's no point in me getting upset or angry about any of this. Just the price of doing business these days. In the same way I ignore the dozens of attempts at connect attempts on linkedin. If I don't know who you are and you don't have a coherent reason as to why we should connect, I'm going to ignore you. Buzzword compatibility doesn't count.

rblion 4y ago

A good philosophy for a happy life to be honest.

blueflow 4y ago
The secret ingredient is in "fuck off" - not caring. If you don't bother with the bad things in life you can focus on the good things better.

implements 4y ago

Fix it, Fork it, Fuck it! scans better. (“Fuck it!” is “I give up!” in British English)

dorkwood 4y ago
I politely disagree. I'm sure you can figure out how this reads for anyone who isn't British.
- nsteel 4y ago
  I (British person) agree with you. "Fuck it" is better. Especially considering "Fork it" could already be considered ambiguous: https://www.urbandictionary.com/define.php?term=fork%20it https://www.urbandictionary.com/define.php?term=fork%20it
  - remram 4y ago
    > I agree with you. "Fuck it" is better. Which is it? You replied to somebody who said it wasn't better.
    - nsteel 4y ago
      Sorry, messed this up. Ironically in an edit to make it clearer. I meant to say that "fuck off" is better than "fuck it".
- laumars 4y ago
  I’m British and I still think the original title reads better. “Fuck it” is ambiguous without context. “Fuck off” isn’t.
mnd999 4y ago
Yes, but everyone else in the world is going to need a new liquid ingress sticker for their laptop.
RF_Savage 4y ago
Find it, Fuck it, Forget it. Who knew KMFDM lyrics could also be applied to OSS development? https://youtu.be/PhS_t0sou_4 https://youtu.be/PhS_t0sou_4

chrisseaton 4y ago

What are the other requests that the author receives? This list seems to still include every option of interaction over an issue as being acceptable, so I’m not sure what behaviour they’re tying to discourage?

ndhlms 4y ago
Basically the assumption that by sharing your work, you become inherently beholden to the wishes of those that use your work. Some time over the last ten years or so, much of the open source community acquired the belief that they deserve to be treated as a customers despite the fact they don't pay for squat.
- chrisseaton 4y ago
  What were people doing based on that assumption? The article says contacting the author to ask for a fix over bug trackers, Twitter, etc is still ok in their mind. What else were people doing?
  - ndhlms 4y ago
    "Ask for a fix" is euphemism what often happens. It's commonplace to receive reports to the tune of: * "Can we get an ETA on this? Some of us need to get real work done" * "How you can justify leaving out such a basic feature?" * "This project is unusable without this feature" * "Why waste people's time by releasing software with bugs like this" * "This kind of mistake is totally unprofessional" * "The developers must not have the skill to fix this" These sorts of interactions can be more exhausting than outright abuse, because they're designed to bait/provoke the developer rather than just insult them. And to be clear, this isn't particular to this developer. There was a whole study done on this that made the rounds awhile back[1]. [1]: https://www.cs.cmu.edu/afs/cs.cmu.edu/Web/People/ckaestne/pdf/icse22_toxicity.pdf https://www.cs.cmu.edu/afs/cs.cmu.edu/Web/People/ckaestne/pd...
Aeolun 4y ago
I assume some of the people do not understand either of these steps, and just keep pestering the author after they say no.

invalidname 4y ago

As an OSS maintainer for a large project I disagree. Sometimes people did fuck off and it didn't do the project any favors. I needed people to communicate clearly and with volume why I should change some opinions. Ultimately, my mistakes led to a competitor that was indeed unsuccessful but sucked a lot of the mindshare so we both got screwed. We're smart people but we all need to learn humility occasionally. I do agree we need manners but I don't agree that people should just fuck off. I want complaints. That's how I can gauge improvement. A culture of ignoring complaints is bad. I know that is not what the article is about exactly, but it's where these things lead.

Timshel 4y ago
Nowhere it said you can't argue for your fix/change in an open issue. Just that once the maintainer close the issue: `So should you get angry and start abusing them? No.` Edit: And nowhere it makes any comments on how much/little the maintainer should listen to issues just that once he closed it you need to respect it and move on.
- invalidname 4y ago
  I had that. It was unpleasant (to say the least) but on a different situation I rejected a direction. User went elsewhere and we all ended up losing. I disagree with the attitude expressed there. Don't like it. Build your own. Every maintainer has his style, I don't think that's a constructive style and as a maintainer I never use that style. I might disagree with someone, I will never say fuck off. Even if I think someone should fork, I will offer help with the fork, at least in advice. Writing the code isn't where it ends. I thank every user who uses my code. Otherwise it's just another code dump. The users are what makes the work worthwhile. To me.
  - deleted 4y ago
    [deleted]
Barrin92 4y ago
the list of abandoned open source projects because the maintainers burned out is I think a lot longer than the list of projects that ended because low quality complaints were ignored. Literally go through GitHub and look how few people contribute the source code to even large projects. If they lose it, it often does significant damage to a project because original creators are important. In a sense being rude is being humble. If I'm rude to bad complaints it's because I'm realistic about my limited capacity to deal with stuff. It's ironically often generous people who end up resenting what they're working on.

systemvoltage 4y ago

It reads Fix it (or Pay for it), Fork it (or Pay for it), Fuck off (Free). I am glad we're realizing that paying for something is a good thing. Rarity in today's entitled attitudes people have for free things.

bakugo 4y ago

> If your project becomes better it will naturally gain more attention and be more inclusive Unfortunately, things don't really work this way. Maybe for niche software with a handful of users, but once a piece of software has gained enough traction it can be very hard to convince users to switch to a fork, it's not enough to just "be better". This post sounds like it was written more out of spite than anything else.

seqizz 4y ago
Might be out of spite. But I wouldn't dismiss the idea. This sounds like redirected to the people who wants a certain thing in the app, and non-stop complaining after a WONTFIX under all slightly related tickets. Rights of the owner has to be respected, even if they're wrong in the eyes of users.

bluenose69 4y ago

This is sensible advice. But I'd add an "R" as a separate and important item: report it. In your report, provide a clear explanation of why you think this is a bug, perhaps speculate on ways to fix it, and perhaps volunteer to help, in a way decided upon by the author. "Cold-call" patches and pull requests can be quite disruptive to an author who might be busy with other parts of the code, or (quite likely) with this part. They may be fine for trivial bugs with simple solutions, because the author can then tell at a glance whether they are going to cause problematic ripple effects. But for more trickier bugs with complex solutions, stitching in a patch/PR can be quite a hassle for the author. This is especially so if the new code is formatted differently than the old code, or uses a different "style" with respect to variable naming, etc. Start by reporting the bug clearly and respectfully. Let the author know, if you see the solution. Perhaps they will ask for a patch or PR. Or perhaps they will say they need a few days to look at it. Either way, start with a conversation.

chrisseaton 4y ago
That’s what the article already says is the first option - ‘Raise the issue in the bug/request tracker of choice.’
TazeTSchnitzel 4y ago
Also, if you're putting a lot of work into a pull request and it's important to you that it get merged, knowing whether you don't have a good chance of success, in advance, is going to save you and the maintainer potential sadness about your wasted effort.

nextlevelwizard 4y ago

My experience with open source is that I find an issue, I fix it, and submit a fix, but the fix isn't good enough and the maintainers ask me to write it better, but at that point I am no longer interested since I already fixed my issue. It is not like I'm going to start maintaining a fork over it. I am just not going to update the software or I'm just going to keep my patch in.

dschuetz 4y ago
If it's "not good enough" then it's the maintainers problem. I mean, come on, somebody fixed it for you and when you as the maintainer complain about the quality of the fix then the FFF rule applies also! I also have nothing against occasional little personal forks, but methinks that keeping track of the issues upon each update could be painful.
- ElCheapo 4y ago
  Imagine you ran a personal twitter account where you posted your jokes but allowed people to send theirs via email and occasionally publish them. Would you find inappropriate to tell people "yeah this joke almost kinda works but it's not funny enough for my account maybe send me a better version"?
  - ZeroGravitas 4y ago
    It also puts you in that weird area, where if you take the half-finished joke and polish it, then you're stealing and/or ruining their idea. Meanwhile, if you were looking for a long-term joke-writing collaborator, then you want to encourage even the people with enthusiasm but sub-par jokes to try harder in the hope they grow into the role.
    - ElCheapo 4y ago
      The code maintainer (or owner) makes the code available to the world without asking for anything in return, but if you send him a patch he is somehow obligated to implement it? (I'm not saying this is what you're implying) Open Source goes both ways: nobody forces you to use some rando's code off of github but also nobody forces said rando to to use some rando^2's patch for his own code

tamsaraas 4y ago

Another example: You contribute for 10 years for opensource project. Familiar with code, all of you fixed dozens of bugs. Community grows, opened issues - shrinks. Dynamic to close all major problems very soon. And when you feel absolutely the safe, some motherfucker comes to a place, and offer: "Guys guys, let's switch our codebase from C to C++, because there are easier to work with strings, easier to work with pointers, easier to work with everything". And big community without listening anyone by decision of 2 guys from community of 100 devs - moving code base from C to C++. All that they doing - changing extension for files, and adding `extern C {` to files. Since that amount of bugs - increased dramatically. Instead of fixing problems, there comes another dev and saying: "guys guys, lib-json too old, let's switch to modern and nice YAML". Yea, does not need to care, that we already have GUI for working easily with ANY data in the repo, all perfectly tuned, and everyone used too. and boom - devs decide to switch to this bullshit. 5 years pass since these changes (since switching to CPP) What do we have now? Community big slice of the communiy leaves from the scene. Because this is impossible to maintain such mess Another slice of community which is left - stay on codebase from 2017 without these changes. Project semi dead, impossible to revive it. Why all of that happened? Because of idiots who have permission to apply final decissions to repo. Repo of community driven project. Where all things done by a community, but merged by owner of the repo. The project do not belong to the owner of the repo, the project belongs to community, the owner just in 2011 made a switch from SVN to github, and uploaded data there. Sometimes - douche-bags = owners of open source repos. And as a guy who contributed to dozens of such projects, this is not "sometimes". This is - usually thing when guys on what rely community project - let the project die by doing nothing or doing wrong actions.

turtleyacht 4y ago
> the project belongs to community I'm sorry to hear about your experiences. It sounds painful to see project(s) pivot like that, especially since you contributed so much to them. What do you do now when you consider contributing to open-source projects? What guidelines do you use to evaluate the maintainer's "ability to keep things on an even keel?"

LtWorf 4y ago

> There is no need to abuse the maintainer, repeatedly post the bug, harass them over twitter. I see. The mistake was letting people know your twitter account.

ndhlms 4y ago
Or using the same the account name on multiple sites, u/LtWorf ;)
- LtWorf 4y ago
  I never said I don't make mistakes!

brunooliv 4y ago

To be honest, I think the real issue with OSS is the whole masquerading of acting like a corporate project and almost red tape attitude that some maintainers have that can block a PR for weeks or months. Unless you are a very important client who is paying money to the maintainers or unless the project is OSS but let's say, backed by/open sourced by a company like Google (as in, not some unknown person who kind of answers to no one) the chances of meaningful contributions landing are effectively zero. If you are a client of a given library working for "Unknown company 8965688" and you are using a library and make a PR with a change you need or request it, in my experience, you'll simply be ignored. Then comes the original post: we'll fork the library to an internal repository, make it our own, and stop depending on the whims of the maintainers who care absolutely nothing for the people who request features precisely _because they are actively using the library_ and need an improvement. OSS has become a really, really bad place to be when it comes to actively depend on something that is managed by someone who simply doesn't care about you in the slightest. Then, as we have people competent enough in the technology, forking becomes the natural thing to do.

andrepd 4y ago
Why do maintainers owe you support? I assume by your comment that you're a company, in that case, since you're making money off the value added by that OSS project, financially support the developers to get support in return. Then you can act entitled :)
- alias_neo 4y ago
  I often have to use open source projects in my work (Backend Software Engineer), there are projects that are popular, many of them backed by companies themselves and there are small one-person projects. As an engineer/developer, you may have an issue with one of these libraries, tools, etc and you'll put in a ticket with all of the details your development expertise can coax out; sometimes you'll get responses of thanks for a clear report, sometimes you'll be ignored, and other times they'll disagree or be unwilling, and now you're stuck. You'll go to management and ask if they'll pay said company/developer to fix it and they might, or they might not. You either look for an alternative, write something yourself, or you fork it internally, fix the issue and move on; now you and your peers have another piece of code to maintain because nobody on either side of you would budge. I've never been abusive to an OSS developer, I've certainly been frustrated, and I'm an FLOSS advocate myself. Some projects I've worked with, and I won't name names, have turned around fixes in literally an hour, are greatful for a good thorough report and want their software to work for you (and I'm talking large internationally used enterprise grade tools), and others will just be rude or dismissive, but you still have to solve that problem, it's your job. When I have a job to do I'll just move on from projects that make it harder, and I'll advocate harder for the projects that make it easier, if it's small and generally unmaintained, we'll just fork internally, improve 8t all we want and move on, now nobody in the wider community benefits. There are other projects that are larger, and we pay them decent recurring sums to be able to ask for a fix or feature to be turned around quick, and it'll end up in their open source code, so everyone benefits from that money this company spent. When you're a small start-up developer you have far fewer options available to you compared to a large company who can or will throw money at people inside and out to get things done.

ducktective 4y ago

The actual reason of this friction is that essentially, FOSS developers are working for free. FOSS devs and maintainers don't have _any_ monetary incentives to continue working on a project unless it helps them getting their desired job. Yeah, you may say some devs have so much passion about their software that they are willing to donate their time for free. But the interest may dwindle after a couple of months and years and that's when the whole thing becomes somehow a burden. It may not even come down to that. One bad morning + constant pings of "any updates yet" by an entitled user may trip the dev off for good.

frou_dh 4y ago

elihu 4y ago

I think there's another side to this, which is that if you're the maintainer of some open-source project and you actually want your software to be successful and widely used and generally to make the world a better place, you're going to need to maintain a good relationship with your users. When people report a bug, that's actually valuable. They're telling you something for free that you would otherwise have had to devote time and effort on validation / quality assurance to find. If someone requests a feature, that's telling you something about what users want (even if you might have perfectly valid reasons to decline the request). For every random email you get, there's probably a hundred more people thinking the same thing but didn't write the email. I think if I were to contact a maintainer of some project and they sent me to this page, my thought would be: "oh, I guess this project is just a hobby project someone uploaded to github for posterity and they're not actually interested in maintaining it." That's okay! Not everyone has time for that.

detaro 4y ago
The first paragraph is important: > I quite often get bug fixes, patches, requests and questions regarding the things I have published. Most of the feedback is respectful and helpful. However occasionally there are other requests. This page is where I plan to redirect them as a final warning before I block and ignore them.
- veltas 4y ago
  I will say that in my own experience with online diplomacy, you should just block and ignore them before sending them something that in context is telling them to "fuck off". As soon as you engage with language like that the civility is already over and not worth talking. Honestly, the title is catchy, but this article is not phrased diplomatically enough to send to a difficult person.
  - imtringued 4y ago
    When a reckless driver is on the road, the worst thing you can do is retaliate and aggravate the reckless driver. No, you should just let the lunatic drive by and hope he forgets you were even on the road.

dschuetz 4y ago

I see it as an attempt to bring a perpetual and painful discussion to an end. I agree, would like to add that: The FFF rule also applies to submission of fixes to maintainers. If it fixes a problem, but not the way you like it to, you can go and FFF.

Andrew_nenakhov 4y ago

Very much this. The most unpleasant part of running an open source project is feedback from some toxic users. Many of them behave as if you work for them, and demand all kinds of privileges, or else they'll give you 1 star rating on Google play!

avg_dev 4y ago
Daniel Stenberg, the lead maintainer of cURL, has some interesting tweets about this topic. In fact several of the toxic comments he posts are from people who seem to lack a basic understanding of what the project even provides. https://twitter.com/bagder/status/1561459354431275009 https://twitter.com/bagder/status/1561459354431275009 https://twitter.com/bagder/status/1535188747427405824 https://twitter.com/bagder/status/1535188747427405824 Just to provide some counterbalance there's also this: https://twitter.com/bagder/status/1552414274101940225 https://twitter.com/bagder/status/1552414274101940225 He has an interesting guide on his thoughts on maintaining open-source as well. Here's the People section: https://un.curl.dev/people https://un.curl.dev/people

pdpi 4y ago

There's (at least) four Fs, and the first in the list should be "File it". Not every open source user is a developer who can Fix it or Fork it, but a well-written bug report (and other forms of high-quality feedback) is a godsend. Even as a developer, everybody benefits if I file a bug and then spend my energy on my own open-source work rather than spending that same amount of time trying to learn the codebase of every piece of software I use.

obert 4y ago
Add “Find it”, eg try debugging and provide some starting points about where/what the root cause might be
sixhobbits 4y ago
That's literally the first sentence of TFA > your first option is to make a request to fix it. Raise the issue in the bug/request tracker of choice.
- pindab0ter 4y ago
  I'm sorry, what's "TFA"?
  - Doctor_Fegg 4y ago
    The Fabulous Article
  - tdrgabi 4y ago
    The fine article
  - dmolony 4y ago
    Presumably 'The Fucking Article'
  - tpoacher 4y ago
    The Fantastic Article
4y ago

stupidcar 4y ago

I agree with the article in general, but the wrinkle comes when you encounter a bug in a large, popular open source project (naming no names, but any of the major web frameworks for example) that you're using for a work project. Fix it? Sure, except despite their ostensibly open nature, many of these projects are run as internal projects of large tech corps, and the bandwidth and interest of the team in reviewing and merging external PRs is limited to nonexistent. I've submitted small, obvious bug fixes, complete with test coverage, to projects and had them sit unreviewed for years. Fork it? Well there is a big, big difference between spending an hour fixing a bug and submitting a PR, and forking a large and complex dependency. You're committing yourself and your team and employer to the ongoing maintenance of the fork and merging of upstream changes, just so you can merge a bug fix. Usually, that's just not practical. Fuck off? Many third-party dependencies in mature projects are non-negotiable. Removing them would require a complete rewrite. You may not even have been the person who chose them, but you're stuck with them, and then your boss asks you to implement a feature or fix something that relies on a change or fix in a dependency. Being blocked due to upstream intransigence is very frustrating, and there is often a professional cost to saying "no" to a request, especially a bug fix, no matter how convincing you argue that it's not your fault or under your control.

account42 4y ago
If you are relying on unpaid open source code for commercial work, you should fully understand what that means for you: > This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. (from the zlib license, but others have similar disclaimers) If that is a problem for you, negotiate a different contract up front - with the maintainer or someone else willing to do the work. That probably means paying them. If you don't then no, the maintainer is not required to invest the time and money you are unwilling to into maintaining your pet feature or "fix".
- danwee 4y ago
  You are right, but in practice that's not what happens. Companies do not rely on open source libraries, the developers working for such companies do. I can give you a realistic example. If you want to use Kafka and Go, your probably only option is to use https://github.com/confluentinc/confluent-kafka-go https://github.com/confluentinc/confluent-kafka-go. Its LICENSE explicitly says "no warranty". Now, what if I find a bug in the library? Only two realistic solutions from my side: 1. I submit the issue and hope for the maintainers to fix it 2. I dig deeper and try to fix the issue. I submit the PR None of the above scenarios are guaranteed to have a happy ending. The issue could be ignored, or piled up among thousand of other (maybe higher prio) issues. My solution may not be optimal and could be rejected (or if it's optimal, nobody is taking a look at it, and it could remain open for weeks/months). > If that is a problem for you, negotiate a different contract up front - with the maintainer or someone else willing to do the work. That probably means paying them. In the real world that would mean that I go to my manager and asks them to pay money to the maintainers of confluent-kafka-go to fix the issue I found. I don't think my manager would approve that, but let's imagine he does. The guys at confluent-kafka-go may not want money to fix the issue. These guys have probably already jobs that pay them well, and they work on the library at will. Note: I'm talking about confluent-kafka-go, which I know is behind the Confluent software company. But I could as well be talking about libraries maintained by individuals like https://github.com/edenhill/librdkafka https://github.com/edenhill/librdkafka

isitmadeofglass 4y ago

Would have been better worded as fix it, fork it, forget about it.

oezi 4y ago

If Github would highlight popular forks better that would be a tremendous help. It currently is annoying to uncover if there are any relevant forks and what they contain.

tracker1 4y ago
It will vary... there's times I've created the PR myself, but cannot wait for the patch to make it in... so I'll reference my fork to start with, then go back and re-reference to upstream and delete my downstream once it's accepted. I usually discover existing forks when looking for a bug/issue fix and see there's already a PR, that may have been sitting for a while, or rejected but the issue remains. Sometimes that means creating my own fork of the downstream for ongoing use. YMMV, I usually do try to update the README to indicate it's a fork for personal use until upstream approves/integrates.
- oezi 4y ago
  I think single issue forks should be presented in the Fork overview in a special way (for instance with the linked issue), but I was mostly talking about actively developed forks which are hundreds of commits further than the original project/upstream. Github should be doing more to advertise these for instance by showing the top 5 forks in terms of activity. Also too many forks are just user interface mistakes where somebody wants to look at the lists of forks but accidentally forks the projects by clicking on the Fork counter in the top right corner rather than the Fork counter in the "About" box of the project.

avg_dev 4y ago

A fine article. > There is no need to abuse the maintainer, repeatedly post the bug, harass them over twitter. All this results in is people wanting to not contribute their time and expertise for free. > [...] > Always remember you are talking to a real human being, and just because their ideas of how to implement a project are not in line with your own does not mean you have any right to abuse them. I do not believe there is ever anything that gives one person the right to abuse another. > https://en.wikipedia.org/wiki/List_of_software_forks https://en.wikipedia.org/wiki/List_of_software_forks An excellent list! The once dominant Apache httpd is a fork. Never knew it. Postgres is a fork! Never knew it. Microsoft SQL Server is a fork! OpenSSH is a fork. The list goes on. I am sure that Wikipedia page, like many I have seen on code/tech, is under-maintained. I bet the reality of forking is much more extensive. Finally, the title of the article makes me laugh. I knew it was gonna be good before I started.

musically_ut 4y ago

The post resonates with me as an OSS user and a contributor. Many a brave souls have taken to forking the project to fix the bugs but those forked projects almost always suffer from a discoverability problem. I have tried making fixes and tried forking projects only to discover that someone else has done it better elsewhere. I've been burned by this problem often enough that I wrote a Chrome extension which would _tell_ me if there are any notable forks of the project I'm currently looking at on GitHub: https://github.com/musically-ut/lovely-forks https://github.com/musically-ut/lovely-forks </self-plug>.

oh_my_goodness 4y ago

Here's a modest proposal. Your employer can no longer pay you, but they have a big code base that you wrote. You are now obligated to maintain that code for free. Think it through. How else can your employer get what they need? You might say that they should pay consulting rates, or that you're busy with your new job. But how is that your former employer's problem? They used your code in good faith, they ran out of money, and they were forced to lay you off. None of this is under their control. *** IRONY NOTICE: THIS COMMENT CONTAINS IRONY ***

oxplot 4y ago

Disclaimer: I write open source software and I use open source software. It's a non-useful and self-damaging trait that most people seem to have: yell at others to try to make them behave in a certain way where they can instead take actions on their own to ignore/avoid those behaviors. This shows up all the time at work where people complain that they are getting too many slack messages or emails. You are not some hopeless caveman who has no idea what a computer is. Set up a filter and send everything you don't like to trash. Silence your notification. Mute/leave channels. Oh right, you are also a software developer. Write code to automate the above. > There is no need to abuse the maintainer, repeatedly post the bug, harass them over twitter. Block the user on GH/Twitter! Lock the conversation. Write a script to do the blocking for you automatically (Twitter and Github both have APIs for that - that should be a hint that this is an intended use case!). If you have already identified someone as an abuser, any response, negative, positive, dismissive or otherwise, is only going to encourage the behavior - that is a well studied pattern. Writing a post and having it end up on HN does the exact opposite of what you hope it would. Someone reading your post is going to specifically go out of his/her way to fuck with you. Instead, just ignore.

viridian 4y ago

Viscerally understand the sentiment as someone who handles vague technical feedback here and there, but I've also seen this attitude kill off project enthusiasm almost completely, specifically with D&D/pathfinder character sheet manager PCGen: https://en.wikipedia.org/wiki/PCGen https://en.wikipedia.org/wiki/PCGen In an era before github issues, the project got a lot of requests via the Yahoo groups mailing list that were often of suspect quality, but usually addressing a real flaw with the software. At some point near the end of the mailing group's life cycle, the most active maintainers really took a shift in the angry direction, and I think that led to a lot of people on Reddit, rpg.net, giantitp, etc no longer recommending it. This might not seem like a problem, but over a long enough long frame, low user interest for a formerly popular piece of software does seem to inevitably lead to a loss of maintainers.

hk__2 4y ago

(2019)

jarek83 4y ago

I must admit that I used to be a harassing parasite. Then I realized how foolish I was being this way. I changed into just a parasite, but I feel urge to contribute and sometimes I do. I also learned that those who harass, will learn one day the same lesson as I did, so I don't bother too much with them.

pacifika 4y ago

Swearing in the same paragraph as talking about respect. That detracts from the article

tpoacher 4y ago

The author of this post conveniently neglects the fact that the third F also has a payment option: Pay someone to bug/sue/harrass the developer on your behalf until they succumb to preserve their sanity. Out of all the payment options, this is likely to be the cheapest and most effective. Be careful what you wish for.

andix 4y ago

It’s also okay to just report a bug. But don’t expect it to be fixed by the community.

kweingar 4y ago

I know this isn’t a one-to-one comparison, but there’s an interesting discrepancy in how HN views free-to-use products. In this situation, there is a prevailing attitude of “You are not paying for this, so you are not entitled to fixes or support. Any suggestion otherwise is entitlement on your part. I don’t care that you’ve grown to rely on this service. Pay me or figure it out yourself.” When it came to Gitlab considering deleting old free-tier repos, however, people were incensed and insisted that there is an obligation to continue providing free service for users. Similarly, with Gmail and YouTube, people often invoke the argument of “this is people’s lives and livelihoods, so of course there is an obligation to provide fixes and support.” So is the difference here that one endeavor is done for profit and the other isn’t? If an open source project becomes profitable for the maintainers, do they now have a obligation to fix and support their software?

samsquire 4y ago
You're uncovering this visceral reaction to paying for things people use or want and expecting people to do things on their behalf that only benefit them. Also the free rider problem. Also examples of the 1% rule and Pareto principle where most value must be produced by a very small number of people and used by lots of people. https://en.m.wikipedia.org/wiki/1%25_rule https://en.m.wikipedia.org/wiki/1%25_rule
naasking 4y ago
> So is the difference here that one endeavor is done for profit and the other isn’t? If an open source project becomes profitable for the maintainers, do they now have a obligation to fix and support their software? Yes, doesn't that seems reasonable? Presumably Gitlab became as popular as it did only because they offered free-tier repos, and generated revenue another way. YouTube only became popular because they offered free content and generated revenue another way, and so on. Suppose you managed to start a company with a couple of loyal customers, and then as you grow bigger you ignore those loyal customers' needs in deference to newer customers that pay more. Maybe it's "good business" to pursue more profit, but kind of shitty to spit in your original customers' faces no?
- 4y ago

geenew 4y ago

Politeness is free. 'Fuck off' is unnecessary, just drop it and say there are only two F's. Users shouldn't be jerks, neither should maintainers.

williamtrask 4y ago

There should be a fourth option, “Fund it”

qwerty456127 4y ago

"Fork it" means a whole lot of additional problems: backport fixes from new upstream versions, build packages for your distro, maintain your repos etc.

keybored 4y ago

> If you find a bug, notice missing, incorrect or misleading documentation, or want an enhancement, your first option is to make a request to fix it. So then the first step is Forward issue. Not Fix it.

darepublic 4y ago

I can't argue with the basic argument of OP but if the project is still active but in the wrong ways (adding new features, add hype, etc) and still not fixing recurring issues then I have to put some blame on the maintainers in how they wish to spend their time. They are busy doing work to get their dep in the codebase you have to work on, but not enough time making it work well in said codebase. And as others have pointed out you often do not have a choice about these matters when not in ownership of the project. Of course none of this is an excuse for any kind of harassment. But public criticism of the library? Sure.

sylware 4y ago

The devil hides in the details: it is all about how much "critical" the set of components is, and what is the core of the pb being reported. Because, as my experience goes, often the pb lies with the "dev" of the set of components itself, not the issue reporters. Software (open source or not) is plagued with planned obsolescence and software Rube Goldberg machines, and on components where it is accute, there is no reasoning of anybody, the "dev" is a scammer, not to mention the "dev" is often a corpo or an organized network of ppl (pulling the strings in the shadows). On critical, big and/or complex sets of components, and those would be well established ("financing" is kind of "secured", and those components are used a lot), the "dev" knows that hardly nobody will be able to provide real-life alternatives, then "dev" may give you a bit of attention but will send you to hell if you start to threaten their scam (namely the "financing" of their network of ppl). Usually, you will get partially true responses missing out the "disturbing" parts, all that with a ton of "mauvaise foi", like a troll. Fighting this can only by done on case by case basis since we are talking about complex component systems. Not to mention, mistakes can happen because it is easy to be fooled in complex matters. Sometimes, you may have to "follow the money" and go legal.

birdmanjeremy 4y ago

So if I find a WebKit bug in the latest iOS beta, file it with both Apple and WebKit, and get ignored, I should just fuck off? I can't fork it (Apple won't use my fork) and it's unlikely my fix would be complete and accepted for upcoming releases, so I guess you're right. "Fuck off" and let iOS devices crash is my only option. This is purely hypothetical (e_e)

dmz73 4y ago

I don't understand why open source developers think they are owed anything by anyone. They chose to work for free and give away that work. In the process they killed any proprietary competition and therefore a chance for anyone to get paid for the equivalent work. Now there are users who demand that these developers fix the bugs they introduced during development or add missing features, and rightly so, since there is no other choice. Users cannot just hire someone to do the work since that is going to be too expensive, more expensive than if they asked proprietary developers to fix the same issues since proprietary developers work would have been paid by many users. Should open source developers be forced to work for free? On the one hand the answer seems to be obviously no. On the other hand, these developers killed all the competition that could have provided cheaper development alternatives for the user so maybe they do owe some free work to these users. Compare this to other professions, electrician can install the wiring for free but they are still liable for any work they do that is not compliant with the relevant standards. They don't have to install more wiring for free but they have to fix any mistakes they made. Software development is still a wild West of professions and it is in dire need of regulation. Then if it costs too much to work for free and release certified code, developers won't do it and users will pay to get a quality product.

pookha 4y ago

Great article. That final F sentiment is EXACTLY what the open source world needs. There's too many free loaders and mega-corp vampires taking advantage of peoples' free time. Some of this is beginning to feel slave-like. Billions in profits and vast fortunes are all on the backs of unpaid maintainers (slaves) toiling nights and weekends (cheap labor). And I'm just as much of the problem...Not giving back (financially or in other ways) makes you a douchebag and most of us are in that boat.

cranky908canuck 4y ago

The only problem I see with the original post is a matter of diplomacy. As the saying goes, the trick is to tell someone to go to hell in a way that makes them eagerly anticipate the vacation. (Or using the original post's terminology, they're eagerly up for it...). I would have expected that the discussion here should be taking that as a given. No paying business is required to take on all suggestions from all customers [1] [2], why would anyone be expected to do that for free? [1] Paying businesses have whole departments dedicated to translating "tell them to go f--k themselves" to "Dear Sir/Madam: We would like to extend our deepest sympathy for your concerns with our product ... ". [2] Another popular HN topic is "the client from hell". Would be interesting to have a thread to discuss this thread in that context.