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.<p>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 <i>years</i>.<p>Fork it? Well there is a big, <i>big</i> 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.<p>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.
As an OSS maintainer for a large project I disagree. Sometimes people did fuck off and it didn't do the project any favors.<p>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.<p>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.
There's (at least) four Fs, and the first in the list should be "File it".<p>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.
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.<p>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.<p>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.
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.<p>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.
I know this isn’t a one-to-one comparison, but there’s an interesting discrepancy in how HN views free-to-use products.<p>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.”<p>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.<p>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.”<p>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?
Disclaimer: I write open source software and I use open source software.<p>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.<p>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.<p>> There is no need to abuse the maintainer, repeatedly post the bug, harass them over twitter.<p>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!).<p>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.<p>Instead, just ignore.
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.<p>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.<p>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.<p>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.<p>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.<p>Then, as we have people competent enough in the technology, forking becomes the natural thing to do.
> If your project becomes better it will naturally gain more attention and be more inclusive<p>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".<p>This post sounds like it was written more out of spite than anything else.
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: <a href="https://en.wikipedia.org/wiki/PCGen" rel="nofollow">https://en.wikipedia.org/wiki/PCGen</a><p>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.<p>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.
> Heck even a tweet at the owner might be good enough.<p>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.
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.<p>"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.<p>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.<p>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.
A fine article.<p>> 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.<p>> [...]<p>> 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.<p>I do not believe there is ever anything that gives one person the right to abuse another.<p>> <a href="https://en.wikipedia.org/wiki/List_of_software_forks" rel="nofollow">https://en.wikipedia.org/wiki/List_of_software_forks</a><p>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.<p>Finally, the title of the article makes me laugh. I knew it was gonna be good before I started.
The actual reason of this friction is that essentially, FOSS developers are working for free.<p>FOSS devs and maintainers don't have _any_ monetary incentives to continue working on a project unless it helps them getting their desired job.<p>Yeah, you may say some devs have so much passion about their software that they are willing to <i>donate their time for free</i>. But the interest may dwindle after a couple of months and years and that's when the whole thing becomes somehow a burden.<p>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.
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?<p>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.<p>*** IRONY NOTICE: THIS COMMENT CONTAINS IRONY ***
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.
It reads Fix it (or Pay for it), Fork it (or Pay for it), Fuck off (Free).<p>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.
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, <i>or else they'll give you 1 star rating on Google play!</i>
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.<p>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: <a href="https://github.com/musically-ut/lovely-forks" rel="nofollow">https://github.com/musically-ut/lovely-forks</a> </self-plug>.
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?
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.<p>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).<p>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.<p>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.<p>Sometimes, you may have to "follow the money" and go legal.
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.<p>This is purely hypothetical (e_e)
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...).<p>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?<p>[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 ... ".<p>[2] Another popular HN topic is "the client from hell". Would be interesting to have a thread to discuss this thread in that context.
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.
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.<p>Out of all the payment options, this is likely to be the cheapest and most effective.<p>Be careful what you wish for.
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.
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.
> 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.<p>So then the first step is Forward issue. Not Fix it.
I see it as an attempt to bring a perpetual and painful discussion to an end.
I agree, would like to add that:<p>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.
"Fork it" means a whole lot of additional problems: backport fixes from new upstream versions, build packages for your distro, maintain your repos etc.
Politeness is free. 'Fuck off' is unnecessary, just drop it and say there are only two F's.<p>Users shouldn't be jerks, neither should maintainers.
> There is no need to abuse the maintainer, repeatedly post the bug, harass them over twitter.<p>I see. The mistake was letting people know your twitter account.
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:<p>"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".<p>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.<p>Since that amount of bugs - increased dramatically.
Instead of fixing problems, there comes another dev and saying:<p>"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.<p>5 years pass since these changes (since switching to CPP)<p>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.<p>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.<p>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.<p>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.
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.