timeless Vision/Mission/Strategy one-pager

why.md

Vision

The Timeless Toolchain is part of a vision to create more reliable and predictable computers. This also translates directly to computers that are more secure, more knowable, and thus more hackable.

At the most broad, making computers more knowable makes our whole digital society grow faster and do a better job of empowering us all.

More specifically:

• we want to see reproducible builds flourish, and become a norm (something that's loudly questioned if a project fails to manifest them!)
• we want to see decentralized systems carrying the day, and all of our systems work usefully either online or offline
• and we want this system to be widely participatory -- it should be equally possible to use the same tools to coordinate huge communities of developers as well as it's possible to do development alone in a yurt in the woods.

Mission

Our mission, simply, is to make that vision happen.

We need tools that can build anything, and contain any toolchain. Our solutions should be universal. "Universal" here means not language-specific, and not siloed into a "distro" which requires bidirectional coordination to join.

Our tools should be highly reliable. And every part of them should be clearly able to operate usefully and predictably without live access to the global network.

Our tools should reinforce and encourage and highlight ways for users to make their own things in ways closer to our goals. When some process in our system is non-reproducible, our tooling should detect it, and make it clearly evident to the authoring user, who should in turn feel both empowered and encouraged to fix it.

Our tools should work the same no matter who is using them, when, or where. Minimize presumptions; identify and maintain environments rather than expecting them.

There should be a self reinforcing energy to all of this: we want tools that work better when building reproducible things, and make it clearly evident the authoring user when reproducibility has been lost. The effect of this should be to make it clear that reproducibility provides value, make the feedback loops more obvious, and orient and draw attention to those feedback loops such that users self-correct and improve their own systems over time.

Strategy

Our strategy is two-part:

1. We need to make tools that support our mission and reinforce our values; and,
2. We need to foster an ecosystem built within these tools, to expand our impact and increase the availability of ways to get things done using these tools.

Overall: we need to build things that make our mission easier to follow over time.

The concrete way we pursue the first part of this strategy is to make build framing tools -- tools which establish a work environment for other tools such as compilers, data crunching systems, packaging systems, and so on.

The second part of this strategy revolves around defining, growing, and fostering an ecosystem that values "Responsible Packaging". In particular, this strict emphasis on path-agnostic linking and packaging conventions, and valuing other choices which make for more self-contained correct behavior in packages. This is an important set of conventions to establish, because it increases the opportunities for interoperability between systems and reduces the amount of in-advance coordinations required to get that interop. Once established, this will continue to grow constructive feedback loops and bigger, better, more coherent, and more interoperable ecosystems.

One key theme we'll find recur overall in the tactics so often that it might as well be called strategy: we're going to hash everything. Hashes let us build content-addressable systems, which work well in decentralized systems; hashes give us ways to dodge naming problems which would otherwise introduce coordination issues, which makes interoperability easier even for people working independently; and hashes create quick ways to detect if data is identical at massive scales, which is critical to reproduciblity detection. Since all three of these properties are so critically useful, executing strategic design with a "hashes first" philosophy gives us a distinct style -- and a distinct advantage.

A second key theme is that the problems we're solving are sufficiently complex that we need to break them down. This shows up in strategy as: Our tools should be simple, and each solve one problem at a time. Factoring apart the hard problems in our mission -- e.g. separating hermetic execution and reproducibility from solving naming and package search; separating both of those from pinning and update selection strategies; etc -- and solving them in distinct layers, with clearly separated tools... will produce a better complete system, and one that is easier to integrate gainfully with other existing ecosystems.

Tactics

Well, see the tools. :)

(Labeling these as "tactics" is useful because it highlights that the tools are... well, bordering on incidental. If we can write better tools which serve the same strategy and vision, that's fine. These tools might not be the right tools. They're just our best current shot.)

• the rio tool provides content addressable file warehousing, using any of a variety of mechanisms, so long as they work by hash.
• the "formulas" specification provides a way to describe (and hash) a computation we want to explore.
• the "runrecords" specificaion provides a way to describe (and hash) the results of a formula.
• the repeatr tool provides hermetic isolation for executing other tools -- following a "formula", and reporting a "runrecord"! -- using containers to deliver it.
• the "modules" specification provides a way to describe graphs of computations, which pass data between them in discrete steps -- this enables larger scale work than formulas alone.
• the reach tool provides a way to execute modules easily.
• the "catalog" specifications, combined with standards for "replayable modules", establishes just enough standards for name->hash mappings to make them sharable -- while leaving just enough explicitly unanswered to spur the evolution of a clear separation between metadata circulation and version selection problems.
• the reach tool also bundles features for authoring catalogs -- both updating the name->hash mappings, attaching replay instructions to those, and sharing the whole thing with others.
• in ecosystem standards, the emphasis on non-turing-complete tools for templating and manipulating catalogs and modules results in a more inspectable and analyzable ecosystem even as it increases in size and scale and number of uncoordinated authors.
• in ecosystem standards, the "XORIGIN hack" plus optional-hashed-symlink-farm library splay is a shared library management strategy which takes a flying leap over conventional linking dichotomies and lands on a viable path-agnostic shared libraries solution which also works without coordination.
• in ecosystem standards, the "tracks" as a version tagging philosophy are an example of new and determinism-friendly version selection strategies -- but also as an opt-in experiment (which works due to the separation of the metadata circulation and version selection problems; thanks catalogs!).

This is not a complete list of goals and tactics. Along the way, we should also find ourselves delivering incidentals, like... producing the best-in-breed CI tools to have ever existed should more or less be slapping a coat of paint on the core engines, for example. "Incidentals" like this can be further force-multipliers and community-growers, offering concrete value even to people who don't yet see the direct connection from the value of our vision. This is just one example; many more potential targets of opportunity should come into reach as we proceed.