I had a report for AI slop today. 1m LOC in 3 months. How do you even modify and distribute that? I do not think we had a rule against it.
IMHO if we allow, the community gets drowned out by AI vomit and it is harder to see handcrafted loved projects that are easy to modify and distribute.
My mind is to ban it to preserve open source.
Are folk in agreememt with this line? Would love to hear your thoughts.
Curious. Woke up to find my post removed at almost exactly the same time you posted this, complete with an accusation of “slop”.
The post had 31 upvotes, a 98% positive vote ratio and genuine discussion, for a project with a 6 month history behind it and a freshly repopulated repo. That doesn’t read like an unwelcome contribution.
To be clear, I’m not asking nor am interested in reinstatement of it.
Speaking plainly, !aials appears to be a tar pit for projects the mods deem guilty until proved innocent. Cool - your room, your rules.
But I suspect this approach will lead you exactly here:
https://lemmy.dbzer0.com/post/78050871/29108982
IMESHO, there may be some merit in approaching things the way !selfhosted does, vis-a-vis [AIP], [CBH] tags.
There’s a significant difference between those categories and a catch all rule that assumes the worst. The latter leads to things like this. The proxy signals you’re proposing would have tar-pitted something like the venerable cURL if it had come out today and been accused of “slopware” (whatever that means).
yes, after a brief assessment i concluded (correctly, i see now after taking another look at it) that your project is exactly the kind of new, single-developer, vibe-coded slop which i think we should not accept the promotion of here… and yes, seeing and deleting your post was what reminded me that i’ve been meaning to post something in this thread.
however, after i deleted it for being slop, i also noticed another reason it is not suitable for this community: as @thingsiplay@lemmy.ml helpfully pointed out in the comments, your README says this:
So, it isn’t even an open source project going forward: the released source code is “frozen” and future versions will be binary-only? so, in this case you actually shouldn’t post this in the !aials@lemmy.ml community either 🤦
fwiw i am personally not completely opposed to AI-assisted coding; i am also doing some of it myself. however i think everyone should be skeptical of new single-developer vibe-coded projects - most are very low quality and will be abandoned in the near future.
This is exactly what the new community is meant to address: to have a place for people to share their AI-created softwares without getting a flood of hate for it being made with AI.
A brief assessment indeed. Dare I say, a perfunctory one.
You claim to have assessed the project, then taken another look, but provide no technical findings. Tell me then, specifically, what defects, security problems, unreliable features or examples of poor code did you find?
Or did you just decide “fresh-looking repo, one dev, disclosed AI, therefore slop”?
In your earlier remarks, you argued that no firm definition of “slop” was necessary. Yet you remain remarkably vibes-based about what constitutes it. Surely, during your extensive twice-over assessment, you would have noticed that SmartTube LOCAL is a fork of an established project, not something generated wholesale from a prompt?
My additions include about 5,000 lines in new source files, plus minor modifications to existing code, across 6-8 months of development. The overwhelming majority of the codebase remains upstream SmartTube and its dependencies.
The new functionality includes local profiles, local subscriptions, playlist imports and offline playback from SMB shares. I’ve tested actual builds on multiple TVs, including offline operation without internet access.
I reviewed the code by hand, tested it myself, rewrote parts of it and iterated upon the results.
None of this proves the code is perfect. It does, however, suggest something rather more substantial to assess than the age of a GitHub repository.
The public repository contains source code, build files and an MIT licence that preserves the original SmartTube copyright notice.
The published 32.71 source code is open source. Anyone can inspect, modify, redistribute or fork it. In fact, I specifically encourage people to do so in the README.
The MIT licence also permits binary-only distribution of MIT-licensed code, subject to its notice requirements. That doesn’t make a future binary-only build open source, but neither does it invalidate the existing release.
I won’t push every intermediate source revision to GitHub. The project is maintained privately on self hosted Forgejo, and preparing a clean public release means sanitising code, separating unfinished features and removing private configuration and internal CI/CD tooling.
That adds to my workload without much benefit to the people I support.
I’m perfectly happy to publish updated source code with the next major revision, which I’m working on slowly.
So, while you might reasonably argue that my README was poorly worded, there’s rather a large difference between not publishing every intermediate source revision and permanently withholding source code for all future releases.
To be frank, you appear to be set on pre-punishing a solo developer for sharing a family-and-friends project based on a rather cursory examination. Doesn’t that run somewhat contrary to the spirit of FOSS?
Great. And yet you readily throw around “slop” as an invective and propose that new, heavily AI-assisted solo projects be relegated to !aials@lemmy.ml, regardless of their actual quality.
I’m sure you see the disconnect.
You also suggest that most new solo AI-assisted projects are low quality and likely to be abandoned.
That’s a generalisation, not an assessment of the project I posted.
I’ve publicly discussed SmartTube LOCAL’s progress on the upstream SmartTube Show and Tell forum since September, with further updates in October.
The repository is new because I repopulated it from my private development tree. Its creation date does not reflect the age of the project.
Time in development alone doesn’t prove that SmartTube LOCAL is high quality. Equally, one developer and a new public repository don’t prove that it is poor quality.
Which takes us full circle to your proposed secondary metrics. Project age and developer count might indicate maturity or maintenance risk, but neither establishes code quality. A young project can be well engineered, and an old one can be dreadful.
There’s a certain irony here I’d like to comment on.
You’ve now publicly called my project “slop” twice, without identifying a single technical defect, while advocating a separate community to protect AI-assisted developers from precisely that sort of hostility.
I’m not opposed to !aials existing. It might become a genuinely useful community for people who use AI in software development.
But presenting it as a refuge from hostility while dismissing projects as “slop” without demonstrating what’s wrong with them or what “slop” is rather undermines the sentiment.
As I said, I’m not asking you to reinstate my post. Your community, your rules.
But if you’re going to dismiss someone’s work as “slop” after two looks at the project, I don’t think it’s unreasonable to ask you to explain what, specifically, is wrong with it.
Otherwise, this is precisely the “guilty until proven innocent” approach I mentioned earlier.
“The spirit of FOSS” entails the users having the four freedoms (to use, modify, share verbatim copies, and share modified copies) of the source code. You’ve suggested that this project is primarily binary-only with only intermittent source code dumps, meaning that until these binaries have corresponding source code they are neither FOSS in letter nor in spirit, and thus inappropriate for this community as well as for !aials@lemmy.ml, which is for AI-assisted FOSS. Given that you’ve suggested you will only provide source code for “major revisions” this suggests that “minor versions” never will be FOSS. Effectively you’re promoting a proprietary product here that may or may not have intermittent source code snapshots.
Furthermore, the fact that you seem to consider it a great effort to “sanitize” the source code for public release suggests that what is being shared with the public is not in fact the corresponding source code to the binaries you upload.
As you pointed out the MIT license does allow you to make proprietary derivatives, so nothing you’ve done is “wrong” or illegal. That doesn’t make it not proprietary.
Edit: I’m a different person than the admin who removed your post. I’m not suggesting your project is slop or that the effort you’ve put into it is inconsequential. I’m just saying that binaries without source code are not FOSS even if you publish occasional snapshots of selected releases. I’d probably be more favorable to this approach if there were FOSS builds from the source code snapshots, or maybe if only the FOSS releases were on github and the proprietary ones somewhere else - but that’s probably asking a bit too much.
The current 32.71 snapshot includes both source code and APKs compiled there from. I take your point that I should make that correspondence clearer, along with which future interim releases might have no public source.
At present, under the definitions you’ve provided, the current release meets all four FOSS criteria.
As for “sanitising”, I mean removing private configuration, credentials and development files, not stripping out functional source code. That’s literally all I meant.
As I’ve said, development happens in my private Forgejo repository, so preparing a public snapshot involves a little housekeeping. I prefer to keep the public release clean, and .gitignore only does part of that job.
I appreciate you being civil. The other points I raised are worth serious community consideration (especially what constitutes “slop”, AI disclosure, and the unintended consequences of penalising transparency rather than judging projects on their merits), but I have said my piece.