Originally aired on May 25 @ 2:00 PM - 2:30 PM EDT
Cloudflare has open sourced workerd, the JavaScript/Wasm runtime based on the same code that powers Cloudflare Workers! Tune in for a conversation featuring Stephen O'Grady, Principal Analyst and Co-founder, RedMonk, and Aly Cabral, VP of Product, Developer Platform at Cloudflare, as they discuss the news — and what it means for developers.
Read the blog post:
Visit the Birthday Week Hub for every announcement and CFTV episode — check back all week for more!
Well, thank you guys for all joining us today. Today, we're going to be talking about one of my favorite announcements across both GA Week and Birthday Week. You know, I said one of my favorite, but I'm going to edit that and say my favorite announcement, and that is us open sourcing the workers' runtime. Very excited about it. Till date, right, you were only able to run this runtime on Cloudflare. Now you can run it anywhere. Very powerful thing. I'm Aly Cabral. I run our product team as VP of product for our developer platform here at Cloudflare. So that includes workers, R2, pages, all of that good stuff that application developers can take and build on Cloudflare end to end. And I'm joined today with Steve O'Grady, a principal analyst and co-founder of RedMonk. And the first thing I'm going to have you do, Steve, is just introduce RedMonk, why you guys started the company, what it does. Sure. Yeah. So RedMonk is a developer-focused industry analyst firm. So basically we do industry analyst and research. You know, we look at what developers are using, why they're using it and so on. But we are primarily oriented towards that practitioner, right? Could be developer, DBA, you know, sysadmin operator, you name it. But yeah, we're just trying to understand what you folks are doing and, you know, provide information that is useful to that audience. Perfect. And I always find your advice and feedback incredibly valuable to us here at Cloudflare. Now, I wanted to ask you just some, you've been thinking about open source for a long time, and I think there's some relevant questions that anybody listening to this might have and certainly questions that we had to ask ourselves. And I'd love to kind of pose some of those here to you today. So first things first, there are a host of different license types available for open sourcing software. The first thing you have to do is decide open source of some kind, but then you're confronted with this choice of license range of licenses. Each comes with various trade-offs in terms of permissiveness and how shouldn't organizations and developers think about these choices when building or contributing to open source? Sure. So, you know, first of all, we'll start on the sort of user side, right? And you absolutely need to sort of understand the differences between different licenses because they come with different responsibilities. So in other words, there's a style of license, you know, typified by Apache, MIT, et cetera, which is commonly referred to as permissive license. And the reason, you know, it's called that is because they typically are very permissive. They don't require much in the way of responsibility. Typically it's, you know, you have to reproduce the license, you know, sort of, and in some cases there's patent grants associated, but basically it's kind of do what you want. So in most cases, you can take these permissive licenses and, you know, for example, you could bundle them up and sell them as a proprietary product, no problem. At the other end of the spectrum, you have reciprocal licenses. And basically this says, you know, the GPL or sort of licenses like that, which typically say, okay, if you, you know, sort of use this and if you distribute it, then you have to distribute any of your changes, fixes, improvements, et cetera, under exactly the same terms. And, you know, so in other words, your responsibilities as an end user are materially different depending on which license you're using. There's also a, you know, sort of emerging category of licenses, which are not open source, but are close. They come with different responsibilities. So yeah, it's incumbent on end users to understand, all right, which license am I using? Is it OSI approved and therefore an open source license? If so, what are my responsibilities and so on? You know, from the perspective of an enterprise, you know, looking to to open source a given asset, you know, the questions for you are, you know, okay, well, what are you trying to accomplish, right? Are you trying to just get this out in the world and maximize your distribution? Are you looking for contributions back? Licensing can play an impact on that. There's more to it. There's obviously governance and sort of how you run your project. But, you know, it is, the way that I've always put it is that, you know, not being a, you know, sort of a member of any one of these communities is that licenses are a tool. And like any other tool, you use them for different purposes. So if you're an enterprise, you just need to understand what is your purpose? What are you trying to do? That makes a lot of sense. And to your point around, they're not open source, but closed licenses that are becoming more prevalent in the industry. What are companies' motivations, I guess, for putting out those licenses? In most cases, it is, you know, sort of a, you know, sort of trying to quote, unquote, protect themselves, you know, from, you know, typically hyperscale cloud providers, right? You know, they don't want somebody else to come in and use these assets to make money effectively that they themselves believe, you know, that they believe that they sort of deserve and, you know, could make. So it's like, you know, at the end of the day, if you own the copyright for an asset, whether you're an individual who just wrote the code yourself, or whether you're a company, you get to decide the license, right? Those licenses, you know, in my view, are less than ideal, you know, because it begins to confuse people as far as what open source is. Because in many cases, they'll go on something like GitHub and see, oh, hey, I can see the source and so on, this is open source, I can use it however I want. And they can't. In fact, you know, they have to be aware of a different set of responsibilities. And, you know, in a lot of cases, the open source licenses have been around for decades. So we understand how they work. They haven't all been tested in court, but there's sort of consensus in terms of right, when does this apply? When is it not? And for a lot of these new licenses that doesn't exist, right? There isn't that consensus, there's been a sort of lack of understanding of exactly how they apply. So I could go on at length about those, I won't do that here. But yeah, they represent, in my view, a less than ideal trend within the industry. I see, that makes a lot of sense. So from like the user's perspective, like a developer's perspective, the licenses probably intentions are not to protect against whatever their usage is. But the complexity and business risk is a new license, not tried and true, not tested, really not like widely used in a way that like feels like something you would want to bet your business on. Yeah. And, you know, there's just basic practical concerns as well. Right. So in other words, you know, we have, you know, there's a huge number of open source licenses, but practically speaking, they're typically concentrated in a handful, right? You know, you have Apache, MIT, you know, BSD, typically on the permissive side, you have, you know, GPL. At one point, GPL was like north of two thirds of all licenses. Now it's sort of much more split, but we had a small number of licenses. So you'd see, for example, the average project might have, you know, Linux, you know, sort of, you know, running GPL or a number of these other, you know, permissively licensed assets. And now, you know, with these new licenses, every company has got a different one, right? So it's like, hey, there's the, you know, license for company A and license for company B and license for company C and license for company D. So the cost from an enterprise standpoint of evaluating all these new licenses goes up, right? Because it used to be, I can evaluate the GPL and look at, you know, basically, if I approve that, I approve thousands of projects at once, or I look at these other licenses and it's like, okay, I'm doing this once for one project. Like that's not really what we're looking for. So it's not, it's not just the sort of impact open source, it really has impacts on enterprise as well. Yeah, procedurally. Yeah, that makes a lot of sense. Awesome. So let's say a developer was, you know, building their backend application and they were looking to use a JavaScript runtime, right? What should they be thinking about in terms of like open source license or anything when making a selection on that side? Well, let me put that actually back to you. So, you know, you obviously are going through the process of open sourcing an asset. Like what was your thought process and sort of looking at the license and how you selected it? Yeah. So from our perspective, we wanted no friction for adoption or to minimize that friction as much as it was within our power to do. And the first thing that we started to have a conversation about is how do we get to a permissive license, right? And everybody on board to a permissive license. And ultimately we chose Apache, very permissive, very tried and true license in the open source community because we wanted and favor this runtime adoption. Now we have a lot of confidence on the Cloudflare side that we will be the best way and continue to be the best way to run that runtime. But we are completely happy to push forward the API for any use case in and outside of Cloudflare because ultimately, again, we think once you have a production ready application, we think Cloudflare's network is going to be the best place to run it. So that's the real strategy here. We're not threatened by the permissiveness of the license because we think it ultimately just helps push the API forward. Yeah. So I think, at least from my end, if you were looking at open sourcing JavaScript assets or frankly consuming them as well, again, it just comes back to what we talked about earlier. It comes back to what are you trying to do, right? And what are your concerns? Whether that is I'm open sourcing this asset or whether I'm taking this asset in and using it. The JavaScript world is very crowded. There's sort of an ever-multiplying number of projects. So frankly, one of the biggest issues is trying to figure out, all right, what are the distributions here? What am I consuming? Are these things compatible? Are they not? So yeah, it is a... Look, the technology world today is heavily fragmented and there's probably no better example of that than the JavaScript world. So licensing is... I wish I could say it'd be a simple exercise, but it's not likely to be, unfortunately. Yep. Yep. It is super fragmented. And actually speaking of that, earlier this year, we had introduced Cloudflare's initiative around working with Node and Deno on the web interoperability group, working group, community group, to really standardize JavaScript backend APIs across different runtimes, ultimately for the benefit of code portability across those runtimes. We think that goes hand in hand with the launch of today, in open sourcing the worker's runtime, because ultimately it gives JavaScript developers flexibility to execute code across the runtimes, migrate from one runtime to the other. And again, it's really all about being the best way to run that runtime versus being competitive at the API level, because we think most JavaScript developers are asking for kind of standardization across those runtimes and not for further fragmentation in the JavaScript ecosystem. So when we think about these competitive runtimes and working together on standards that make the JavaScript ecosystem a little bit more standardized, how do you think about that effort? What do you think ultimately is the impact on your developer building applications? Yeah. I think for the most part, standards are a very, very useful tool in the industry. They do come with trade-offs in the sense that they can throttle the development velocity. Because if you have to get, let me just think about it in pure terms, if you are just making your own decisions versus if you're making decisions that have to be agreed on by a bunch of other people, that second process is going to take longer. But as I said before, I think one of the standards can be more difficult and more problematic early in a market's development. So in other words, when you're just getting going, when you're just establishing a market, using standards can be, as I said, can sort of pump the brakes on the market a little too much. Look, the JavaScript market at this point is huge. And I think we're at the point where standards and interoperability are really much more at a premium than velocity. Velocity is not a problem within that space at this point. So the primary trade -off or your primary concern when you go this route is, at least to my mind, not a particular concern. So really anything that can be done to drive standardization, interoperability in that market in particular is probably a good thing. Yeah, yeah, no. And along that same vein of JavaScript community or JavaScript ecosystem evolving really quickly and has been for many, many, many years, in recent months, we've seen new JavaScript runtimes really come into the game. Notably, Deno and that bun. How should developers think about new entrants in this space? It's always good because I've seen a variety of takes on both in the sense that, to me, this is kind of where interoperability comes in, where it's like, OK, if we can get to a place where the standards and interfaces are interchangeable and I can sort of pick and choose, then it becomes easier. Because one of the things that I've learned in my years in this business is that it's very, very difficult to horse race technology. It takes very unpredictable twists and turns and things that you think are going to be successful or not. So for example, the case of bun, I've seen a lot of focus on sort of the speed, the raw velocity of a bun as a sort of justification for its use, which great. If you have a need for that, by all means, you should kick the tires on it. But like I said, I mean, I think ultimately what tends to happen over time is that people tend to be over-impressed by the technical characteristics of a given platform and undervalue the things that are not the technical characteristics that impact its adoption. So in that case, it's really too easy to say. There's a lot of interest in both. We're getting a lot of inquiries about both. But it's always important to realize that, as we talked about, in the JavaScript world, there's always going to be a shiny new thing that may or may not be the future. And you want to be cautious in terms of where you're placing bets. That makes a lot of sense. And besides the runtime itself, how should you think about, sure, runtime optionality there versus where you actually host that runtime and who has the management responsibility, I guess, in that decision making? Are those different decisions? Or should people be thinking about them together? Yeah. Yeah. You should be thinking about them together. Because in the sense that we get asked often about, take a technology like Kubernetes, for example. We get asked often about, hey, people are using Kubernetes on various platforms to ensure portability, but they don't actually move between platforms. And my answer has always been, it's all about, right or wrong, the psychology that is very important from a user standpoint in the sense that they want the optionality to move later. Now, the market has consistently also demonstrated that if they are not offered that optionality, but somebody will manage it for them, they'll walk in that door every time. But if you are choosing in a vacuum and you have the option, it's always better to walk in the door that you have an option to walk out of, that there's an exit from. So by all means, consider the management side of things. Because the overwhelming trend of this industry in category after category after category is, how do I take this operational responsibility and make it someone else's? I don't want to deal with it. I don't want to run it, you know, which is perfectly acceptable. And frankly, we do the same thing with all of our infrastructure. But you want to understand, what are my options going to be in terms of where I host this later? Am I tied to this vendor until the end of time? Or can I pick this up and move it somewhere else if I need to? Yeah, I think that completely makes sense to me. Aside from opening up, what trends do you see in the JavaScript community? Maybe specific to open source, but I also want to broaden that up for you, too. Yeah, I mean, JavaScript, like I said, is I think, you know, it's just the fragmentation has been the rule forever, right? It has been, you know, to the point where, you know, there was a, I'm trying to remember how many years ago this was, there was a high profile developer, most of you would know, who had basically said, I've lost all interest in being a web developer, because I can't keep up. You know, that's how that's how sort of high the volume of new projects is. You know, so that is, you know, still sort of rampant, you know, we may see some standardization efforts begin to address that, you know, because if you have competing implementations along the same standard, fine. If I have to move from one runtime to another to another, and everything breaks when I do so, then that's decidedly less fine. So that's one of the things that we're seeing, we're seeing an increased emphasis on safety, right? So the I can preview that TypeScript is going to make a move in our rankings, has moved up, you know, pretty consistently. And a lot of that is because people want the benefits of, you know, for being interoperable with the JavaScript ecosystem, but they want some some additional type safety, you know, sort of at the same time. So that's another piece. But then, you know, a lot of it is going to come down to the managed services, right, how these play out, because that ultimately, you know, where are you going to host these applications? And more importantly, who's going to run them is ultimately going to be the question, I think, for a lot of end users, because what we hear from developers over and over is, you know, as I said before, I don't want to run this, like who's going to run this for me. So to some degree, some of these decisions may be made less by who's got the better tech, then where is it easier for me to find a host? I think that I think that makes a lot of sense. And just to kind of reiterate some of the launch announcement that we're making here today, we're open sourcing the workers runtime to do exactly what we just been talking about, right? The first reason is to allow people to have that door they can log out of. Sure, they want to come in and they want to get all the benefits of hosting and managing on Cloudflare Workers directly. But if you need to walk away, you want that optionality, right? You don't want to feel like locked into an ecosystem or an API. And we need to, we need that as a table stakes, in order to be a developer platform, the ability for folks to have that optionality when they bet on us as an application platform for them. The other piece is around local development, right? We've heard loudly and proudly from many developers that they want the exact same API experience on their local machines when they're going and testing, evaluating products, like building their code. And we have this like edge development ecosystem. But even that, even like running in the colo closest to you from Cloudflare's perspective, not fast enough. People want that quick iterative code running directly on their machines. And then Cloudflare, we also are doubling down on our commitment both to the JavaScript community by investing in this web interoperable group, but also the open source. We want to give back. We were built on open source foundations with V8 isolates, right? And we want to give back to that community that served us so well. So just wanted to kind of ask you some questions now about, do you think companies ever get open sourced wrong? And if they do, like their open source strategy, where do they get it wrong? Like how do they get it wrong? Yeah, I mean, we could be here for several hours. The short answer is yes. There's any number of things that companies do wrong, right? One is they think, okay, I'll open source this asset and just sort of chuck it over the wall and it'll just take off and flower and be this vibrant new project. It's not how it works. Other companies will sort of open source it and not set expectations, right? So in other words, it's like, hey, here's this open source asset and developers think they can contribute and then they'll submit PRs and so on. Then they'll just sit there and a company hasn't said we will or won't take them. Here's the ones that we will take or we'll take anything or we will take them, but you have to sign copyright. So you have to sort of set the expectations in terms of front. There are other companies that will use sort of open source as an attempt to essentially get free labor, right? Which is like, oh, this is costing me too much. I'm going to open source this and people will just come along and sort of fix it and run it for me. It's like, no, no, that's very much not how this works. So yeah, I mean, the list could go on and on and on. There's lots and lots and lots of ways to get it wrong. But the important thing is that there are an infinite number of resources out there in terms of trying to help you get it right, right? And there are a lot of very patient people who will say, okay, hey, this may not have gone perfectly, but you can correct it and here's how. So the key is just sort of trying to get it right from the get-go, trying to think before you leap, as they say. But if you get it wrong, just be open to feedback in terms of, hey, this didn't meet the mark and here's what we can do to fix it. I think that brings up a great point around open sourcing. Yeah, half of the battle is the project, maybe less than half of the battle, but so much of the battle is building that community with the community you're serving. And what's the best way to build an open source community or a community around an open source project? Or what are some ways to do that? Yeah, yeah. So I think there's a number of different ways, right? So a lot of it depends on the project because there are companies that will open source an asset and they don't want to build a community, right? They just want it to be available in case somebody wants to look through the source code and so on, right? So MySQL famously as basically a model where they do all the development and have all along, right? Now, they have a tremendous community around it that has developed sort of by default because it's so popular, but there are companies much smaller than MySQL, they're just say, hey, here's an open source asset and we don't really care if there's a community. So that's not everybody's need or ambition, but to build one, like I said, there's a couple of things you need to do, which is one set expectations, right? In terms of, okay, here's what we'll accept, here are the rules for sort of acceptance. So setting those sort of ground rules, if you will, importantly codes of conduct are part of that, right? Here's what we expect from our contributors, because if there's nothing we'll kill, it's for contributions faster than sort of a bad actor who comes in and has no mechanism for being policed, right? So that's a huge problem. And then a lot of it is sort of awareness, visibility, how do you build that out? How do you get it in front of people so that they're aware of a given project? What are the resources that you provide for a project in terms of things like, okay, obviously, where is the source code itself, but what's your issue tracker, are there forums associated with it? So there's a lot of different things that go into open sourcing a project, but it is very much depends again on what is your ambition, right? What are you trying to build? Is this just a, I don't care, is it, I want to have the opportunity for people to tell me about bugs if they find them, or I want to build a vibrant community that involves lots of different parties, some of which may be competitors of mine competing on the same asset. Obviously, depending on sort of where you sit on that spectrum, you're going to do different things in terms of how you build your community. That makes a lot of sense. Going back to the JavaScript community for a bit, we talked about a bunch of new runtime entrants, right? JavaScript runtimes coming up, solving longstanding problems, but to that effect, what problems are these new entrants focused on solving? Like why are people dissatisfied with, you know, running code on node in some cases? It really varies. Like the one I've heard the most, and this is particular to Bunn, is speed, right? We want this to be faster. You know, it's really just a velocity-based argument. You know, in some cases, I mean, obviously in years past, we've seen, you know, node itself forked at one point, right? You know, so there were, you know, sort of the obvious issues around project governance and direction and all of that. You know, some of it is, you know, sort of, you know, trying to be sort of more discreet and sort of more normal sized, if you will, because node has become, you know, to its credit, a phenomenon unto itself, and it's this huge thing. And so that's why I think in many cases, you know, the responses to it are smaller, stripped down, you know, much more focused in terms of what they're trying to do. So, you know, there's a bunch of different sort of directions people are taking, you know, to respond to different opportunities. But like I said, the one that I hear the most, you know, at least recently is just sort of raw velocity, right? That's why like, hey, this is really cool. It's not quite there, but, you know, this is the one that, you know, we're focusing our time and attention on. That makes sense. And is that velocity typically in terms of like execution time overall, or like startup times, or is that focused anywhere in particular? And is it just speed in general? It can be both. I mean, a lot of times it's just raw execution time, right? You know, that's a lot of the benchmarking that you'll see. You know, certainly latency, you know, is an issue depending on, you know, the nature of the, you know, the architecture you're building out, right? You know, for example, in function as a service architectures, latency is hugely critical, because if you have something sitting cold and idle, how quickly it's, you know, fires up is, hey, that matters a lot, right? So that's an area, you know, that people are absolutely focusing on. But yeah, it's basically kind of across the board, at least from what we hear in terms of what people are asking about. That's great. So workers was actually developed over five years ago now. Crazy, crazy how time flies. And it has been servicing for at least the past couple of years, at least millions of requests per second, millions of requests per second going through this runtime. The reason why I am most excited about this announcement is because we really put it through the ringer, right? Yes, this might be a new open source project. But this is not a new project, right? And that's, that's one of the things that feels a little different than some of these other new JavaScript runtime entrants. It's like this, this is run a significant portion of the Internet for a while now. And I am excited to see how folks like use this project, take it, run with it. And, you know, surprise us even more with how they might want to use it. Yeah. And it's always interesting, open sourcing an existing asset, right? You know, because Martin, Martin Mikos, who is the CEO of MySQL for many years used to say that there are a lot of the open source companies that were born as open source, right? We're developing things on their front lawn, which people tend to keep sort of mode and sort of manicured and all that. Whereas a lot of the proprietary sort of assets were sort of created in the back lawn, the backyard. And that doesn't necessarily, you're not necessarily showing them off in the same way. So I would love to hear the story at some point of, you know, how it was to take some of those assets and make them open. Yes. Yes. I mean, it was a process, right? Detangling also some parts of the runtime that were very Cloudflare out versus like things that were generally applicable to anybody who would want to run this runtime. So I think significant amount of work it took us to get to get it here. Amazing. In our last couple of minutes here, any other closing remarks, comments, anything from you that you think we should touch on today around either open source or the workers runtime? No, I think for me, you know, I think the one thing that I would hope that all of these sort of open source communities, you know, particularly runtimes are thinking about is, you know, what's the experience of using them like, right? Because I think there's a tendency for products across every category, right? To focus on, you know, speeds and feeds and performance and scalability and all those fun things, which are important, of course. But, you know, there is commensurately less attention paid in many cases to, you know, more prosaic concerns like what's the documentation like, right? How easy is this to stand up and instantiate? And, you know, what are the options if I'm a developer who doesn't want to geek out on this and just wants to run it, right? What does that look like? So, yeah, I mean, as these sort of new options emerge and are bidding for developers' time and attention and ultimately workloads, you know, I think sort of the experience of what it's like using them and what it's like using them in conjunction with all the other different, you know, sort of technologies, you know, whether they're open source projects or, you know, as-a-service implementations, you know, what is it like to use all those together, I think is going to be critical. Thank you, Steve, so much for your time today. Not at all. My pleasure.
