The editorial frames the 63-year project as a 'monorepo with append-only commits' running on deterministic-from-random-seed mutations. It contrasts this with the median GitHub side project lifespan of weeks and SaaS half-lives of a couple years, arguing that Gretzinger's discipline of executing one card per day exposes how disposable our own creative output has become.
By submitting the link directly to jerrysmap.com/the-map (the process page) rather than a gallery of finished panels, the submitter emphasizes the methodology over the artifact. The 378-point response and comment section that 'asked about the process' rather than debating aesthetics validates that readers also saw the shuffled index-card ritual — not the continent — as the real point.
Jerry Gretzinger started drawing a map of a place that doesn't exist in 1963. He was a teenager, bored in class, doodling on a piece of paper. He's now in his eighties. The map is still growing. It is, at last count, more than 3,400 individual 8-by-10-inch panels, stitched into a continent-sized cartography of cities, rivers, voids, and color-coded political regions that he revisits and revises in a fixed daily ritual.
The Hacker News thread linking to jerrysmap.com — and the Open Culture profile it points at — hit 378 points with the kind of comment section that doesn't happen for AI launches: people stopped arguing. They asked about the process. The process is the story. Gretzinger draws the next panel based on instructions from a shuffled deck of index cards, each prescribing a mutation: extend a road, drown a region in a new sea, introduce a void, recolor a province. He pulls a card. He executes. He files the panel. He moves on. The map is not designed. It is *grown*, one stochastic edit at a time, over 63 years.
There is no roadmap. There is no release. There is no v2.0. There is only the next card, the next panel, the next morning.
Every senior developer recognizes this shape, even if they've never seen the map. Jerry's Map is a 63-year-old monorepo with append-only commits, deterministic-from-random-seed mutations, and no refactor branch. The cards are a fuzzer. The panels are immutable migrations. The continent is the production database. He has been running the same job, on the same schedule, against the same artifact, since the Kennedy administration.
Compare this to how we actually ship. The median software side project on GitHub has, by various surveys, a lifespan measured in weeks. A startup's median runway is measured in quarters. A SaaS product's median half-life — the point at which half of customers have churned — is measured in a couple of years. The frameworks we built our careers on a decade ago are now legacy. React itself, the closest thing we have to a generational constant, is twelve years old. Jerry's map is more than five times older than React, two and a half times older than Linux, and it has shipped continuously the entire time.
The community reaction on HN converged on something uncomfortable: the constraint that makes the project survive is the same constraint that makes it impossible to scope. Gretzinger does not get to decide what's interesting today. The card tells him. If the card says "introduce a void at coordinates 47-N," the next two hours are about voids, regardless of whether voids are the most engaging thing to draw. This is the part the engineers in the comments kept circling back to: he removed his own agency over the day's work, and that's *why* he's still doing it.
This maps cleanly onto something we know from biology and from incremental systems design. Long-lived systems are not the ones with the best architecture. They're the ones with a mutation rate low enough to preserve continuity and high enough to keep adapting. Coral reefs do this. Lisp does this. The Linux kernel does this — Linus didn't write modern Linux, he wrote a rule set that lets thousands of small mutations accrete without breaking the whole. Jerry wrote a rule set for a map. The rule set is older than TCP/IP.
The other thing worth naming: there is no audience layer. No analytics. No engagement metrics. The map is not a startup. It's not even an art career in the conventional sense — Gretzinger spent decades not showing it to anyone. The feedback loop is the act itself. For an industry that has spent the last decade optimizing every side project into a content funnel, a SaaS, a personal brand, or a Twitter thread, the map is a reminder that the longest-running creative systems tend to have no monetization layer at all, because a monetization layer introduces a second optimization target, and two optimization targets is one too many.
The practitioner takeaway is not "go draw a map." It's structural.
First, on side projects: the ones that survive are the ones with the smallest unit of daily progress. Jerry's unit is one panel. Not one chapter, one feature, one release. If the smallest commit your project can accept is larger than what you can ship in a single sitting, your project is already dying. This is why "rewrite the framework" projects die and "add one parser test per morning" projects don't.
Second, on randomness as a design tool: the deck of cards is the part most engineers underestimate. Most of us treat randomness as a thing to eliminate from our systems — flaky tests, nondeterministic builds, race conditions. But injected randomness at the *planning* layer is what keeps long projects from collapsing into local maxima. Fuzzers find bugs human testers miss for exactly this reason. Genetic algorithms work for exactly this reason. If your roadmap is entirely top-down, you will keep building the same product over and over.
Third, on legacy: every system that lasts long enough becomes incomprehensible to anyone who didn't grow up with it. Jerry's map has regions whose meaning he himself has forgotten. The HN thread had several comments pointing out that this is how a 20-year-old codebase feels to its current maintainer. The right response is not to refactor — it's to preserve the mutation log, accept the opacity, and keep shipping panels. The maintainers who try to comprehend the whole legacy system before touching it never touch it.
Gretzinger will not finish the map. There is no finish state — the cards keep being drawn, and the only stopping condition is the cartographer. The interesting question for anyone reading this in an industry obsessed with v1 launches, exits, and shutdowns is whether you have a single project, hobby, codebase, or notebook that you have committed to for ten years, let alone sixty. Most of us don't. The map is not a productivity hack. It's a quiet proof that the longest-running systems in any domain — software, art, biology, or imaginary cartography — are the ones where the maintainer stopped trying to decide what comes next and let the rule set decide instead.
<a href="https://www.openculture.com/2026/06/this-man-has-been-drawing-a-map-of-an-imaginary-land-since-1963.html" rel="nofollow">https://www.openculture.com/20
→ read on Hacker NewsTop 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.