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

51–60 of 238 posts

Re: The fate of "small" open source

#51

Post by cortesoft »

BrenBarn wrote: post #32

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

Part of the benefit over a dependency is that the code added will (hopefully) be narrowly tailored to your specific need, rather than the generic implementation from a library that likely has support for unused features.

Not including the unused features both makes the code you are adding easier to read and understand, but it also may be more efficient for your specific use case, since you don't have to take into account all the other possible use cases you don't care about.

Re: The fate of "small" open source

#52

Post by exasperaited »

micromacrofoot wrote: post #25
exasperaited wrote: post #21

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…

yeah we are getting lots of "I don't know how to do this and AI gave me this code that doesn't work, can you fix it" or "AI said it can do this" and the feature doesn't exist... some people will even argue and say "but AI said it doesn't take long, why won't you add it"

It weaponises incompetence, carelessness and arrogance at every turn.

AI, to me, is a character test: I'm regularly fascinated by finding out who fails it.

For example, in my personal life I have been treated to AI-generated comms from someone that I would never have expected it from. They don't know I know, and they don't know that I think less of them, and I always will.

Re: The fate of "small" open source

#53

Post by skydhash »

jamietanna wrote: post #46
threatofrain wrote: post #43

Earlier quoted context omitted.

Copying is just as much dependency, you just have to do maintenance through manual find-and-replace now.

Yeah it's the main thing I really dislike about this - how do you make sure you know where it's from? (ie licensing) What if there are updates you need? Are you going to maintain it forever? For some definition of "small piece of code" that may be ok, but also sometimes this is more than folks consider

Do you know that you can just add a small text file or a comment explaining that a module is vendored code. Ad updates is handled the same way as the rest of the code. And you will be “maintaining” it as long as you need to. Libraries are not “here be dragons” best left to adventurous ones.

Re: The fate of "small" open source

#54

Post by sodapopcan »

threatofrain wrote: post #43
ncruces wrote: post #27

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

Usually these types if things never change. I understand that all code is a liability, but npm takes this way too far. Many utility functions can be left untouched for many years if not forever.

Re: The fate of "small" open source

#55

Post by ninkendo »

threatofrain wrote: post #43
ncruces wrote: post #27

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

> you just have to do maintenance through manual find-and-replace now

Do you? It doesn't seem even remotely like an apples-to-apples comparison to me.

If you're the author of a library, you have to cover every possible way in which your code might be used. Most of the "maintenance" ends up being due to some bug report coming from a user who is not doing things in the way you anticipated, and you have to adjust your library (possibly causing more bugs) to accommodate, etc.

If you instead imaging the same functionality being just another private thing within your application, you only need to make sure that functionality works in the one single way you're using it. You don't have to make it arbitrarily general purpose. You can do error handling elsewhere in your app. You can test it only against the range of inputs you've already ensured are the case in your app, etc. The amount of "maintenance" is tiny by comparison to what a library maintainer would have to be doing.

It seems obvious to me that "maintenance" means a much more limited thing when talking about some functionality that the rest of your app is using (and which you can test against the way you're using it), versus a public library that everyone is using and needs to work for everyone's usage of it.

Re: The fate of "small" open source

#56

Post by exasperaited »

siliconpotato wrote: post #38
smcameron wrote: post #34

In the U.S., anything machine generated is uncopyrightable. Why would you put uncopyrightable code into your codebase?

Even worse...unmaintained code. Only the human-written one has a maintainer. The other one plagiariased by AI is instant legacy code

> The other one plagiariased by AI is instant legacy code

I have used this "instant legacy code" concept before. It's absolutely true, IMO. But people really, really, really hate hearing it.

Re: The fate of "small" open source

#57

Post by fullofideas »

ronbenton wrote: post #42
BrenBarn wrote: post #32

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

> and you just dump it in your project with limited vetting 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

> The truth is that irresponsibles developers will produce irresponsible code, with or without LLMs True. But the difference is the scale and ease of doing with code generators. With a few clicks you can add hundreds of lines of code which supposedly does the right thing. While in the past, you would get code snippets for a particular aspect of the problem that you are trying to solve. You still had to figure out how to add it to your code base and somehow make it “work”

Re: The fate of "small" open source

#58

Post by w10-1 »

TLDR: [AI promises] a future where we prize instant answers over teaching and understanding

But what this article and the comments don't say: open-source is mainly a quality metric. I re-use code from popular open-source repo's in part because others have used it without complaints (or document the bugs), in part because people are embarrassed to write poor-quality open-source so it's above-par code, and in part because if there are issues in this corner of the world, this dependency will solve them over time (and I can watch and wait when I don't have time to fix and contribute).

The quality aspect drives me to prefer dependencies over AI when I don't want full ownership, so I'll often ask AI to show open-source projects that do something well.

(As an aside, this article is about AI, but AI is so pervasive now as an issue that it doesn't even need saying in the title.)

Re: The fate of "small" open source

#59

Post by NewsaHackO »

AstroBen wrote: post #19
NitpickLawyer wrote: post #10

Earlier quoted context omitted.

> or a spammer where your incentives have probably increased. Slight pushback on this. The web has been spammed with subpar tutorials for ages now. The kind of medium "articles" that are nothing more than "getting started" steps + slop that got popular circa 2017-2019 is imo worse than the listy-boldy-emojy-filled articles that the LLMs come up with. So nothing gained, nothing lost imo. You still have to learn how to…

The difference is that the cost of slop has decreased by orders of magnitude. What happens when only 1 in 10,000 of those tutorials you can find is any good, from someone actually qualified to write it?

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

Re: The fate of "small" open source

#60

Post by bloomca »

cortesoft wrote: post #51
BrenBarn wrote: post #32

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

Part of the benefit over a dependency is that the code added will (hopefully) be narrowly tailored to your specific need, rather than the generic implementation from a library that likely has support for unused features. Not including the unused features both makes the code you are adding easier to read and understand, but it also may be more efficient for your specific use case, since you don't have to take into acc…

But in a lot of cases you can't know all the dependencies, so you lean on the community trusting that a package solves the problem well enough that you can abstract it.

You can pin the dependency and review the changes for security reasons, but fully grasping the logic is non-trivial.

Smaller dependencies are fine to copy at first, but at some point the codebase becomes too big, so you abstract it and at that point it becomes a self-maintained dependency. Which is a fair decision, but it is all about tradeoffs and sometimes too costly.

Post reply on HN