In the U.S., anything machine generated is uncopyrightable. Why would you put uncopyrightable code into your codebase?
The fate of "small" open source
41–50 of 238 posts
Re: The fate of "small" open source
#42> Sure, you could use blob-util, but then you’d be taking on an extra dependency, with unknown performance, maintenance, and supply-chain risks. Use of an AI to write your code is also a form of dependency. When the LLM spits out code and you just dump it in your project with limited vetting, that's not really that different from vendoring a dependency. It has a different set of risks, but it still has risks.
Well yes there’s your problem. But people have been doing this with random snippets found on the internet for a while now. The truth is that irresponsibles developers will produce irresponsible code, with or without LLMs
Re: The fate of "small" open source
#43> the era of small, low-value libraries like blob-util is over. Thankfully (not against blob-util specifically because I've never intentionally used it), I wouldn't completely blame llms either since languages like Go never had this dependency hell. npm is a security nightmare not just because of npm the package manager, because the culture of the language rewards behavior such as "left-pad". Instead of writing endle…
But as Go puts it: “A little copying is better than a little dependency.” https://go-proverbs.github.io/
Re: The fate of "small" open source
#44> the era of small, low-value libraries like blob-util is over. Thankfully (not against blob-util specifically because I've never intentionally used it), I wouldn't completely blame llms either since languages like Go never had this dependency hell. npm is a security nightmare not just because of npm the package manager, because the culture of the language rewards behavior such as "left-pad". Instead of writing endle…
What is the feature of Go that this is referring to?
Re: The fate of "small" open source
#45> Sure, you could use blob-util, but then you’d be taking on an extra dependency, with unknown performance, maintenance, and supply-chain risks. Use of an AI to write your code is also a form of dependency. When the LLM spits out code and you just dump it in your project with limited vetting, that's not really that different from vendoring a dependency. It has a different set of risks, but it still has risks.
Re: The fate of "small" open source
#46Earlier quoted context omitted.
But as Go puts it: “A little copying is better than a little dependency.” https://go-proverbs.github.io/
Copying is just as much dependency, you just have to do maintenance through manual find-and-replace now.
For some definition of "small piece of code" that may be ok, but also sometimes this is more than folks consider
Re: The fate of "small" open source
#47In the U.S., anything machine generated is uncopyrightable. Why would you put uncopyrightable code into your codebase?
Re: The fate of "small" open source
#48Earlier quoted context omitted.
But as Go puts it: “A little copying is better than a little dependency.” https://go-proverbs.github.io/
Copying is just as much dependency, you just have to do maintenance through manual find-and-replace now.
Re: The fate of "small" open source
#49Earlier quoted context omitted.
> It’s posed to get significantly stronger It's really not. Every project of any significance is now fending off AI submissions from people who have not the slightest fucking clue about what is involved in working on long-running, difficult projects or how offensive it is to just slather some slop on a bug report and demand it is given scrutiny. Even at the 10,000 feet view it has wasted people's time because they ha…
This isn't an AI issue. It is a care issue. People shouldn't submit PRs to project where they don't care enough to understand the project they are submitting to or the code they are submitting. This has always been a problem, there is nothing new. The thing that is new is more people can get to a point where they can submit regardless of their care or understanding. A lot of people are trying to gild their resume by…
The Tragedy Of The Commons is always about this: people want what they want, and they do not care to prevent the tragedy, if they even recognise it.
> Project owners should instead be working ways to filter out careless code more efficiently.
Great. So the industry creates a burden and then forces people to deal with it — I guess it's an opportunity to sell some AI detection tools.
Re: The fate of "small" open source
#50Earlier quoted context omitted.
> It’s posed to get significantly stronger It's really not. Every project of any significance is now fending off AI submissions from people who have not the slightest fucking clue about what is involved in working on long-running, difficult projects or how offensive it is to just slather some slop on a bug report and demand it is given scrutiny. Even at the 10,000 feet view it has wasted people's time because they ha…
Sounds like a lot of FUD to me — if major projects balk at the emergence of new classes of tools, perhaps the management strategy wasn’t resilient in the first place? Further: sitting down to discuss how your project will adapt to change is never a waste of time, I’m surprised you stated it like that. In such a setting, you’re working within a trusted party — and for a major project, that likely means extremely compe…
It is a waste of time for large-scale volunteer-led projects who now have to deal with tons of shit — when the very topic is "how do we fend off this stuff that we do not want, because our project relies on much deeper knowledge than these submissions ever demonstrate?"