June 17, 2026
Fence drama goes open source
From Chesterton's fence to Chesterton's gap
When helpful strangers keep building stuff nobody asked for
TLDR: The article argues that the new problem in shared software isn’t removing old ideas too quickly, but adding shiny new ones nobody requested. Commenters split between “a suggestion is harmless” and “extra features become someone else’s lifelong chore,” with minimalists and jokers stealing the show.
A charming old idea about not ripping out a mystery fence until you know why it was built has now spawned a very 2020s sequel: what if the real problem is people eagerly building brand-new fences where nobody wanted one in the first place? That’s the argument here, and the comment section instantly turned it into a full-on philosophy brawl about good intentions, clutter, and the eternal internet curse of “I was just trying to help.” In plain English: the author says people keep sending huge feature additions to shared software projects, and while those additions may be clever, useful, and even beautifully made, they also create future upkeep for someone else. As one commenter basically put it, “free” help is often free as in puppies, not free as in pizza.
But the crowd was not united. One camp pushed back hard, saying a suggestion isn’t the same as forcing change: a proposed addition is just a demo sitting off to the side, proof that an idea can work. Another faction came in with minimalist energy, practically chanting delete more code, arguing that the best tool is the smallest one that does one job and doesn’t turn into a junk drawer. Then came the jokes: one user proposed “Milito’s Meadow,” a chaotic reboot fantasy where you bulldoze everything and rebuild from bare dirt, while another swerved completely and praised the site’s lavender background like the design review nobody expected. In other words: classic internet debate — part wisdom, part ego, part comedy, and somehow the color scheme still got a cameo.
Key Points
- •The article explains Chesterton’s fence as a principle of understanding why something exists before removing it.
- •It applies the principle to programming, where rewriting seemingly bad code can reveal valid reasons for earlier implementation choices.
- •The author introduces “Chesterton’s gap” to describe building features in software where maintainers may have intentionally left nothing there.
- •The article says lower code-creation costs have contributed to more large unsolicited pull requests for open source projects.
- •The author argues that maintainers should be asked why a feature is absent before contributors build and propose it, with maintenance cited as a major concern.