1 files changed, 74 insertions, 0 deletions
diff --git a/ripple/website/pages/index.md b/ripple/website/pages/index.md
new file mode 100644
index 0000000..3fac3ac
--- /dev/null
+++ b/ripple/website/pages/index.md
@@ -0,0 +1,74 @@
+title: Ripple
+
+# A build system for the next decade
+
+Ripple is an experimental build system. Blending functional reactive
+programming, process tracing, automatic memoization, and a smattering of
+object capabilities, it aims to completely redefine the state of the art
+in software assembly.
+
+Ripple will provide completely [reproducible builds](https://reproducible-builds.org/), guaranteeing that
+any piece of software which builds successfully on one computer can be
+recreated bit-for-bit identically on any other computer — even ten years
+down the line. This allows users of binary packages to be confident that
+they're running software directly corresponding to published source
+code.
+
+While reproducible builds are nothing new, combining them with automatic
+fine-grained incremental compilation is necessary to make them usable
+every step of the way, as opposed to something only performed at
+software release time. By doing so, Ripple will banish invocations of
+`make clean` to antiquity, and save billions of hours of CPU time wasted
+by CI systems pointlessly rebuilding the same thing over and over again.
+
+In addition, Ripple will take care of some other tricky problems, like
+coherently expressing precisely versioned dependencies across language
+ecosystem boundaries, correct cross-compilation support, and precise
+runtime/build-time dependency calculation.
+
+## Doesn't this exist already?
+
+No. I've looked.
+
+## Why doesn't this exist already?
+
+While I can't answer this for sure, I would posit the following: build
+systems and package managers are [infrastructure](https://www.destroyallsoftware.com/talks/a-whole-new-world).
+They cannot be marketed (who would pay for a build system in this day
+and age?) and need to be rethought from the ground up, so the design and
+implementation of such is relegated to a select few: academics, bored
+nerds, and very large companies with insane scaling requirements.
+
+Academic research projects are usually left to gather dust once the
+thesis is said and done. Nerds build toy clones of existing software,
+except it's going to be better this time. Megacorps don't need their
+build system to handle reproducibility — they just vendor everything
+into their humongous monorepo and call it a day.
+
+## Why don't you just ...?
+
+Given that existing package managers and build systems overlap in scope
+with Ripple, this is a perfectly reasonable question to ask. Why not
+just combine [two](https://github.com/NixOS/nix) [existing](https://bazel.build/) tools which each hold half of the solution?
+
+On a surface level, this seems perfectly innocent: reducing the amount
+of work that has to be put in and avoiding fracturing ecosystems is
+surely a good thing! Digging deeper, however, you'll quickly realise
+the following: in order for each side to function efficiently in this
+arrangement, they need some fairly invasive modifications to integrate
+with each other. Hard fork territory.
+
+So, attempting to reuse existing software would require some fairly
+significant effort nonetheless, and also involve taking on legacy from
+the get-go. On the other hand, designing a new system from the ground
+up will be vastly simpler, as we can entirely do away with the build
+system/package manager dichotomy and make entire swaths of cross-cutting
+concerns disappear into thin air.
+
+## Why doesn't *this* exist already?
+
+Designing and implementing a project of this scope and complexity is
+going to require a significant investment of time and energy. It's not
+something that will get to a usable state in the near future if I'm just
+tinkering on it at the weekend, so I'm currently seeking funding that
+would allow me to work on it full-time. Watch this space!