Live data from Hacker News

The fate of "small" open source

nolanlawson.com

171–180 of 238 posts

Re: The fate of "small" open source

#171

Earlier 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…

That's why I'm not super optimistic. Even pre-AI and tech slump there were talks about how hard it may be to replace the old guard maintaining these open source initiatives. Now...

>Blaming AI is blaming the wrong problem. AI is a a tool like a spreadsheet. Project owners should instead be working ways to filter out careless code more efficiently.

When care leaves, the entire commons starts to fall apart. New talent doesn't come in. Old talent won't put up with it and retire out of the scene. They already have so much work to do, needing to add in non-development work to make better spam filters may very well be the final stray.

Even when the careless leave, it won't bring back the talent lost. Directing the blame onto the sure won't do that.

Re: The fate of "small" open source

#172

Earlier quoted context omitted.

This is an AI issue because people, including the developers of AI tools, don't care enough. 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 g…

We don't need an AI detector, we need a "human vetted" detector.

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

Re: The fate of "small" open source

#173
post #31

Earlier 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…

> 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 down.

>that likely means extremely competent maintainers and contributors.

Your assumption falls apart here, sadly. Dunning-Kruger hits hard here for new contributors powered by LLMs and the maintainers suffer the brunt of the hit.

Re: The fate of "small" open source

#174

Earlier quoted context omitted.

_.any, some, every, keyBy.

_.any doesn’t seem to exist. Some and every are also in JS (with the same names even!). keyBy is just Array.map -> Object.fromEntries

It was more useful before when browsers didn't support array.map and fromEntries. That's the origin of all these libraries, but browsers caught up. Things like keyBy, groupBy, debounce, uniqueId, and some others, are still useful.

Re: The fate of "small" open source

#175

Earlier quoted context omitted.

We don't need an AI detector, we need a "human vetted" detector.

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.

Re: The fate of "small" open source

#176

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…

The proper way to do it, would be to have an industry standard on the default things people blindly but massivly pull through dependencies.

I also don't get how code can be so massivly inefficient. left-pad needs 9kb to download and the code is a handful of lines: https://www.npmjs.com/package/left-pad?activeTab=code

If my unit tests run through, i don't have 'unproven' code. I have well working code which doesn't need to go through a dependency hell upgrade cycle just because one function in that lib, i don't use, has some CVE too high to be ignored.

Re: The fate of "small" open source

#177
post #73

I see this as an absolute win. The state of micro dependencies of js was a nightmare that only happened because a lot of undereducated developers flooded the market to get that sweet faang money. Now that both have dried up I hope we can close the vault door on js and have people learn how to code again.

> Now that both have dried up

They have??

And is it not going to be orders of magnitude worse with the vibe-coded crud hitting the internet?

Re: The fate of "small" open source

#178

Small open source is still valuable, but the bar is higher. If your project is something that's trivial and nobody just thought to do it before you and bothered to do it after, that's probably not going to survive, but if your project is a small focused tool that handles something difficult really well, it's 100% got a future.

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.)

Re: The fate of "small" open source

#179

AI offering the solution for a small problem that probably doesn’t deserve yet another dependency suggests to me that there’s a middle ground that we’ve failed to sufficiently cover: how to socialize code snippets that you’re meant to just inline into your project. Stack Overflow is probably the closest we’ve gotten to a generalized solution and it doesn’t exactly feel like a good one. I came across this once before…

GitHub gists are probably the best technical option. They come with versioning (I think), and have comment threads.

Re: The fate of "small" open source

#180
post #89
post #74

Earlier quoted context omitted.

Copied text does not inject bitcoin mining malware three months after I paste it.

Neither does a dependency you don't update, though, which is isomorphic to copied code you never update.

somehow, in the js/npm world, dependencies are updated willy nilly, which is the cause of a lot of that ecosystem's headaches.
Post reply on HN