🎂 Open Sourcing the Workers Runtime

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. I said one of my favorites, 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. To date. Right. You're 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 Red Monk. And the first thing I'm going to have you do, Steve, is just introduce Red Monk. Why you guys started the company. What it does. Sure. Yeah. So Red Monk is a developer focused industry analyst, firm. So basically, we do industry analysts and research. You know, we look at what developers are using, why are they using it and so on. But we are primarily oriented towards that practitioner. It could be developer, DBA, sysadmin, operator or you name it. But yeah, we're just try and understand what you folks are doing and 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 want to ask you just some, you've been thinking about open source for a long time, and I think there are 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 put 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 to open source something, but then you're confronted with this choice of license or range of licenses. Each comes with various trade offs in terms of permissiveness. And how should organizations and developers think about these choices when building or contributing to open source? Sure. So, 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 typified by Apache MIT. Etc. Which is commonly referred to as permissive license. And the reason 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 have to reproduce the license 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 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 the you know, the GPL or licenses like that, which typically say if you sort of use this and if you distribute it, then you have to distribute any of your changes, fixes, improvements, etc. under exactly the same terms. And so, in other words, your responsibilities as an end user are materially different depending on which license you're using. There's also a 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. From the perspective of an enterprise looking to open source a given asset, you know, the questions for you are, Okay, 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 it is the way that I've always put it is that not being a 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, 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 sort of a sort of trying to quote unquote, protect themselves from, you know, typically hyperscale cloud providers. They don't want somebody else to come in and use these assets to make money effectively. They themselves believe. They believe that they sort of deserve and could make. So it's like, you know, at the end of the day, if you own the copyright for an asset, whether you are an individual who just wrote the code yourself or whether you're a company, you get to decide the license. Right. Those licenses, in my view, are less than ideal 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 whoever I want and they can. In fact, they have to be aware of a different set of responsibilities. And in a lot of cases, the open source license is 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 when does this apply and what is it not? And for a lot of these new licenses that doesn't exist, there isn't that consensus. There's sort of a 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 a in my view, a less than ideal trend within the industry. All right. I see that makes a lot of sense. So from 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 in business risk is a new license not tried and true, not tested, really not widely used in a way that's like feels like something you would want to bet your business on. Yeah. And, you know, there's there's just basic practical concerns as well. Right. So in other words, 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 have Apache MIT, you know, BSD, typically on the permissive side, you have 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 Linux sort of running GPL or whatever, these other permissive license assets. And now with these new licenses, every company has got a different one, right? So it's like, hey, there's the license for Company A and A license for Company B and license for Company C and A 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 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. You realize it has impacts on enterprise as well. Yeah, procedurally, yeah, that makes a lot of sense. Also. So let's say a developer was building their back end 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 and when making a selection on that side? Well, let me let me let me put that actually back to you. So 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 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, a 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 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, yeah. So I think at least from my end, if you're if you were, you know, sort of looking at open source 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 sort of taking this asset in and using it. You know, 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 what are the distributions here? What am I consuming? Are these things compatible or 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. Yeah. Yeah, 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 with 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 right in open sourcing the Workers runtime because ultimately it gives JavaScript developers flexibility to execute code across the runtime, migrate from one runtime to the other. And again, it's, 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, but you must correct your system. So when we think about these competitive runtimes and or 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, you know, I think for the most part, standards are standards are very, very useful tool in the industry. They do come with tradeoffs. Right, in the sense that they can throttle the development velocity. Right. And because if you have to get let me just think about it in pure, pure terms. If you are just making your own decisions versus if you're making decisions that have to be agreed on with a bunch of other people, that second process is going to take longer. Right. But as I said before, I think one of the standards can be can be more difficult and more problematic early in a market's development. Right. So in other words, when you're just getting going, when you're just establishing a market, using standards can be as I say, it can sort of pump the brakes in the market a little too much. You know, 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. Right. We don't that's velocity is not a problem within that space at this point. So the primary trade off, your primary concern when you go this route is, at least to my mind, not a particular concern. So really anything that could 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 Bun. How should developers think about new entrants in the space? And it's always because I've seen a variety of takes on both. Right, in the sense that, you know, to me, this is kind of where interoperability comes in, where it's like, okay, if I don't really 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. Right. Because the 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 is it takes very unpredictable twists and turns and things that you think are going to be successful or not. So, for example, in the case of bond, like, 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 know, you should kick the tires on it. But like I said, I mean, I think the ultimately what tends to happen over time is that, you know, people tend to be over impressed by the 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 is it's always it's always important to realize that, as we talked about in the JavaScript world, there is 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 place bets. That makes a lot of sense. And besides the runtime itself, how should you think about short runtime optionality there versus where you actually host that runtime and who has the management responsibility, I guess, in that decision making? Is it really are those different decisions or should people be thinking about them together? Yeah. Yeah, you should you should be thinking about them together because in the sense that we get asked too often about a technology like Kubernetes, for example. Right? We get asked often about, hey, you know, people are using Kubernetes on various platforms to ensure portability, but they don't actually move between platforms. And, you know, my answer has always been like, it's all about right or wrong. The psychology that is very important, you know, 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 offer that optionality, but somebody will manage it for them. They'll walk in that door every time. Right. But if you are choosing in a vacuum and you have sort of the option, it's always better to walk in the door that you have an option to walk out of. Right. That there's an exit from. So by all means, consider the management side of things, because the overwhelming trend of this industry and 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, 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 layer? 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 I think that completely, completely makes sense to me. Aside from new brand names 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 it's just the fragmentation has been the rule forever, right? It has been to the point where there was a churn. Remember how many years ago this was? It 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. That's how that's how sort of high the volume of new projects is. So that is still sort of rampant. We may see some standardization efforts begin to address that because if you have competing implementations along the same standard, fine. If I have to move from one runtime to another or 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 pretty consistently. And a lot of that is because people want the benefits of sort of being interoperable with the JavaScript ecosystem, but they want some additional type safety sort of at the same time. So that's another piece. But then a lot of it is going to come down to the managed services, right, how these play out because that ultimately where are you going to host these applications and more 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, 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 than 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 we're making here today, we're open sourcing the Workers runtime to do exactly what we've just been talking about. Right. The first reason is to allow people to have that door they can walk 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 a as an application platform for them. The other piece is around global 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 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 get back. We were built on open source foundations with VA isolates, right. And we want to give back to that community that served us so well. So just want to ask you some questions now about do you think companies ever get open source wrong? And if they do like their open source strategy, where do they get it wrong? like. I mean, we could be here for some 4 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 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 peers and so on. And then they'll just sit there and they haven't the 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 know there are other companies that will. Use sort of open source as a as an attempt to essentially get free labor, which is like, oh, this is costing me too much, I'm going to open source this. And people would just come along and sort of fix it, run it for me. It's like, No, no, this is 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, is that there are an infinite number of resources that are 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 this may not have gone perfectly, but you can correct it and here's how. So the key is is 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 just be open to feedback in terms of, hey, this wasn't you know, 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 product. Maybe, 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 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 so MySQL famously has 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 my scale there. 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 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 will kill sort of 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 obviously, where is the source code itself, but what's your issue tracker? Are there forums associated with it? So there's 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, 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 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 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 runtime coming up, solving longstanding problems. But to that effect, what problems are these new entrants focused on solving? Like why are people dissatisfied with running code on Node in some cases? It really varies. Like the one I've heard the most and this is particular to bond is is been wants us to be faster. It's really just a velocity based argument. In some cases, I mean, obviously in years past, we've seen Node itself forked at one point. Right. So there were sort of obviously issues around project governance and direction and all of that. Some of it is sort of trying to be sort of more discrete and sort of more normal sized, if you will, because Node has become, to its credit, a phenomenon unto itself and is this huge thing. And so that's why I think in many cases, the responses to it are smaller, stripped down, much more focused in terms of what they're trying to do. So, yeah, there's a bunch of different sort of directions people are taking to respond to different opportunities. But like I said, the one that I hear the most these recently is just sort of raw velocity. That's why like, hey, this is this is really cool. It's not quite there, but this is the one that we're focusing our time and attention on. That makes sense. And is that philosophy typically in terms of execution time overall or like startup times or is that focused anywhere in particular? And is it just speed? And it can be both. I mean, a lot of times it's just raw execution time, right? That's a lot of the benchmarking that you'll see. You know, certainly latency is an issue depending on the nature of the the architecture you're building out. Right. For example, in function is the service architecture is latency is usually critical because you have something sitting cold and idle. How quickly it fires up is, Hey, that matters a lot, right? So that's an area 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 has been servicing for at least the past couple of years at least. Millions of requests per second. Millions of requests per second flowing through this runtime. The reason why I am most excited about this announcement is because we've 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 running a significant portion of the Internet for a while now. Right. And I am excited to see how folks like use this projects, 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 was the CEO of MySQL for many years, used to say that there are a lot of the the open source companies that were born as open source. Right. Were developing things on their front lawn, which people tend to keep sort of mowed and 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 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 at versus 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, I think the one thing that I would hope that all the sort of open source communities, particularly runtimes, are thinking about is what's the experience of using them like? Right. Because I think there's a tendency for, for products across every category, right, to focus on speeds and feeds and performance and scalability and all those fun things which are important of course. But there is commensurately less attention paid in many cases to more prosaic concerns. Like what's the documentation like, right? How easy is this to stand up and instantiate? And what are the options? If I'm a developer who doesn't want to geek out on this, it 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, and 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 sort of technologies, you know, whether they're, they're open source projects or 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.