Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The fate of "small" open source

nolanlawson.com

Post reply on HN
Print view View original

221–230 of 238 posts

Re: The fate of "small" open source

#221

Post by LtWorf »

Pet_Ant wrote: post #210
NegativeK wrote: post #12

Earlier quoted context omitted.

The problem isn't that AI slop is doing something new. Phishing, blogspam, time wasting PRs, website scraping, etc have all existed before. The problem is that AI makes all of that far, far easier. Even using tooling to filter articles doesn't scale as slop grows to be a larger and larger percentage of content, and it means I'm going to have to consider prompt injections and running arbitrary code. All of this is a r…

> The problem isn't that AI slop is doing something new. Phishing, blogspam, time wasting PRs, website scraping, etc have all existed before. The problem is that AI makes all of that far, far easier. The term I like is that AI has _industrialised_ those behaviours. While native hunted buffalo, it wasn't destructive until it was industrialised [1] it that it became truly destructive. [1] https://allthatsinteresting.co…

Well they hunted buffalo for feeding and pelt, the slaughter was done to make them hungry.

Re: The fate of "small" open source

#222

Post by immibis »

llbbdd wrote: post #119
ef2k wrote: post #92

> I’m still trying to figure out what kinds of open source are worth writing in this new era Is there any upside to opensourcing anything anymore? Anything published today becomes training data for the next model, with no attribution to the original work. If the goal is to experiment, share ideas, or let others learn from the work, maybe the better default now is "source available", instead of FOSS in the classic sen…

I keep seeing this attitude and I don't really understand it at all; there's no upside to publishing open source work because it might be utilized by more people, is that correct? Or is it the attribution? There are many many libraries I have used and continue to use and I don't know the author's internet handle or Christian name. Does that matter? Why? I have written a lot of code that my name is no longer attached…

People were publishing "open source" not because they gave a shit, but to pad their resumes to get hired at FAANG - like they're paid by the number of projects published on Github It was always human slop. I'm glad this practice is dying. Soon we might be able to reinstate the assumption that the remaining open source projects contain interesting ideas that are worth your eyeball time to look at.

Re: The fate of "small" open source

#223

Post by m463 »

p0w3n3d wrote: post #142

Given that some 80% of developers are now using AI in their regular work, blob-util is almost certainly the kind of thing that most developers would just happily have an LLM generate for them. Sure, you could use blob-util, but then you’d be taking on an extra dependency, with unknown performance, maintenance, and supply-chain risks. Letting LLM write utility code is a sword that cuts both ways. You often create a th…

Actually sounds like something someone that wrote a really small utility that is surprisingly (to him) used by a lot of people would say.

But the benefit he provided is significantly more than he realizes/acknowledges.

Re: The fate of "small" open source

#224

Post by inferiorhuman »

m000 wrote: post #178
inferiorhuman wrote: post #105

Earlier quoted context omitted.

Earlier this year I wrote an interpreter for a niche, proprietary binary format. Someone asked if I could open source it so that they could (more easily) run it on NixOS. I declined as I'm just that strongly opposed to my work being used to train AI models and further entrench the enshittification of the internet.

Curious: So you only release your interpreter as a binary? Is there some license that explicitly forbids use for AI training? (Although it would probably be unclear if that is really enforceable until someone challenges it.)

Yep binary only with an eye towards an AGPL release. No, I don't think verbiage in a license would do much.

Re: The fate of "small" open source

#225

Post by inferiorhuman »

NewsaHackO wrote: post #204
inferiorhuman wrote: post #131

Earlier quoted context omitted.

"here's the type of message that the author of this page is trying to convey" is not what most people think is a simple question It's also not the question I asked. I'm literally trying to parse out what question was asked. That's what makes AI slop so infuriating: it's entirely orthogonal to the information I'm after. Asking Google "what is the flag for persevering Metadata using scp" and getting the flag name inste…

At least with Google, it quotes the pages where it gets the information from. Also, I think you are definitely underplaying the fact that it answers the question in one sentence,as wellas the whole ask a question get a compact answer. I am going to need a concrete example, because in my experience, the AI summary has never even required me to verify the source except out of curiosity, much less click on any search re…

I'm talking about page summaries.

Re: The fate of "small" open source

#226

Post by johnnyanmac »

danielbln wrote: post #175
johnnyanmac wrote: post #172

Earlier quoted context omitted.

Who's paying the human to vet it? Or will we have volunteers dedicated to being AI detectors instead of developers?

I don't have those answers. My point was that trying to outright ban any AI is futile and probably overall counter productive, and that we need to find ways to ensure a human hasn't submitted slop. I don't have an answer as to the how.

> trying to outright ban any AI is futile and probably overall counter productive

okay, you can keep thinking that. I'll just reject anything that has a whiff of AI and lacks care. No point campaigning in this admin to regulate anything, so that's off the table for 1-3 years.

Re: The fate of "small" open source

#227

Post by johnnyanmac »

SoftTalker wrote: post #215
eloisant wrote: post #182

Earlier quoted context omitted.

> I see it as the same way Tinder works if you want the mentality. There's a point where being "optimal" hurts your bottom line, so you don't desire achieving a perfect algorithm Yes, in the case of Google: - They make more money from ads if the organic results are not as good (especially if it's not clear they're add) - They get more impressions if you don't find the answer at the first search and have to try a diff…

This is entirely because "we" insist on search being free. This means Google needs to find other ways to pay for it, which creates a different set of incentives. If we somehow paid directly for search, then Google's incentives would be to make search good so that we'd be happy customers and come back again, rather than find devious ways to show us more ads. Most people put up with the current search experience becaus…

When I get a full time job, Kagi is the first thing I'm buying a subsciption for. It's not perfect, but I want to at least show a demand. I'm willing to contribute premiums for proper services that won't mine all my data and is actually beholden to customers

Re: The fate of "small" open source

#228

Post by WorldMaker »

josephg wrote: post #198
friendzis wrote: post #148

Earlier quoted context omitted.

> 400 bytes of source code becomes 70kb in an instant, This only shows how limited and/or impractical dependency management story is. The whole idea behind semver is that at the public interface level patch version does not matter at all and minor versions can be upped without breaking changes, therefore a release build should be safe to only include major versions referenced (or on the safe side, the highest version…

> Any decent compiler should be able to shake dead code in source dependencies anyway, therefore there should not be any functional difference between importing specific members and importing the whole package. Part of the problem is that a javascript module is (or at least used to be) just a normal function body that gets executed. In javascript you can write any code you want at the global scope - including code wi…

> Modules need to opt in to even allowing tree shaking by adding sideEffects: false in package.json - which is something most people don't know to do.

That flag has always been a non-standard mostly-just-Webpack-specific thing. It's still useful to include in package.json for now, because Webpack still has a huge footprint.

It shouldn't be an opt-in that anything written and published purely as ESM should need, it was a hack to paper over problems with CommonJS. One of the reasons to be excitedly dropping CommonJS support everywhere and be we are getting to be mostly on the other side of the long and ugly transition and getting to a much more ESM-native JS world.

Re: The fate of "small" open source

#229

Post by matheusmoreira »

AlexandrB wrote: post #213
matheusmoreira wrote: post #93

> I don’t know which direction we’re going in with AI Maybe programming languages will be designed for AIs in the future. Maybe they'll have features that make grafting unknown generated code easier.

Will we ever even get a widespread new programming language? AIs work great for coding because they have massive codebases in C/C++/Python/JS/etc. to train on. If I create a language called "foo" tomorrow, no such codebase will exist for it and the lack of AI support for the language will be a huge barrier for adoption so it's going to be much less likely to catch on like Python did back in the day.

I'm working on my own lisp. I've used ChatGPT to generate some cases for my test suite. Somehow it can generate decent code if I instruct it thoroughly enough and provide samples. Maybe the fact all lisps have similar syntax helps?

Re: The fate of "small" open source

#230

Post by johnnyanmac »

mccoyb wrote: post #199
johnnyanmac wrote: post #173

Earlier quoted context omitted.

> if major projects balk at the emergence of new classes of tools, perhaps the management strategy wasn’t resilient in the first place? It's not the tools, it's the quality. No FOSS dev would care where the code came from if it followed the contributor's guidelines and coding style. This is why it's a spam issue. a bunch of low quality submissions only gum up the time of such developers and slows the entire process d…

Why not just disallow PRs from non-vetted contributors? Why not just disallow issues without a vetting process? Many of these things could be explored -- you're right: it's a spam issue. But we have solutions to spam issues ... filters. LLMs have shown that "praying for the best" with permissive repository settings is not sufficient. We can and will improve our filters, no?

That's certainly going to be the eventual outcome at this rate, yes. Close off the FOSS and go underground. Contributing will now involve negotiating the politics and vetting oneself instead of the quality of the contributions. Rejective, but it feels like it hurts the spirit of FOSS. For an industry that can already be considered a bit gatekeep-y

You can definitely argue we hit that point a long time ago, but this will exacerbate it.

Post reply on HN