I do agree with what I take as the general message: most people don't really understand how open source works and have unreasonable expectations. Maintainers don't owe users anything unless the user actually pays for it and the maintainer accepts the money for the task.
Developers should understand what it actually means to depend on a project. If one needs a fix or a change down the line, it could be that nobody will be there to do it for free, or at all. Therefore one should be ready to either pay or take over the maintenance. And this should be carefully put in balance every time: "Should I add this dependency, or should I write it myself?".
Modern language package managers like cargo amplify this problem by making it almost too easy to add tons of dependencies (and then be pissed at the maintainers who don't want to maintain for free or at all).
> Modern language package managers like cargo amplify this problem by making it almost too easy to add tons of dependencies...
Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up.
One of the worse offenders I have seen was adding whole Pandas and the kitchen sink for a simple table lookup. I have seen other programs which adds almost hundred libraries for something which can be implemented in a relatively simple way.
The problem with this approach is not shipping unused functions at the end. Pruning them is an old practice.
The problem is inclusion of that much libraries creates a dependency hell, because a higher level library pulls in approximately 5 more libraries which are generally shared amongst other libraries you potentially pull.
Library A updates its' dependency to library C to a new, more recent minimum, but library B depends on C's behavior which is recently changed. Hence A requires C > v3, but B requires C==v2. Then the fun begins.
Bonus points for having a serious CVE/RCE as a reason for updating C to v3 in the first place.
This doesn't change the fact that some security fixes forces behavioral changes, and semver doesn't protect you against that.
You fix the bug, and the behavior changes, because your design was wrong in the first place. Now there is at least one library which depends on that behavior so bad, so they can't change their dependency chain in two days.
The dev who you made download and build all those deps just to throw them away for one. Not super fond of the attitude that efficiency for the end user is a necessary evil... but a dev can be expected to endure any indignity.
What about the dev who is making the library for their own purposes, they don't matter? Be thankful for the opportunity to use their work for free; you can do your own thing if you don't like theirs.
Yes, you can't criticize that somebody made a big library - you have no idea why, how and under what circumstances it was made. Even if the only reason is that the author doesn't find it fun to maintain a bunch of libraries, that's still a valid reason. It's actually exactly that most of the time - it's a hobby, not a job to them. They probably maintain few dozen microservices at work, why bring it home too? In other cases you have resource constraints, cost/benefit optimization, etc.
You can say you'd prefer a bunch of smaller more focused libraries, but criticizing that big one is wrong, especially if you got it for free including the source and a license to distribute and modify it. And this has nothing to do with how you should or should not code, there's no definite way how everyone should code; some prefer batteries-included frameworks and some prefer small focused pieces - it's an opinion more than a fact that small library is better. But even if not, people are free to share their bad work and you are free to pass on it, provide suggestions or patches - but criticizing it is entitled.
BTW it's funny to argue that you should be able to criticize a big library for being too big right under a discussion about dependency version requirement hell. One big library that includes everything would alleviate that pain - perhaps that's what the authors were looking to fix. As I said, this is an opinion, not fact.
> Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up.
Well then which one is it? There’s no middle ground, unless at some point you decide it’s now worth using a big library and start replacing your own code.
If you decide to write everything from scratch, good luck to your users, they’re not getting a better product.
I use big and well matured libraries for the critical parts of my code. These can be logging, option/file parsing, or linear algebra.
When I add these libraries, I use most parts of them at the end of the day.
However for other one-off things like internal state handling or stuff which I can prop up using the standard library, I refuse to use external libraries.
I kindly disagree on the part of they're not getting a better product. On the contrary. They require to manage less dependencies, most critical parts are well cooked/tested, and other parts are built using the standard library which is built to build these things.
When rolling things forward, I need to juggle less dependencies, too. So things can move forward easier.
It's not like I'm banging the keyboard and shouting done when it prints something meaningful to screen.
unless using a language that supports tree-shaking.
Also, you could also use the same interface (fn-signature etc), or even add a flag for if the lib is installed (in python, try-except over import, with "dummy" module as fallback).
*Maintainers don't owe users anything unless the user actually pays for it and the maintainer accepts the money for the task.*
I have a nitpick on that take. If maintainer was actively building community and advocating use of his project (for whatever reasons but usually to gain audience - money is not the only value exchange that there is) they still do owe users bug fixes or reviewing bug fixes made by community. Especially if there were other community contributions, cash on hand is too specific.
If someone doesn't want to owe users anything, don't make project open source or make it clear "don't use this or fork for yourself, please" in read-me or something.
But also one should not pull dependencies willy-nilly especially if one is building business on top of that.
Free Software ecosystem is not black and white (i.e. Build a community or don't share).
I put my software in the open with a license which I think is fair, because I hope someone might find it useful, with a completely neutral stance. On the other hand, I set my expectations with the license I assign to my codebase. If nobody cares about what I do, I'm also fine with it. At the end of the day, I wrote that thing for myself in the first place.
If somebody decides to contribute something back, my primary responsibility is to act as decently as other party allows me. They can report a bug, send in a fix, or ask something.
If the proposed change is favorable to both of us (i.e. it also fits into the design/role I have in my mind for that codebase, or doesn't disturb it), why not work together and make something better?
If the change makes the software unfit for me, but fit for the other party, they're free to fork and maintain their fork as they fit, as long as they honor the license. This is why is this thing is in the open.
But, if the requester wants me to implement their changes to make the software fit for themselves, while making it unfit for me, and want to pass the burden of maintenance on me, then sorry, we can't cooperate.
Plus, who decides which codebase I open to the world, and in what way?
That's not what I wrote *Build a community or don't share*
I wrote that if you build community you have responsibility. If you don't want to build a community be clear about it.
My beef is with people who build community for "fame" and for "money somewhere along the road" - that are getting burned out because money are not there. Where we have loads of libraries by genuine people.
I think you just have to accept that projects are not evergreen. Some popular tools we used 10 years ago are gone for the most part, and it’s no one’s fault.
Did maintainers make any promise? Even so they can break promises made for some reasons (especially sickness, accidents, etc.). Whatever type of contributions (money, work, feedbacks, etc.) doesn't make maintainers owe any work to contributors unless previously mutually agreed upon.
Be prepared to DIY (PR, fork, other forms) if you are willing to but you don't owe anything to other people unless you choose to and express that explicitly, and that's the same for maintainers.
> If someone doesn't want to owe users anything, don't make project open source or make it clear "don't use this or fork for yourself, please" in read-me or something.
That's where I believe you misunderstand open source, and that's the point of the article.
Because I make my project open source does not imply anything other than the terms of the licence. Of course it's okay to report a bug (it's even nice) or to open a PR. But asking "is this maintained?" as part of the decision process before depending on a project just shows some misunderstanding about how open source works, IMHO.
You plucked that quote from the comment you replied to but carefully didn't include the critical lead in: "If maintainer was actively building community and advocating use of his project". All the replies are hung up nitpicking some later wording which wasn't the point.
Having the standard website/readme with a bunch of claims about how awesome your software is as a way to entice other developers to get excited by it, start using it, and even (gasp) depend on it absolutely implies something more than the mere terms of the license.
Put elsewise: if you don't want the expectation of feeding people, haven't put any thought into how you will actually make that happen, and are just going to get defensive when people are annoyed at how you don't own a grill, you have no business inviting everyone to a BBQ.
> but carefully didn't include the critical lead in
Because it's irrelevant to my point. My point being that if you don't sign a contract with me where I commit to do something for you, then I don't owe you anything.
If you misunderstand open source and have wrong expectations because of it, then you will get frustrated. My point is that it is important for you to understand that open source just means that the author shares something for free, no strings attached. Maybe the maintainer is super responsive today, and that's great. But you have to know that they may stop responding tomorrow. And you should be ready to handle that if you depend on their project for something important.
I disagree. Open source maintainers owe nothing to anybody unless they've explicitly made some sort of commitment/promise beyond just releasing something under an OSS license.
> But also one should not pull dependencies willy-nilly especially if one is building business on top of that.
If you're building a business, you want to avoid all such dependencies as much as possible, open source or not. The big advantage to using open source code, though, is that you don't have to rely on someone else -- not even the maintainer -- to keep things going for you. You can maintain it in-house and eliminate that external dependency.
Nope. Open source’s only purpose is make something available in case anyone wants to pick it up. The “no warranty or assurance of fitness for a particular purpose” verbiage in open source licenses is precisely what this means: the author disclaims all responsibility, and that’s it.
That's a legal protection, it has little bearing on whether the creator 'owes' (in the informal sense) anything to the software's users/community.
If the software isn't being sold, it presumably won't be legally required to be fit for purpose in any sense. The no warranty provided text is just stating this explicitly. (Usual disclaimer: I'm not a lawyer, this is not legal advice, etc.)
This sounds suspiciously like the "you should work for the exposure" argument given in the arts industry. Landlords don't accept expore for rent and grocers don't accept exposure for food. It's just a misunderstanding of how things work rooted in greed and entitlement.
A worker's time is worth their wage. If you're paying nothing, nothing is owed. If you pay nothing for a creation, the creator owes you nothing. That's the contact.
I’m not sure cargo is really the fault rather than developers who import a library just to use a trivial utility function in one place. Modern package managers solve 1000x problems and make one pitfall slightly easier. But it’s still a very easily avoided problem.
If you want to go with that analogy, it's more like opening a community cafe and hanging a sign on the wall saying "please bring a dish for our free communal meal - we'd be happy to add it (when we get around to it, if we like it, and if the cafe is still open - good luck, because you probably won't know if it has closed!)
I have a fairly popular free/open source project and I both agree and disagree with the author. Mostly users are polite and non-entitled, but it's exhausting answering all the (very polite) questions and requests for help.
I've had to turn down dishes that wouldn't have worked for the cafe, and it makes me feel bad. I've requested users contact me before writing a PR but of course people don't read the FAQ.
> it's more like opening a community cafe and hanging a sign on the wall saying "please bring a dish for our free communal meal - we'd be happy to add it (when we get around to it, if we like it, and if the cafe is still open - good luck, because you probably won't know if it has closed!)
that may be a better analogy for you, but i reckon the best-fit analogy is up to each individual, depending on where they want to set their boundaries.
some may prefer the analogy of being an author of a book: the author researches and writes a 10 chapter book, then copy-edits and publish the finished work, perhaps releasing it into the public domain. not obvious that the author would be willing to copy-edit and release a 2nd edition of the book incorporating an 11th chapter written by someone else.
> I've had to turn down dishes that wouldn't have worked for the cafe, and it makes me feel bad. I've requested users contact me before writing a PR but of course people don't read the FAQ.
As someone who has submitted PRs without much communication to repos asking to talk before PR are submitted: in my case these were generally cases where it just seemed easier for me as a user to just change the code rather than to contact the author, try to make some sort of social interaction online, explain why and what I'm trying to do, potentially enter some sort of negotiation trying to hammer out some agreement and then doing the code change PR dance anyway. Much easier to just make some straightforward code changes - done and dusted in a few hours.
And sure, I completely understand if a maintainer then says "no thank you". That's the risk I took by my just do it attitude. No hard feelings on my side.
I do that, too! Sometimes it makes most sense: for instance if I found and fixed a bug, I don't need to open an issue to ask permission for the PR; I just send the PR.
Also many times, I find it easier to express my idea with code (by making a PR with the change) than with text.
I only open an issue first if the code contribution will take a considerable amount of time and I want to make sure that the maintainer is fine with it before I start. Or if I need help from the maintainer, of course.
with the last project that i had some fixes for, i forked the project, fixed the issues so they would work for me, and then opened issue reports on the upstream repo, sharing the problem, and how i fixed it with links to the commits, in order to open a discussion to find out if that is the right fix for the problem i found. i didn't want to submit a PR as long as i wasn't confident that this was an appropriate fix.
on the other hand, in that project, just submitting a PR might have gotten me more feedback (i didn't receive any responses to my issues)
the main point though is that i fix problems for my own needs, so why should i ask you before doing so? but then i also do not have any expectations that my fix is accepted. if it isn't, then i'll just keep running my own fork.
To be fair, at this point GitHub is the only thing most developers know. To the point where most developers don't really know the difference between "git" and "GitHub".
I recently talked with a junior developer fresh out of school who was very surprised that you could just use git locally to track changes to your own files, without ever connecting to a server. He seemed to think git is the CLI for Github.
The number of times I've encountered this truly amazes me. Another weird misconception I've been seeing more and more is the idea that it has to be on GitHub to count as an OSS project.
I have seen shell scripts written "directly" as GitHub actions. Meaning that it was impossible to run them locally... assuming that everyone always has an Internet connection and GitHub is never down. I guess it is "portable" in a sense (as long as you have a browser and Internet access, you can "run" the script, no matter your platform).
I feel he may be overthinking it.. people just want to understand the best options available for their use-case.
If you see a project with no new commits for 3 years (1), you would rather not invest time trying to get it working if there is a newer/maintained project.
1 And whilst you may argue the software is "finished", reality is very little software survives without maintenance. Unless you have zero dependencies and future exploits in no way apply.
pystring [1] is such a "finished" project, they even have a note in the readme that the project is not dead (I guess they got a lot of such questions too). It's a small yet complete library with a very narrow focus, so there really is nothing to change once it's done (and despite that recently merged CI pipeline having failed on macOS for some reason, it works just fine there, I make heavy use of pystring in one my projects across Windows, macOS and Linux).
Quote:
"Note: Despite the infrequent updates, this repo is not dead/abandoned - just stable! We use it every day at Imageworks."
As a person who writes code for himself, I generally write a note about the state of the repository.
In my case, if there's no commit for three years, this means that code is in production for at least three years, and is not broken on any of my systems, so nothing is being updated.
This is generally result of my (sometimes unreasonable) effort to write everything with absolute minimum number of libraries, and vendoring of the libraries I use. So, clone, (optionally) compile, use.
If it doesn't work for you, let me know. We can work something out, as long as it's reasonable.
Yep, I've got some self-made python glue that's been running for at least half a decade with zero changes.
It's all in Github and there haven't been any commits because it's doing its current job with 100% precision and I don't need a single additional feature.
> I feel he may be overthinking it.. people just want to understand the best options available for their use-case.
As I understand it, that is the point of the author: people feel the need to "ping" the maintainer because they don't really understand how open source works. But receiving a "pong" does not mean it is "more maintained", does it? You could ask "is this project maintained?", I could answer in the minute "yes, it is!", then you could ask for a feature and I would just not implement it for free.
In the end, before choosing to depend on a project, you should ideally read the code base and decide whether you would feel comfortable modifying it (fixing a bug or adding a feature) yourself. If not, maybe it would be less risky for you to write your own code. And if you can't do that, then you have to accept that you rely on code that is out of your depth, and choose whether it is a risk you are willing to take or not.
It's also perfectly fine to release source code out of the github/gitlab decorum: Just the source with the license and maybe an email. No git repo history, no comments, no PRs, no bug reports. That would probably filter a large number of self-entitled consumers.
This is something I don't understand about the author's stance. Why are they seemingly insulted by the prompt? The insult doesn't come from the asker's lack of helpfulness or unwillingness to fork or merge request, that's all irrelevant in their eyes. Just from the questions in of themselves, be them loaded or not.
But there IS an implicit contract at the moment of creation of a repository which states "you may contact me here" and... that's what those people did? The only way to address a maintainer with the question beyond email, which isn't generally available anymore in the current environment, is the repo issues. Issues and merge requests are opt-out features, not opt-in, so, unmaintained repositories will in fact appear completely indistinguishable from maintained one. But repo creation is opt-in. Repo public status is opt-in. You can retract both of those contracts.
If the question annoys someone so deeply - you can stop reading other repo's public issues, and you got a toggle to mute your own. I also am annoyed with people and things. I wish mosquitos disappeared, but I'm not going to make a ideological statement on it with so many more actionable approaches avaiable. Heck, even if the whole purpose of the article is to vent, you still got a way to direct that emotion "productively" - just give a cute little angry emoji to the issue's author.
I think it's interesting to reflect on what we mean with maintain vs support.
And while I agree with the author that people often expect too much of what maintaining mean at the same time I don't understand why the author want to be able to say that he maintains the library while ignoring potential bug ...
If you are ignoring bug reports just say it's not maintained and if your forge allows it just disable issues, and it will be clear to users what they should expect.
some bugs are critical, and some are a mere inconvenience. for example, my app not looking right on your device could be considered a bug. but it works fine on mine because i have a different resolution. so it's not a bug for me, but rather the application was not designed to work on your device.
the same goes for any bugs that result from interactions with a different environment. an environment i don't have, and possibly can't even test against.
i'll fix those bugs if i have time and motivation (strongly influenced by the tone of the submitter, but also by the fact that i have a family and need to make a living) and if i can verify that the fix doesn't impact my own use.
If you feel the need to write an entry for this at the end, I recommend you go back and improve the rest of the document so this section isn’t necessary.
Even when someone has been actively rude to you (which isn’t the case here, as the document is unprompted), being rude back only makes it worse. But being kind sometimes makes the other person change their attitude, or at the very least doesn’t make future contributors think of you as an asshole too. And there’s the bonus that sometimes you misinterpret someone as rude when they were not, so being disrespectful makes you the sole offender in a public interaction. Remember you can always not reply to someone, or politely say you don’t accept abuse—especially not when providing something to others at the expense of your free time and at no cost for them—and lock the conversation and/or block the user.
You think when you’re rude back you’re shoving the other person away so they leave you alone. You’re not. You’re giving them ammunition to come back harder and for others to pile on. Be kind and deprive them of their weapons instead. Ask them to leave if they’re repeat offenders. Force them to leave if you have to, but don’t make a show of it.
Remember you’re the maintainer. It’s your house that you opened for others to visit. Don’t give them reason to trash it.
64 comments
[ 2.1 ms ] story [ 122 ms ] threadDevelopers should understand what it actually means to depend on a project. If one needs a fix or a change down the line, it could be that nobody will be there to do it for free, or at all. Therefore one should be ready to either pay or take over the maintenance. And this should be carefully put in balance every time: "Should I add this dependency, or should I write it myself?".
Modern language package managers like cargo amplify this problem by making it almost too easy to add tons of dependencies (and then be pissed at the maintainers who don't want to maintain for free or at all).
Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up.
One of the worse offenders I have seen was adding whole Pandas and the kitchen sink for a simple table lookup. I have seen other programs which adds almost hundred libraries for something which can be implemented in a relatively simple way.
Then people whine about dependency hell.
Well that's where modern bundler steps in - who cares if you throw the unnecessary cruft away during build process?
Except in Python where a dependency might uninstall your desktop GUI and switch the init system, perhaps.
The problem is inclusion of that much libraries creates a dependency hell, because a higher level library pulls in approximately 5 more libraries which are generally shared amongst other libraries you potentially pull.
Library A updates its' dependency to library C to a new, more recent minimum, but library B depends on C's behavior which is recently changed. Hence A requires C > v3, but B requires C==v2. Then the fun begins.
Bonus points for having a serious CVE/RCE as a reason for updating C to v3 in the first place.
You fix the bug, and the behavior changes, because your design was wrong in the first place. Now there is at least one library which depends on that behavior so bad, so they can't change their dependency chain in two days.
You can say you'd prefer a bunch of smaller more focused libraries, but criticizing that big one is wrong, especially if you got it for free including the source and a license to distribute and modify it. And this has nothing to do with how you should or should not code, there's no definite way how everyone should code; some prefer batteries-included frameworks and some prefer small focused pieces - it's an opinion more than a fact that small library is better. But even if not, people are free to share their bad work and you are free to pass on it, provide suggestions or patches - but criticizing it is entitled.
BTW it's funny to argue that you should be able to criticize a big library for being too big right under a discussion about dependency version requirement hell. One big library that includes everything would alleviate that pain - perhaps that's what the authors were looking to fix. As I said, this is an opinion, not fact.
Well then which one is it? There’s no middle ground, unless at some point you decide it’s now worth using a big library and start replacing your own code.
If you decide to write everything from scratch, good luck to your users, they’re not getting a better product.
When I add these libraries, I use most parts of them at the end of the day.
However for other one-off things like internal state handling or stuff which I can prop up using the standard library, I refuse to use external libraries.
I kindly disagree on the part of they're not getting a better product. On the contrary. They require to manage less dependencies, most critical parts are well cooked/tested, and other parts are built using the standard library which is built to build these things.
When rolling things forward, I need to juggle less dependencies, too. So things can move forward easier.
It's not like I'm banging the keyboard and shouting done when it prints something meaningful to screen.
unless using a language that supports tree-shaking.
Also, you could also use the same interface (fn-signature etc), or even add a flag for if the lib is installed (in python, try-except over import, with "dummy" module as fallback).
I have a nitpick on that take. If maintainer was actively building community and advocating use of his project (for whatever reasons but usually to gain audience - money is not the only value exchange that there is) they still do owe users bug fixes or reviewing bug fixes made by community. Especially if there were other community contributions, cash on hand is too specific.
If someone doesn't want to owe users anything, don't make project open source or make it clear "don't use this or fork for yourself, please" in read-me or something.
But also one should not pull dependencies willy-nilly especially if one is building business on top of that.
I put my software in the open with a license which I think is fair, because I hope someone might find it useful, with a completely neutral stance. On the other hand, I set my expectations with the license I assign to my codebase. If nobody cares about what I do, I'm also fine with it. At the end of the day, I wrote that thing for myself in the first place.
If somebody decides to contribute something back, my primary responsibility is to act as decently as other party allows me. They can report a bug, send in a fix, or ask something.
If the proposed change is favorable to both of us (i.e. it also fits into the design/role I have in my mind for that codebase, or doesn't disturb it), why not work together and make something better?
If the change makes the software unfit for me, but fit for the other party, they're free to fork and maintain their fork as they fit, as long as they honor the license. This is why is this thing is in the open.
But, if the requester wants me to implement their changes to make the software fit for themselves, while making it unfit for me, and want to pass the burden of maintenance on me, then sorry, we can't cooperate.
Plus, who decides which codebase I open to the world, and in what way?
I wrote that if you build community you have responsibility. If you don't want to build a community be clear about it.
My beef is with people who build community for "fame" and for "money somewhere along the road" - that are getting burned out because money are not there. Where we have loads of libraries by genuine people.
Can you give out some examples of projects that function(ed) on this principle?
Did maintainers make any promise? Even so they can break promises made for some reasons (especially sickness, accidents, etc.). Whatever type of contributions (money, work, feedbacks, etc.) doesn't make maintainers owe any work to contributors unless previously mutually agreed upon.
Be prepared to DIY (PR, fork, other forms) if you are willing to but you don't owe anything to other people unless you choose to and express that explicitly, and that's the same for maintainers.
That's where I believe you misunderstand open source, and that's the point of the article.
Because I make my project open source does not imply anything other than the terms of the licence. Of course it's okay to report a bug (it's even nice) or to open a PR. But asking "is this maintained?" as part of the decision process before depending on a project just shows some misunderstanding about how open source works, IMHO.
Having the standard website/readme with a bunch of claims about how awesome your software is as a way to entice other developers to get excited by it, start using it, and even (gasp) depend on it absolutely implies something more than the mere terms of the license.
Put elsewise: if you don't want the expectation of feeding people, haven't put any thought into how you will actually make that happen, and are just going to get defensive when people are annoyed at how you don't own a grill, you have no business inviting everyone to a BBQ.
https://imgur.com/a/chris-pratt-barbecue-gDL2O
https://www.reddit.com/r/funny/comments/3v8svx/barbecue_at_c...
Because it's irrelevant to my point. My point being that if you don't sign a contract with me where I commit to do something for you, then I don't owe you anything.
If you misunderstand open source and have wrong expectations because of it, then you will get frustrated. My point is that it is important for you to understand that open source just means that the author shares something for free, no strings attached. Maybe the maintainer is super responsive today, and that's great. But you have to know that they may stop responding tomorrow. And you should be ready to handle that if you depend on their project for something important.
> But also one should not pull dependencies willy-nilly especially if one is building business on top of that.
If you're building a business, you want to avoid all such dependencies as much as possible, open source or not. The big advantage to using open source code, though, is that you don't have to rely on someone else -- not even the maintainer -- to keep things going for you. You can maintain it in-house and eliminate that external dependency.
Most free-beer software state "Provided as-is with no warranty expressed or implied." somewhere in their readme or licensing terms.
Of course, fucking noone reads readmes or licenses.
If the software isn't being sold, it presumably won't be legally required to be fit for purpose in any sense. The no warranty provided text is just stating this explicitly. (Usual disclaimer: I'm not a lawyer, this is not legal advice, etc.)
A worker's time is worth their wage. If you're paying nothing, nothing is owed. If you pay nothing for a creation, the creator owes you nothing. That's the contact.
And property and grocery goods aren't even the same category as IP - You can't consume the same cabbage repeatedly.
> That's the contact.
I think you mean contract, but you are ignoring the social contract here. A "worker" isn't going around advocating their own project(s).
My code is open source, at a minimum it’s there for your own perusal to be copy-pasted. I don’t owe you anything.
or allowing community members the power to do these things, without having to fork.
It's like showing up unannounced at someone's place with a grocery bag of ingredients and asking them to cook for you.
"But I brought steak and brussel sprouts! Surely you like these things too. Why don't you just prepare the meal now?"
It might be a great meal and a generous offering, but clearly it's not exactly in the spirit of a gift to do this.
I have a fairly popular free/open source project and I both agree and disagree with the author. Mostly users are polite and non-entitled, but it's exhausting answering all the (very polite) questions and requests for help.
I've had to turn down dishes that wouldn't have worked for the cafe, and it makes me feel bad. I've requested users contact me before writing a PR but of course people don't read the FAQ.
that may be a better analogy for you, but i reckon the best-fit analogy is up to each individual, depending on where they want to set their boundaries.
some may prefer the analogy of being an author of a book: the author researches and writes a 10 chapter book, then copy-edits and publish the finished work, perhaps releasing it into the public domain. not obvious that the author would be willing to copy-edit and release a 2nd edition of the book incorporating an 11th chapter written by someone else.
As someone who has submitted PRs without much communication to repos asking to talk before PR are submitted: in my case these were generally cases where it just seemed easier for me as a user to just change the code rather than to contact the author, try to make some sort of social interaction online, explain why and what I'm trying to do, potentially enter some sort of negotiation trying to hammer out some agreement and then doing the code change PR dance anyway. Much easier to just make some straightforward code changes - done and dusted in a few hours.
And sure, I completely understand if a maintainer then says "no thank you". That's the risk I took by my just do it attitude. No hard feelings on my side.
Also many times, I find it easier to express my idea with code (by making a PR with the change) than with text.
I only open an issue first if the code contribution will take a considerable amount of time and I want to make sure that the maintainer is fine with it before I start. Or if I need help from the maintainer, of course.
on the other hand, in that project, just submitting a PR might have gotten me more feedback (i didn't receive any responses to my issues)
the main point though is that i fix problems for my own needs, so why should i ask you before doing so? but then i also do not have any expectations that my fix is accepted. if it isn't, then i'll just keep running my own fork.
Take the issue by sending a PR. Don't ask to ask, do.
If you see a project with no new commits for 3 years (1), you would rather not invest time trying to get it working if there is a newer/maintained project.
1 And whilst you may argue the software is "finished", reality is very little software survives without maintenance. Unless you have zero dependencies and future exploits in no way apply.
This was the default for most software up until maybe a decade ago, when everything-in-the-cloud software-as-a-service ate the world
Quote:
"Note: Despite the infrequent updates, this repo is not dead/abandoned - just stable! We use it every day at Imageworks."
[1] https://github.com/imageworks/pystring
In my case, if there's no commit for three years, this means that code is in production for at least three years, and is not broken on any of my systems, so nothing is being updated.
This is generally result of my (sometimes unreasonable) effort to write everything with absolute minimum number of libraries, and vendoring of the libraries I use. So, clone, (optionally) compile, use.
If it doesn't work for you, let me know. We can work something out, as long as it's reasonable.
It's all in Github and there haven't been any commits because it's doing its current job with 100% precision and I don't need a single additional feature.
As I understand it, that is the point of the author: people feel the need to "ping" the maintainer because they don't really understand how open source works. But receiving a "pong" does not mean it is "more maintained", does it? You could ask "is this project maintained?", I could answer in the minute "yes, it is!", then you could ask for a feature and I would just not implement it for free.
In the end, before choosing to depend on a project, you should ideally read the code base and decide whether you would feel comfortable modifying it (fixing a bug or adding a feature) yourself. If not, maybe it would be less risky for you to write your own code. And if you can't do that, then you have to accept that you rely on code that is out of your depth, and choose whether it is a risk you are willing to take or not.
It does, potentially (though I don't disagree that most people would misinterpret it).
It means there is someone there, who you could potentially ask some questions nicely and get an answer (e.g., "Why is this line of code here?").
But there IS an implicit contract at the moment of creation of a repository which states "you may contact me here" and... that's what those people did? The only way to address a maintainer with the question beyond email, which isn't generally available anymore in the current environment, is the repo issues. Issues and merge requests are opt-out features, not opt-in, so, unmaintained repositories will in fact appear completely indistinguishable from maintained one. But repo creation is opt-in. Repo public status is opt-in. You can retract both of those contracts.
If the question annoys someone so deeply - you can stop reading other repo's public issues, and you got a toggle to mute your own. I also am annoyed with people and things. I wish mosquitos disappeared, but I'm not going to make a ideological statement on it with so many more actionable approaches avaiable. Heck, even if the whole purpose of the article is to vent, you still got a way to direct that emotion "productively" - just give a cute little angry emoji to the issue's author.
And while I agree with the author that people often expect too much of what maintaining mean at the same time I don't understand why the author want to be able to say that he maintains the library while ignoring potential bug ...
If you are ignoring bug reports just say it's not maintained and if your forge allows it just disable issues, and it will be clear to users what they should expect.
some bugs are critical, and some are a mere inconvenience. for example, my app not looking right on your device could be considered a bug. but it works fine on mine because i have a different resolution. so it's not a bug for me, but rather the application was not designed to work on your device.
the same goes for any bugs that result from interactions with a different environment. an environment i don't have, and possibly can't even test against.
i'll fix those bugs if i have time and motivation (strongly influenced by the tone of the submitter, but also by the fact that i have a family and need to make a living) and if i can verify that the fix doesn't impact my own use.
If you feel the need to write an entry for this at the end, I recommend you go back and improve the rest of the document so this section isn’t necessary.
Even when someone has been actively rude to you (which isn’t the case here, as the document is unprompted), being rude back only makes it worse. But being kind sometimes makes the other person change their attitude, or at the very least doesn’t make future contributors think of you as an asshole too. And there’s the bonus that sometimes you misinterpret someone as rude when they were not, so being disrespectful makes you the sole offender in a public interaction. Remember you can always not reply to someone, or politely say you don’t accept abuse—especially not when providing something to others at the expense of your free time and at no cost for them—and lock the conversation and/or block the user.
You think when you’re rude back you’re shoving the other person away so they leave you alone. You’re not. You’re giving them ammunition to come back harder and for others to pile on. Be kind and deprive them of their weapons instead. Ask them to leave if they’re repeat offenders. Force them to leave if you have to, but don’t make a show of it.
Remember you’re the maintainer. It’s your house that you opened for others to visit. Don’t give them reason to trash it.