search

oh-my-fish / oh-my-fish

The Fish Shell Framework
MIT License
10.4k stars 810 forks source link

This project is end of life. It's unmaintained, plugins are broken, and it's tripping up new users. Let's talk decomm. #947

Open mattmc3 opened 1 month ago

mattmc3 commented 1 month ago

Oh-My-Fish has been a great project for many years, but has fallen into disrepair. New users are finding old blog posts about it, installing it, and then when something breaks they are left in the cold. For a user-friendly shell like Fish, this creates a bad user experience, especially for new users. Its continued existence in its current state is a drain on the Fish ecosystem. Even the uninstaller (omf destroy) is broken. So, once a user discovers this project is abandoned, they can't even remove it without experiencing more issues. That's not the experience we want for the Fish user community.

Oh-My-Fish is now effectively end-of-life. That's not a bad thing! But leaving it in its current zombie state is. It's now become a hazard.

An attempt was made to find new maintainers, but the call largely went unanswered and we're back to the same place we were a few years ago. The last time someone asked about the state of this project, a new release was promised, but never delivered. It's just too big a project for the small number of people left invested in it. Someone will get excited and offer to help - all with good intentions I'm sure - and then ghost.

My proposed solution? A graceful decomm of Oh-My-Fish repos. The steps I see to do this would be this:

If an existing maintainer does not have time to do those things, then I am willing to be added as a maintainer of this org to do this. As maintainer, I would commit to not ghost this project for a period of no less than 4 years, and ensure that it is gracefully decommed. I am also willing to offer help in other ways if needed.

References:

derekstavis commented 4 weeks ago

You know what would be more helpful than all the complaints and issues people keep filing? Actually sending helpful PRs that fixes issues and actually engaging in development.

One does not become a maintainer by asking to become a maintainer, but by actually maintaining things.

I’ve been using OMF for the past 8 or more ghosted years without any problems. At least for what I use it for it hasn’t been problematic, so I consider this more finished software for my usage purposes.

Don’t get me wrong though. I don’t want to shut down discussion, but I also don’t think OMF is EOL or should be declared archived. It just needs maintainers.

If you want to send PRs fixing things that are broken you’re very welcome and I will dedicate time to review them and get them merged. If you contribute enough meaningful work I’m sure we maintainers are going to be happy adding you as a maintainer, but we all got to a maintainer position by contributing meaningfully to the project, even if it was a long time ago, before Fisherman’s maintainer destroyed our willpower.

mattmc3 commented 4 weeks ago

You know what would be more helpful than all the complaints and issues people keep filing? Actually sending helpful PRs that fixes issues and actually engaging in development. It just needs maintainers.

I understand this sentiment. But the reality is that there's been plenty of calls for that and it just never happened. It's like a derelict building with broken windows - "all it needs is new renters who will clean up the place!" Hope is not a great strategy here - enough time has passed with calls for maintainers that it seems very unlikely to happen. So this is a call for the existing landlords to finally put up appropriate warning signs.

I'm certainly not looking to dis a project that once had a useful life and was an important part of the Fish ecosystem at one time. What I'm seeing now is people active in the Fish community are being asked to help out new users that stumble upon this project with all 159 of its unmaintained repos. And as a maintainer and contributor to other Fish projects, and an active member of the Fish community, I don't think it's too far out of line to open a good faith dialog about winding down this project responsibly.

That could take a lot of different forms. It doesn't seem to be too much to ask to mark these repos as public archives, but it could also mean updating READMEs to ask for maintainers, or disabling issue reporting if no one is monitoring them instead - I'm not looking to be prescriptive. However, right now, there's no meaningful notice to users about the state of things. My offer to maintain was not an attempt to usurp or undermine any of the existing maintainers - but only an offer to help do what needs done if there's not the willpower to do what's needed.

pushpdeep commented 4 weeks ago

Please don't shut the project. Maintainers and contributors will come. It's just matter of time. OMF is a beautiful application that we use daily. Very handy fast and awesome. Wish I had all the coding skills needed to close the issues. However now I will see how directly or indirectly I can contribute.

Let's give our Fish extra gills to breathe. 🐠🐟 🦈 🎏🐡🐠

mattmc3 commented 4 weeks ago

@pushpdeep - With GitHub, you can archive a repository or an organization and all the code is all still available. It wouldn't stop existing users like yourself from using OMF. New contributors could still fork repos, view history, and see old issues. But, they wouldn't be able to commit, comment, or open new PRs/Issues. That's actually a good thing since PRs and Issues for this project have largely gone unacknowledged for some time, so in effect this project is already in this unmaintained state - users just haven't been made aware.

This is the commit graph for this repo as an example: Commits over time

derekstavis commented 4 weeks ago

I think adding a call for maintainers in the README is a great idea. One thing that I could use some help from folks in this issue is grooming the issues in the repo, helping to find what makes sense to get done and prioritizing them. I would be happy to add labels to them and say that if someone is interested in maintaining they could send PRs to address any of the labeled issues as part of the contributor call for action in the README.

I'd honestly prefer to resuscitate this instead of just killing it, because I don't think OMF is useless, if anything, it does everything I need from it.

faho commented 3 weeks ago

One thing that I could use some help from folks in this issue is grooming the issues in the repo, helping to find what makes sense to get done and prioritizing them.

We tried all that almost four years ago. I personally reviewed a number of pull requests and triaged issues. It did not stick.

The problem is that many things that need to be done, like e.g. merging PRs in the packages-main repo, are things that simply need a maintainer to spend five minutes looking at them. Even if someone else reviews a PR, you still want to check that it makes some form of sense so you don't get spammed or scammed.

There are, at this time, 5 open PRs on oh-my-fish/oh-my-fish. Four of them have an "LGTM" acknowledgement from a non-maintainer. Two of them (#926, which fixes a typo, and #907, which adds a single line to the README) are completely trivial and really just need a maintainer to either press the "merge" or "close" button.

The maintainer time / interest appears to be so limited that it simply is not happening. And at that point you're stuck in a hole and need to invest work to get out.

Actually sending helpful PRs that fixes issues and actually engaging in development.

There are three problems I can see with someone sending in a PR to work on this:

  1. I would currently not be confident that my PR will be merged even if it is good
  2. The project is already in a bad state, where both installation and uninstallation seem to be broken at least for some people, plugins aren't being added to the centralized repository, nobody is available to answer questions or mentor new people
  3. The project claims to support fish 2.2.0.

How you would write scripts for fish 2.2.0 differs a lot from how you would currently write scripts. Anyone who started using fish in the last eight years won't know how to even do that. 2.2.0 is missing 75% of all commits ever made to fish. (however fish 2.2.0 support is currently broken, see #934)

So contributing to OMF is currently pretty unappealing. There needs to be some minimum amount of work happening to be able to get new people on-board. If that isn't happening, and it currently isn't, it would be easier to revive the project in a fork ("oh-my-fish-ng") than to work upstream against nonexistent maintainers.

Improving that would require some amount of work from the maintainers. You would:

  1. Set the project's minimum supported fish version to e.g. 3.0. This is a one-line change to the README (if you don't want to do this, revert the commit that caused #934)
  2. Fix the installer and uninstaller bugs
  3. Add a call for maintainers to the installer - people don't read the README or trawl through open issues.
  4. Make a release
  5. Be available to merge PRs, possibly asking "the community" for review (but note that "the community" isn't all that large anymore to begin with)

I expect this would be three hours of work now and about an hour a week after, and can be divided up between the 14 current members of the oh-my-fish organization. Once you then notice that someone is picking up the slack (and I must stress this is unlikely given that it has been FOUR YEARS since a call for maintainers was posted), you can add them as a maintainer and they'll hopefully continue.

I need to reiterate the current state of affairs:

As it currently stands, new people are trying to use fish, find old blog posts telling them to use oh-my-fish (or simply come from zsh and assume since oh-my-zsh is important oh-my-fish must be as well), and then have a bad first impression when the installer is broken. Then they have a bad second impression when they try to use a plugin that doesn't support omf or isn't in packages-main. Then they have a bad third impression when they try to uninstall oh-my-fish.

This is not a theoretical exercise, this is actually happening. I'm sorry, that's a net-negative to how new users come to fish, and shutting down oh-my-fish would improve the situation.

cyber199 commented 1 week ago

For what it's worth I agree that something has to change. It works enough to change a theme but when some themes are listed in the themes.md but not in the repos (e.g. #800 ) it is a poor experience, especially for noobs that just want a fancy looking shell finding out that $ omf install shellder doesn't work. The shellder theme itself is unmaintained, which is sad, but if it is dead it shouldn't be listed anywhere.

derekstavis commented 1 day ago

The README has been updated with a call for maintainers. I've set up an email where people interested can reach out to, and I will dedicate some of my free time to provide access to maintainers to the packages repo, review PRs and try to get the ball rolling on fixing some of the core issues.

faho commented 1 day ago

Okay.

The next steps I would recommend:

mattmc3 commented 21 hours ago

@derekstavis - Are you the only active maintainer left? This issue has been open for a month, and of the other 13 maintainers in this org, you're the only one that's weighed in. Your willingness to work together here is so appreciated! Most of the other maintainers appear inactive, but looking at commit history - @sagebind, @scorphus, @ZuraGuerra, @syl20bnr - they all appear to be very active committers in other projects. Is it only you left making decisions for the future of this project?

I agree with all of @faho's points above and was glad to see the readme updates at least. However, I fear that the complexity of this implementation will deter people from volunteering to help. While I hope I'm wrong and you get the aid you need, if this project doesn't get active maintainers in whatever reasonable timeframe you set I respectfully want to offer an alternative approach. Over the last month since I opened this issue, I threw together a proof-of-concept for a significantly simpler Oh-My-Fish implementation. I too still see value in the idea of an OMF project.

The PoC is hosted here: https://github.com/omf2/omf2. It uses Fisher under the covers to manage its plugins, and could be a way to migrate existing OMF content to something much easier to maintain. I'm willing to pitch in and collaborate on variations of that implementation if that's a viable alternative to you. Sprinkle in some starship and Tide themes, and I see a path to rebirth rather than resuscitate this project. Just an idea.

derekstavis commented 6 hours ago

I'm probably the only "active" maintainer nowadays (if you can call my sporadic clicks and keypresses active) and I have no problem making decisions as the other maintainers don't have the time or have even less energy than me to put in the project.

A possible alternative is to just send people to Fisher, but what I particularly miss in Fisher is the package registry, since with OMF I can just do omf i nvm instead of trying to figure out the repository/GH path.

Your idea of replacing the existing version of OMF by a rewrite one isn't a bad one, but my worry is that over the years we've supported some really weird use-cases (like NixOS and offline install) that I'm not sure what would be the impact if we broke. To bring some context -- in the last 15 days alone we had 1,136 unique cloners.

But then comes the fact a) OMF has been "stable" for over 8 years, if not more, b) no one is currently maintaining OMF and having someone making progress is better than having no one making progress, c) making maintenance easier matters (fisher itself ended up moving to a single file due to all the issues associated with fish and multiple files). so I think that this may be the right call.

Having this said, to your point of variations of your idea, I think there are a few things that I'd like to have in OMF that I find to be part of its value proposition:

  1. The package registry: I think people prefer doing omf i <tab> and having a list of things to install than scavenging Github. Likewise, search should be possible.
  2. Package dependencies: I may be the only one finds value in this, but I reuse packages quite a bit in my own private plugins.
  3. Scaffolders: Creating new packages and themes with all the structure needed is what helped people to create new packages.

Things that I would avoid reimplementing in a rewrite:

  1. Offline install: It's been a while but this to me seemed like a weird edge case that we covered for IT deployments and created quite a bit of complexity
  2. Channels and versioning: This also created a ton of complexity, and mostly existed because OMF is multi-file and there was no way to perform atomic upgrades (fish would break in weird ways due to function autoloading)
  3. Theme linking: I apologize for proposing and implementing the theme symlinking. That was a really bad idea and shouldn't be replicated.

Since you are open to working on this together, shoot me an email at the google group and we can set up a more efficient way of communication that is not GH.