The Changelog: Software Development, Open Source - Wasmer is taking WebAssembly beyond the browser (Interview)

Episode Date: April 12, 2019

We’re talking with Syrus Akbary about WebAssembly and Wasmer — a standalone just in time WebAssembly runtime aiming to be fully compatible with Emscripten, Rust, and Go. We talked about taking WebAssembly beyond the browser, universal binaries, what’s an ABI?, running WebAssembly from any language, and what a world might look like with platform independent universal binaries powered by WebAssembly.

Bandwidth for ChangeLog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at ChangeLog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash ChangeLog. This episode is brought to you by DigitalOcean, the simplest cloud platform out there. And we're excited to share they now offer dedicated virtual droplets and unlike standard

droplets which use shared virtual cpu threads their two performance plans general purpose and cpu optimized they have dedicated virtual cpu threads this translates to higher performance and increased consistency during cpu intensive processes so if you have build boxes cicd video encoding machine learning ad serving game, game servers, databases, batch processing, data mining, application servers, or active front-end web servers that need to be full-duty CPU all day every day, then check out DigitalOcean's dedicated virtual CPU droplets. Pricing is very competitive starting at $40 a month. Learn more and get started for free with a $100 credit at do.co slash changelog. Again, do.co slash changelog. All right, welcome back, everyone. This is the changelog, a podcast featuring the hackers,

the leaders, and the innovators of software development. I'm Adam Stachowiak, Editor-in-Chief here at Changelog. Today, we're talking with Sirius Akbari about WebAssembly and Wasmer, a standalone, just-in-time WebAssembly runtime, aiming to be fully compatible with Emscripten, Rust, and Go. We talk about taking WebAssembly beyond the browser, universal binaries, what's an ABI, running WebAssembly from any language, and what a world might look like with platform-independent universal binaries, what's an ABI, running WebAssembly from any language, and what a world might look like with platform-independent universal binaries powered by WebAssembly. So there was a tweet by Steve Kalabnick that Adam, I think you were a fan of,

where he said that 2019 is going to be a huge year for WebAssembly, even if many people don't know it yet and may not see the effects until 2020. So we're not joined by Steve. We're joined by Cyrus of Wasmer. And I just wanted to pitch that over to you and ask you if you agree with Steve. Do you know what he's talking about?

Are you inside on this? What do you think about WebAssembly 2019? Completely. Yeah, so I think WebAssembly is, I completely agree with Steve. WebAssembly will be very big this year. We are just warming up. The main reason we believe it's going to be big is because there is a lot of agreement on the industry that WebAssembly is the path to go for executing things like universal

binaries in a universal way, first across browsers and then outside of browser environments. And basically right now there are a lot of companies pushing towards that, and we are one of those. So Wasmr.io is what you're up to. It's a standalone, just-in-time web assembly runtime with an aim to be fully compatible with Emscript and Rust and Go. Can you unpack that description and put it in layman's terms for me so I can understand it?

Completely. So what we are trying to do is move WebAssembly to the server side. So up to basically like one year ago, WebAssembly was mainly a way for executing performance code on the browser. However, we believe WebAssembly will also be big on the server side. And we are trying to do a similar thing that Node JavaScript did moving JavaScript to the server side, but with WebAssembly instead. So first, we are focusing on creating a runtime that will let developers use WebAssembly on the server side. And second, we are adding integrations into other languages. So basically, you can call WebAssembly not just from JavaScript,

but also from Python, or for Ruby, or from Rust, or from any other language. So yeah, that's basically like what we are focused on. So I understand why you would want to run WebAssembly in the browser, I guess, where I'm missing it, and where I'm gonna need your help. And I obviously am missing it, because lots of people are excited about this. I just don't get it yet. Why would you want to run WebAssembly outside of the browser server side when you could just write, like the example you give is Nginx. Nginx, let's just take that, running via WebAssembly. But why can't I just compile Nginx and run it? Why run WebAssembly in between, so to speak? so the main reason for using web assembly there is because it provides a way of running binaries universally so right now if you're

using nginx you need to compile or to run nginx like in your system you need to compile specifically for your platform and architecture that means like if you are in linux you need to compile it like for your linux distribution and like certain architecture that you are using. In Windows, you need to compile it like in a different way. And this is super tedious. So that means like you need to distribute the source code and let the developer compile the source code itself to be able to use it. And what we believe will be much nicer if we provide universal binaries that can be used across any platform or architecture without actually any further change.

So your same nginx.wasm could run in Linux, could run in Windows, in Macintosh, or eventually in your phone without any change. And we believe that's going to be really, really big. So it's kind of the old promise of write once run anywhere only it actually delivers yes it's um like this concept is similar into like what java or the jvm was trying to achieve yes with the main difference that right now any other language actually like can target very easily to WebAssembly. So it provides a nice transition

for projects that already exist either because they are developed in C or C++ or Rust or any other language can be compiled very easily to WebAssembly. So that means you can transition or you can like reuse your projects or target WebAssembly very, very easily. What makes WebAssembly good for this, this universal binary idea? So what makes it great first is that we have universal agreement or agreement across all the industry. That means companies like Google, Apple, Mozilla are all pushing towards a standard

that everyone agreed on. So this is big. And the second thing is it started from the need of executing performant code on the browser. So actually, it started from a prototype that was actually in JavaScript, asm.js. And from that, actually, it's been shaped exactly to fit the needs of executing bytecode

in a way that was very performant on the user side. So in the browser, there's a specific surface area of functionality that needs to be available. And the server on an operating system level, there's just way more things there, right? I just feel like there's much more surface area to the APIs and to the system calls and all of the different things that need to be bridged, so to speak. So is this a huge undertaking or is it easier than I'm thinking? So it's actually not really that hard. So, for example, one of the projects that I started targeting or actually like created kind of like WebAssembly was MScripten.

So how MScripten started started, we have a native binary that we wanted to execute on the browser. So basically, it provides a bridge between LLVM IR and JavaScript. So it just translated LLVM bytecode into JavaScript bytecode. So with this first bridge, what MSKrypton did is basically designing an interface that will

help on executing this code on the browsers. How they did it was by creating wrappers around these syscalls that actually don't exist on the browser. For example, for opening a file or actually opening a socket or closing a socket all that they did is creating like a set of sys calls that were kind of like just fake but like reply with the same structure that like web assembly was expecting and this is this set of sys calls is actually like i think on the mscript inside this is about like 200 but there are other implementations that actually require to implement much less syscalls. So the truth of the fact here is at the end, with a set of more or less like 50 real syscalls,

you can implement almost all the calls that like any native library or native binary will need to do to talk with the operating system. And that will be enough. And in general, this set of syscalls will be like again like opening a file closing it uh reading its contents uh opening a socket i don't know maybe like getting a random number and things like that so at the end of the day there's only about 50. is that what you're saying that you have to implement for any particular platform yeah like basically any other one this is a superset or is just a play between this Inter50. So with 50, you will be very much served.

So is that where Wasmr comes into play? Is it provides that interface to those system calls? Or what exactly, how does Wasmr come into play? I know you say it's a runtime bug. So first, before starting Wasmr, curiously enough, I just started reviewing like, all the WebAssembly runtimes. And there were the fastest ones were actually like on the browser side. And there were like other implementations on or trying to have like a WebAssembly virtual machine on the server side. So I reviewed all of them. And funnily enough, the faster one was Firefox.

So I started sneaking into how they were implementing a WebAssembly runtime. And basically what I did is I created a toy project using their engine. So their WebAssembly engine, but trying to use it outside of JavaScript. So removing all the JavaScript part. We started just creating the runtime

as a pet project, which was a very cool project. And then, like, can you repeat again, like, what was the question? I think I diverged it a little bit. I was just trying to figure out where Wasmur fits into the picture with regard to the system calls.

So yeah, regarding the system calls, how Wasmere fits is we provide different integrations or interfaces. So for example, MScripten defines a set of syscalls on top of Libsyn. And we just kind of like, rather than creating these syscalls or emulating these syscalls in JavaScript, we do it like natively with native functions. But the truth of the fact is we can plug MScripten or we can plug like any other kind of ABI. So for example, today Mozilla released this new project, WebAssembly Common Interface called WASI.

And they basically redefined the set of syscalls rather than being 205 MScripten, I think it's just like 40 or 50. And the cool fact of Wasmere is you can plug the ABI that you want to use for certain binary. So there will be some WebAssembly binaries that are

compiled using MScripten, and therefore will use the MScripten syscalls. And then there will be other WebAssembly modules that are compiled using this new WASI interface. And then you will need to use this WASI interface instead.

So the cool thing about Wasmary is you can plug any pre-existing ABI that we already created, or you can plug your own ABI. Can you explain what ABI means and what that entails? ABI, what it means is Application Binary Interface,BI, what it means is application binary interface.

But what it really means is the interface that you set for having your syscalls. So it's just a set of syscalls that is defined. So there are, I don't know, 30 different ways of opening a file. So what is the open function? How many arguments received, and how many results output or types output? That will be the definition of the open function. But then the ABI might have other syscalls. And basically, the ABI will mainly define what is this

set of syscall functions, what are their inputs and what are their outputs. And that's it. This is what is an ABI. So famous ABI, for example, is the Lipsy. An ABI, MingW is another one based on Lipsy. So there are multiple. Okay, so an ABI, it's like an API but it's a binary interface.

Yes. And that means that there's specific contracts or agreements of how you are going to access certain functions inside the binaries. Am I understanding it correctly? Yes, you got it completely right. Okay, so rewind a little bit, because you might have lost me on the WASI and on the ABI side. Just because I wasn't completely tracking on what ABIs are.

Can you explain again how WASI, which is what Mozilla announced today, we'll have a link to that in the show notes. WASI being a system interface to run WebAssembly outside of the web, what we're talking about here. Yes. Basically, they're trying to standardize this interface. So is that an ABI that they're standardizing, or are there multiple ABIs? I just don't quite understand. So before WASI,

the only way of running or the main way for running C projects on the browser was MScripten. With MScripten, you have a lot of set of syscalls, but it was not really designed in the sense of trying to run outside of the browser was MScripten. And with MScripten, you have a lot of set of syscalls, but it was not really designed in the sense of trying to run outside of the browser or basically on server-side environments.

And what WASI is doing is trying to redefine this ABI so it's a much cleaner way of interacting. So I will say WASI is just a cleaner way of having the MS Script and ABI with much less system calls to implement. Okay. This is very much bleeding edge, right? I mean, we're talking about a thing that was just announced

literally today as we record, March 27th, an ever-moving space. Yes. But the cool thing... Grab on tight and hold on for as long as you can because things are moving fast. Completely. Actually, before MScripten,

one of the things that we were researching on was Cloud ABI, which was a similar set of syscalls that WASI is doing, with only the difference that it will let you define permissions on top of that. So before you're opening, for example, a file, it will check if you have permission

or someone gave you permission for opening the file. And therefore, it will let you execute the syscall or it will fail if that's not the case. So Cloud ABI, for example, was another ABI, potential ABI for WebAssembly. But regarding WASI, WASI actually fits much better the WebAssembly needs because Cloud ABI was not designed with the WebAssembly in mind. This episode is brought to you by our friends at GoCD. GoCD is an open-source continuous delivery server built by ThoughtWorks. Check them out at gocd.org or on GitHub at github.com slash gocd. GoCD provides continuous delivery out of the box with its built-in pipelines,

advanced traceability, and value stream visualization. With GoCD, you can easily model, orchestrate, and visualize complex workflows from end to end with no problem. They support Kubernetes and modern infrastructure with Elastic On-Demandand agents and cloud deployments. To learn more about GoCD, visit gocd.org slash changelog. It's free to use, and they have professional support and enterprise add-ons available from ThoughtWorks.

Once again, gocd.org slash changelog. so it seems like what this direction has taken us is like being able to not limit certain type of applications to a certain platform almost akin Jared to your stop limiting your open source library's potential where you write something for react or a certain language jQuery or whatever and you're using x and you can't use it in y it's almost like we're going that direction to get to this universal binary run anywhere where it's nginx sqlite or whatever being able to be on any platform and not kind of limiting what it can run on. Completely. So as you say, like there are two sides of where WebAssembly can be really successful. One is for having like universal binaries that can be run without any modification in any platform

and also in any architecture. That means like any chipset. So that means running Nginx in your Linux system or that same Nginx binary in your Macintosh system or in Windows or even eventually in your phone. And the same could go like with SQLite or other binaries. So this is one side of where WebAssembly will be very successful, which is universal binaries. And the other one that I think will be also key will be for having universal libraries. So what this actually means, that means having a library that can be used across any other language.

So imagine you have a face detection library, that this face detection actually provided a binary image. It detects the squares of where are the faces. So right now, if you search, you will find different implementations. One, this library detect face, library detection will be implemented in JavaScript, then in Python, then in Rust,

then in C, you will have another one. So basically, depending on the system you are at, you will use one or other library. But what I think WebAssembly will unleash is this generation of universal libraries that can be used across any language. So imagine you create your

library, your face detection library in Rust, and you compile it to WebAssembly, basically using the Rust toolchain. And the cool thing is once you have this face detection library .wasm, you can use this library in Python, or you can use this in JavaScript, or you can use it in Rust

without actually needing to reimplement it. And I think that's going to be really, really powerful. So having that power is pretty interesting. How, when you're at that language, let's say in JavaScript, trying to use this face detection library that's written in Rust, compiled to Wasm, you know, what's the user experience or the dev experience like from a JavaScript developer's perspective to interface with this library or these libraries? So from the JavaScript perspective, the cool thing is JavaScript have actually like a WebAssembly engine already like embedded.

So if you are using Node.js, you will have already a way for interacting with WebAssembly very easily. So the only thing that you will need to do is first point to where this WebAssembly file is located, then create a WebAssembly module, and then from that, instantiate it. So the difference from a WebAssembly module and a WebAssembly instance is you can see one is the program and the other is the process running that program. So basically like one module can have like multiple instances running or multiple processes running that code. So the cool thing is JavaScript already have a way of using WebAssembly, but it's actually like the only language that right now is able to do it.

So one of the things that we are doing here at Wasm is trying to make very easy to call WebAssembly or to use these WebAssembly modules outside of JavaScript. So we just integrated an extension into PHP. So you can, for example, take this face detection library.wasm and use it from your PHP code, just instantiating the WebAssembly module and then calling a function that exists on this WebAssembly module, for instance. I'm sitting over here thinking about graphical interfaces. Yeah. Because I would love to

have something like Slack where they could write it once, run it on all these different platforms, but not have to ship Chromium and all the overhead of Slack. Maybe they could run the exact same binary in the browser and have a web app, although in the web, I would like to have a regular web app.

That being said, what about graphical interfaces? Are we pretty far away from that? Is there a lot more filling to do that? Or are we pretty close? Actually, we are not really that far. I mean, UIs in general are a little bit more complicated because they require like an interface to touch the graphic system but in general i will say we are not really that far

one of the things that right now basically the industry is pushing towards that direction just with electron electron embedded embeds chromium under or uses chromium under hood and then you can have like your application application running in any system. But the cool thing, with WebAssembly, you can do exactly the same, with the difference that rather than having a JavaScript runtime, you will have a native runtime running at native performance. So then the RAM usage will be much lower,

the performance will be much higher, and I think will also be a super attractive area for WebAssembly. I think we are really not that far, probably a few months off. be like much higher and i think will also be like a super attractive area for web assembly and i think like we are really not that far probably like a few months off well that will be awesome and you can do it in any language you want there's no limit as long as your language has web assembly support yes as long as your language actually can compile to web assembly right so cool thing right now we have c or c++ or Rust that actually can target WebAssembly super easily. But we have other interpreted languages, for example, Python, that cannot compile directly to WebAssembly. So the way to go there is actually compiling the interpreter itself to WebAssembly and then execute the interpreter in the machine.

What? Yeah. That's a nice hack. Is there first-party support coming? I'm thinking of Python, Ruby, Elixir. Is there a place where you say, can I WebAssembly it yet?.com? And all the languages are there with what kind of support they have?

What's the situation with these other languages? There is one great repo created by one of our team members, called Steve. I think, is WebAssembly Awesome Langs or something like that. And you can see all the languages that can compile or any language that can be executed or compiled to WebAssembly. So the list is actually pretty big.

One cool thing that we did in Wasmere was being able to run Lua, the Lua interpreter. So we have like a Lua compiled to WebAssembly, the Lua interpreter. And now you can just do Wasmere run Lua.wasm and you will basically run the Lua interpreter. But almost any other language that you can think of, even Java can compile to WebAssembly very easily.

So there is, like talking about Java, there is a very interesting project called TVM. T, like as you are drinking that tea. This VM actually compiles Java bytecode to WebAssembly bytecode. And then you can have like your universal WebAssembly bytecode with your code that is actually written in Java,

but targets WebAssembly. And I think that's a very interesting idea. So we have found awesome WebAssembly languages repo. Link in the show notes. Lots of languages listed here, and then each one has a little emoji. It's either an egg, or a baby chick hatching out of the egg, or a full-on chicken. There's no legend, so I'm not sure exactly what these indicate. I guess it's just starting

to support it, or it's... I don't know. So, man, there's a lot of them. Yeah, there are. A lot going on there. For example, right now we are actually working on having the PHP interpreter in WebAssembly. There is already a project that targets web, so we are

trying to just complete the syscalls needed to actually get the PHP interpreter in WebAssembly. So we are trying to just complete the syscalls needed to actually get the PHP interpreter in WebAssembly. And we are super close. So then you can start seeing how the ecosystem will grow into a place where you can install these universal libraries, there is PHP, Python, or whatever, in a way that is super localized

and doesn't require you to compile the project itself for using it. That's a good point. What is the installation process currently? Will we ever see a package manager for this or is there a package manager for this? Cool, actually like good thing that you asked that. We are working on the first package manager for WebAssembly and it will be released very very soon and hopefully at the same time that like this show is aired. So yeah we are working on this. This is like breaking, breaking. Breaking news.

Yeah, super breaking. We are actually very, very excited because for example, now we have like SQLite compiled to WebAssembly and uploaded to our WebAssembly package manager. And you can just do like Wapum install SQLite and then like Wapum run SQLite and you will run like SQLite locally, but like at native speed. That means like with all the things that SQLite, and then Wappen runs SQLite, and you will run SQLite locally,

but at native speed. That means with all the things that SQLite has. So does this, let's say you're on Mac, would this replace someone using Homebrew to install SQLite? Yeah, that will probably be it. And the cool thing is it will work in Linux and then Windows

as well. So then exactly the same binaries will work like Windows, Linux, Mac, and could work also in your phone. We just need to build the integration, but that should be like not really hard. So what's the, what's the UX for installing currently? Is it a curl command or something like that to install? So it will be like similar to what NPM is doing uh that means like um i mean now what's what's the way it is now and how it will change i guess ah okay so right now the way you will have

to do it is you will like first need to compile whatever you have like to web assembly then you will need to upload this web assembly package or module like somewhere and then like from that when you want to use it you you need to download it manually. And then you need to either, for running it, you will need to use Wasmere, for example, to target this file that you downloaded and try to execute it. This is how it's done until now. How it will be done in the future will be like, just do like WAPM install SQLite and then like WAPM run SQLite and that's it.

I might be splitting hairs here, Jared, and correct me if I'm wrong, but I'm kind of feeling like WebAssembly might not be the best long-term name. Thank God for the acronym. Because, I mean, at some point we might just digress to WASM and move on because WebAssembly will eventually not make sense anymore. Yes, completely. Actually, I mean, at some point we might just digress to Wasm and move on because WebAssembly will eventually not make sense anymore.

Yes, completely. Actually, I completely agree with that. But like WebAssembly actually started from the web. So that's the why behind the name. But like, yeah, I guess in the future we'll just call Wasm. Like WebAssembly is actually like not really tied to the web anymore. But we can see like a lot of applications on the server side. So the potential to replace Electron-style applications, potential to replace all package managers,

apt-get, homebrew, whatever your distribution or operating system-specific package managers, because it's universal. There's one SQLite, and it doesn't matter what system you're on, it's universal. There's one SQLite and it doesn't matter what system you're on, it's going to work. Yeah. That's a pretty bright future if you ask me.

If it delivers, that's a bright future. Yes. Actually, I'm super sure it will deliver. Funny enough, before starting Wasmert, I was kind of sneaking to this idea like what could be possible and when I realized what are all the possibilities that we have with WebAssembly, I was was like i need to create something that's gonna

be like really really big and the truth is we are not really that far from from that future so how long have you been working on this stuff and how did you initially get that insight what were you up to when you stumbled upon this and what finally you know when did you see the light and why so first uh i started like developing on open source like for a long time um funnily enough i released like a graphql library for python uh that was about like three years ago so while i was trying to create this framework at some moment basically i dropped my job and i created a company just solely focused on this GraphQL framework for Python. So at that moment, I was trying to compete with companies that actually were much more funded than me because I didn't get any money from

investors. So at that moment, the way to compete against them is, okay, I'm going to make this library available in more languages, but without making the effort of recreating the same framework in another language. So I was taking a look already into WebAssembly, and I started basically researching more into WebAssembly and what I can do with it and what can be done. And I then realized that WebAssembly can be the perfect bridge to compile my framework to WebAssembly and then be used across any language. So that's kind of like what was the first idea.

And then from that, I started realizing WebAssembly can also be big, not just for universal libraries, but also for universal binaries. And what I eventually saw is this is going to be big for edge computing, or in general, the localized computing. So right now, for example, if you have a website that, I don't know, is running like on Docker, for example, the way it will work is maybe you set up with Kubernetes or something else.

And then you will have like an instance that is running like all time, all day long, even if you have like three requests a day. So that means like if you have like total of 90 requests in a month, you will need to have a server running for fully 30 days running. The cool thing is with WebAssembly, we have much more optimized times. So rather than having a startup time compared to Docker of one second, it's five milliseconds. And rather than having a container focused on an operating system that has an operating system and then your application, it's just the application contained itself.

So what I saw is because of these startup times were super, super low, and because the container sizes, rather than being in the order of hundreds of megabytes, will be in the order of just a few megabytes, it will enable the next generation of edge computing. And that means we can start thinking of having servers that run only when you request them. So rather than having to pay for full 30 days of usage, even if you go like a server with 30 requests, you might just need to pay like for 30 seconds. And we can afford to do that because we can spin up and spin down like WebAssembly instances in a very performant way. And actually that's our long-term business. I was just going to ask what your commercial angle was. And it sounds like that's,

you just described it right there. Yeah yeah so one of the things that we are seeing now is uh i'm not sure if you saw how google uh we released this um gaming platform which was ultra cool uh it's actually like running it lets you like run very cool games that will be streamed to to i don't know, your laptop or your phone or whatever. So actually, the game is executed somewhere else, but you will see the UI or the video or the streaming in your laptop itself or whatever device you are using.

So we can see this, for example, is a very compelling thing for web assembling, but not just in this case. You can start thinking on running things the localized of like, where are you at right now? And the cool thing is this binary can be shipped very easily to the remote place where it will be executed. So I believe that's also going to be big. And we are seeing kind of like a lot of pushing from the industry towards that. This episode is brought to you by O'Reilly Open Source Conference

in Portland, Oregon, July 15th through 18th. We'll be there, by the way. As you know, OSCON has been ground zero for the open source community for 20 years. And this year,

they're expanding to become a software development conference because in 2019, software development is open source. At OzCon, you get to see what's shaping the future of software development. The program covers everything from open source, AI, infrastructure, blockchain, edge computing, architecture, and emerging languages. Hear from industry leaders like Holden Caro, Rupa Dhatri, Julian Simon, and Allison McCulley. Learn more and register

at oscon.com slash changelog. Prices start at just $925 when you register before April 19th. After that, the price is going to go up. Plus, you can use our code

changelog20 to get 20% off your bronze, silver, or gold passes. Once again, our code is changANGELOG20 and head to oscon.com slash changelog to learn more and register.

So the way we got connected with you was through Joseph Jax. Go back to the show we did with him. Jerry, what's the number of that show, by the way? Look that up for me real quick. He introduced us to you, I'm assuming, because of his interest in the funding of future open source, commercial open source companies and things like that. He has a generous interest in you.

I'm curious what the backstory is to that so how i got connected to uh with joseph was basically like when i started pitching the idea to investors like almost all investors were looking like with candy eyes to the product so then i knew like i have like something something big between hands so at that moment i started researching into what kind of investor I want to bring on board and how they can help us. So at that moment I started looking into Oasis Capital, which was the firm that Joseph was directing. Basically they are a VC firm that is completely focused on open source projects because they believe on the long term open source is going to win.

It's going to win regarding companies using it, regarding how right now almost a lot of open source projects are able to monetize or to have value from the industry. And the thesis is actually open source is going to be big. We are going to have a lot of interest

on the industry on monetizing or to spending money on on 13 tooling um and as long as uh basically we create a powerful platform uh then like probably like the company eventually will be able to capture certain uh percentage of of that value that generated maybe a five percent or a two percent but a 2% of a market that is gigantic can be like super, super big. Sure. Getting there is the hard part though, right?

I mean, you got to put the work in, not just you, but others. And it is open source. That means you tend to come in free or funded if in the case of commercial open source. What's your state now? Are you working somewhere? Do you freelance?

How do you and your team make money? so right now we are not making money right now our goal uh for this stage is just trying to get adoption trying to improve web assembly trying to basically like make uh the barrier for introducing people or developers to web assembly much lower and make them like tools so they can use webAssembly in a very easy way. On the long term, how we will make money will be more on the decentralized computing platform or just kind of like we can call edge computing. So that's how we'll make money. But that's not something that we are focusing on right now. We are a team of six engineers. The cool thing, fun fact, before working as CEO of Wasmere, I was CTO at try.com. And in there, it was so hard to find good

developers. We were in the fashion industry and developers in general are not interested about fashion. But on Wasmere instead instead i got much more reach from people that were interested into working in this area so the cool thing is it was very easy to get people that are very passionate into web assembly and trying to attract them it was actually like a not not very challenging thing i guess because like people can come foresee like what web assembly will be in the future and they want to be part of that so is it safe to say that this discussion we've been having we've just discussed in the last section how we're seeing a potentially bright future of universal binaries and libraries and this beautiful world that could potentially take over the electrons the homebrews or the app gets

whatever that between now and then you and your team are sacrificing and investing into a long-term future. And I think that's one interesting area of open source. It's kind of, you know, obviously open source is free, but you've got to somehow sustain yourselves until that day comes, right? Yeah, which can be tricky. But the cool thing is if we are aligned with the investors into how you're going to approach the space, how you're going to eventually monetize it, if you are aligned with them, then you should be in a good place. So there are certain industries like Uber that takes longer, or Lyft,

that takes longer to monetize. But once you do, you will be in a very good spot. So I guess it's just a matter of trying to pitch the right idea and trying to get the right investors on board. So has the idea been pitched then? Do you have investors on board? What's the state? Yeah, so we pitch to a few investors. In general, everyone is very interested.

We got some cautious investors which are not sure yet if WebAssembly is going to take off or how it's going to take off. And they wanted to stay a little bit more cautious about that. But in general, like we are in a good place regarding investment and we are more on the side of like deciding who want to bring on board and what they are going to bring. Either if it's networking or knowledge or what they are going to bring. And based on that, we are choosing that.

By the way, that episode number that I could not get and I gapped. Thanks, Jared. Episode 320, Venture Capital Meets Commercial Open Source Software with Joseph Jaxx. Great conversation. We kind of went through the growing landscape of commercial open source, in particular, this spreadsheet that he created of $100 million plus revenue companies, 13 years in the making. Seems to just now be getting some serious attention kind of ask the question of like why open source now and it kind of makes sense because hey you know this last year we had so many billion dollar acquisitions in the open source space it makes

sense why there's so much more people uh you know you know coming i'm curious though because when the herds form people get slaughtered hopefully that doesn't happen here i don't you know when the herds form people get slaughtered hopefully that doesn't happen here i don't you know what i'm saying when the herds form people get slaughtered well you start to follow if you're leading you know you get ahead if you're following then that's when in terms of say blue ocean or red ocean for example blue ocean means that uh you know the landscape is open water to be had whatever uh when you got a red ocean that means there's lots of people feeding off of what's there in terms of this metaphor that's that's out there around blue ocean and red ocean is that you got some blood in the water so once more and more people come

into a blue ocean it gets red yes completely and the cool thing or like i think like as a business like what you are trying to do is trying to to get as much stake of that as you can. So when people are trying to come in, you will already have a very good position so you can remain stronger. So that's one of the attractives of WebAssembly. It's starting to take off. It's still early. But we will start seeing more companies and more companies approaching this space.

We'll see how the ecosystem basically improves and matures. And from that, the companies that are there from the start probably will be in a very good place. One thing I'd like to revisit is you talking about this package manager that you're excited to be releasing. And that there's a WAPM installer,apom install or whatever it is and you know you download sqlite.wasm from a repository is this an attempt of becoming you know the npm for web assembly because i think npm would like to be the npm for web assembly yes i mean npm is actually

like trying to to be the the package manager forsembly, but the truth is NPM is designed with JavaScript in mind. The way packages work in NPM is very different into how we think it should work with WebAssembly. So we are designing a package manager from the ground up designed explicitly for WebAssembly. That means what kind of ABI you want to use for your WebAssembly module, how they are going to interoperate.

So because of that, we believe we cannot reuse a package manager that already exists, and we need to create something that is completely tailored to the WebAssembly needs. Plus, we don't need Node JavaScript, Node, yes. And basically, we want to make this package manager friendly for people that, I don't know, want to use a package from Python or want to use a package from Rust or from PHP without the need for them to have to install Node JavaScript on their servers. So will this be a centralized service

or are you thinking decentralized? We were talking decentralized during the break, so I'm just curious what the plans are if this will be a centralized repository. So the registry will be centralized, the main one, but the cool thing is you will be able to plug into any registry that you want. And another cool thing that we are

investigating is actually to move packages to be stored in a decentralized manner, so you actually not depend on any explicit registry. But news to come on that a little bit later, probably in a month or so. Do we have an official name for this package manager?

Yes. Maybe a website since it's coming soon? Yes. It's going to be wapom.io, Wapom as WebAssembly Package Manager. And yeah, the logo is also super cool. It's going to be, I believe the community is going to take it with a lot of attention, and I think it's going to be really great

for developers that want to start using WebAssembly or publishing WebAssembly modules from Rust or from C or whatever. And they want to create these universal libraries that can be used across anywhere. Dream a little bit for us. Pin us a picture. Take us a couple of years in advance. Everything you're talking about works out great. WebAssembly continues to rise and shine.

Edge devices, Fastly, all these people that are really into this edge computing stuff, what you've built is amazing. What's that future like? So I believe in general, what we will start seeing is more applications or more libraries compared to WebAssembly. And we'll start using WebAssembly

as the main way of running things, either locally or remotely. And I think in the future, we'll start using WebAssembly as the main way of running things, either locally or remotely. And I think in the future, we'll start seeing maybe the next generation of a browser where we actually don't depend on HTML or JavaScript, and maybe the UI is a little bit different. Or maybe an operating system where your programs are actually downloaded from the cloud

and executed securely in their own Windows, but at a native performance of a native way so i foresee like we'll start using like web assembly much more for these use cases on the on the long term and we want to be there to be to be the provider or to be the platform that empowers that what about the community getting involved is there is there any inroads for i know you got a spectrum.f, what is it? What is spectrum? Is it spectrum.fm or is it something else? Dot chat, isn't it?

Dot chat. Yeah, dot chat. Yes, so we got like a spectrum.chat where we are talking with the community. I think the URL is wasmere.spectrum.chat if anyone wants to enter. That's one way we communicate. The other thing that we will start doing

is start being more involved, created into the WebAssembly specification itself to help to shape it for the future. But in general, all these things, how we... Because we are also users of our own libraries and our own... Basically, what we ship, we use it internally. Because of that, it helps us to shape it in a way

that actually like will feel like a lot of different scenarios and the way we approach this we create a prototype and from there like we gather information from the community to see if basically the signs that we are doing are matches like different scenarios that i think we should cover and from that like it's just a conversation i'm trying to see like to design something that like will fit a lot of use cases on the long term. You want to give any shout outs to anybody that's been on your team that's really done some amazing stuff.

It sounds like you got a pretty solid team going on there. Maybe even some dream collaborations, you know, other organizations really digging into WebAssembly that you want to give a shout out to or say, hey, reach out and talk to us. So regarding my team, like I got like very, very lucky.

Everyone in my team is super talented. They know they are much more expert on compilers or regarding memory utilization than actually I've ever been. I'm super happy about every one of them. I will name them just because probably they will make them happy.

Blackland, McKenzie, Ivan, Brandon, Steve, who is no longer with us, but he was also very key for us. Hey, Yang, Mark, and then a lot of other people that have been contributing on the outside. In general, a lot of companies have been reaching and using it. So one of those is Near Protocol. That was one of the first companies adopting our runtime. Right now, we have other edge computing platforms

that are going to use our runtime as well, which is awesome. So basically, if you know any use case for the listener, if you know any use case where you think WebAssembly can be compelling for you and you are not sure yet how to approach that space, feel free to send me an email at cyrus at wasmer.io.

Cyrus, I spell S-Y-R-U-S at wasmer.io. And I will be super happy to see how we can use the power of WebAssembly to fit the needs that you have. Very cool. Well, Cyrus, thank you very much for your time today.

Thanks for sharing what you're doing and super cool to see what's happening here. I don't know. At some point, bailing homebrew? That would be a shame, right, Jerry? That would be a sad future, but maybe a happy future. Who knows, right? We'll wait and see. Yeah. Maybe we're going to start having like homebrew in Windows in the future

itself. Or maybe like on phones. So I feel like that would be like something super interesting. When I say homebrew, Windows in the future itself. Or maybe on phones. So I feel like that would be something super interesting. When I say homebrew, I really mean the WebAssembly package manager. Gotcha. Well, thanks again for your time. It's been an awesome conversation. Thank you so much. Thank you. I really

enjoyed our conversation as well. Alright, thank you for tuning in to this episode of the ChangeLog. Hey, guess what? We have discussions on every single episode now. So head to changelog.com and discuss this episode. And if you want to help us grow this show, reach more listeners and influence more developers, do us a favor and give us a rating or review in iTunes or Apple podcasts. If you use Overcast, give us a star.

If you tweet, tweet a link. If you make lists of your favorite podcasts, include us in it. And of course, thank you to our sponsors, DigitalOcean, GoCD, and also OzCon. Remember, use ChangeLog20 to save 20% off your pass. Also, thanks to Fastly, our

bandwidth partner, Rollbar, our monitoring service, and Linode, our cloud server of choice. This episode is hosted by myself, Adam Stachowiak, and Jared Santo, and our music is done by Breakmaster Cylinder. If you want to hear more episodes like this, subscribe to our master feed at changelog.com slash master, or go into your podcast app and search for Changelog Master. You'll find it.

Thank you for tuning in this Master. You'll find it. Thank you for tuning in this week. We'll see you again soon. Winner, winner, chicken dinner. You are today's winner because you stuck in here all the way to the end of the show. Here's another preview of our upcoming show called Brain Science. This podcast is for the curious. We explore the inner workings of the human brain to understand behavior change,

habit formation, mental health, and the complexities of the human condition. It's hosted by myself, Adam Stachowiak, and my good friend, Muriel Reese, a doctor in clinical psychology. It's about brain science applied, not just how the brain works, but how we apply what we know about the brain to better our lives. There you go. One of the things that's fundamental, I would say, to being human is change, right? And so sometimes people come in and are really key in our life for a period of time, and then things change. Either we grow or they grow or they change in a different direction. And then the relationship changes or that feedback loop gets modified in some way. That isn't always a bad thing. It's just going, my sense of choice

actually is a critical component when it comes to feeling good about my life. If I feel like everything is sort of outside of me. And I don't have any charge over it. Like I didn't choose to work in a more remote location. Or I didn't choose to go to school. Or I didn't choose this person. Then it feels far more oppressive. As opposed to I actually participated in the outcome.

That I'm actually experiencing. So I then also have more charge over whether or not I want to change it. I think this feedback loop process that we're talking about here is super common to developers, from people who write code to people who plan and to engineer

and to manage and lead. There's no one in the software process that doesn't understand the feedback loop. And the reason, the reason why is because in product development, they have this concept of agile and basically it means you produce something, you put it out there and you expect the feedback loop to happen in order to gain insights and course correction to then release another version of it that continually and iteratively becomes more and more improved.

So this whole process in day-to-day work in software is normal. And I think it's interesting how it can apply to their lives and people's lives, you know, to take the same importance of a feedback loop, for example, and apply it. Right. Well, so this is very much how it goes in relationship, which is why there is an importance when it comes to sort of things resonating. You ever walk into a room or an interaction with a couple other people and like something just feels wonky or off? You're like, I can't put my finger on it. Definitely been there. Right. Well, and so to be able to identify that in relationships and even go, wow, I need to, I'm experiencing this person in my world with the limited interactions that I have with them. It hasn't really resonated with me. And so I don't

get good feedback. So now I'm going to be more defensive because I feel as though there's a threat. It doesn't necessarily mean the person is threatening. However, my brain is going to tell me, hey, we need to be more protective. We need to do some strategies so that you're not fully exposed. You know, one way I look at scenarios like this, I would say as of late, is because if you've ever watched a TV show or a movie where the narration, the storytelling part of it, they expose a character in a certain light. And you may dislike that. They may be a villain or villainess. Right.

Sure. But the moment they turn the story to their backstory and why they are the way they are or why they're acting the way they're acting yeah you then kind of fall in love with them you're almost rooting for them right i feel like that's the same thing that happens day to day to our lives is that you know there are people who seem villainous or not for us but we don't understand their backstory and why they are the way they are for us to have and employ that empathy that's required to have this dance, as you say, this iteration of relationship. You know, we just assume they are who they are and we project, you know, our worst fears onto them and they become true. Yes, you know, a face, I don't really get to engage with people in the same sort

of humanness that we are all in. And so you're exactly right. I mean, over and over and over again, because you can identify and go, oh, that's why they're harsh. Or, you know, I recently had an interaction I had shared with someone that I was a competitive gymnastics coach for a number of years. And so somebody thought that my response to them when they were really struggling was kind of harsh, but they remembered that I had told them I was a coach for so long and they're like, oh, this is just another side of her coming out. Right. And I'm not sure I prefer it, but I get it. And then it switched for their reaction. Because then they're like, oh, wait, we're on the same team.

She's not trying to, like, oppress me or fight back against me. She actually is helping me, trying to get me to where I want to go. That's a preview of Brain Science. If you love where we're going with this, send us an email to get on the list to be notified the very moment this show gets released. Email us at editors at changelog.com. In the subject line, put in all caps, Brain Science with a couple bangs if you're really excited. You can also subscribe to our master feed to get all of our shows in one single feed at the changelog.com slash master or search in your podcast app for change all master. You'll find it subscribe, get all of our shows and even those that only

hit the master feed again, changelog.com slash master. I want to be remembered for my gourmet line of frozen seafood dinners.