Craft
Three Things #132: August 11, 2024
Athena, the namesake of our project, is the Greek goddess of warfare and strategy, but she's also the goddess of craft. While we didn't choose the name Athena for this reason, I've always been more drawn to the "warfare and strategy" aspect. Recently, however, I had a revelation about the "craft" element while listening to an insightful podcast on the history of Hermès, the renowned French boutique.
Craftsmanship has always been central to Hermès' story and brand. Although many of its competitors also emphasized craft, during the 1970s and 1980s, all the other luxury brands essentially "sold out," abandoning true craftsmanship in favor of fast fashion, outsourcing design and production, etc.. During this time, Hermès faced challenges because consumer tastes were rapidly changing. They hired expensive consultants for guidance, who advised them to follow the same path: abandon true craft, sell out, and join the competition.
The CEO at the time had a different vision for the company—one that involved staying true to its roots in craftsmanship. This vision has continued to serve as a guiding principle for Hermès, which is why the brand remains globally renowned for its exceptional craftsmanship, limited production, and high prices.
But what does all this have to do with software, Athena, and Spacemesh? Let's dive in.
Thing #1: Vision and Brand 🏷️
The Hermès story resonated with me deeply because it mirrors the story of Spacemesh. Every successful brand or company that seems inevitable today has experienced moments of vulnerability and doubt—times when it was uncertain whether an idea, product, market, or even the entire company would succeed. This is one reason I love studying the history of iconic companies: it reveals that no brand or company was destined to succeed from the start.
Another lesson from history is that brands and companies that become truly iconic, those that dominate industries, almost always prioritize vision and brand. Few things are nearly universal markers of success, but I believe vision and brand are among them. Successful companies, like successful individuals, know who they are and what they want to achieve. They have a clear vision that they can articulate to the world and a set of values that motivate them and rarely change. They build their brand around these core values.
Hermès reminds me of Spacemesh because, like Hermès, we have been pursuing our vision for some time (albeit in a much younger industry). We started with a set of values and a specific mission, and like Hermès, we’ve seen nearly the entire industry sell out and adopt a very different ethos and set of values. Many "overpriced, self-professed expert consultant" types are always trying to convince us to fall in line and do what everyone else does, what’s "proven to work," but we have no interest in compromising our values.
Remaining true to their roots and going against the grain of the industry wasn’t an obvious decision for Hermès at the time, but it paid off in the long run. It would have been much easier to sell out and join the competition, as the so-called experts advised. But had they done that, Hermès wouldn’t be Hermès today. At best, they’d be another Louis Vuitton, and at worst, they might not exist at all.
Similarly, Spacemesh wouldn’t be Spacemesh if we adopted the same strategies as other projects and chains, such as billboards, lobbying, partnerships, airdrops, and spending millions on superficial marketing. That approach might seem like a winning playbook today. However, when you take a broader view, it’s clear that none of the projects engaging in these behaviors are achieving meaningful, lasting success. They mostly lack users or applications and have little track record. Nor are we, as an industry, winning yet. It’s too soon to tell, but I believe that investing in the right technology, the best people, an organic community, and, above all, vision and brand will pay off in the long run.
Thing #2: Software as Craft 🔨
Another reason the Hermès story resonated with me is my long-standing fascination with the concept of craft. I've explored this idea before in the context of software. While the age of the journeyman apprentice and master craftsman may have passed, I believe we're entering a new era of the sovereign master coder.
This new age is on the horizon, but we're not there yet. Software isn't typically associated with craft, likely because, in recent years, it has become a big business that's famously "eating the world." Today, software is produced and operated at scale by enormous teams at billion-dollar companies. The most powerful aspect of software is its ability to scale cheaply: adding one more installation costs almost nothing.
It wasn't always this way. Historically, software was difficult to write. The earliest software was crafted by hackers who developed individual applications "by hand" using tools like punch cards and assembly code. These hackers can certainly be considered craftspeople. While this didn't lead to extremely robust or mature software, and the process didn't scale, it was undoubtedly a form of craft.
This is more or less how software was written for decades, until relatively recently. Software engineering began to professionalize in the 1990s; before that, creating even simple programs was extraordinarily time-consuming, tools were either awful or nonexistent, and, as a result, software was more of a craft than an industry. I remember the tail end of those days in the 1990s, before the advent of the web, cloud computing, and mobile technologies, which I believe were the final nails in the "software as a craft" coffin. I remember when magazines published source code for transcription by hand, and when in-person meetups allowed people to swap programs on floppy disks because there were no other ways to distribute software or recruit users.
The software industry has been completely transformed since then, but craft software still exists. It's hard to pinpoint what sets it apart, but you know it when you see it. Craft software is created primarily as an act of creation, rather than to solve a problem or make money.
The first craft project that comes to mind is Urbit. It was designed and coded with great care and love. It's unlike anything else, eschewing tradition and not adhering to existing frameworks or standards. It's not designed or built to be monetized and may never work at scale. Perhaps these are good hallmarks of craft software.
Then there's open source. The open-source movement has been a significant factor. Just as artisans once swapped ideas and designs without worrying about patents and competition, and motivated upstarts gained skills by working as apprentices to master crafters, we see similar trends in open source today. Open-source projects openly borrow ideas and code from one another. Newcomers can jump in, get their hands dirty, and contribute without a formal hiring process, with guidance from experts. Many contributors to open-source projects do so in their spare time because they love it, rather than as a full-time job or for money.
Looking back, software developers began as individual craftspeople. At the time, software was quite immature, but it has matured significantly. Many developers joined (or founded) big companies, and it's hard to call what these companies do craft, but I think we're beginning to come full circle. We're moving into a bold future of work focused less on the company and more on the task or project. In this future, a form of neo-artisanism is reasserting itself. The best software developers are becoming increasingly selective about their work, demanding the ability to contribute to open source. This trend will continue, and we will return to the roots of software, when it was a craft, not just an output from big tech's assembly line of overworked code monkeys.
Thing #3: Athena 🦉
What does all this mean for Athena and Spacemesh?
With very few exceptions, blockchain VMs today are commoditized. What do I mean by that? They were mostly assembled quickly, with little thought given to design or developer experience. Bitcoin Script, the first of its kind, was groundbreaking at the time but is the least user-friendly of them all. Ethereum's EVM and Solidity are significant improvements over Bitcoin Script, yet they remain somewhat clunky and not particularly well-designed. If the team had had more time, more expertise in VM and programming language design, and better examples to draw upon, Ethereum's programmability would probably look quite different.
Solana's programmability, despite coming years after Ethereum and using Rust, is, in some ways, a step backward because it’s even more confusing than Ethereum. And these are just the mainstream chains. There are, of course, many other chains and execution environments, from Chia’s Chialisp to Stacks’s Clarity to Tezos’s Michelson, but these tend to emphasize things like purity, elegance, or safety at the expense of practicality and developer experience. Functional programming languages are fascinating but not practical for most developers. Very few are familiar with them, and history and the market have shown that the vast majority prefer C-like, imperative, multi-paradigm languages like Rust. Another way of looking at the situation is that blockchains are already innovating along many dimensions and they already require developers to learn lots of new concepts. Why make them learn new programming languages, too?
I sense that most of these tools were not designed with art or craft in mind. They were built to solve specific problems. Bitcoin Script was designed to allow simple programs like multisig or timelock, adding useful functionality without affecting Bitcoin-as-money too much or making Bitcoin too complicated. The EVM and Solidity were created to be a Turing-complete, deterministic VM with a language that felt familiar, like JavaScript. Solana's programmability stack was designed to work on top of the obscure eBPF VM.
These aren't the types of platforms you’d build if your goal was to create the best environment for developers, emphasizing developer experience and enabling them to build the best possible applications. Platforms and tools designed to be developer-centric do exist, and you recognize them when you see them: Linux, Python, TypeScript, React, and Kubernetes, to name a few recent examples. And then there's Rust, the most desirable and popular programming language for many years running. Rust is precisely what you'd build if you wanted to make programmers' lives easier and more enjoyable and empower them to create the best possible applications.
I've always said that developer experience is our number one goal for Athena. Other things matter too, but none of them will matter if we don’t emphasize developer experience since Athena's success hinges on it. Rust and some of the other tools I mentioned likely share similar priorities, which is why they’re so developer-friendly, but this isn’t the case for any other blockchain platform I’m aware of. Developer experience in modern blockchains ranges from horrendous to acceptable, but it’s rarely enjoyable. It’s much harder than it should be, and harder than it needs to be. We aim to change that with Athena.
In other words, Athena is for craftspeople. Building applications on Athena should be as enjoyable and frustration-free as building applications with Rust. Athena is Rust, and any additional tooling we develop for Athena should seamlessly integrate with the existing Rust toolchain. This is why, for instance, you run cargo athena build to compile an Athena application, and it’s why the prototype Athena programs (smart contracts) are simply Rust structs with a few simple annotations.
This is also a significant reason we chose not to pursue EVM compatibility. We don't want low-quality, commodity-grade spaghetti code already deployed on dozens of EVM chains to be copy-pasted to Athena and Spacemesh. We want novel applications, thoughtfully custom-crafted for the Athena runtime. To extend a metaphor, we don’t want mass-market, sugary, high-calorie snack food. Athena is for creatively crafted, high-quality, wholesome superfoods. This priority is more important to me than maximizing the number of deployed applications in the short term. I don’t have especially strong opinions about many things, but I am very opinionated about what the experience of building and running software on Athena should be like. Developing bespoke software for Athena should be joyful, and running Athena applications as a user should also be joyful.
We’ll build whatever tools we need to elevate blockchain software development to the stage of craft for the first time. This is what Athena stands for, and this is why I’m happy we have the goddess of craft as our mascot and patron.