We have just delivered Holochain Beta 0.1.0.
I find myself feeling more deeply satisfied than I expected, and I’m realizing why.
I had been thinking that Beta was just about getting to stability, but what we have really just delivered is viability. In some ways Holochain has felt viable to me from the start, because I can see its power and value, which is enough (for me). But I didn’t really understand what it would take to land viability for a project of our scope and scale in the world.
A little history
But before we go there, indulge me as I take you through some history. Arthur’s first commit to the Holochain repo was made on December 23, 2017. It contained a one-line README file describing Holochain as Holographic storage for distributed applications -- a monotonic DHT "backed" by authoritative hashchains, a GNU LICENSE, and a .gitignore file.
My memory is that I started actively coding a few days later on Dec 31st of that year. If you look at the commit history you then see a flurry of commits in January and February of 2017 which led to a Hackathon in March where we already had a functional prototype of the code.
So why the heck did it take so long to get to Beta? We built what felt like a working prototype in just 3 months! At that time it seemed like we could have a fully functional beta in under a year. But I was wrong–and kept being wrong. I remember thinking it would be just one more year, and that continued to be my thought for the next four years until at last I just gave up and decided it would happen when it happens. And now in early 2023 it has finally happened.
Retrospective
I want to know why it took so long. It’s tempting to look for single, or “root” causes. I can think of some clear internal problems of our own making where we took both some technical and organizational mis-steps. I can also point to some specific external events, like the crypto crash of 2019, which required us to do a big restructuring that took quite a while to integrate and recover from. And of course there’s the well known experience of software projects taking way longer than developers imagine they will, in part because it’s just so hard to know how hard something is, and also because there’s scope creep. We have this tendency to make it harder as we go along because we see things that we missed. But identifying a single factor to act as scape-goat would hide the real story here.
Non-Linear growth
My current reflection about this turns to the complex interactions between interior capacities and the external environment: the constant, yet non-linear, re-configuration that growth entails — and what we so glibly refer to as “timing.” When we look at the growth patterns of living organisms, they are always non-linear. A fertilized egg grows exponentially for a time and then slows down dramatically before alternating phases of fast and slow growth. Seeds planted in hospitable soil can spend quite some time in germination, then suddenly grow rapidly to sprout above ground, but then seemingly stop growing above ground while underground root systems are spreading like crazy, only to then have the above ground portion explode into exponential growth again before slowing.
What I have learned is that a startup, especially one building such a core-level infrastructure, can be much the same as those seeds. There were points of hidden growth in our project, where it didn’t look like we were getting anywhere in the code, but what was really happening was internal reconfiguration and maturing of the organization itself. And then there were moments where tons of code was being committed, and it really looked like things were on fire, but that might have been from just one team and not integrated with other teams' work. Seeds take time to germinate, and projects like this twist and bend as they reach for light and water.
For example, it’s been possible to use a fully functional Holochain app (hApp) well before Beta 0.1.0. Core community members had created a wonderfully usable early release of Acorn back in May of 2021! But we still hadn’t matured into a framework that full stack developers could use ‘out of the box’ to build apps. This demonstrates that functionality isn’t always the same as viability. So what is viability anyways?
Viability
One of the strategies that software teams are urged to use to combat the problem of ever extending delivery timelines is to just build and deliver a “minimum viable product” and then iterate. But what constitutes viability!? You could say that viability is when the tool you are delivering creates enough value that a person (or some number of people related to your business model) will use it despite whatever things they don’t like about it. That’s well and good for a simple product, but what about an infrastructure platform, where you are delivering to developers who themselves have to deliver to end-users? There is a double viability requirement in that. The developers have to experience the value in the platform to use it despite any flaws, and then the end-users have to do the same again. And I’m guessing this is not merely additive, but at least multiplies the challenge or even causes exponential difficulty!
So, I want to offer three aspects of viability that I think we’ve at least made good headway on: meeting people where they are, providing confidence in the integrity and security of the system, and achieving “minimum viable beauty”.
Meeting people where they are
As I mentioned, in projects like Holochain we need to make sure that we are meeting both end-users and developers where they are. In both cases, that’s about not asking for too much change, however revolutionary our platform may be!
A simple way to do this is by supporting whatever hardware platform they are already using. Our run-time for end-users has supported Linux, Mac and Windows for over a year, but adding this same support for developers turned out to have been really difficult to deliver. After years of really only supporting development on Linux, with Beta 0.1.0 developers can now develop Holochain apps on their platform of choice: Linux, Mac (Intel & M1), and Windows (under WSL2). We spent hundreds of hours developing and redeveloping our CI tooling such that when a Holochain-core team dev merges a branch, our test suite runs across all the platforms; and when we deploy a new version, binaries are automatically compiled and added to our package management system so that developers can easily pull them to in their dev environment of choice.
A much more difficult place to meet developers where they are has to do with the nature of Holochain itself as a distributed application development platform. The core value that Holochain delivers, distributed applications that don’t rely on any centralized architecture, actually requires developers to think and do things a little differently than they might be used to. This means that there’s a learning curve, and so getting started can take some effort. To address this, for Beta 0.1.0 we have delivered what I can only describe as a stellar scaffolding framework. Our scaffolding tool allows developers to generate the bones of a fully functional hApp in minutes. But, again, in our commitment to meeting developers where they are, the scaffolding tool allows you to pick which UI framework you want to use (currently Svelte, Lit, or Vue). Additionally because the scaffolding tool is modular and extensible, advanced developers can create more scaffolding templates that support more UI frameworks or even different types of projects.
Confidence
Viability in terms of adoption of any complex system requires delivering confidence in the integrity and security of the system. Supporting Beta 0.1.0 we’ve also delivered on our commitment to providing that confidence via external validation of the security and integrity of our code. Least Authority (one of the most trusted third-party evaluators in the industry) has so far audited both lair-keystore, our cryptographic key-manager, as well our deterministic integrity model. We’re very pleased with their initial findings and we will be delivering much more code that supports integrity, security, and thus confidence in Beta 0.2.0.
Minimum viable beauty
There’s one more aspect to viability that I feel intrigued about, and this is what I like to call “minimum viable beauty.” There’s something deeply subjective about what makes something feel viable, and it deserves facing head on. I believe that the tools we use on a daily basis aren’t just functional. Our use of them touches into all kinds of aspects of our being, our identity and our sense of aesthetics. From my own experience, at least some part of my willingness to try something new is just that it feels right. This doesn’t necessarily mean that it has to match my preferred style, it’s almost more that I can recognize that enough care was put into the tool that it actually has its own style. It’s as if in this realm, what matters happens at the level of recognizing attention to detail.
We spent lots of time and effort upgrading the Dev Portal, testing out the layout, the instructions,, and more, in a way that I hope transmits our care. Similarly we’ve done lot’s of “pixel pushing” on both the Launcher and our sample hApps (TalkingStickies and KanDo!), so that they look good as well as being really usable and thus deliver a strong end-user experience. The DevHub for uploading hApps is working pretty darn well. The scaffolding’s command-line UX was tested over and over. Even internally in the Holochain’s HDK we spent months working on improving dev ergonomics, i.e. ensuring that it is easy and clear to make Holochain calls from within your DNAs.
I’m not really trying to make a strong claim about what minimum viable beauty is. I’m just saying that I like to think through that lens. The lens of how things feel to use, and what thresholds actually matter when developing a project like this. Clearly we will use things that are really clunky if the value of use is great enough. So minimum-viability is relative. But my sense is that we’ve crossed over a threshold.
With Holochain at Beta 0.1.0 it’s more than a seed or a sprout; Holochain is a sapling chasing after the sun.
