What is Permacomputing — and why does it matter?
Permaculture gave us a framework for sustainable agriculture. Permacomputing asks: what would that look like for software?
The word “permacomputing” sounds like jargon. But the idea behind it is one of the clearest frameworks I’ve encountered for thinking about what sustainable software actually means.
Start with permaculture
Permaculture — short for permanent agriculture — is a design philosophy developed in the 1970s by Bill Mollison and David Holmgren. Its core insight: instead of fighting natural systems, design with them. Use what’s already there. Build for resilience, not efficiency. Produce no waste. Ensure long-term fertility.
The result is farms that get more productive over time, not less. Soil that improves each year. Systems that can be maintained and passed on for generations.
Now apply that to computing
Permacomputing asks: what would software look like if we designed it the same way? The community defines it as “oriented around issues of resilience and regenerativity in computer and network technology.” That word — regenerativity — is doing a lot of work. Not just sustainable (do less harm), but regenerative (actively restore what’s been depleted).
Most software today is the opposite of permacultural. It’s engineered for rapid deployment and fast obsolescence. Apps require ever-newer hardware to run. Dependencies multiply until no one understands the whole system. Code becomes unmaintainable and is thrown away, taking years of embedded knowledge with it.
The ecological parallels are uncomfortable. Monoculture farming exhausts soil. Monoculture software exhausts hardware, expertise, and trust.
The principles
The permacomputing community has converged on ten principles. A few that stand out:
Observe First — Before building anything, watch how the system actually behaves. Resist the urge to immediately add, fix, or optimise. The most valuable interventions are usually the ones you don’t take.
Not Doing — Sometimes the right answer is to not build the feature. Every line of code is a liability. Every dependency is a future vulnerability. The question isn’t “can we?” but “should we?”
Expose the Seams — Treat understandability as an aesthetic principle, not an afterthought. Software that hides its internals creates dependency and brittleness. Legible systems can be fixed, adapted, and handed on.
Care for All Hardware — Especially the Chips — Manufacturing semiconductors is ecologically catastrophic. The most sustainable device is the one already in someone’s hands. Build for the hardware that exists, not the hardware you wish people had.
Build on Solid Ground — Prefer boring, battle-tested foundations over novelty. The most resilient systems are built on technologies with decades of operational history behind them.
Integrate Biological and Renewable Resources — Where possible, align computation with natural rhythms — renewable energy sources, reduced cooling demands, hardware with a path to graceful degradation rather than landfill.
These aren’t just technical guidelines. They’re a shift in attitude.
Why this matters now
We’re at an inflection point. AI is pushing hardware consumption to new highs. Every new model release comes with enormous energy and water costs. Meanwhile, the global south is experiencing the worst effects of climate change while having contributed least to the emissions that caused it.
The tech industry can’t keep externalising those costs and calling itself progressive.
Permacomputing isn’t a complete answer. But it’s a useful constraint — a way of asking what would we build differently if longevity and ecological cost were real design requirements, not afterthoughts.
What it looks like in practice
At Novatum, we try to apply permacomputing thinking concretely:
- Choosing boring, well-understood technology over trendy frameworks
- Designing data models to last, not just to ship
- Writing documentation as a first-class deliverable
- Preferring static sites over heavy client-side apps when the use case allows
- Being honest with clients about the true cost of complexity
- Asking whether a feature needs to exist before building it
None of this is dogma. Sometimes you need a complex system. But the question is worth asking first: what’s the simplest thing that would actually work?
That question — asked seriously — tends to lead somewhere interesting.
Want to go deeper? permacomputing.net is where the community builds shared understanding of these ideas.