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

131–140 of 238 posts

Re: The fate of "small" open source

#131

Post by inferiorhuman »

NewsaHackO wrote: post #125
inferiorhuman wrote: post #101

Earlier quoted context omitted.

Hard disagree. AI summaries are useless for the same reason AI summaries from Google and DDG are useless: it's almost always missing the context. The AI page summaries typically take the form of "here's the type of message that the author of this page is trying to convey" instead of "here's what the page actually says". Just give me the fucking contents. If I wanted AI slop I'd ask my fucking doorknob.

I think you have some of your wires crossed, asking Google for "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 (also asking Google to reprint copyrighted material us also a non starter). Asking Google "what is the flag for persevering Metadata using scp" and getting the flag name instead of a SEO article with the a misleading title go on…

   "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 instead of a SEO article with the a misleading title go on about so third party program
  that you can download that does exactly that and never actually tell you the answer is
  ridiculous and I am happy AI has help reduce the click bait
Except that the AI slop Google and Microsoft and DDG use for summaries masks whether or not a result is SEO nonsense. Instead of using excerpts of the page the AI summary simply suggests that the SEO garbage is answering the question you asked. These bullshit AI summaries make it infinitely harder to parse out what's actually useful. I suppose that's the goal though. Hide that most of the results are low quality and force you to click through to more pages (ad views) to find something relevant. AI slop changes the summaries from "garbage in, garbage out" to simply "garbage out".

Re: The fate of "small" open source

#132

Post by whatevertrevor »

cml123 wrote: post #67
NewsaHackO wrote: post #59

Earlier quoted context omitted.

One instance of definite benefit of AI is AI summary web search. Searching for answers to simple questions and not having to cut though SEO slop is such an improvement

I don't think searching for answers to simple questions was a problem until Google nerfed their own search engine.

I don't understand this position, do you have direct evidence that Google actively made search worse? Before I'm misunderstood I do want to clarify that IMO, the end user experience for web searching on Google is much worse in 2025 than it was in say 2000. But, the web was also much much smaller, less commercial and the SNR was much better in general.

Sure, web search companies moved away from direct keyword matching to much more complex "semantics-adjacent" matching algorithms. But we don't have the counterfactual keyword-based Google search algorithm from 2000 on data from 2025 to claim that it's just search getting worse, or the problem simply getting much harder over time and Google failing to keep up with it.

In light of that, I'm much more inclined to believe that it's SEO spam becoming an industry that killed web search instead of companies "nerfing their own search engines".

Re: The fate of "small" open source

#133

Post by austin-cheney »

KPGv2 wrote: post #85
noosphr wrote: 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.

Your first sentence cheers that we're moving from NPM micropackages to LLM-generated code, and then you say this will result in people having to learn to code again. I don't see how the conclusion follows from this. There will be many LLM-generated functions purporting to do the same thing, and a bug in one of them that gets fixed means only one project gets fixed instead of every project using an NPM package as a de…

You mention that you don’t see how this could result in developers that write code. Then you immediately follow that with fixing bugs.

Yes, use of LLMs is still developers not writing original code, but it’s still an improvement (a minor one) of the copy/paste of micro dependencies.

Ultimately developers aren’t going to figure out writing original code until they are forced to do so from changed conditions within their employer.

Re: The fate of "small" open source

#134

Post by finaard »

KPGv2 wrote: post #85
noosphr wrote: 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.

Your first sentence cheers that we're moving from NPM micropackages to LLM-generated code, and then you say this will result in people having to learn to code again. I don't see how the conclusion follows from this. There will be many LLM-generated functions purporting to do the same thing, and a bug in one of them that gets fixed means only one project gets fixed instead of every project using an NPM package as a de…

There will be many LLM-generated functions doing the same thing, in the same project, unless the human pays attention.

I've been playing a lot recently with various models, lately with the expensive claude models (API, for the large context windows), and in every attempt things are really impressive at the beginning, and start going south once the codebase reaches about 10k to 15k lines of code. Even with tools split out into a separate library and separate documentation at that point it has a tendency to generate tool functions again in the module it's currently working on over taking the already defined one in the helper library.

Re: The fate of "small" open source

#135

Post by theturtlemoves »

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…

You're not obligated to give away your mind for free. You're free to share, of course. But sharing implies reciprocity, a back and forth. The internet used to be like that, but if the environment changes, you adapt your behavior accordingly.

In the long run I think it's time to starve the system from input until it's attitude reverts to reciprocal. It's not what I'd want, but it seems necessary. People learn from consequences, not from words alone

Re: The fate of "small" open source

#136

Post by skrebbel »

epicureanideal wrote: post #130
josephg wrote: post #129

Earlier quoted context omitted.

Can you give some examples? I’ve written js / ts for 10-15 years and I’ve never reached for lodash in my life.

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

Re: The fate of "small" open source

#137

Post by miki123211 »

josephg wrote: post #108
SchemaLoad wrote: post #80

Earlier quoted context omitted.

The best outcome was things like jquery and then lodash where a whole collection of small util functions get rolled in to one package.

Oh god, without tree shaking, lodash is such a blight. I've seen so many tiny packages pull in lodash for some little utility method so many times. 400 bytes of source code becomes 70kb in an instant, all because someone doesn't know how to filter items in an array. And I've also seen plenty of projects which somehow include multiple copies of lodash in their dependency tree. Its such a common junior move. Ugh. Exper…

The problem with helper functions is that they're often very easy to write, but very hard to figure out the types for.

Take a generic function that recursively converts snake_case object keys to pascalCase. That's about 10 lines of Javascript, you can write that in 2 mins if you're a competent dev. Figuring out the types for it can be done, but you really need a lot of ts expertise to pull it off.

Re: The fate of "small" open source

#138

Post by strogonoff »

Chances are, even if you deliberately and strategically pick to work on an OSS project that you are positively sure an LLM can’t just spit out on command, it will be capable of doing so by the time you are close to completion. In that sense, one has to either be not inclined to question “what’s the point” or have a bit of gambling mentality in order to work on anything substantial.

That’s not automatically a problem, however. The problem is that even if you do come up with a really cool idea that LLM is not capable of autocompleting, and you release it under a copyleft license (to ensure the project survives and volunteer contributor’s work is not adopted and extinguished by some commercial interest), it will get incorporated into its dataset regardless of the licensing, and thereafter the LLM will be capable of spitting it out and its large corporate operator will be able to monetise your code (allowing anyone with money wishing to build a commercial product based on it).

Re: The fate of "small" open source

#140

Post by shakow »

miki123211 wrote: post #137
josephg wrote: post #108

Earlier quoted context omitted.

Oh god, without tree shaking, lodash is such a blight. I've seen so many tiny packages pull in lodash for some little utility method so many times. 400 bytes of source code becomes 70kb in an instant, all because someone doesn't know how to filter items in an array. And I've also seen plenty of projects which somehow include multiple copies of lodash in their dependency tree. Its such a common junior move. Ugh. Exper…

The problem with helper functions is that they're often very easy to write, but very hard to figure out the types for. Take a generic function that recursively converts snake_case object keys to pascalCase. That's about 10 lines of Javascript, you can write that in 2 mins if you're a competent dev. Figuring out the types for it can be done, but you really need a lot of ts expertise to pull it off.

Not really familiar with TS, but what would be so weird with the typing? Wouldn't it be generic over `T -> U`, with T the type with snake_case fields and U the type with pascalCase fields?
Post reply on HN