Software Preservation Philosophy: Building for the Long Term Without Dependencies
Developers living on a boat explore creating durable, offline-first software using minimal languages like Forth to ensure long-term preservation.
The Quest for Software Longevity
A couple living on a sailboat has embarked on a unique software development philosophy focused on creating programs that can survive decades without external dependencies or cloud services. Their approach prioritizes software preservation over modern convenience, choosing tools and languages that can be easily recreated if everything else is lost.
This philosophy emerged from practical constraints of boat-based living, where internet connectivity is unreliable and modern cloud-dependent software becomes unusable. However, their exploration extends beyond immediate needs to fundamental questions about software durability and the fragility of contemporary development ecosystems.
The authors describe their journey as similar to “a carpenter creating his own tools before building a dining room table”—investing time in foundational systems that enable long-term creative work rather than relying on external infrastructure that might disappear.
Community Debate: Artistic Programming vs Practical Solutions
The boat-based developers’ choice of Forth as their primary language sparked intense community debate about whether this represents genuine technical wisdom or artistic affectation. Critics note the authors use words like “beauty” and “love” frequently when describing their code, suggesting an aesthetic rather than practical motivation.
One developer characterized the approach as “like learning calligraphy”—beautiful and personally fulfilling, but impractical for daily use when modern alternatives exist. They argue that languages like Lua offer similar portability and longevity benefits while remaining more accessible and maintainable.
However, defenders point to Forth’s unique technical properties, particularly its extreme compactness. Forth implementations can achieve self-hosting with minimal resources, making them ideal for scenarios where rebuilding the entire software stack from scratch becomes necessary.
Modern Language Ecosystem Fragility
The discussion revealed widespread concern about the long-term viability of popular modern languages. While Java enjoys stability through backward compatibility commitments, newer languages like Go and Rust face uncertain futures regarding code written today.
Developers expressed doubt that Go or Rust code written now will compile on 2035 compilers without modification. Package manager dependencies compound this problem—the likelihood of downloading correct dependency versions after ten years approaches zero for most ecosystems.
The left-pad incident, nearly a decade old, continues to influence developer attitudes toward dependencies. Many developers report developing “incredibly strong aversion to dependencies” and preferring to understand foundational systems rather than building on potentially unstable external packages.
The C Language as a Stability Anchor
Several developers identified C as their preferred language for long-term projects, citing its simplicity and proven longevity. C’s ecosystem has demonstrated remarkable stability over decades, with code from the 1980s often compiling without modification on modern systems.
This stability comes from C’s minimal feature set and mature standardization. Unlike rapidly evolving languages that introduce breaking changes, C’s conservative development approach prioritizes backward compatibility over new features.
However, C’s limitations drive some developers toward Rust for new projects, despite concerns about long-term stability. The challenge becomes treating Rust as “better C” while minimizing dependencies that could compromise future buildability.
Dependency Aversion and Self-Reliance
The boat developers’ philosophy resonates with programmers who prioritize understanding over productivity. This approach trades development speed for deep comprehension and long-term maintainability.
Developers following this philosophy report learning more by building from first principles rather than assembling existing components. However, they acknowledge completing fewer projects due to the additional effort required for foundational work.
This tension between “build fast” and “build to last” reflects broader industry debates about technical debt, maintainability, and the true cost of external dependencies.
Practical Constraints vs Universal Applicability
Critics question whether software designed for “2 people on a boat in international waters” can generalize to mainstream development needs. The extreme constraints of maritime life may not reflect typical user requirements or development contexts.
However, supporters argue that the principles—minimalism, self-containment, and offline capability—apply broadly. Many users worldwide lack reliable internet access, and even well-connected users benefit from software that doesn’t require constant online validation.
The boat-based constraints serve as a useful thought experiment for identifying truly essential software features versus conveniences that depend on abundant connectivity and computing resources.
The Broader Message About Software Resilience
Beyond the specific technical choices, the boat developers’ work highlights fundamental questions about software resilience and ownership. Modern software stacks often depend on services and infrastructure controlled by others, creating single points of failure that can render applications useless.
Their approach suggests that valuable software should be designed to survive the disappearance of its original development environment. This requires choosing stable foundations, minimizing external dependencies, and maintaining the ability to rebuild systems from source.
While few developers will adopt Forth or live on boats, the underlying philosophy of building durable, self-contained software offers valuable lessons for anyone concerned about long-term software preservation and independence from fragile external systems.