Shipped and Forgotten: The Small Repos That Actually Work

The Code That Stopped Needing You

There is a particular feeling that maintainers of small open source libraries describe, almost universally, when their project crosses a certain threshold. You wrote a thing. You shipped it. You forgot about it. And then, sometime later, you noticed it was being downloaded a hundred thousand times a week. The code had not changed. You had not promoted it. People had simply found it, used it, and never had a reason to ask you for anything.

This is not the dramatic open source story. The dramatic story is the maintainer crisis — the burnout, the legal threat, the angry pull request, the security incident that everyone blames you for. Those stories are real and they get written about, repeatedly, because they make good copy. But the more common story, the median story, is much quieter. Someone wrote a small, focused thing. It worked. It still works. It will probably keep working long after the author has stopped checking the inbox.

[calm]

These are the libraries in the attic. There are hundreds of thousands of them. And if you know how to find them, they are a remarkable resource for borrowing, for forking, and for learning how good code is shaped.

The Sweet Spot

The interesting forkable repository, the one worth looking at when you are starting a new project, has a recognizable shape. It is between five hundred and five thousand lines of code. It has one author, maybe two. It does one thing, and it does the one thing cleanly. The last commit was probably between one and four years ago, and the most recent issues are mostly thank-you notes or quiet confirmations that the code still works in the current year.

This shape matters. The reason it matters is that the project is small enough to read end to end in an afternoon. You can hold the whole thing in your head. You can understand why every file exists. You can see the choices the author made, and you can ask yourself whether you would have made the same choices, and you can disagree without being lost in a maze of abstractions you do not yet understand.

[serious]

Large projects, by contrast, are unreadable in this sense. Not in the literal sense — anyone can open the source. But the choices have accreted over too many years and too many contributors to make sense as a coherent design. There is no one mind behind the project. It is a committee, even if every individual decision was made by one person, because the cumulative shape is what no individual would have designed if they were starting fresh.

Forking a small project is forking a worldview. Forking a large project is forking a compromise. The two activities feel similar from the outside but they teach you almost nothing of the same thing.

The Naming Story

Sometimes the small repository tells you it is small just by its name. The convention in certain corners of the open source world is the deeply unglamorous name. A library called least-recently-used cache is almost certainly going to be a small library that implements a least-recently-used cache, no more, no less. A library called is-thirteen is going to be a one-line library that checks whether a number is thirteen, which is a joke, but the joke is making a real point. Small focused libraries are the basic unit of healthy software, even if the unit can be absurd in isolation.

A library called make-directory-recursive is going to make directories, recursively, the way the unix command does it. Isaac Schlueter wrote a famous version of this years ago. It does that one thing. It has been downloaded billions of times across the history of the package registry. It does not need to do anything else. If you tried to add features to it, you would be making it worse, not better.

Compare this to projects with grand names. A project called framework or platform or studio is signaling something different. It is signaling ambition. Ambition is sometimes good. But ambition in a library you might want to fork is a warning. You are not going to fork a platform. You are going to fork a thing that does a thing. The naming is the first hint about which kind of project you are looking at.

The Author Who Walked Away

There is a category of small repository where the author has explicitly walked away, and these are interesting in a particular way. The readme says something like "this is no longer maintained" or "I do not have time to respond to issues, sorry about that." A naive reader sees this as a warning to avoid the project. An experienced reader reads it as honest information about the project's state.

What the experienced reader knows is that "no longer maintained" for a small focused library often means "shipped and works, nothing left to do." If the scope of the library is small enough, there is nothing left to maintain. The dependencies that the library depends on might rot eventually, but the library itself is done. It is finished software, in the strange sense that finished software can exist at all, which most modern software pretends it cannot.

The opposite signal — a project with a lot of recent activity — is sometimes a warning in the other direction. If a small library has commits every week for years on end, something is either wrong with it or someone is bored and is fiddling. Neither is necessarily bad, but the steady drumbeat of activity does not always mean health. It can mean that the design was not quite right at the start and is being incrementally corrected forever, which is a different thing entirely.

Media Companies and the Boring Parts

A specific corner of this landscape worth knowing about is the open source output of media companies. Large news organizations have engineering teams. Those engineering teams write a lot of code. Most of that code is private — the recommendation algorithms, the paywall logic, the editorial workflow tooling. But there is a band of code that media companies tend to open source, and it is usefully boring.

[calm]

The boring code is the infrastructure glue. The image pipeline helpers. The consent management widgets. The advertising integration libraries. The static site generators tuned to news content. The Twitter card tooling, back when Twitter cards mattered. The accessibility helpers. The print archive importers. The frontend monorepo organization patterns. None of this is glamorous. There is no commercial moat in any of it.

The New York Times, the Guardian, the various Nordic groups like Schibsted and Bonnier, the German publishers like Axel Springer — they all publish this kind of code, in varying amounts, under permissive licenses. Most people do not look at it because most people are not building media products. But if you are building something media-shaped, this is one of the richest seams of borrowable code on the internet, and almost nobody is digging in it.

A useful caveat. Media-organization code often has organizational shape baked in. There will be naming conventions tied to their brands. There will be assumptions about their internal services. There will be dependencies on identity systems that only exist inside the company. Forking these projects directly is risky because you inherit all of that organizational scar tissue. But reading them, learning the patterns, and writing your own smaller version informed by their choices — that is almost always worth the time you put in.

The Half-Life

The phrase half-life is a useful one to keep in mind when browsing for forkable code. Half-life, in the original physics sense, is the time it takes for half of something to decay. For a repository, the half-life is the time it takes before the code stops being relevant to its world, before the substrate has moved enough that the code can no longer be used as it was written.

[serious]

A web framework written in twenty-fifteen has a short half-life. The web changed underneath it. The dependencies rotted. The browsers got new APIs. The patterns shifted from server-rendered to single-page to server-components and back. You can still read the framework. You cannot use it without significant updating, and the updating is sometimes more work than starting over fresh.

A small utility library, written in the same year, often has a remarkably long half-life. A function that parses dates is still parsing dates. A function that makes directories is still making directories. A function that throttles events is still throttling events. The substrate did not move. The code still works exactly as it did when it was written.

The half-life of a repository depends on how much of the surrounding world it touches. The smaller the surface area, the longer the half-life. This is one reason why small, focused libraries with permissive licenses are such good forking material. They are likely to still work. The patterns are likely to still be valid. The choices are likely to still make sense in five years, because the world they touched was small enough to stay still.

The Reading List Nobody Maintains

A practical move, if you are interested in this style of code archaeology. Keep a running file somewhere — a notes file, a markdown document, a paper notebook, whatever works. Every time you stumble on a small, focused, well-made repository, write down the URL and one sentence about why it caught you. Do not try to use it right away. Do not try to fork it. Just note it down and move on with your day.

Over a year, this file becomes something interesting. It becomes a personal reading list of code you found worth noticing, curated by your taste, accumulated while you were paying attention to other things. The next time you start a project, you have a specific source of inspiration that nobody else has, because nobody else has your collection. You did not search for it under pressure. You collected it while you were curious.

This is the part of the open source ecosystem that does not show up in the trending repositories or the conference talks or the newsletter roundups. It is the slow, accumulated taste of someone who pays attention to small things over time. It is, in a strange way, the actual library — not the package manager registry, but the curated personal collection of code that resonated enough to remember.

The big projects get the attention. The half-life repositories quietly hold up everything else underneath. Knowing how to find them, and knowing how to recognize the shape of the one worth your time, is a skill worth developing slowly, over years, while you are working on other things and not in any particular hurry.