I have wondered where we are with stuff like this.

I myself have been using an open source lib that I contributed a fix for and inquired about it. I didn't just drop a PR either, opened an issue, was told PRs accepted, opened a PR, signed a license agreement and then the PR just sort hung out for months without response even after some gentle prodding.

Now, they don't owe me anything and they don't have to merge the code, it is their repo after all. However what did I do? use an LLM, fork the repo with my changes and now "I" maintain that private fork and add to it as needed.

As time goes on I think these smaller packages / clients will start to disappear as people/LLMs just spit out a client library or whatever or just implement the same thing over and over. Combined with the opinion of the author I figure oss libs for npm, ruby, pypi etc will start to dwindle.

▲

aaronax 6 hours ago | parent | next [-]

Eventually maintainers will just throw up their hands and leave the repo under the care of a LLM. "Merge PRs that align with the product's vision/design/intention. Meticulously examine for malicious contributions. Email me if there are doubts."

The top tier LLMs would be as good at this as a lot of maintainers, right?

	▲	tempest_ 5 hours ago \| parent [-]
		> The top tier LLMs would be as good at this as a lot of maintainers, right? In some respects maybe in others less so. So in my situation I am using a client for a system and am using a very specific part of it even though there is a lot of other complicated code in other parts of the client. A LLM is good enough to maintain the code path I am using and of course any changes are triggered / watched over by me. In this situation I am comfortable letting LLMs do most of the code. I would be less enthused if that was outside of my control and the code changes were more often and faster.

▲

slopinthebag 4 hours ago | parent | prev [-]

yeah maybe. i think it's become a lot more feasible to fork and modify vs wait for new features or fix bugs. the future might be that the main repo for a project forms the "core", and consumers use their own forks which are automatically kept up to date. the core doesn't need to be as configurable or flexible as the forks can add functionality directly. in theory it could be easier for the maintainers.