On the subject of early strategy, I think there are important lessons to be gleaned from the web-startup community which faces a similar problem as seasteading: that of creating complex systems from limited means to address difficult problems of which we have only a limited understanding. In doing so, the startup community has developed a few key lessons, which have been proven through the success of the institutions which adopt them. The greatest of these lessons is that meticulous design simply doesn’t work on early-stage systems with so many unknowns.
The alternative is the iterative approach known by the phrase: “Release Early, Release Often.” As put by entrepreneur and now early-stage startup funder Paul Graham:
The thing I probably repeat most is this recipe for a startup: get a version 1 out fast, then improve it based on users’ reactions. By “release early” I don’t mean you should release something full of bugs, but that you should release something minimal. Users hate bugs, but they don’t seem to mind a minimal version 1, if there’s more coming soon.
Release Early, Release Often
When one says release early, they don’t mean to make a reckless effort, but to solve the minimal problem. Create “the simplest thing that could possibly work.” Intentionally restrict your problem to solve the smallest meaningful problem.
Why should we go about building small? A few reasons, interconnected:
- In building small, you’re free to make more mistakes, and correct them. Inexpensive iterations leaves more time and money after each to get it right. Rather than bet on a single technology, you can test many individually over time, and elaborate on only the most promising. And with any given failure, you haven’t bet the farm on one structure, approach or technology only to see it fail because it was built on the wrong premise or with fatal flaws, and thus paying only for a very expensive education and a major setback to the movement.
- Innovations are more likely to succeed or provide meaningful education when tested in isolation. A structure with many exploratory components has many likely points of failure - in our case, any one of them literally could sink the ship. Making incremental improvement on a working structure, or exploratory proof-of-concept structures is much more likely to produce a working result (in the form of an incrementally improved new structure) than a wholesale untested reinvention.
Let me emphasize: we don’t know what will actually work, and only experimentation and experience can provide clear answers to our first questions. Getting the earliest and least expensive education is key to quick progress. As we refine ideas, designs, ways of life, the most trustworthy, effective designs can be replicated on larger scale while smaller vessels continue to innovate. As in evolution, complex systems spring from building on and elaborating on simple systems.
Some argue that having a large early example is necessary for credibility or inspiration or somesuch - but the credibility that matters is building structures that work. Having an expensive failure can be a PR as well as financial disaster for the movement. But providing small examples that work and are continually improving with each generation enables inclined people to dream and buy into the project, on a small scale. While the press is free to consider us a curiosity while we build up a track record of progress and success. Then, when a large project is built on proven technology, the attention coincides with a healthy chance for success.
And for seasteading in the mean-time, having many small livable incrementally-improved structures is not a problem but rather in sum they represent an opportunity for enabling far greater early experiments in ocean economy and society, as compared to a single large structure. A diversity of people in a diversity of structures, making a diversity of experiments in living and collaborating asea.
The Minimal Problem
So what represents the minimal problem? What’s the smallest thing that could possibly work?
I suggest a safe but small (not fit for the claustrophobic) multi-person single household, limited to relatively shallow waters and with the necessity of relatively frequent docking (say, weekly) due to limited storage and productive facilities on board. A single person vessel may be even simpler, and perhaps should be pursued first, but does not do much to explore the needs of social life and cohabitation on board, so I prefer multi-person. Structurally, the vessel would serve as a test bed for the most promising structure for future developments, which I would guess is the spar-style platform.
Operating costs would be either be funded through on-board software development (or some other lucrative relatively solitary task able to be carried out remotely), or perhaps funded to some extent by on-shore earnings. This represents the minimal ocean economy, requiring no off-shore business or social organization.
So the only purpose here, in “Seastead I” is testing this relatively new style of structure, presumably the spar, both for seaworthiness and habitability, and thus to direct future developments.
So that’s my inclination, and now I put it to you: what do you think?