55 comments

[ 0.26 ms ] story [ 52.4 ms ] thread
Less incentive to write small libraries. Less incentive to write small tutorials on your own website. Unless you are a hacker or a spammer where your incentives have probably increased. We are entering the era of cheap spam of everything with little incentive for quality. All this for the best case outcome of most people being made unemployed and rolling the dice on society reorganising to that reality.
He almost got it right. It's not just the fate of small open source. It's the fate of all programmers now. Why hire a programmer when an LLM costs less, works faster and makes less mistakes (OP compliments better error handling, read the article).

Unless you are a product owner, you have paying clients that love you and your product and won't simply ditch it in favour of a new clone, you are really screwed.

(comment deleted)
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.
I don’t think open source is going anywhere. It’s posed to get significantly stronger — as the devs which care about it learn how to leverage AI tools to make things that corporate greasemonkeys never had the inspiration to. Low quality code spammers are just marketing themselves for jobs where they can be themselves: soulless and devoid of creative impulse.

That’s the thing: open source is the only place where the true value (or lack of value) of these tools can be established — the only place where one can test mettle against metal in a completely unconstrained way.

Did you ever want to build a compiler (or an equally complex artifact) but got stuck on various details? Try now. It’s going to stand up something half-baked, and as you refine it, you will learn those details — but you’ll also learn that you can productively use AI to reach past the limits of your knowledge, to make what’s beyond a little more palatable.

All the things people say about AI is true to some degree: my take is that some people are rolling the slots to win a CRUD app, and others are trying to use it to do things that they could only imagine before —- and open source tends to be the home of the latter group.

Open source exists because coding was a significant effort and code was a thing of high value. Unsurprisingly companies hesitated to make the code public and free. All of this is changing now as coding has suddenly become trivial. So, yes, the mission of open source, in general, will be challenged.
Several issues:

1. Reducing dependencies is a wrong success metric. You just end up doing more work yourself, except you can't be an expert in everything, so your code is often strictly worse.

2. Regenerating the same solutions with a probabilistic machine will produce bugs a certain percentage of the time. Dependencies are always the same code (when versioned).

3. Cognitive overhead for human review is higher with LLM-generated libs, for no additional benefit.

This author assumes that open sourcing a package only delivers value if is added as a dependency. Publicly sharing code with a permissive license is still useful and a radical idea.
A copyleft license is much better because it ensures that it will remain open and in most cases large companies won't use it, making sure they will have to shell out the money to hire someone to do it instead.
> the era of small, low-value libraries like blob-util is over.

Thankfully (not against blob-util specifically because I've never intentionally used it), I wouldn't completely blame llms either since languages like Go never had this dependency hell.

npm is a security nightmare not just because of npm the package manager, because the culture of the language rewards behavior such as "left-pad".

Instead of writing endless utilities for other project to re-use, write actual working things instead - that's where the value/fun is.

Another thing about Go, and more generally, the statically-typed languages, is that these utility functions are generally safer to get a once-over and a commit into the code base than in dynamically-typed languages. Something that joins an array of strings with a joiner in some non-trivial way is a lot easier to review when you don't have to worry about it getting an array of DOM nodes and a NaN for the join character, and all the other things that could come in. Well-tested little utilities for Javascript are valuable, and I don't 100% trust LLMs to not give me code based on common misconceptions rather than the actually correct code in that case. Or at least, correct for some definition of correct, which in the dynamic languages can itself be some work to figure out.
Bad take. In the first place, the appropriate time order of magnitude for how long static type checkers have existed for JS is "decades". In the second place, the function that "joins an array of strings with a joiner" is the wrong place to worry about whether that array is actually an array of DOM nodes or the joiner is NaN.
More likely, what we will see is the decline of low effort projects. The JavaScript/ Typescript ecosystem has been plagued with such packages. But that’s more anomalous to the JS community than it is a systemic problem with open source in general.

So if fewer people are including silly dependencies like isEven or leftPad, then I see that as a positive outcome.

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

In the U.S., anything machine generated is uncopyrightable.

Why would you put uncopyrightable code into your codebase?

> Claude’s version is pretty close to the blob-util version (unsurprising, since it was probably trained on it!).

AI are thieves!

> I don’t know which direction we’re going in with AI (well, ~80% of us; to the remaining holdouts, I salute you and wish you godspeed!), but I do think it’s a future where we prize instant answers over teaching and understanding.

Google ruined its search engine years ago before AI already.

The big problem I see is that we have become WAY too dependent on these mega-corporations. Which browser are people using? Typically chrome. An evil company writes the code. And soon it will fire the remaining devs and replace them with AI. Which is kind of fitting.

> Even now there’s a movement toward putting documentation in an llms.txt file, so you can just point an agent at it and save your brain cells the effort of deciphering English prose. (Is this even documentation anymore? What is documentation?)

Documentation in general sucks. But documentation is also a hard problem.

I love examples. Small snippets. FAQs. Well, many projects barely have these.

Look at ruby webassembly/wasm or ruby opal. Their documentation is about 99% useless. Or, even worse - rack in ruby. And I did not notice this in the past, in part because e. g. StackOverflow still worked, there were many blogs which helped fill up missing information too. Well all of that is largely gone now or has been slurped up by AI spam.

> the era of small, low-value libraries like blob-util is over. They were already on their way out thanks to Node.js and the browser taking on more and more of their functionality (see node:glob, structuredClone, etc.), but LLMs are the final nail in the coffin.

I still think they have value, but looking at organisations such as rubygems.org disrupt the ecosystem and bleeding it dry by kicking out small hobbyists, I think there is indeed a trend towards eliminating the silly solo devs who think their unpaid spare time is not worthy of anything at all, yet the big organisations eagerly throw down more and more restrictions onto them (my favourite example is the arbitrary 100k download limit for gems hosted at rubygems.org, but look at the new shiny corporate rules on rubygems.org - this is when corporations take over the infrastructure and control it. Ironically this also happened to pypi and they admit this indirectly: https://blog.pypi.org/posts/2023-05-25-securing-pypi-with-2f... - of course they deny that corporations control pypi now, but by claiming otherwise they admit it, because this is how hobbyists get eliminated. Just throw more and more restrictions at them without paying them. Sooner or later they decide to do something better with their time.)

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

(comment deleted)
(comment deleted)
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 repository than actually writing the library.

I like the approach C sometimes takes, with the "tiny header file" type of libraries. Though I guess that also stems from the lack of a central build system.

What's your copy& paste solution to security updates?
Why aren't those tiny header file libraries just part of the standard C library?

Wait sorry, I don't mean that. I read too many bog-standard HN comments about NPM above.

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.

This. The code is like 10 lines long. I might as well copy that from Stackoverflow and adapt that for my own use. Why bother packaging that?
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?

I would have and did write this instead of including it anyway. These small npms you would spend more time to look up than write are a pest.
> 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 sense. It gives people visibility while setting clearer boundaries on how the work can be used.

I learned most of what I know thanks to FOSS projects so I'm still on the fence on this.

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 to. I don't care and I don't know why anyone does. If it were valuable I would have made more money off of it in the first place, and I don't have the ego to just care that people know it's my code either.

I want the things I do today to have an upside for people in the future. If that means I write code that gets incorporated into a model that people use to build things N number of years from now, that's great. That's awesome. Why the hell is that apparently so demotivating to some people?

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

> It gives people visibility while setting clearer boundaries on how the work can be used.

... Because those would be respected?

> 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.
> Even now there’s a movement toward putting documentation in an llms.txt file, so you can just point an agent at it and save your brain cells the effort of deciphering English prose. (Is this even documentation anymore? What is documentation?)

I look at it as why not have the best of both worlds? The docs for my JS framework all have the option of being returned as LLM-friendly text [1].

When I utilize this myself, it's to get help fleshing out skeleton code inside of an app built w/ my framework (e.g, Claude Sonnet w/ these docs in context build a nearly ~90-100% accurate implementation for most stuff I throw at it—anything from little lib stuff up to full-blown API endpoint design and even framework-level implementations of small stuff like helping to refactor the built-in middleware loading). It's not for a lack of desire to read, but rather a lack of desire to build every little thing from scratch when I know an LLM is perfectly capable (and much faster than me).

[1] https://docs.cheatcode.co/joystick/ui/component/dynamic-page...

> ….but I do think it’s a future where we prize instant answers over teaching and understanding

It depends. For stuff I don’t care about I’m happy to treat it as a black box. Conversely, AI now allows me to do deep dive on essentially anything I’m interested in, which has been a massive boon to my learning ability.

It would be a cool feature of AI to include only the subset of the library you use and nothing else.
I don't buy the education angle.

If you're not learning to code, then you want efficient code, so the comments are wasted bytes (ok, not a huge expense, but still).

If you are learning to code, or just want to understand how this code works, then asking an LLM is going to get a lot better result. LLMs are fantastic tutors. Endlessly patient, go down any rabbit hole with you, will continue explaining a concept until you get it, etc. I think they're going to revolutionise education, especially for practical subjects like coding.

Respect to the author for trying to educate, though.

(comment deleted)