Deno business model

#1

Some information on the Deno license/business model in a Changelog podcast:

Ryan Dahl Says

Ryan Dahl

Everybody’s trying to figure out open source companies and how to do this properly… And one model of doing this is the open core model, where your open source software would be free, but then you’d kind of have an enterprise edition that you add on some extra nice features, and you would charge for that.

You can also get into some licensing trickery, where maybe you make your software AGPL-licensed, and kind of allow people to run this locally, or kind of in non-commercial applications for free… But once you get into the commercial realm of things, you are then asked to pay a fee.

I think for Deno - this is a programming system that we’re asking people to program against. We’re asking a lot of our users, we’re asking them to invest a lot in the system… And I personally would be very, very uncomfortable with programming using the base layer of my – you know, Deno sits below all of your other software; I would feel very uncomfortable if there was some weird payment hook at that layer of the system. It would prevent me from ever even trying out the software, in fact… And I think that’s the case with Deno. If we tried to make Deno itself commercial, and people are looking at Python, and Node, and Ruby as alternatives, I think many would choose the solutions to this problem that do not have a payment hook in it.

[01:00:11.01] We are pursuing a different funding/revenue model. As I said, we think this software is pretty useful, and we think it’s useful in different commercial applications. I haven’t mentioned it yet, but Deno - you download it as this one executable, but it’s actually a collection of software, and we’ve been pretty careful in breaking this up into different bits that we can recombine in different ways… So we have a product that we’ve been working on for the last six months or so that is a different runtime. It is called Deno Deploy, and it has a very similar API to Deno, a very web browsery API. It’s a JavaScript runtime, but it doesn’t run on your computer, it runs in the cloud. You can think of it as a dynamic CDN if you want to… So we have processes running in 22 locations around the world, and we have an Anycast IP, and you can provision a domain name on our system. When you go to access your domain name, it resolves to this Anycast IP, and that gets routed to the nearest data center. So if you’re in Tokyo, it gets served locally in Tokyo.

And rather than a CDN which responds with static content, this invokes a JavaScript hook. It is a serverless system, so think AWS Lambda, or Cloudflare workers… So it’s a system for responding to requests dynamically. The best way to describe it is it’s a web server, a multi-tenant web server with V8 built into it. It is completely a separate system, and this thing AWS cannot – this is not open source; this is proprietary code.

1 Like
#2

Interesting.

Maybe I’m reading too deeply here, but I see him mixing messages in that third paragraph. Are we not going to pay for a programming language because of something peculiar to programming languages, as a “base layer”? Or are we not going to pay for a programming language because there are lots of free alternatives out there? Competition is a fact. Is “base layer anxiety” as real? Or is it a rationalization for language developers who don’t find people ready and willing to pay?

I guess I’m still a “Node guy”. And I’ve definitely tried Deno. Without meaning to put anybody’s work down, my honest assessment was that even trading free-for-free, there wasn’t enough there to justify switching from Node. It’s a refinement and a different set of opinions, but the delta is small. That impression’s only been reinforced as Node has moved on ES Modules and Deno lost the fire for TypeScript.

I hope the hosted-service model works out for them. Vercel and other companies seem to be having success offering that kind of development experience. But for me, selfishly, the real question is whether that model might succeed enough so they have the resources and gall to really do interesting, breakaway work. Could that engine power something compelling, in a way it hasn’t to date?

It’s my overall view that programming language development is, first, a lot of work, but second, really pretty stagnant, conceptually. We see a lot of new languages as master’s and doctor’s level work, mostly to showcase One Quirky New Idea. We see the state of the art advancing on efficiency, in the sense of how fast the code runs once written. But even academia has seen the rise of dominant languages like Haskell, which is more than thirty years old.

Java is 26. Python is 30. Ruby is 27. A lot of new, “exciting” work is “porting” existing features of one old language to another.

I suspect there are several reasons for this. One is the specialization of the work. Not everybody is an interpreter or compiler hacker, or wants to be. Another is how often languages get written by successful hackers later in their careers, rather than in the young-and-hungry stage. Perhaps another is the unwillingness of programmers to pay for good work on programming languages.

I for one have notebooks full of language ideas and frustrations I’ve piled up over the years. I’d love to find a peer or group of peers online really taking pages out of those books and trying to make big leaps, charging for perpetual licenses to successive versions of the outcome, with a strong focus on getting the most out of dedicated early adopters, rather than growing the largest herd possible. Take my money!

#3

From my perspective, I think there are interesting new languages, specifically Go, Rust, and Elm. Go is an improvement and Rust may be as well, although I’ve not used it much yet. Go and Elm have a lot of the same values (simplicity, excellent tooling). Elm was developed by a young person, and Go came from old Unix/C guys at Google. Go is funded by Google, Rust was funded by Mozilla, but now seems to have a broad industry base behind it, much like the Linux kernel. Elm has not had any significant funding behind it, other than various organizations paying the salary of the developer at various times. With Go, Google calls all the shots. With Elm, Evan makes all the core decisions. Rust seems to have a more democratic process where anyone can participate. All three models are working and delivering nice results. I don’t have an opinion on Deno yet, but it does seem it will be a difficult sell when its only an incremental improvement. Hopefully, they find a model that works. Developers are getting tired of the NPM treadmill where anything you do brings in a truckload of bloated dependencies – especially for edge/embedded devices.

Here is another discussion on funding for language developers:

Evan is deep thinker on all this, so may be someone to connect with if you have not already.

What I get out of all this is there is very little consistency in the development models, funding, motivations, and priorities of developers. It will be nice to have better models/mechanisms for software funding and should continue working on these, but I don’t think we’ll ever find a one-size-fits-all model.

#4

Thanks for the video link! I haven’t watched it yet, but I had a good chuckle at the first few seconds. I’m sure they paid Top Dog to license that DNA clip! :stuck_out_tongue_winking_eye:

#5

I’m the kind of young-and-hungry language dev pursuing truly innovative and important work that you’d like to see.

Hopefully I’ll manage to carve out a space in the industry, and not die trying.

1 Like