Files
harmony/docs/why-harmony.draft.md
Jean-Gabriel Gill-Couture 4a9bee73ad docs+deprecate: Application Capabilities guide; deprecate ApplicationFeature model
- docs/guides/application-capabilities.md: the .with(...) menu, by-reference
  wiring, and a recipe for writing a capability; disambiguates the overloaded
  'capability' (topology vs application) flagged in DX review; wired into the book.
- Deprecate ApplicationScore, features::Monitoring, features::PackagingDeployment
  (+ doc-deprecate the ApplicationFeature trait) in favour of harmony_app +
  ComposeDeploy/.with(...) (ADR-026). Legacy examples now warn; harmony lib is
  warning-clean (internal self-refs allowed).
2026-06-22 15:38:35 -04:00

160 lines
8.2 KiB
Markdown

<!--
STATUS: PRIVATE DRAFT — not for publication.
This is a working articulation of motivation and differentiation, kept in the
working tree but uncommitted. The author controls if/when any of it is made
public. Companion to the essay "A Wonderful Future for Computers"
(nationtech.io/wonderful-future-for-computers), which makes the case for the
decentralized *hardware*; this makes the case for the *software* that makes it
humane and real.
-->
# Why Harmony
## A nagging feeling, continued
The first essay was about *where* computing should live: not in a handful of
enormous datacenters drinking water and land while sitting mostly idle, but
spread out — in homes, offices, clinics, community spaces — machines that heat
a room while they compute, infrastructure made to *sing*.
That's the body. This is about the nervous system.
Because decentralized hardware doesn't matter if the only people who can
operate it are the same large organizations that already run the centralized
kind. A micro-datacenter in a village is just expensive scrap if it takes a
platform team of ten and a year of glue to run a single service on it
reliably. The hardware vision is only liberating if the software to wield it
is within reach of ordinary people and small teams. **Infrastructure is the
root of nearly every software business, and right now the root is owned.** If
we want computing to serve people, we have to give people something that lets
them actually run it.
That something is Harmony.
## The motivation, plainly
I've spent a long career deploying distributed systems for some of the largest
companies in the world. The robustness those systems have — the ability to
survive a failed machine, a bad deploy, a 3 a.m. outage and keep serving — is
not magic. It's the product of expensive teams, hard-won patterns, and an
enormous amount of careful, repetitive work. It is real, and it is *rationed*.
Only the well-resourced get it.
I find that quietly unjust. Not because anyone is villainous — I don't think
the people at the top of the cloud are evil — but because the *system* is
shaped so that the value of computing flows, by default, upward and inward: to
whoever already owns the most infrastructure. Lock-in, pricing that rewards
scale, defaults that assume you're big — none of it is a conspiracy. It's just
an incline. Everything rolls toward the same few owners because the ground is
tilted.
This project comes from a simple, almost stubborn conviction: that I should
try to give the best of what I know back to the world, and that the best thing
I know is how to make infrastructure trustworthy. If that knowledge can be put
into code instead of into another consulting invoice, then the robustness that
today costs a platform team can become something every app simply *has* — for
free, by default, the way running water is supposed to be.
## What we believe
**Computing should serve people, not skew toward owners.** We are not against
the rich or the large — we will gladly serve a Fortune 100 and a rural clinic
with the same code. What we refuse is to *bake the skew in*. We remove the
tilt rather than tilt it the other way. The playing field, made actually
level, is already radical, because the ground today is sloped. So we serve
whoever comes, on their terms, rich or poor, and we let no one be the default.
**Robustness is a right, not a privilege.** The ability to deploy something and
have it actually keep working should not be reserved for organizations with an
SRE budget. It should come in the box.
**Freedom means you can leave.** If your infrastructure only runs on one
vendor's cloud, you don't own it; you rent your own existence. The same
definition should run on your laptop, a cluster in your office, bare metal in a
community space, or any cloud — and you should be able to move it whenever you
like, without a rewrite.
## What Harmony is
Harmony is one way to describe what you want running, and have it converge —
the same way — wherever you point it. You write your infrastructure as real
code, not as piles of YAML validated at runtime when it's already too late. A
*Score* says what should exist. A *Topology* is wherever you're putting it — a
laptop, a tenant cluster, bare metal — described by what it can actually *do*.
Ask a Topology for something it can't provide and the program doesn't compile;
the mistake is caught at your desk, not at 3 a.m. And a deploy isn't finished
when a command exits successfully — it's finished when the thing is actually
*working*, proven by a smoke test, the way a careful human would check before
walking away.
The same Score runs in all of those places. Only the Topology changes.
## How we differ — honestly, and without mysticism
There is no shortage of good infrastructure tools. We are not claiming to have
invented robustness or declarative systems; we stand on a generation of work
that did. What we've found is a *seam* that, as far as we can tell, no one is
standing in:
- Tools that turn bare metal into a running cluster stop at the cluster.
- Tools that deliver applications assume a cluster already exists.
- Tools that compose infrastructure live in the cloud and assume someone else
handled the metal.
- The one project closest to our "infrastructure and application in one real
language" idea targets only the big public clouds — and its company didn't
survive the attempt.
Nobody we can find spans the whole thing — **bare metal, to running
distributed service, to keeping it alive over time — in a single, coherent,
type-checked model that is honest about the physical machine.** That seam,
aimed first at *decentralized and sovereign* deployments rather than the
hyperscalers, is where Harmony lives.
The differences that make it possible aren't tricks; they're choices:
- **Capabilities are described as types**, so the compiler is a colleague that
catches whole classes of misconfiguration before anything runs.
- **One model from the metal to the service to day-two**, instead of four tools
with four mental models taped together.
- **Local equals production**, so "it worked on my machine" stops being a
confession and becomes a guarantee.
- **It's real code**, which means it's reviewable, testable, and yours — not a
configuration dialect you'll be fighting in two years.
## Where we honestly stand
We are early, and I want to be the first to say it. The incumbents are years
ahead of us on breadth — the sheer number of clouds and services they can talk
to is a real moat we have not crossed and may never fully cross. We're a small
project written in a language with a smaller pool of contributors than the
mainstream. Anyone who tells you a young tool has already won is selling
something.
So we don't intend to win by breadth. We intend to be *undeniably good* at one
thing first: running and operating real services on self-hosted and sovereign
clusters, with the robustness usually reserved for the big players, proven by
systems that actually work in the world. Our proof isn't a benchmark or a
funding round. It's a sovereign public-health data hub headed to a community in
Cameroon, with a university partner — a place where depending on a distant
hyperscaler isn't just expensive but a question of whose hands the data is in.
If Harmony can stand up *there*, robustly, owned locally, then the promise is
real. If it can't, no manifesto will save it.
## The ambition, kept humble
I don't think of this as building a company so much as removing a tax — the
quiet tax that infrastructure complexity levies on every person with an idea
and no platform team. If software is one of the great levers humans have for
helping each other, then the cost and lock-in of the ground it stands on is a
weight on that lever. Take the weight off, and you don't know in advance what
people will build — a greenhouse controller, a clinic's records, a town's own
small cloud — and that not-knowing is exactly the point. You don't pave a road
because you know who'll walk it. You pave it so they can.
That's all this is, really: an attempt to make the infrastructure sing — not
for a few, and not against them either, but for anyone who shows up — and to
leave behind a paved road to freedom for all software.
If we get it right, most people will never think about it. The water will just
run.