Please Don't Ask If an Open Source Project Is Dead
minimaxir.com
minimaxir.com
I think it would behoove open-source developers who are sensitive to dealing with potential users and collaborators to more clearly state and set expectations on the repository's README. Many authors clearly like to use open-source packages they maintain as a sort of professional portfolio, which is perfectly fine, and this author even asks for paid support at the bottom of the README. Is it really out of line to ask about the status if it is not otherwise clear?
All of these little scuffles from maintainers towards contributors and users are often from lack of communication and expectation setting on the side of the maintainer(s) and code owner(s), although contributors and users can also be demanding. I think the issue is that everyone has their version of expectations in their head but not everyone shares those. It's the same as with any human communication, so the more information the better.
I think there is a bit of a mismatch between advertising code, asking for paid support, etc. and then being upset at activity in the repo without more clear guidelines. I have seen plenty of repositories that very clearly state that they won't accept pull requests, they won't accept anything but the simplest of bug fixes, that this library is really just for the author's use but it is being open sourced in case it's useful to someone else. That's a good example of setting expectations that provides more context than pointing to a license.
But there's some general commentary here that I think is applicable to maintainers appropriately setting expectations that contributors can abide to or be held to when interacting with the given projects.
In my opinion, it's perfectly reasonable to ask if a project is still being maintained. I often come across packages that have had no updates in a year, and it's hard to know if that's because they aren't being maintained, or if they are being maintained and no updates have been required.
I hear the argument from some open-source maintainers that they have no obligations to the people who use (and depend on) their software. But there are lots of open-source developers that actually want people to use (and to depend) on their software. Being an open-source developer of a widely-used application or package can bring great benefits to the developer - at the very least it garners them respect from the community and potentially from future employers, and in some cases it can lead to huge financial rewards: acquisitions, great career prospects, paid trips around the world to speak at conferences, etc.
It's definitely more of a two-way street than some developers would lead you to believe.
>"What's your time commitment?"
Why didn't you post the whole comment?
> I really like the philosophy and design of this package but it appears its development process has basically stopped. I don't mean to pressure or to be rude but if @minimaxir could share his thoughts on this I would really appreciate it.
> Can we expect development by the maintainer?
> How can the community support?
> Are you open to PRs and reviewing them?
> What's your time commitment?
> Should someone just fork the repo and develop it from there?
> Thanks
He seems burned out over trying to keep up with the fast pace of AI development (which is understandable). He's clearly putting inhuman amounts of effort into whatever he's doing and it's wrecking him, so I'm guessing he's perceiving questions about his project's longevity because he hasn't addressed issues from six months ago as seeing vultures circling in anticipation of his imminent demise. He's giving it his all and he's being presumed dead after six months...what more can he give?
That's all totally ok and understandable, and I hope he takes some time off to relax in the next few weeks. But I also wish that he would take this article down. He's externalized his own internal struggle as authoritative-sounding advice proscribed to the community at large, based on his own misguided perceptions of perfectly-acceptable discourse. It's Toxic-with-a-capital-T.
The polite thing to do is to check in on the status, in a public setting, and get an answer from the maintainer, which is what this person is doing. Yes, it's entirely possible that there's nothing new to add to it, and it's "done." But what if there is somehow some sort of major change to OpenAI's API, or they deprecate [current API version] and you're expected to migrate to a new one? Or, worse still, a major exploit is found? These are valid concerns that even free users would want to know, and the best way to do that is to check the pulse of the project.
The person in the screenshot made extra care to be polite about asking, and they're now being put on blast for it. Also worth mentioning is the user who commented saying there are "relevant and important" PRs and issues that haven't been addressed over the last year. Whether they're relevant and important, I don't know, based off my experience I'll say likely not... But the fact that you're allowing irrelevant and non-important things to go stale, without closing them, only lends credence to the possibility that the project is abandoned and, if something were to go wrong in the future, nobody would be around to fix it.
Also, your statement that they're offering to fork it as a "threat" against your project is not at all what is going on. If your project got forked with reason "original was abandoned," I think you'd be even more frustrated than you are now. They asked what the status was before putting in the work to fork it and attempt to move users away from your project. That is a courtesy notice, not a threat, designed to save everyone time and frustration.
It is a good thing for someone's open-source code to have interest by the community, and for users to want to use it. Getting angry at those same users for checking on the status won't do any good.
The more constructive open source move would be to file an issue explicitly noting "the upstream dependency may breaksand there will need to be changes to accomidate it" or "there is a zero-day that needs to be fixed ASAP" instead of "is this repo dead." In the former case, others will have more information and it saves the maintainers time.
Many of my other projects have had people do that and I've been very greatful.
> The person in the screenshot made extra care to be polite about asking, and they're now being put on blast for it.
"What's the status of development?" or "Will this incorporate X feature coming up?" is polite and gives enough information on aliveness. The comment I screenshotted is passive-aggressive at best, and there's no really good way to ask "is this repo dead" without being passive-aggressive. My day-to-day job that actually pays me a salary wouldn't ever provide a bulleted list of the reasons I suck, let alone a project I develop in my spare time.
If I mass close stale unimportant issues/PRs the argument would then be "you don't want issues/PRs so no reason to contribute." Lose-lose situation.
> Also, your statement that they're offering to fork it as a "threat" against your project is not at all what is going on. If your project got forked with reason "original was abandoned," I think you'd be even more frustrated than you are now.
I would definitely not be frustrated (assuming that they give proper license/credit to the source code which is a different issue)
The fork comment wasn't directly related to the screenshot, but was a part of other discussions over the years where people say "I'd use a fork but the forks aren't as popular" which becomes an annoying Catch-22.
It's polite and it asks questions that are very pertinent, given how you claim to manage your repos.
> How can the community support?
I've been involved in a project that accepted drive-by PRs and I get that that sucks. You know what helped? People who asked how they could tick something off my personal todo list before they tried to crowbar their pet feature in.
> Can we expect development by the maintainer? > Are you open to PRs and reviewing them? > What's your time commitment? > Should someone just fork the repo?
All of these questions really just ask the same one: should I fork your repo if I want to make a change.
Your very next point discusses a repo where you don't accept PRs, don't reply to issues, but also refuse to say it's not being "developed". You literally ask for PRs in the README.md, but then ignore them? Are people supposed to figure out that you think it's perfect as-is and doesn't need more input in contradiction to that?. All of the questions other than #2 are literally just trying to get you to put that in writing.
Forks suck. There's no if's, and's, or but's.
At best the original project is dead and the fork goes on to be kind of a successor. But it never really will be, because 90% of people will stay on the original, 5% of people will move to the fork, 18% of people will post on both repos about how it's unclear which one they should use, and 7% of people will post on the new repo threatening to sue because they found a similar-sounding project in some disclosure and they don't agree to your imaginary terms that allow you to sell their private info to the Illuminati.
But the worst is when the original project isn't dead. You go and do a significant amount of work to fork it, and then the original author comes back with some pretty major changes that completely break the foundation of your fork. Now you're stuck on a legacy fork, or a ton of work to rebase onto the core library. If other people are depending on your fork that's a difficult question to answer.
This email is basically asking "should I go and do all of that work?" in as polite a way as possible. If you put together a canned response (cough CONTRIBUTING.md cough) that would solve 100% of this:
> Thanks for your interest in contributing. I think this project is pretty complete as-is. If there are breaking changes or zero-days that come up, I plan on fixing them. Otherwise I don't expect to approve many PRs. If you feel you need to get a change in, feel free to fork the repository and make your change there.
Most forks don't even become relevant enough to be known
I understand both points of view. Ideally if you decide to fork it and you're willing to take it up then leave a note in the issues on the original mentioning the fork. The original might decide to point to your fork or at least others can go look if your fork looks like a better fit for their needs.
There is nothing passive-aggressive about that comment. There is nothing problematic about it at all. Nobody's calling you slurs or making demands. I see one guy who might as well be a Mormon Boy Scout from Canada. "Is this repo dead" is not passive-aggressive, just ineloquent. Fuck my eyes until the jelly leaks out my ears if a courteous and professionally-written question constitutes "applying pressure and being rude" these days.
I don't know what a "bulleted list of the reasons [you] suck" has to do with anything (I don't see where anybody sent you one) but you're coming across as someone who invites people to your garage sale and then brandishes a shotgun and starts screaming when they set foot on your property.
> I’ve never seen any discussions or articles about whether it’s appropriate to ask if an open source repository is dead. Is there an implicit contract to actively maintain any open source software you publish? Are you obligated to provide free support if you hit a certain star amount on GitHub or ask for funding through GitHub Sponsorships/Patreon? After all, most permissive open source code licenses like the MIT License contain some variant of “the software is provided ‘as is’, without warranty of any kind.”
Here's an example of why everyone should ask if an open source project is dead:
https://github.com/mckaywrigley/chatbot-ui/issues
A number of issues complain about it leaking OpenAI keys. Nobody's figured out how, but it'd be nice to know if anybody's working on it, if it's worth submitting a PR, if it should be forked, if it's worth bothering with at all. This code is a massive liability in its current state. Its creator is absent. It warrants questions being asked about its future. Yeah, it's as-is software, but it's not an affront to your mother's virtue when someone asks if your shit still works or if you have plans to fix it. Nor is it a call for you to offer free labor.
> I’ve had an existential crisis about my work in open source AI on GitHub, particularly as there has been both increasingly toxic backlash against AI and because the AI industry has been evolving so rapidly that I flat-out don’t have enough bandwidth to keep up
Herein lies the problem? You sound overwhelmed. I've been there myself. I don't know what your year's been like but you genuinely might want to get away from the screen and get some fresh air. This is a good time of year to do it, since things generally slow down at work.
I used to think the world would be worse off if more people do what I did by removing code they don’t want to maintain. I don’t think that anymore. There are enough people and businesses who, for various reasons, want to maintain free (in both senses of the word) software. I don’t think the marginal people like me - the people who don’t want to maintain, and who don’t want to be nagged - really contribute more than negligible value.
I make stuff to scratch my itches. I stopped being so big-headed as to think that others need to see that stuff. But if I really wanted to post it, I’d put it on a website, probably under a pseudonym, with a warning not to nag me. Not on Github.
Sadly, I didn't have the opportunity to maintain a relevant enough repo.
But, why not just develop at your own pace and simply not give a damn about complaints?
Maybe a README to clarify the situation, specifying that it's your project, you are doing it at your leisure, and that's all.
I think those who post PRs and messages on GitHub are not entitled to any response. But I can understand those who think it’s rude not to reply. I would rather not reply. So there’s no reason to post in the first place.
GitHub is more like a city there are different places, open stores, private building, parks.
Everyone can go into stores. Repo that is promoting themself on GitHub or other websites.
No one will go into your private house that you don't want into it. Private repo or repo with no readme , description or topics.
If you have a park with trees that look nice, maybe some people like it too and wann chill on it, if you don't want people on it write a shield private or do not step on the grass. Repo that is willing to be used by third parties, as other are interested into it as they see it. You don't want something write a rule into readme.
Yes, open source maintainers aren't obligated to do anything. Doesn't mean that asking if a project is dead or not is rude or problematic.
I'm not sure how to ask that won't in some way feel like either a demand for action or and accusation of abandonment.
Maybe just look at the commit history. If nothing has been committed in 6-12 months and if the code is not great as is then fork or move on.
I've written a couple of libs I consider done. They are still super useful but there's nothing I want to add for 2-3 yrs now. They are not abandoned
This clarifies your stance so well that people acting in good faith won't bother you, and anyone who does bother you very likely isn't acting in good faith - easy to ban.
Plus, when you see someone ask questions about your project and interpret them as "a bulleted list of the reasons I suck", it implies that on some level you think "I suck because I'm not giving these projects more of my time". Giving that kind of disclaimer might help you move away from that mindset, and instead feel more at ease with yourself. Your contributions should be celebrated (as the person with those bulleted points did!), and anyone acting in good faith can appreciate them and fork if needed
Yes, I do have inherent guilt for not updating my projects often enough.
I consider this project
- actively developed
- a toy
- finished
- still interesting to me
- no longer something I expect to progress
Your best option if you would like changes is
- raise a PR
- ping me
- fork it
- use a different project
- pay me
- The more the merrier
- A necessary evil
- I'd like to avoid them for this project if possible
- Not allowed by the licenseThe questions you received were:
> Can we expect development from the maintainer?
> How can the community support?
> Are you open to PRs and reviewing them?
> What's your time commitment?
> Should someone just fork the repo and develop it from there?
This is far from a "bulleted list of the reasons I suck". Whoever asked this cared about your project and its future. They just wanted to know what was going on. They might have been intending to contribute patches to you: they specically asked if you were accepting pull requests for review. It's extremely frustrating when you send a patch in and don't get a response.
This was my approach when I received similar questions:
https://github.com/matheusmoreira/liblinux/issues/16
I think it's better to just be sincere and provide the necessary context.
It's really sad to see people decide they don't want to publish code because some strangers have weird expectations. Of course ideally those strangers wouldn't exist, but that's not something anyone can change... but it's perfectly OK to kick them out of your space.
As a relatively prolific open source maintainer; there is absolutely nothing wrong with asking if a project is dead, abandoned, or otherwise stuck in the mud. Open source projects fall off every day, and there's nothing wrong with that or inquiring about it. If your project is dead, post a note on the README to that effect or explaining the current status. One can always put a call out for maintainers as well.
If a question like that, or critical comments in general, negatively affect your well-being, seek help and immediately disconnect or disengage. Alternatively, one can always disable Pull Requests, Issues, and Discussions for proper isolation and read-only code sharing.
In short, quit telling people how they need to be and take some personal responsibility for your well-being or mental state in the realm of Open Source Software.
I don't think so. The person was perfectly polite in my opinion.
You don't owe anyone anything, they aren't paying you and it's absolutely fine to just drop everything and go do something else if you want. However, the people using your project will want to know what's up so they can deal with the consequences. They find out what's up by asking perfectly reasonable questions like the ones in the first screenshot. It's simple to provide a sincere answer to all of those questions. No response is also a valid and clear answer, there's no actual pressure to respond either. The point is it's not rude to ask.
As a free software developer and user, when I ask such questions it's because I'm wondering whether I should fork the project or try to work with the maintainer. I've sent patches to projects, most recently cosmopolitan libc, because I knew the developers were actively maintaining the project. I've forked the pug/jade templating language into my own static site generator tool because the maintainer seemed to have moved on, I went there and asked just to confirm before I did so. I don't think there's anything rude or pressuring about it. We're just trying to decide what to do with our own time. Our decisions depend on your decisions and therefore we ask.
It gets rude when people start subtly shaming you for not working on things. That's absolutely unacceptable but I don't think that happened in the first screen shot which was just polite questions.
Seems like OP perceived shame by being asked this, though. -- Why would anyone ask "what's the status of this project?" (or however politely you want to phrase it) if the project were clearly being maintained? There's at least a meta-message of "you're not working on this enough", even without otherwise being hostile/rude.
I'm reminded of the "ask vs guess culture" differences.
But as you say, users aren't owed reliability. Perhaps a better interaction would have been "Is this dead?" "I haven't been working on it. I hope to work on it soon, though. But, I would rather not have to deal with PRs from others".
Still, I think it'd be better if people didn't have to walk on eggshells when making interactions; and to reserve accusations of rudeness for more overt or persistent badgering.
There's many implied messages in everything we say and do.
The action of not working on something sends a clear message and communicates a lot of information: you're doing something else with your time. The "you're not working on this" message will be received and understood by others because the repository is public and anyone can see the activity. It's just a statement of fact. The "not working on this enough" message is definitely insulting because it implies obligation but I didn't receive that message in this case. Maybe it's just me.
What that action doesn't communicate though is intent. Perhaps the developer intends to work on it but hasn't been able to because life happens. Perhaps they're just sick of the project and want out which is also absolutely fine. I think the questions were just attempting to clarify the intent.
Another message that I felt was overlooked and led to my comment: "I care enough about this project to ask about its future". People ignore things they don't care about, it's like it doesn't even exist. Even hate could be preferable to oblivion.
> I think it'd be better if people didn't have to walk on eggshells when making interactions
I agree. People are extremely hard.
Then again, maybe there is no ongoing development, but the application is being used on a daily basis. Could you class something in everyday use as being 'dead'?
To most people in the world, the Usenet News Reader 'Tass' (remember Usenet?) is still stuck on version 3.6.4 from around 2006 and would be considered 'dead'.
Looking through my archives, I see that I developed my internal-use version 3.7.0 in January 20014, and version 3.7.2 in April 2017.
So ... is the 'Tass' Usenet News Reader 'dead'? Or is it not?
Personally I am (I think rightfully) hesitant to use a library that hasn’t had a commit in years. Similarly, downward trends in usage are also a pre-indicator of a library’s long term health, as it can signal lack of user trust, better competition, or just that the original need isn’t quite there anymore.
So you’re right that it can be picked back up, but I think in practice this is far from the most common outcome.
1. the people with the commit bit in the original repository are all gone
2. people fork the repository to fix one minor thing, and never update again
There's a certain social problem that I can't describe very well. Projects should have a form of "succession planning" or else they end up in the state I just described (impossible to commit to the original repo, numerous inactive forks that merged 1 or 2 stale PRs).
This is especially common, for example, if you want to revive the source of a Minecraft 1.7.10 mod, say.
As more and more code build scripts pull in external things, the harder it is to get them running again years later.
I'm playing a 1.7.10 pack lately actually, still just as good as when it came out!
> if you want to revive the source of a Minecraft 1.7.10 mod
i.e. if you want to change/alter or recompile a mod for version 1.7.10
None of the things you have mentioned apply to this.
If you take a piece of application software, tar it up including its dependencies, you should be able to untar it 15 years later and it should compile and run. If it doesn’t, it’s not your fault as a developer—it’s the fault of everything else that changed and broke that previously working code.
If vendors took compatibility seriously, we wouldn’t have “code rot”.
As a Windows user, it's sad that so many people think that way nowadays.
I've encountered one DOS program from the early 90s that doesn't run anymore because it used its own custom memory management which newer systems don't allow, but that one was later re-released in an updated version that still works today. And there were one or two late-90s Windows programs that no longer run either because they have 16-bit components or depended on some then-standard now long-gone libraries to be on the system, but those run in a VM.
Other than that, there is plenty of software dating back to the 90s, some to the 80s, that mostly still works fine. It doesn't need constant maintenance and updates. It worked about 30 years ago and still works today and should still work tomorrow. You'll find even older legacy code in major organizations that's still chugging along.
That's hard to find in modern software. Now everyone always has to have the latest thing and it has to be updated almost every single day just to keep a massive chain of transitive dependencies from collapsing out from under it.
I guess that's why people get rude and ask whether a project is 'dead' even though patches have been released for it multiple times within the last 10 years.
I considered picking it up, but I’d have to make some hard decisions about the code base that wouldn’t make everyone happy, and I just don’t have the context to do that. Another issue is the lack of testing infrastructure.
So for everyone who still cares, the path of least resistance is to maintain their own fork or do a rewrite in a different language.
There is/was a clojure library for Apache Spark. It stopped being maintained. In ensuing 9 years, the tooling it uses has completely changed, the 3rd party libs it uses either changed or stopped being maintained and underlying Spark changed a great deal.
It would be less effort to start over than try to pick it up
Assuming it's maintainable and not the illegible scrawlings of someone crazy, sometimes software is just some random folk in Nebraska's pet project and it's been dropped for something shinier/they gained employment.
Then suddenly one day they have decided to completely remove a few crucial feature without much warning and release a version 2, without giving any sort of alternative to those great features.
They stopped support for prisma 1, deprecated the packages, changed whole codebase and links, features and so on.
It was open source project but at a very large scale where their change impacted thousands of businesses. A lot of people wanted to sponsor or support ongoing development of prisma 1 until the similar functionalities have been developed on prisma 2. But their repo, their rules, their business decisions. Which I respect. Nothing to do there, except accepting and moving on and creating alternative solutions.
It was devastating for me personally. Took me half a year to refactor a lot of code in a lot of different projects that were purely business logic dependent on prisma 1. And I couldn’t do anything as a solo dev at that point.
What could I do? I waited and created alternative solutions until we get official ones.
...
I still use prisma. Its a great piece of tool, backed by a the awesome community and team. They are doing wonders.
But the incident taught me a different reality of open sourced projects.
I tried to connect that case with the post and thinking back, I think you are right, and at same time, you could ask for sponsorship for your time, or share your situation instead.
People have expectations. Its what keeps them connected and growing.
Was it not BSD or GPL or some similar license? If so someone could just fork it while ignoring their rules and business decisions (as long as at least one other person had the code I guess).
Maybe you’re a developer who can keep account of multiple layers, or all layers in your stack. If so that’s great. But we’re all limited to varying degrees and there’s only so much one can do. Really, you need to find reliable partners who can own some of that complexity for you.
In OPs case, they picked a partner that was not reliable. They paid for it with more maintenance. But this is what you get with open source. You can get it for free and you can set it up fast because you don’t need to negotiate contracts, but your dependencies are under no obligation to support your use cases.
But yeah I get it, too much of a pain, too unrealistic, etc.
Of course, open source software is not the only thing at risk of this, seems like most modern software gives you little control over what version you use.
On the flip side, one thing I dislike a lot about the Clojure community is when people say "sometimes software is complete and there is nothing else to do" as an excuse to tolerate libraries that have gone unmaintained for years. Again, anecdotal evidence, but half the time I hear "the software is complete", I end up finding a bug in said software.
Lastly, this paragraph summarizes a bigger problem with consumer behavior in open source:
The best-case scenario for asking if an open source project is dead is that you annoy the maintainers and delay development. The worst-case scenario is that you give the maintainers an opportunity to reconsider if continuing to work on the open source project is worth it.
... accepting a misguided PR will create technical debt and take even more effort to address.No one expects anyone to indefinitely maintain any code. But please be upfront about it. It is not burdensome to write in capital letters THIS PROJECT IS UNMAINTAINED in the README file if that is the case. And it saves a lot of time for others.
That being said, the first comment seems rather polite and considerate to me. Yes accusations of neglect are rough, but if that isn’t the case it shouldn’t be too hard to put a disclaimer in the README as to why the project isn’t moving much.
Your feelings are valid, but so are theirs (although in some case should have been expressed more thoughtfully). It doesn’t feel productive to dismiss their questions on the ground that you behave differently when faced with this situation.
An open source project does not have any opinion or feeling about not being under active development, but people interested in the project might, and they can use those words to communicate their displeasure by evoking those feelings. But, I'd wager that there are just as many instances where no connotation or hard feelings are intended.
Words are powerful! If you are merely asking, maybe avoid "dead" or "abandoned" when "no longer actively maintained" will do. And if you're not merely asking and really do want to communicate your displeasure, maybe just don't.
If you don’t want to interact with people keep the source to yourself.
Or maybe ask yourself why it isn’t immediately obvious that your project is active. I see a project with a low semantic version number and a release three months ago.
Nowhere in the readme is there any blunt statement on the current status of the project or what kind of state it’s in.
Some direct and affirmative language like that can go a long way there. Put info in the readme somewhere prominent and it would probably stop a lot of people from asking questions.
Tell us how when to raise issues or not. You can even tell people not to ask whether the project is active and they might just comply!
Calling that 'dead' and demanding status updates is the overreaction here. Unless you're paying this person to work on it full-time.
One of the bits of software I use has an update as recently as 2019, and before that 2015 and two 2013. It's clearly still relatively active. For software released in its current form in 1997, after being ported from an older version.
Even if modern software might sometimes need more frequent updates, it's still pretty demanding to insinuate death and demand status notes from an open-source maintainer just because they're not moving quick enough for you.
The people who asked those questions were greeted by a software author who lashed out at them. See for yourself:
https://github.com/minimaxir/simpleaichat/issues/91
https://github.com/minimaxir/simpleaichat/issues/92
One person who asked (rightfully, IMO) pointed out that all these questions are reasonable considering the project has sponsorship and Patreon links. The author is collecting $100 a month in Patreon and GitHub sponsorships, which is not nothing.
Noone want use a libray that is not active maintained.
simpleaichat also use other dependencies, i think they are choosed by the developer the same way i would choose his library.
If its an library that implements things that dont change often like string functions this is not important.
But a library connecting to third party apis maintaining status is relevant. So asking if he need help or if its dead is a fair question.
dead and death are not nice words, but github is a world with many persons that dont speak native english.
Make a practice out of README's having more context about who is behind this work (individual, team, etc), the status of it, and the desired outcomes. I think this helps not just to make it clear that users shouldn't have an expectation of support, but also if a solo project it will end and flow.
I think that this kind of becoming a requirement because open -source is in a really peculiar place and these sorts of issues are likely going to get worse before they get better.
It isn't just the number of open-source projects that is growing, but the variety in models and desired outcomes for open source that is diversifying, and in many cases, more towards where any project with traction is less likely to be a fun side thing for a smart dev and more seen as a 'product'
I am not sure how I feel about this trend overall, but I do know I have appreciated this sort of context in projects and it does seem to at least make it easier to close issues by pointing at those statements.
Having dealt with a fair share of this along with bizarre interactions over PR's that leave me stressed out, my question to them would be: if the author simply said "no it's not dead", would you accept that as a closed issue?
Or are they expected to actually make some commits in response?
If you find a bug, security issue or dependency issue I will attempt a fix or accept a PR."
That is a closed issue. Maybe as other's have said put that in the readme but that's up to you, it might just prevent the same issue popping up in 5 months.
Perhaps the person could have said:
> Hi, we at ACME Corp are planning to use this library but are not entirely sure about the current state of it, can you confirm it's still maintained? It would make my boss very happy, also thanks for your work, appreciate it :)
And the response might be different?
Both sides can definitely introspect but I'm not on OP side on that one.
Assume incompetence not malice etc
I understand the pressure open source maintainers are under (having been there myself), but the general advice has always been to fork a project if the maintainers can't or won't integrate PRs and fixes that you need.
If we can't ask questions about the repo's status, the backlog of legitimate PRs is growing without response, and even forking the project is considered hostile, that leaves no real options.
If someone wants to publish something to GitHub with expectations like this, it's better IMO to advertise them at the top of the README.md. Or better yet, don't publish a project to GitHub if you don't want to have to read GitHub issues and you don't want anyone forking your work.
> The best-case scenario for asking if an open source project is dead is that you annoy the maintainers and delay development. The worst-case scenario is that you give the maintainers an opportunity to reconsider if continuing to work on the open source project is worth it.
This is remarkably cynical. I've seen many GitHub issues asking about the status of a project that turned into constructive discussions about adding more maintainers, collaborating on future work, or coordinating a newly-maintained fork with an updated link in the README.md.
To say that the outcome can only possibly be negative or that spending 60 seconds responding to a couple legitimate GitHub questions (I checked, the repo has had 3 new issues in 2023) will significantly "delay development" is really negative.
If such simple communications are causing the developer to publish long rants on their blog and consider withdrawal from open source completely, I think there's something deeper going on. This long rant in response to a single legitimate GitHub question is more than the typical open source maintainer frustration.
I don't know who came up with and propagated the notion that software needs to be constantly "in motion" and perpetually changing (perhaps to justify their continued employment?), but it's an irritating trend.
Likewise, a hell of a lot of SDL1.2 projects will still compile and run fine.
I have binaries from the early 90s that I still use today (mainly small utilities). Win32 ain't going away.
The industry is full of solutions looking for problems. Ignore them and stick to the basics if you want what you do to last.
Tell that to the banks, government, and companies still running software older than I am. And for which, on the rare occasions when maintenance is needed, the developers are likely using tools older than I am to do the maintenance. (I'm middle-aged btw.)
It's been a nice 23 years since the major Y2K projects, and we've still got 15 more until we really have to hustle on the Y2038 projects.
If your use of open-source code is predicated on the expectation that someone else will always be there to take care of it, then you're just a freeloader.
1) One of the package's dependencies has a breaking change which breaks the package
2) One of the package's dependencies has a security bug. The dependent package cannot be upgraded to a fixed version because the dependent package's fixed version has a breaking change which breaks the original package.
Basically, ecosystems which do not have strong backwards compatibility tend to require packages/libraries/creates/assemblies/DLLs to be maintained forever.
the maintenance is not a small part of the usability of a software
> it's open source you can take it and use it or enhance it as you like.
No, I need to have the ability and the time to do so
> then you're just a freeloader.
I don't remember the part in the free software licence that doesn't allow me to chose to use or not use a specific software or a clause that force me to take over it's development in case the original dev abandon it
1) Be polite - Open Source developers and maintainers are incredibly generous, and they should be treated with respect.
2) Treat maintainers with respect - For example, instead of asking if something is dead, try writing something like "Are you still working on this project? Would types of issues will you fix? Security bugs? Serious bugs? What else?"
3) Give back - If you depend on a project, ask the maintainer if there is anything you can do to help?
4) Consider giving money to the maintainer as a thank you. If you really like a project or really depend on it, you should probably give the maintainer some money. There are two reasons for this. First, it shows you appreciate their work. Second, it encourages them to keep on supporting the project.
5) Let maintainers know that you appreciate their work. Also, let them know what you like about it.
One thing I think a lot of people are not thinking about is real people work on open source software and these people have limitations, desires, likes, etc. They are not meat bags which create software because users demand it or feel they are entitled to it.
There are so many blog posts like this. And, a few times a year, HN likes to rehash this topic. Open source seems like a thankless, but necessary exercise in the modern world. At this point in history, I doubt there are any strong intellectual arguments to favour closed- over open-source. (However, there are economic arguments. For example: If you have excellent intellectual property, then it is much more economically valuable to keep as closed source.) I am so glad that I do not run an open source project with lots of attention. It looks like hell having to fight with Internet trolls all day long.
To show some compassion for people who reach their wit's end and write a noisy blog post like this: It must be difficult being poked and prodded all day long. After you lash out, and a bunch of people (trolls?) tell you to "calm down". If only there was a (VR!?) simulator to put those very same people through the same hell to watch how they would react.
[1] https://mikemcquaid.com/open-source-maintainers-owe-you-noth...
Happy to contribute to help but knowing that the persons who actually understand and took the responsibility to maintain a library are around, informs my choices.
It’s fine if you don’t want to fix problems in your library anymore, that’s your choice, I just won’t use that library—but I need to know what’s going on or else I can’t make choices for my own benefit.
Whether you like it or not, posting an open-source library is equivalent in my and many developers minds, to telling other people that they ought to use your code in some way. If the way you signal them to use it is as a dependency in their own critical software, by posting it to a package manager and hyping up the benefits of your design choices and code, I do think it’s kinda on you if people get burned by deciding to work with you, even if indirectly.
Communication is the point - if you don’t want people to expect maintenance of your software, say that you won’t maintain it, don’t put it on a package manager, or else people will get the wrong idea, because open sourcing and posting the code is also communicating something, even if in your case it’s unconscious and not what you actually meant.
> > I don't mean to pressure or be rude but if @minimaxir could share his
> > thoughts on this I would really appreciate it.
> To be perfectly clear, this absolutely is applying pressure and being rude.
I've been in open source development for two decades. It's not rude to ask if a project is abandoned. If asking that question causes somebody to quit, it's probably for the best.
I've been a bit upset (more confused) myself as a user/contributor when I've spent hours or even days debugging something, clearly and politely communicating the issue or bug, and then it gets immediately closed with something like "we're just volunteers" as if I demanded something by merely pointing out an issue (that I offered to help with!). What does being unpaid volunteers have to do with any of that? It's just knowledge and information I have reported, but then I have to deal with a maintainer getting upset because I simply used their advertised library, one they advertised on their CV, in talks, in books, etc.
I was wanting to start being a regular contributor, so what's the point of treating a potential contributor like that? I'm not totally sure I get it. They don't owe me anything, and I'm also fine with their library willowing away into obscurity and going off and doing my own thing.
Honestly feel this reflects poorly on the OP more than anything else.
honestly, that sucks but also she mustve been interested enough to do due diligence, i see that as an absolute win
Furthermore I think that this sample is exactly what can discourage an open source project maintainer to stop development and work on something else, maybe something closed and private, which is bad for open source generally.
So people need to be more patient and read the code of conduct of any project they want to interact with.
If you are going to have a 3k star project and you get your feelings hurt over someone asking if it is after you took a break, that is a legitimate question.
Dumb blog post got me again, I almost never click on them from here because it is either some VC self congratulating themselves or some developer griping about their hard life while driving their Tesla home to their $500k home.
Scratch your itch. It might scratch my itch too. If the users make demands that you don't want to deal with then let one of them take it on.
Because that's what open source is supposed to be about - community. Nowadays it seems the community aspect is disappearing and what people want is commercial-grade software for free. Yeah, I'm not working for you for free, let alone you thinking you can make demands of me. You can go straight to Hell with that idea.
Why is this legalese so appealing as the answer to social issues that have nothing to do with licensing and warranty etc?