Hmm... If they are "burning" tons of energy on nice picture generation, cover letter creation or sloppy code snippets generation via those so "called-AI-things", maybe this energy could be used to create "AI-thing" that will detect issues in code? In my POV this would be better wasted energy...
> The companies profiting from this infrastructure can afford to thoroughly vet and monitor key dependencies on behalf of the community.
I'm not sure what you're recommending, but it sounds like more eyes on dependencies (code review, testing, and so on) from packagers who are downstream from library maintainers, rather than the library maintainers themselves?
This is what Linux distributions do, among others. Unfortunately there's a lot of volunteer work in that, too. Also, a lot of duplicate work. It seems worth mentioning that some codebases are easier to review and test than others, and the language they're written in plays a role in that.
The Go SDK is an example of a more centralized, monolithic approach. I don't think there are any outside dependencies at all? Volunteers contribute patches, but things like mandatory code review happen because that's what the project requires.
It's pretty stable. Some improvements take a long time, though.
This is the best take on the topic (of single maintainers).
Hmm... If they are "burning" tons of energy on nice picture generation, cover letter creation or sloppy code snippets generation via those so "called-AI-things", maybe this energy could be used to create "AI-thing" that will detect issues in code? In my POV this would be better wasted energy...
Could you do this to any linux package, or is it only worth it for one that is a low level dependency, something run as root?
> The companies profiting from this infrastructure can afford to thoroughly vet and monitor key dependencies on behalf of the community.
I'm not sure what you're recommending, but it sounds like more eyes on dependencies (code review, testing, and so on) from packagers who are downstream from library maintainers, rather than the library maintainers themselves?
This is what Linux distributions do, among others. Unfortunately there's a lot of volunteer work in that, too. Also, a lot of duplicate work. It seems worth mentioning that some codebases are easier to review and test than others, and the language they're written in plays a role in that.
The Go SDK is an example of a more centralized, monolithic approach. I don't think there are any outside dependencies at all? Volunteers contribute patches, but things like mandatory code review happen because that's what the project requires.
It's pretty stable. Some improvements take a long time, though.
a-Yup.