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.
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".
I think you should make sure, before choosing a dependency (framework or otherwise) that it either has the level of support (free or paid) that you require, or that you can easily replace it with something else that does or that you can build in-house (in case the maintainer won't merge your patches).
If a dependency fail to satisfy that requirement, it means you cannot afford it, even though it's apparently free.
Now from your description, it seems like you are paying someone else decision of choosing a framework the company could not afford, which sucks (as any situation where you inherit someone's debt), but in any case it's hard to blame the framework maintainer for that poor choice.
For small changes, there can be a fourth way between the fix and the fork: maintaining a _patch set_ for the official version. One ecosystem where this happens often is the Linux kernel.
The practicality of this depends on the nature of the changes and the rate of upstream conflicts. But if you can automate the application of the patch, maintaining a "fork" can be a much lighter affair. It would be nice if patching was handled as a first class dependency mechanism by high-level build systems (e.g. npm, cargo, maven, etc.)
This scenario is one of my favorite things about Ruby. In every non-Ruby project I’ve run there’s some level of forked dependencies because we need something fixed immediately, but end up maintaining the dependencies as we wait for the PR to be merged eventually, if ever.
With the Ruby projects, I can just monkey patch the fix into the original code without breaking the upgrade path. Wrap a test around it to let me know when the upstream fixes the issue themselves and we’re on our way.
Working with 3rd party packages is probably my top selling point for Ruby long term.
The solution to the given problem with “fork it” is not to use any major dependency for which you aren’t already prepared to maintain a fork. The way to ensure that is fork it preemptively at the start of product development. I’ve maintained bugfix and feature forks of major dependencies with millions of lines of code, and not only does the merge from upstream become for the most part quite straightforwardly routine, I can say it’s much easier today using git than a vendor branch was back in the days of CVS.
There's a fourth option: Pay them. Pay someone to prioritize and fix your issue. You mention a work project, a work project is a commercial project, and a commercial project has money to spend; money it SHOULD spend. Either on you - to fix and/or fork it - or someone else.
We use an open source mobile app framework and we have a guy on retainer for 8 hours / week for just that reason.
If the upstream project does not want to merge your fix, but it's an obvious improvement and a non-controversial patch, then one option is to have packagers carry the patch instead. For example in Nixpkgs, it is quite easy to patch an upstream project. If you then want to step in and keep the patch rebased, that's great. If you throw it over the fence and later the patch starts to conflict, then the packagers would likely remove it. It shouldn't be the first thing you try, but it can be a valid alternative with unworkable upstreams.
> 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.
Seems easy enough to build a custom fork in your CI and use that in your deployment. You could even automate the merge from upstream once a day. How often do you find merge conflicts in practice?
I agree. The fourth F is 'Figure out a workaround'. Wrappers, control processes, plugins. When Terraform decides it's going to be user-antagonistic and not fix problems that literally everyone complains about, we have to create entire projects to work around it, like Terragrunt and Terraformer.
All of this is why you get paid. The alchemist turning the free stuff into stuff worth dollars! And bridging the impedance mismatch therewith.
Other options are changing libraries, changing the “requirements” or in a recent case in my company submitting a fix and waiting the months for the review and finally getting fixed for everyone. And yes it is a lot of work to do that in a complex OSS project.
If you don’t like this I recommend architecting to avoid it. Avoid front end libraries and use .NET for the back end which gives you fully featured system without needing as much FOSS reliance then pay M$ for top tier support.
Then just patch if after download. Maybee from time to time you need to change your patch a little bit. But in the end, thats the way when the maintainer is doing nothing for you.
Think about it as, you tried to help them fix a bug. When they don't want your help, all what you supposed to do on open source software is done.
Question! I'll assume your employer is paying you for your work project. For example, if you fixed the bug yourself, your employer would pay you for your time. If the maintainer fixes the bug, should your employer pay them for that work?
I would probably treat such corporate "open source" project as free (as beer) proprietary ones. The only options are either accept them as they are or ask the business level to involve. The blog is more about real (aka community) open source as I see it.
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.
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.
I'm glad to see this attitude expressed in the current sea of "reluctant maintainers". I don't really get why so many people get stuck maintaining a project when they don't want to maintain it. Just step away? If someone else wants to take it, they'll take it. If no one wants to take it, it'll just peacefully die, and that's fine.
Or if you want to run a project with no issue tracker, that's also fine. That's how most of the closed source Windows freeware programs were ran in the late 90s/early 2000s. Once it stops working for most people's use cases, people will just switch to something else. Granted, this model lends itself more to full products and not libraries or frameworks.
But if you want to become the "Hot New Framework", one of the ones that all the devs talk about, one that will be picked by teams across the world, with all of the clout, prestige, speaker invitations to conferences and whatnot that will get you, I'm sorry, you need to hold your end of the bargain. The mindshare doesn't come for free, if you get upset and take your ball home every time someone points out a bug in your code or requests a feature, the other kids will just stop playing with your (formerly) fancy ball. And as you found out, if people don't come with the right feedback and said feedback isn't taken seriously, your project's popularity will dwindle and perhaps even die altogether if the flaws or missing features are serious enough.
You'd think this much would be obvious, but the "Don't Talk to an OSS Maintainer Ever" doctrine keeps getting more and more popular and it's really bewildering. Being an OSS maintainer for a project out in the open means that your (volunteer) job is literally talking to people. Firemen may be volunteers in many regions, but if a random fireman randomly stopped putting out fires because "I don't owe you anything!", they'd be rightfully kicked out. Just because you're not getting paid, it doesn't mean you have no moral duty to anything in life.
RMS would famously shout "YOU are the GNU Hurd maintainer!" at people who asked him what GNU's plan for Hurd was. That obviously turned out great. It's a good attitude to have if you don't want anything to happen and just want to claim the moral high ground, it's not great if you want your project to be successful and it pains me that we're teaching people that it's ok to be unprofessional at volunteer jobs because you're volunteering.
If you are an OSS maintainer who wants to build a succesful project used by a lot of people and companies and that has much mindshare, etc. etc. then yes, you will need to evaluate people's opinions, listen to them, and decide when it's in your interest to fix something or change the design or whatever. Because then keeping people interested in and using your project and in fact growing their numbers is your goal, so obviously you will need to attract and work with them.
If you released some code you wrote that was useful to you and sometimes update it or fix it for others because the fix is easy or helps you too or you just feel nice, then the calculation might look a bit different.
You say you disagree, but you are actually discussing a separate (even though related) issue: the maintainers' options in these situations.
The article does not say "just fuck off"; it says it is what you should do if you have exhausted all reasonable attempts to get your preferred outcome.
>> “I needed people to communicate clearly and with volume why I should change some opinions.”
This is not how real world works. People rarely intentionally communicate unclearly — or fail to add the “volume” they feel is necessary.
Only aspects that are in your control are: how you allow people to communicate with you - and what you do with what they share.
- Problem with how is that the more constraints you add, less likely they are to communicate; you’re basically increasing cost for them to reduce the cost for you.
- Easiest way to increase the efficiency of what you do with the information is to have another set of eyes helping process the information; in doing so, you’re delegating control and adding overhead — but gaining a predictable interface to filter less predictable information.
Communicating information takes energy, and there’s only so much efficiency that’s reasonable to expect, especially when dealing with random people via systems you do not fully control.
I gave a talk once on a piece of code I wrote and mentioned that an OSS library my project depended on lacked a feature. I wasn't so much complaining as just stating the fact that it didn't do X and it would be really awesome if it did X.
Afterwards one of the maintainers came up and asked me to make a bug report on Github. So I did.
I lack the expertise or time to implement this feature and the feature is still not implemented. But it's useful to have the feature request on Github because other people find and there are a few comments on it now.
Documenting stuff like this is important for maintainers. It's when the documentation turns into a form of harassment that people need to fuck off.
I will never understand the concept of competition in the context of open-source. I would love to have my projects be superseded by something better that is someone else's doing and responsibility.
You’re allowed to run your project any way you want to achieve your goals.
But I think the post still applies. If I use your project, it’s up to me to communicate bugs clearly and in a manner useful to yourself if I want a chance of getting it fixed. Otherwise, I shouldn’t expect anything or go and do it myself.
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.
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.
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.
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.
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?
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.
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.
> 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.
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
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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!
[+] [-] stupidcar|3 years ago|reply
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|3 years ago|reply
> 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".
[+] [-] puchatek|3 years ago|reply
How is this the maintainer's problem?
[+] [-] forty|3 years ago|reply
If a dependency fail to satisfy that requirement, it means you cannot afford it, even though it's apparently free.
Now from your description, it seems like you are paying someone else decision of choosing a framework the company could not afford, which sucks (as any situation where you inherit someone's debt), but in any case it's hard to blame the framework maintainer for that poor choice.
[+] [-] speed_spread|3 years ago|reply
The practicality of this depends on the nature of the changes and the rate of upstream conflicts. But if you can automate the application of the patch, maintaining a "fork" can be a much lighter affair. It would be nice if patching was handled as a first class dependency mechanism by high-level build systems (e.g. npm, cargo, maven, etc.)
[+] [-] psychstudio|3 years ago|reply
* Does the maintainer have any obligation to you, or anyone else?
* Are you entitled to anything at all from the maintainer?
* Is the maintainer in any way at all responsible for your "professional costs" for using their software?
[+] [-] brightball|3 years ago|reply
With the Ruby projects, I can just monkey patch the fix into the original code without breaking the upgrade path. Wrap a test around it to let me know when the upstream fixes the issue themselves and we’re on our way.
Working with 3rd party packages is probably my top selling point for Ruby long term.
[+] [-] inopinatus|3 years ago|reply
[+] [-] Cthulhu_|3 years ago|reply
We use an open source mobile app framework and we have a guy on retainer for 8 hours / week for just that reason.
[+] [-] ruuda|3 years ago|reply
[+] [-] chrisseaton|3 years ago|reply
Seems easy enough to build a custom fork in your CI and use that in your deployment. You could even automate the merge from upstream once a day. How often do you find merge conflicts in practice?
[+] [-] labrador|3 years ago|reply
from: "You can choose submit a patch and fix yourself"
to: "You can fix your local copy for yourself and optionally submit a patch"
[+] [-] 0xbadcafebee|3 years ago|reply
[+] [-] quickthrower2|3 years ago|reply
Other options are changing libraries, changing the “requirements” or in a recent case in my company submitting a fix and waiting the months for the review and finally getting fixed for everyone. And yes it is a lot of work to do that in a complex OSS project.
If you don’t like this I recommend architecting to avoid it. Avoid front end libraries and use .NET for the back end which gives you fully featured system without needing as much FOSS reliance then pay M$ for top tier support.
[+] [-] krater23|3 years ago|reply
[+] [-] oh_my_goodness|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] oytis|3 years ago|reply
[+] [-] brudgers|3 years ago|reply
If the employer cannot afford to pay then the business is simply not viable to the degree the problem is mission critical.
[+] [-] svnt|3 years ago|reply
It is a fishhook constructed between an implied social/free project and a corporation’s revenue source.
You took the bait.
[+] [-] michaelcampbell|3 years ago|reply
"Open Source Owners: Accept the PR, Reject the PR. No fuck off option."
[+] [-] invalidname|3 years ago|reply
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|3 years ago|reply
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.
[+] [-] disruptiveink|3 years ago|reply
Or if you want to run a project with no issue tracker, that's also fine. That's how most of the closed source Windows freeware programs were ran in the late 90s/early 2000s. Once it stops working for most people's use cases, people will just switch to something else. Granted, this model lends itself more to full products and not libraries or frameworks.
But if you want to become the "Hot New Framework", one of the ones that all the devs talk about, one that will be picked by teams across the world, with all of the clout, prestige, speaker invitations to conferences and whatnot that will get you, I'm sorry, you need to hold your end of the bargain. The mindshare doesn't come for free, if you get upset and take your ball home every time someone points out a bug in your code or requests a feature, the other kids will just stop playing with your (formerly) fancy ball. And as you found out, if people don't come with the right feedback and said feedback isn't taken seriously, your project's popularity will dwindle and perhaps even die altogether if the flaws or missing features are serious enough.
You'd think this much would be obvious, but the "Don't Talk to an OSS Maintainer Ever" doctrine keeps getting more and more popular and it's really bewildering. Being an OSS maintainer for a project out in the open means that your (volunteer) job is literally talking to people. Firemen may be volunteers in many regions, but if a random fireman randomly stopped putting out fires because "I don't owe you anything!", they'd be rightfully kicked out. Just because you're not getting paid, it doesn't mean you have no moral duty to anything in life.
RMS would famously shout "YOU are the GNU Hurd maintainer!" at people who asked him what GNU's plan for Hurd was. That obviously turned out great. It's a good attitude to have if you don't want anything to happen and just want to claim the moral high ground, it's not great if you want your project to be successful and it pains me that we're teaching people that it's ok to be unprofessional at volunteer jobs because you're volunteering.
[+] [-] barnabee|3 years ago|reply
If you are an OSS maintainer who wants to build a succesful project used by a lot of people and companies and that has much mindshare, etc. etc. then yes, you will need to evaluate people's opinions, listen to them, and decide when it's in your interest to fix something or change the design or whatever. Because then keeping people interested in and using your project and in fact growing their numbers is your goal, so obviously you will need to attract and work with them.
If you released some code you wrote that was useful to you and sometimes update it or fix it for others because the fix is easy or helps you too or you just feel nice, then the calculation might look a bit different.
[+] [-] mannykannot|3 years ago|reply
The article does not say "just fuck off"; it says it is what you should do if you have exhausted all reasonable attempts to get your preferred outcome.
[+] [-] O__________O|3 years ago|reply
This is not how real world works. People rarely intentionally communicate unclearly — or fail to add the “volume” they feel is necessary.
Only aspects that are in your control are: how you allow people to communicate with you - and what you do with what they share.
- Problem with how is that the more constraints you add, less likely they are to communicate; you’re basically increasing cost for them to reduce the cost for you.
- Easiest way to increase the efficiency of what you do with the information is to have another set of eyes helping process the information; in doing so, you’re delegating control and adding overhead — but gaining a predictable interface to filter less predictable information.
Communicating information takes energy, and there’s only so much efficiency that’s reasonable to expect, especially when dealing with random people via systems you do not fully control.
[+] [-] AndyMcConachie|3 years ago|reply
I gave a talk once on a piece of code I wrote and mentioned that an OSS library my project depended on lacked a feature. I wasn't so much complaining as just stating the fact that it didn't do X and it would be really awesome if it did X.
Afterwards one of the maintainers came up and asked me to make a bug report on Github. So I did.
I lack the expertise or time to implement this feature and the feature is still not implemented. But it's useful to have the feature request on Github because other people find and there are a few comments on it now.
Documenting stuff like this is important for maintainers. It's when the documentation turns into a form of harassment that people need to fuck off.
[+] [-] phoronixrly|3 years ago|reply
I will never understand the concept of competition in the context of open-source. I would love to have my projects be superseded by something better that is someone else's doing and responsibility.
[+] [-] 2muchcoffeeman|3 years ago|reply
But I think the post still applies. If I use your project, it’s up to me to communicate bugs clearly and in a manner useful to yourself if I want a chance of getting it fixed. Otherwise, I shouldn’t expect anything or go and do it myself.
[+] [-] Ygg2|3 years ago|reply
Are you paid for maintaining that software? If not, and are doing another job on the side, then other people aren't entitled to your free time.
[+] [-] Barrin92|3 years ago|reply
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.
[+] [-] pdpi|3 years ago|reply
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.
[+] [-] elihu|3 years ago|reply
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.
[+] [-] nextlevelwizard|3 years ago|reply
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.
[+] [-] kweingar|3 years ago|reply
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?
[+] [-] oxplot|3 years ago|reply
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.
[+] [-] brunooliv|3 years ago|reply
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.
[+] [-] bakugo|3 years ago|reply
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.
[+] [-] viridian|3 years ago|reply
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.
[+] [-] xPaw|3 years ago|reply
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.
[+] [-] bluenose69|3 years ago|reply
"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.
[+] [-] avg_dev|3 years ago|reply
> 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
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.
[+] [-] ducktective|3 years ago|reply
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.
[+] [-] have_faith|3 years ago|reply
Too easily forgotten these days it seems.
[+] [-] implements|3 years ago|reply
(“Fuck it!” is “I give up!” in British English)
[+] [-] oh_my_goodness|3 years ago|reply
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 ***
[+] [-] oezi|3 years ago|reply
[+] [-] systemvoltage|3 years ago|reply
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.
[+] [-] Andrew_nenakhov|3 years ago|reply