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

191–200 of 238 posts

Re: The fate of "small" open source

#191

Post by safety1st »

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…

This mostly sounds like a good thing to me from a utilitarian standpoint. Getting all your utility classes from somewhere like npm and creating dependencies on 20 different people and organizations who may or may not maintain their software has been a security nightmare with many highly public examples. If a LLM writes a utility class for me then my supply chain is smaller, meaning less surface area to attack plus I probably benefit from some form of security through obscurity for whatever non-trivial amount that's worth. "Downside" is I don't have some rando, probably unpaid labor out there updating a piece of my app for me...

Re: The fate of "small" open source

#193

Post by mrweasel »

croes wrote: post #83
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.

Now you got vibe coder

Yeah, you're sort of swapping in one issue for another. I agree that micro dependencies needs to be tackled, but perhaps not using LLMs.

I could fear that rather than keep pushing for a Javascript standard library, which would encompass all these smaller function, we now just get more or less the same defective implementations generated by LLMs, but hidden in thousands of repos, where tools won't find security issues. At least with NPM we can pull in updated versions with NPM tells us that we're running an outdated version. Who is going to traverse your proprietary code base and let you know that the vibe coded left-pad Claude put in three years ago is buggy?

Re: The fate of "small" open source

#194

Post by jorvi »

marcus_holmes wrote: post #96
jorvi wrote: post #88

Earlier quoted context omitted.

> If you're the author of a library, you have to cover every possible way in which your code might be used. You don't actually. You write the library for how you use it, and you accept pull requests that extend it if you feel it has merit. If you don't, people are free to fork it and pull in your improvements periodically. Or their fork gets more popular, and you get to swap in a library that is now better-maintained…

It's a rare developer (or human for that matter) who can just shrug and say "fork off" when asked for help with their library.

It really depends. If it's the occasional request and I can bang out a solution in 30 minutes, I'll help. But I'll also weigh how much maintenance burden it'll be going forward. And if I won't do it myself, I'd always give some quick pointers.

Maintenance demands (your library X doesn't work with Python Y, please maintain another version for me) I'd shrug off. Wait for me, pay me, or fix it yourself.

Re: The fate of "small" open source

#195

Post by Cthulhu_ »

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…

It's not a new thing either, many years ago there was already the debate whether you should trust utility code copied from SO or use an NPM library. In fact, I'm 99% confident that the slew of single function NPM libraries became a thing because of that mindset.

Re: The fate of "small" open source

#196

Post by Waterluvian »

jcgl wrote: post #179
Waterluvian wrote: post #121

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.

And a decent API as well.

I think what’s missing is some amount of organization to make them more discoverable.

Re: The fate of "small" open source

#197

Post by _heimdall »

Levitating wrote: post #68

I am sure I am not the only one who thinks these micro-dependencies are worthless anyway. You'd be better off just listing the functions in a markdown file for people to copy over than ship an entire package for it. This isn't "small" open source, "small" would be something you put together in a week or weekend. These are like "micro" projects, where more work goes into actually publishing and maintaining the reposit…

Vendoring dependencies is how I remember doing it for web projects pre-NPM. Find an open source, well tested library and copy the source into your project.

You have to manually update for any releases you care about, but that is also an incentive to keep dependency count low.

Re: The fate of "small" open source

#198

Post by josephg »

friendzis wrote: post #148
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…

> 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 with side effects. This makes dead code elimination in the compiler waay more complicated.

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.

> I don't see much value in having exact members imported listed out at the preamble

The benefit to having exact members explicitly imported is that you don't need to rely on a "sufficiently advanced compiler". As you say, if its done correctly, the result is indistinguishable anyway.

In my mind, anything that helps stop all of lodash being pulled in unnecessarily is a win in my books. A lot of javascript projects need all the help they can get.

Re: The fate of "small" open source

#199

Post by mccoyb »

johnnyanmac wrote: post #173
mccoyb wrote: post #31

Earlier quoted context omitted.

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 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?

Re: The fate of "small" open source

#200

Post by cml123 »

NewsaHackO wrote: post #127
cml123 wrote: post #67

Earlier quoted context omitted.

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

Pretty sure Google attempting to curb SEO tactics is what led to whatever nerfing you are talking about.

granted it's not up to courtroom standards, this post linked by another commenter in the chain does paint the picture pretty well of an internal struggle between Search and Ads inside Google as a company, where there was a decision to promote user-negative changes to Search as a way to increase the total number of searches performed, thereby increasing the number of ads that can be shown. This happened during 2019.

https://www.wheresyoured.at/the-men-who-killed-google/

Post reply on HN