Building in-person developer communities with Paul Butler from Drifting In Space

Paul Butler 0:00
We started feeling more comfortable about posting something in person. And I think there was, at least in New York, this hunger to meet people again, and it was kind of this blank slate.

Jack Bridger 0:09
Hi, everyone, you're listening to scanning dev tools, the show that investigates dev tools go from zero to one. I'm joined today by Paul Butler, who is the co founder of drifting in space, which is pushing the limits of browser technology, which is very vague way of saying that are doing some really cool stuff. And, Paul, do you want to tell us a bit about what that cool stuff is?

Paul Butler 0:32
Sure, yeah. And thanks for having me back. So the genesis of what we're trying to do is we've seen, you know, this movement of application software into the browser over the last decade plus, I guess, you kind of trace it back to database apps in the in the 2000s, and Google Docs and that kind of thing in that era. And over time, we've seen more and more advanced applications, being kind of shoved into the browser, things like 3d editing, video editing, CAD software, geographic, data manipulation, things like that. So what we're trying to do is address the pain points that come up when you're trying to run these applications that expect a heavyweight, maybe 32 gigabytes of memory 64 gigs of memory. And they're trying to kind of push that down to WebAssembly, where they get about four gigs in the best case scenario. So what we've kind of done is built a way for these browser based applications, to spin up what we think of as kind of a child process that runs on a remote machine, a server, and they get a low latency direct connection to that. They can send messages and split compute, really, between the two. We even have a way of doing remote rendering in that child process and then rendering that or sending that back as a compressed video back to the client and rendering it in inside the application as a React component. So we've really been going after these problems of these pain points that emerge when these heavyweight kind of industrial scale applications come into the browser.

Jack Bridger 2:09
Yeah, that's really cool. And so like, is it kind of, you know, you're democratizing the ability to build like the next figma? In a way like,

Paul Butler 2:19
yeah, we definitely took inspiration from figma architecture, they've been very generous in posting a lot of blog posts about what they done, which was really, I think, at the time pretty pioneering in their architecture. We've seen similar architectures in things like GitHub Code Spaces, and other places where they talked about it a little bit less, but I guess, because vs codes open source, you kind of get a sense of it. Where we were kind of extending it is sort of taking the underlying infrastructure that figma build, and then adding this high compute component. So if you want to make the scheduler aware of how much memory how much GPU capacity, CPU capacity each of these machines have, so that you could build an app that, for example, pulls down 10 gigabytes of data for each user. And obviously, you know, you can't do that at Facebook scale. But you can do that on the scale of an internal app at a company that deals with large data or an expensive SAS app or that kind of thing.

Jack Bridger 3:22
So you could actually be like, an even more powerful figma.

Paul Butler 3:26
Yeah, and maybe not, you know, I think vector graphics editing, there's, it's inherently a relatively computationally lightweight problem. So they can do do a lot where they just compile stuff to WebAssembly and do it in the browser. That makes a lot of sense for something like figma. It doesn't, it doesn't go all the way for something like a video editor or a 3d modeling tool, where you may have more computationally heavyweight stuff to do there.

Jack Bridger 3:56
Yeah. Okay. Yeah. So sorry, I'm still like digging in just to make sure. So like, you're saying that, like, if someone were to build like a video, like a seriously computational video editor, they could they could do that in the browser, if they're using plain? Yeah, that's the idea. Yeah. Very, very cool. And exciting. Yeah. And I liked the way you talked about it off offline that like, the expectation is that browser apps kind of have to be a lot further behind desktop desktop apps. And it seems like you're kind of bringing that kind of parity.

Paul Butler 4:38
Yeah, I think there's been this people have been excited about just being able to run stuff in the browser. And I think it just, it's a really low friction experience that you can, you know, open up a URL and be immersed in an application. And so I think for a while we've we've kind of put up with that type of application being janky and slow and less featureful And I think what we've seen lately and what we're going to see over the next few years as technologies like web GPU web transport, web codecs really take off is that that will change, there will be more of a competition for performance instead of just the table stakes running in the browser piece.

Jack Bridger 5:17
Yeah, that makes sense. And, and that kind of brings us on to the main topic that we're going to talk about today. Which is that you're kind of somewhere where you're kind of pushing the limits of like, what, what's possible. And you've built this community of an in person community, called the browser tech community.

Paul Butler 5:39
Yeah, we started as browser tech, New York. And now Now it's just browser tech, because we have one, and we did one in San Francisco as well. And we're actually looking at other cities too.

Jack Bridger 5:50
Amazing. And this is something that like, we're kind of, you know, especially after COVID, everything went online. It's like, you know, how many slack group communities that we all learn that actually like in person, I'm in a community in London, and it's just been incredible. And so I'd love to hear about, like, what it's been like to kind of organize that.

Paul Butler 6:11
Yeah, so. So we we started as a company, kind of early 2022. So we still, you know, people were still wearing masks, it was still in person events, were still kind of frowned upon. About, I guess it was August, we started feeling more comfortable about hosting something in person. And I think there is, at least in New York, this hunger to meet people again, and a lot of the previous the meetups, pre COVID meetups, that people were hosting kind of ended, that I think people just moved on, it's a lot of energy to organize these things. If they had corporate sponsorship, there's often changes turnover corporate in the company. So there's kind of harder to reboot that, that thing. So it was kind of this blank slate, where there weren't a lot of these recurring meetups happening in New York, at least. And we also felt like, were the where the browser browser based development community had kind of gone in. Over the last couple of years, during COVID, there was kind of this blank space where we're what we saw is kind of a bifurcation of web development, where on one hand, you have people, you know, building next Jas apps and Gatsby blogs and care about SEO and bundlers and that kind of thing. And then this other world of people who are more approaching application development, as desktop application developers would, you know, their code bases were rust that they're compiling to WebAssembly. And they're, in some cases, they were even avoiding the DOM and doing directed GPU rendering. And so you got these applications that were yes, they're running in the browser, but like, is the developers really identifying as web developers? They just happen to be deploying to the browser, because the browser is kind of the new operating system. So we kind of looked at it from this angle of if the browser is the new operating system. Where are the people developing for this operating system, developing applications and pushing the limits of this operating system meeting. And we found that the web development, traditional web development communities were not really that or if they were that they were kind of watered down by, you know, SEO and other things that were not relevant to those developers. So we were interested just because we wanted to be in the same room as them. We if this meetup existed, we would not have probably created it. But because we felt that there was a void there we started, started meeting with some folks, we initially just kind of invited, we looked at who was building these applications in New York, invited everybody out for tacos, and runway ml, who's building a video editor in the browser. When we asked them about it, they were like, Let's, you know, we could host this. So we basically just got a bunch of takeout tacos and had tacos with, with a number of other application developers in the city. And that was kind of when we realized that there was this core mass of people and that we should start doing kind of a more formal meetup with talks and things like that.

Jack Bridger 9:18
Yeah, sounds amazing. Could I ask you like, asked like, what kind of topics were people talking about?

Paul Butler 9:24
Yeah, so we had talks on things like, like high performance with React. We had a talk from runway actually, where, where the talk was sort of about creative ml tools in the browser. We've had a talk on scaling up duck DB in the browser. And one of the one of the coolest ones, I think, was a talk from WAMP, which is a 3d editor that runs in the browser. And they actually do server side pixel streaming down of GPU rendered content. So it's a really fascinating and I think, really powerful art. conjecture. So it's really interesting to see that one.

Jack Bridger 10:03
Yeah, amazing. And when you say like about being in the same room, and you just wanted to be in the same room as people building, you know, like, kind of advanced tools for the browser, like, what? What do you think are the benefits of being in the same room?

Paul Butler 10:20
I think there's a lot of a lot of these people building in different verticals or different types of software, are when we found this kind of talking to a lot of these people, when we're just trying to do have customer conversations, we found that people were discovering the same things are having the same problems. And there, there wasn't really this means of knowledge sharing between between those folks, like, I think in some cases, they'd have a company blog, and maybe it would get on Hacker News, and the other people would see it, but there wasn't really this community the same way that in more mature communities like web development in general, like React, communities felt community. I think in in a lot of cases, there are these online and offline communities where people are talking to each other about the tools that they use, when it came to kind of these raw, you know, just pushing the edge of these browser API's. And, you know, we're, we're kind of interested in like WebRTC WebGL, basically all the web prefects technologies. So there were meetups for individual ones of those like, there's some cities have WebAssembly meetups, some cities have WebGL meetups, but people kind of tackling this application building and using all of these API's, and just really trying to build advanced applications in the browser, that was where we kind of felt like, there was this blank space.

Jack Bridger 11:46
Yeah, so it's like people, it's less about the exact technology, but more like the goal that they're trying to reach.

Paul Butler 11:54
Yeah, I would say it's, it's kind of it's less about, I mean, it sort of is, we're very interested in the, in the surface area of the browser API's. So the things that are, are and aren't possible in the browser are definitely on topic for us. But you were equally interested in kind of what people build on top of that. So they the way that they build applications, the design choices that they make in doing that.

Jack Bridger 12:18
Yeah, that makes sense. And in terms of like, drifting in space, how, how is like drifting in space, his relationship with the community that you've built?

Paul Butler 12:29
So we kind of, you know, in building this community, I've kind of tried to keep the browser tech brand and community a little bit arm's length in that, you know, we don't want people to see it and be like, Oh, that's, that's just drifting in spaces megaphone, we kind of want to fill in the what we see as the blank space and build sort of a community where, you know, we're, we obviously benefit from having it we give, we kind of treat the meetups as a chance where we can demo some stuff as well. So we usually have a couple of talks, and then demo some stuff we're working on. And then I run a newsletter as well. So the the newsletters, occasionally mentioned some stuff that we've been working on, but is also kind of independent. In my voice anyway. I mean, obviously, it's not, it's not independent. I'm writing it. But it's I tried to kind of keep an independent voice with it.

Jack Bridger 13:20
Yeah, that makes sense. So there's like a couple of ways that maybe like does help with getting getting drifting in space out there. amongst people that would be interested. I could imagine it also like helps feed into like your product development stuff a little bit.

Paul Butler 13:35
Exactly. Yeah, a lot of this. I mean, I think one of the reasons that it's it's easier for me to do this newsletter and things is, it's, I'm kind of just writing what I've already learned in the process of talking to a lot of customers, following what's going on in the industry. So I realized I was kind of already building up this base of knowledge in my head of what's happening in the browser right now, and who's on the forefront of it and what they're doing and how they're doing it. So like, when we see a new app, we love to just, like, especially collaborative apps, Will, we'll sign up for the beta and run it in the office and play with it and talk about how they built things. And you're we have a lot of fun doing that. And I think there's other people who enjoy that type of content as well. So So yeah, one of the one of the things that we like doing is just playing with new apps. And so writing about that comes very naturally to us.

Jack Bridger 14:29
That's already cool. So is that like a big part of what your content that you put out is about just like kind of deconstructing like, oh, how, how did they build this?

Paul Butler 14:39
Yeah, it tends not to be like in deconstructing individual apps. Although I've I've kind of thought about going down that path a bit. Because I do think that's interesting. If, you know, we don't want to alienate anybody. So with permission from the app developers, but what more more of what we do is kind of looking at because we kind of break down the what these application Since we're doing we do observe trends, and then we can write about those trends. So the last issue, for example, was about GPU render DUIs. So these are applications that are talking directly to a GPU API like, like OpenGL or WebGL, to render the entire UI. So these are apps that don't talk to the DOM at all, except to kind of create a canvas element and then get the context of the canvas element. And then basically render render everything, we started to see this emerging pattern over the last few years and put it into a blog posts.

Jack Bridger 15:38
Yeah, really cool. Pretty cool. Kind of actually stepping back a little bit like we've got the like, it's amazing community that you've built. And it's like kind of a very targeted community. One of the things that two of our guests mentioned recently is that you have to be very sure of who your kind of persona are like the target customers. And it sounds like, first of all, that you are pretty sure on that you're not nodding your head. So how did you come to that that place?

Paul Butler 16:13
Yeah, so I think the so I would define our customers as kind of people building really ambitious applications in the browser, people kind of pushing the edges of what's possible in the browser. And I think that really just comes from what the technology is. So I think of the technology as kind of a solution to the problem, where you've hit the limit of what you can do in the browser itself. Either, because you are dealing with so much data that you don't want to send it all over the wire down to the user, we were talking about the video editing use case earlier, if you're trying to do 4k video, you might have gigabytes, many, many gigabytes, terabytes of data, depending on how much video content you're working with. So you know, you can't send that down to the browser, even if the browser could hold it, you have network problems. Another example of this is data visualizations, with many, many points. We have a demo recently, where will will load in a bunch of other gigantic point cloud millions and millions of points loaded into the point that it chokes the browser, and then we can almost instantly switch to remote cloud rendering of that on a remote GPU, dedicated GPU machine, and streaming that back. So that type of thing, you know, that doesn't, if you're building a blog site, or building e commerce or something like that, it's, you know, you're not the customer. But if you're building really ambitious desktop class applications, I almost think of it as is like, if you're building the type of application that if it were running on the browser, somebody would upgrade their RAM to run it. That's kind of the the, the scope of what we're doing.

Jack Bridger 17:55
Yeah, that makes sense. I guess you've got like a nice advantage, in some ways that it's not like a subtle difference. Like, I know, like some agents that some companies struggle with, like a we like, early stage people kind of like medium. And yours is like, if they're really doing something ambitious, very obvious if they're, if they need, if they're like all target audience, it seems.

Paul Butler 18:20
Yeah. And we find, we find that they can sort of self identify, and in many cases as well, where people sort of see, okay, I've got this use case. And I, you know, I thought of an infrastructure like this in my head, and I thought of all the things that I would need to build it, and thought it'd be better if somebody else had built it, and then I found plane, and then, you know, it kind of goes from there sometimes.

Jack Bridger 18:42
Yeah, yeah, that makes sense. And then the other question I've got is like, at the moment, I think you're very focused on open source, or open source projects, is that correct?

Paul Butler 18:55
Yeah, we're focusing a lot on open source, the way that it works with with playing in JAM socket. So playing is kind of our flagship open source project. And then jam socket is built on top of it. So blend jam sockets, kind of a managed version of it. And it's really kind of a spectrum from completely using the managed product to completely using the open source product. Where there's also an option in the middle, which is you can kind of run the worker knows that you actually run the compute on your machines, but use our central control plane to coordinate it. And that's kind of a nice middle ground where, you know, none of the data goes through us. None of the application data goes through us only the coordination data and routing. And so we're kind of just taking care of the DNS and certificates and orchestration, scheduling that kind of thing on our end.

Jack Bridger 19:50
Super cool. So how are you like, kind of thinking about like, getting customers that like, how did it how do people start paying you money, I guess is like does it go from like? Yeah,

Paul Butler 20:04
yeah. So. So it's for, you know, we, we get paid for the infrastructure. So people running it open source. I mean, we maybe could negotiate a support contract. But in theory, they can do it without even talking to us. So the money comes from the Manage side. It's kind of like a any other usage based type thing for the completely managed side. And then in the middle, where they're kind of running it as a control plane, it's more of a monthly fee. And then fee per per machine that they attached to it kind of data dog model.

Jack Bridger 20:38
Yeah, nice. Like these kind of individuals, like, it seems like it's kind of a, it would be like a larger organization type of thing. Commonly,

Paul Butler 20:49
it does tend to be I think, right now, with with the way the platform is, it's, I mean, it is fairly simple in the sense that the surface area is fairly small, basically, you push a Docker container to us. And then instead of deploying it immediately what you get as an API, and every time you hit the API, we send you back a hostname, that is a basically an ephemeral instance of the container that you spawned up. So the way that you kind of use that as a child process is from the browser, you can open a WebSocket connection to it. Obviously, whatever you're running in, the container needs to have a WebSocket connection server built into it. So we're not prescriptive about what framework you're using inside the container. You know, you could you could serve a WebSocket from no JS, or Python or whatever. But you can connect to that from the client. When that connection goes away, if that's the only connection that exists to it, we will schedule that container to shut down so it's it's kind of ephemeral, short lived, but Well, we call it session live. So it's like, as long as the tabs open, we keep the process alive. So do you answer your question about kind of who's using this, it we do find people kind of come in to poke around with it as individuals, where we find larger companies can come in as I did it, typically, at this point, seed and series, a kind of stage companies so tends to be people building new stuff, or scaling stuff, kind of going from being able to run everything on one vertically scaled out machine to realizing that they need to add more machines, but kind of doing that naively just putting that one machine they had behind a load balancer doesn't work anymore, because they relied on having stayed in memory and things like that.

Jack Bridger 22:40
Okay, and then so they, they have like this pain. And that is it like they, they remember like, Oh, what if plane could help us with this? Or yeah, how do they?

Paul Butler 22:53
Yeah, often when we hear from people it is, it is like, Okay, I saw, I saw playing on GitHub or on Hacker News or something six months ago, and didn't think much of it at the time, but came around to this now. And I was like, Oh, wait, I've seen a solution to this problem. And they almost like have this this moment of enlightenment, where they're like, oh, that's what plane was trying to do. Okay, yeah, I'll take a look now. So it is kind of a slow burn that way. Because I think this is not, you know, we've had to really create the vocabulary even around this problem. We call this a session back end when, when we do this, and you're when we spin up one of these processes that lives for the lifetime as of a tab. But figma was doing that Code Spaces was doing that all these applications were already doing something like this, they just didn't really have a word for it. So we've had to really educate people about that architecture. And that's been slow. But but when they get it, they get it.

Jack Bridger 23:56
Yeah, is there like any kind of things that you've learned from like having this where it's like a new concept?

Paul Butler 24:04
Um, I would say, so we decided, you know, we wrote a blog post about it, we shared the blog post around, I think that's helped, that's helped to click for people is sort of having these different approaches to it. There's, there's kind of the explanation that you get, if you look at plane directly, which is a very technical explanation. There's the explanation you get if you read our blog post, and there's, you know, I've done pot, you know, podcasts you've heard. So, yeah, there's sort of, we're just trying to get out there and explain it in a bunch of different ways. We have talks that we've given in person and then those are on YouTube. So really just trying to evangelize this concept and talk about it. And, you know, when we talk about it, we don't really push plain as, as the only solution like we're, I think, the best solution because we've we've been the first to kind of really address it head on as a problem but there's other people kind of building their on infrastructure on this around Kubernetes, and, and things like that. So we're just trying to get the word out about this problem and go from there.

Jack Bridger 25:10
Yeah, that's, that's pretty awesome. Paul, that is what we've got time for. But we just started doing a takeaways, section, very brief section of takeaways that you've got, either that we covered in the episode or that you think that other dev tool founders, early stage employees or dev tools should kind of take away from what you've learned.

Paul Butler 25:36
So one, I had a hot take on Twitter this week. So I'll repeat that. It's that I think that if you're trying to break through on Hacker News that a cookie banner is detrimental. I had one of the founders of of Y Combinator actually commented and he was like yeah, if I see something that has a cookie banner, like my bounce rate is 50% immediately but my theory around this is a bit more intricate. It's not that the cookie banner is always detrimental, it's that it's detrimental when you have no social proof. And if you're trying to make the main page from the new page, which is kind of the process you have you start with no social proof. So that's that's been my, my hot take this week.

Jack Bridger 26:20
How to have fast remove your cookie bonus.

Paul Butler 26:24
And remove the cookie. I mean, I'm not saying

Jack Bridger 26:28
you should clarify by the book,

Paul Butler 26:31
because I looked at some of these sites like flied out i o Super Bass, like they they just don't drop cookies if you land on the blog, so and I, you know, change. I tried to promote a few different IPs and that sort of stuff. We also don't drop cookies we use plausible, so

Jack Bridger 26:48
amazing. Amazing. That's very good stuff. Yeah, Paul. So if people want to learn more about yourself, or they want to learn more about drifting in space, or browser tech, where can they learn more?

Paul Butler 27:01
Yeah, so. So we write a newsletter on browser tech tends to be either a link digest or in weeks where I have something to say it tends to be more commentary. So that is digest dot browser. tech.com. Browser. tech.com is also where we have our in person events listed. The database I mentioned is drift dB. So drift db.com. Our site is we're drifting in space. It's drifting in dot space drifting in one word dot space. And then on Twitter, we're drifting underscore Corp.

Jack Bridger 27:36
Awesome. Awesome. Well, thanks for joining pool and thanks, everyone for listening. We'll be back again soon.

Paul Butler 27:42
My pleasure. Thank you, Jack.