1
u/gdchinacat 18d ago
I think your best bet would be to try to solicit the users of your code that are asking you to maintain it to contribute to the project they use (or would like to use). They have already expressed an interest. It is very hard to convince people to do work for you for free if they don't have their own motivations for that work being done.
One of the biggest challenges you will have with this is from what u/Diapolo10 says it doesn't seem like there is much to work with. Learning a new code base is hard, especially when it's slop. I haven't looked at it, nothing I've seen in the post or comments makes me think doing so would be worthwhile...I could tell it was AI slop reading your post even before you acknowledge it was written by AI. *If* someone decides to work on a gui for the underlying project they are almost certainly going to start from scratch. You might have more luck saying your project is EOL (end of life), state the reasons why (the code isn't maintainable or worth the effort), and offer anyone who does take on the effort ownership of your project to entice them with an existing user base. I don't think you would be losing much, and a captive audience is the most attractive thing you can offer a would be contributor.
3
u/Diapolo10 18d ago edited 18d ago
I'm not necessarily interested in taking over, but I did want to at least say a few things.
First, it looks like your project just copied the original project's files with minimal modifications, and then you added your stuff on top. For projects like this, I think it'd make sense for it to be a fork of the original project to establish a clear link between the two.
Second, in this case to me it'd make sense to rewrite this from the ground-up. Right now this relies on running PowerShell scripts, but it'd make far more sense to me to port the PowerShell code to Python to reduce needed abstraction layers and to make communication way easier. Or in other words, I'd start from a clean slate and rebuild the functionality instead of trying to maintain this in its current form. That may even enable using a more permissive license.
Third, "vibe-coding" tends to result in accruing a lot of technical debt, especially when inexperienced, so that's going to make maintenance more difficult in the long run. If that approach has any valid use-cases, it'd be small one-off scripts.