Ethical-foss open slopware

Edit, thanks to @Gamall : someone has a repository on codeberg to make a list categorising software according to their stance on LLM/AI.

The list of software I’m seeing is nearly 100% AI-integrated. They are being rated on how ā€˜permissive’ AI policy is which is interesting. (I’m saying that based on the Tags & Evidence column).

Lot to digest here. Language Models aren’t even mentioned on this page unless they are an implied built-in part to AI.

I don’t use most of the software on this list…I worry about the software I got.

Interesting compilation.

EDIT: found the inclusion of yay (ā€œPermissive AI Policyā€) on the list concerning.

This is one of many projects hosted on Codeberg. It does not look like it has anything whatsoever to do with Codeberg itself.

It’s interesting to note omissions like dwm, arch, manjaro, mxlinux, debian, mint…

rsync is flagged as vibe coded, according to this.

But the link to the evidence only reveals a merge request in relation to (unit ?) tests rewritten in python. And claude code has been involved in that process. That isn’t necessarily clear proof that this has been vibe-coded. And it’s not representative for the whole code base and the whole development team behind rsync being notorious vibe coders that don’t have a clue. Rsync was initially released back in 1996. Therefore, I’m pretty certain that the majority of it’s code base definitely was written without any AI involvement.

From my point of view, and I’ll loosely cite Linus Torvalds in this context:
The usage of automation tools, either man-made or by the assistance of AI tools, is more or less inevitable in the context of software development. By automation, for instance in the case of unit testing, simple and pretty tedious time-consuming tasks could be orchestrated, without the need of spending a whole lot of man hours on the task at hand.

Sure, vibe coding does exist. But I’m pretty certain that labeling a open source software due to their ā€œpermissive AI policiesā€ doesn’t make a whole lot of sense. And labeling a whole 30 year old software project as ā€œvibe codedā€ only due to the involvement of claude code within a single pull request is definitely not the sensible thing to do. There is a huge difference between vibe coding and AI code assistance that has been reviewed.

I also noticed the footnotes never established anything definitive. I have to agree with Torvalds on the hard work and tools sentiment, as long as humans doublechecked.

Perhaps this person’s hard work would be more stunning if they simply published the short list of completely anti-AI/AI-free apps only. Then all the stuff we normally use becomes suspect by omission. May that is poetic license?

the inclusion of 10 distros and the rest disappeared did not get by me either.

IMHO I see zero issue if some dev uses ai tools to help them out creating good software.

If the code is good and works why not? If it was a suggestion by someone else to implement the code or dev found/generated it, understands the code fully and is able to use and work with it it’s fine in my book.

There is software out there that made huge improvements thanks to these tools, like a project that was able to implement GPU passthrough thanks to ai, as the dev himself was not able to figure out how to do it (think it was lutris or some other program similar to it that exists since quite a long time, I forgot). It worked flawlessly with no issues, there are many stories like these where projects have either small teams, or a single person maintains it, yet many use it and those are only able to improve thanks to ai tools.

But nonetheless, if I read that a project is fully written by ai, I will definitely wonder if it is buggy, can be maintained and if the person behind it even understands the code to troubleshoot it, or is interested in keeping it updated… And so on.

But if it’s a dev, a good one with experience? First sentence I wrote up there stands :backhand_index_pointing_up:
(As it is the Linux kernel also has ai parts in it by now)

Really important observation which I would like to highlight again

I edited the first post to make that clear.

When the top of the README of the repository starts with political and social stances that are completely unrelated to the topic at hand, it honestly flagged the entire thing, for me, as being biased towards the view of LLMs being a negative immediately… No, I don’t have a problem with those stances, I support them too, but putting them at the top of the README certainly makes it… pushy, honestly…

Another thing that some people here seem to have said, but using tools like LLMs to help you out code is… a thing that will happen. Yes, I do agree that attached to LLMs and generative AI are a lot of societal, economical and political issues, but I don’t believe that’s the fault of the tool, it’s the fault of the people behind the tool, trying their hardest to profit off a still largely unproven technological development. It’s the fault of management and investors and general delusional individuals with a lot of power, trying to suck more and more money out of society. Does that make the tool bad? No. I actually believe that for newcomers to programming, like me, it has made things much smoother and opened a way for me to learn much more quickly about things. Vibecoding is bad, but how bad is it to use a LLM, alongside documentation and your own previous experience to learn how pieces go together?

I edited the first post to make this clear

It seems more people are collating the same sort of information:

From what I can tell, that tracker reports AI automated commits but doesn’t allow to distinguish which kind of commit has been pushed. E.g. you see a whole lot of documentation and overviews generated in a similar fashion that may only relate to the repositories markdown files, without being functional source code.

So it’s not obvious in which context AI assistance had been used from these statistics. It could be only documentation, automatic code commenting within the source code to meet given code documentation standards.

Only the fact that it has been an automated commit doesn’t reflect the context in which way the code has been reviewed by the author. If it’s only affecting the repositories README.md file, or actual code-generation isn’t distinguishable.

Even, if an developer would suppress any evidence that AI assistance has been used in the process, wouldn’t be traceable.

I guess it all boils down to garbage in- garbage out. Undefined data selection, accumulation constraints, limitations, specifications significantly degrade the value of the summarization