Listen: Open-Source WebAssembly Tools
Matt Butcher
podcast
Earlier this year, Matt Butcher joined Robby and Tim on the Open Source Startup Podcast. The session begins with the story about why we started Fermyon and why we’re so enthusiastic about WebAssembly. From there the discussion delves into how to focus a startup’s energy when building a specific thing or things. And then we go on into the burgeoning WebAssembly ecosystem. Somehow, we veer into French post-structuralist philosophy as a way to understand ecosystems and community emergence in open source. Finally, we talk about company building and what it’s like to build a team.
Ruby and Rails: A Pattern
While discussing how to create an ecosystem, we chatted a bit about the Ruby case, and whether there is a parallel with WebAssembly.
Ruby was invented nearly ten years before it hit the mainstream. Not until Rails hit the mainstream did Ruby itself really balloon in popularity. It took the right technology to make the language an enticing option.
WebAssembly has also been around for a while. It was first announced in 2015, seven years ago. For whatever reason, it did not immediately gain huge adoption among the developer community even though it has support in every major browser. But over the last couple of years, WebAssembly has found a new application. The runtime itself solves problems for the cloud.
I like thinking of tech as having Zeitgeist moments. A technology that floats under the radar suddenly reveals itself as a solution to a problem, and interest in that technology rises rapidly. This happened with Ruby as a result of Rails. And WebAssembly is experiencing the phenomenon now as we apply it to problems beyond the browser.
WebAssembly as the Last Plugin Model
In the interview, I talk about WebAssembly as the “last plugin model.” This bit has been taken out of context a bit since I first recorded this podcast. I do not believe that all WebAssembly usage equates to plugins.
A plugin architecture is one in which the core features of an existing application can be extended by loading additional code from third parties. The core distinction here is that what is being extended is the core feature set of a application.
WebAssembly’s role in the browser is not to extend the browser (e.g. add better bookmarks or integration with a password manager). That is, WebAssembly in the browser is not for plugins, nor does it use the plugin model. It is to allow developers to work in languages other than JavaScript.
WebAssembly’s role in the cloud is also not a plugin model. Spin does not follow a plugin approach. It is a framework for building microserivces and web applications. When a developer writes a new Spin application, they are not writing a plugin because they are not extending the feature set of Spin. They are writing an application that has its own feature set.
So to me, WebAssembly has three different major applications:
- Running (non-JS) code in the web browser
- Providing a compute runtime in the cloud
- Adding plugin support to existing applications
As much as I believe that WebAssembly is a great plugin technology, and will grow quite a bit in this regard, I do not think that all WebAssembly usage is necessarily done in a plugin model.
Building an Airplane as You Fall
Tim talks about startup life as jumping off a cliff and building an airplane as you fall. In many ways, this is apt. The commitment you make up front when forming a startup is high risk. Tim further suggests that with Fermyon, it’s sort of a doubly complex problem, because we are both building the core architecture (WASI, Wagi, Spin, etc.) while also finding the product market fit.
With WebAssembly, we’re collectively forming an ecosystem around a still-changing technology, and we at Fermyon are simultaneously trying to build a company along the way.
This adventure reminds me of Deleuze and Guittari’s concept of “smooth and striated spaces” in their essay The Nomadology. A striated space is one where the rules have already been set, the groundwork is laid, and things have been “straightened out” for us. A smooth space, characterized by fracture lines that are anything but straight, is where discovery happens. We went out into the vast openness and began building a community, an ecosystem. This is different than starting from a “striated space” – a built-out ecosystem – and participating in that ecosystem.
As this part of the conversation winds down, we talk about how WebAssembly’s pervasiveness across browser and server ecosystems will cause it to rapidly evolve because communities (e.g. front-end and devops) will innovate together, each based on their needs. I point to the component model as the primary driver for the future of WebAssembly. And WebAssembly’s cross-language model will further this. Instead of implementing the same things (YAML parser, utility libraries) in language after language, we will have a single pool of WebAssembly components that we can use all over the case.
The Mechanics of Creating a Startup
Finally, we talk about starting a company. We talk about the Forming, Storming, Norming, Conforming model of group formation. Then I explain how we use Gallup’s Clifton Strengths Finder to help us all understand our own strengths and the strengths of our peers.
At Fermyon, one of our stated goals is for our team to consider Fermyon to be the best place they’ve ever worked. See our discussion on company values for more about why we at Fermyon work hard to build a healthy culture.
Check out the Open Source Startup Podcast for more great stories from open source founders