Thanks for sitting down with us, aard. Do you want to introduce yourself to people, tell us about yourself, your background, what you do? Yeah, sure. I'm a programmer originally from Holland. I've spent most of my life making either game engines or programming languages - I tend to alternate between the two. That's kind of what I worked on and I guess the Cube games have been my most well-known personal projects on that side. One of your notable programming languages is Lobster. Can you tell us a little about it? Lobster is an engine, but it's also first and foremost, a programming language, and nowadays it's pretty hard to make programming languages popular. It requires a lot of effort or preferably requires that there's a large company behind you that helps you push the language. I think without that, it's almost impossible to make a popular new language nowadays. But that's okay, and I'm having a lot of fun making it and a lot of fun using it. I’ve used that language to even build new engine prototypes. It's all kind of intermixed in the sense that my programming language hobby, making engines, and 3d worlds, are all kind of like one big blur as far as I'm concerned. So is it correct that you started working on the original Cube engine in the late 90’s / early 2000s, after your PhD work was completed while you were teaching at Guild Hall? Not quite, no. I did a fair bit of the initial work of making my first 3D engine during my PhD. Towards the end of my PhD is when I started working on the Cube engine. And then, I transitioned to working for Crytek, the makers of Far Cry. And actually I think the Cube engine helped me land that job in the sense that the then-CEO of Crytek saw the Cube engine and was particularly excited about the idea of the in-game map editing that it was presenting, and he had all these ideas about how Cryengine was also going to have in-game map editing, at least for its interior spaces, though that ended up not materializing. I ended up working there for quite a while anyway. And while I was working at Crytek, because I ended up talking to a lot of other game programmers and lots of close friends there, somehow I got inspired for the octree based format that was the basis for Cube 2. So Cube 2 I actually designed and started working on during my time working at Crytek. And then only after leaving Crytek and after Cube 2 was already released that I started working as a teacher for Guild Hall in Texas. The first release for Cube on Sourceforge was 2002, and your site has it listed as 2001, but it sounds like you had older releases much earlier than those dates. Yeah. Releasing it on SourceForge was a relatively late thing. Initially, it was just me hacking on a bit of source code and I did not use source control or SourceForge or any of that stuff. It was just me, and then after a while Lee Salzman - eihrul - came in. The first version of Cube had this really simple TCP/IP based networking. Me and him were already talking a lot about programming languages, so naturally I showed him what I was working on on the engine side, and he was not working on anything like 3D engines at the time. He was like, well, “that's all very cool, but this TCP/IP based networking really has to go. That is absolutely terrible. You can't do that in games”, which I agreed to, but I didn't have time to do anything else. That's when he decided to start making this little library called ENet, which was kind of developed in parallel with Cube, becoming Cube’s networking engine, and he tested it with Cube. I was developing on Windows at the time, he was a big Linux user and also was working on Mac, so he started helping me out with porting. And then, Cube 2 came around. He got more and more involved and even got involved in graphics - and eventually, as you all know, eventually ended up taking over maintenance entirely. As for the timeline initially, I'm not sure exactly when Lee started getting involved and it became a two person project, but for the first half year or so, the sourcecode was just on my hard drive, and that was it. So then did you release it to SourceForge specifically because you wanted to release it as a game versus just a little engine demo? I guess we brought it to SourceForge because it was easier for me and him to work to get it that way. With the very first version of Cube, it was mostly a whole bunch of my Quake and DOOM map editing buddies, basically people I used to play with at the time. They were the people that were most interested in playing the game and playing with the engine and making maps for it, so I probably just had a binary on my website. And the thing was at the time, everything about that whole game was incredibly small. I mean, much smaller than the distribution you can still download today. Like, the first binary of Cube could actually fit in only 64k with some compression. The maps were tiny; like the first version of aard1, which is one of the maps I made, was just like three kilobytes or something. I made most of the initial sounds for the game, which were all 8-bit 11KHz sounds. I think textures probably must have taken up the largest amount of space in the first releases, but the first release was only a couple of megabytes in total space. When did Cube transition from this kind of editor you used to a fully fledged game that was played and people tried to actually get good at and what-not? It didn't transition. It was pretty much a game from day one in the sense that the absolute first release of Cube had that basic first person shooter game playing there. The thing about it was definitely, the first versions were only multiplayer first person shooter gameplay. The single player gameplay was something that came later. It took quite a while. So initially you just had deathmatch and co-operative editing things you would do with Cube, but that wasn't there right from the start, like the first version I ever showed to my friends had the first-person shooter game in it. I'm not sure how long it took me to add the single player game play, but that must've been the first year as well - it couldn’t have taken too long. That was definitely a very separate thing. I remember having to take some time to do that. Multiplayer was more simple to make than singleplayer? That's a good question. Multiplayer definitely is very complicated generally, but in this case it probably wasn't because the basic game was so simple. It was similar to Doom and Quake multiplayer, but probably even simpler than that. So it was really just, player positions and projectiles and a couple other things, and because it was very programmer driven. It just required me to have one model in the game - a player model. Actually doing single player requires that you do AI and AI needs to find its way around, it needs to have pathfinding and collision with the world and make big decisions, it needs to have a whole bunch of different enemies, they all have their different sounds and animations and pictures and all these kinds of things - so making single player was actually more work than making the initial multiplayer. The style of multiplayer in Cube is much simpler than most multiplayer first-person shooters that you find because it trusts all the clients. It takes your local position, sends them to the server. The server just bundles them up and sends them back to all the clients. The server doesn't do anything except just multiplexing all the data. It makes it extremely cheat sensitive, but most of the gameplay could be implemented client side. If you want to shoot an enemy, it just checks your local version of the other player. If it hits that box, then you shot it and hit points get deducted. That is super simple as opposed to the server side version which is much more complicated, essentially, cause you’re running two games and you need to synchronize them. In Cube, every player is effectively running an independent local game. Once things start to get laggy, you can also see that the games of all the different players don't correspond anymore, but most people don't notice these small differences so it was fine. Again, a lot of things in Cube - its world structure, its graphics, its networking, its gameplay - were designed for maximum simplicity, cause I’d spent a lot of time playing Quake before that, and I knew that I didn't have the time to implement something like Quake’s features. So I really focused on simplicity as a way to get the game done. And of course, in the end, if you're looking at the current version of Cube 2, simplicity has kind of gone out the window. It's a fairly complex and featureful engine and game, but in the first versions, everything was cut down and simplified just in the name of getting the game and engine actually working, and that was pretty successful in that sense. So for anyone out there who’s wondering about the networking model, Sauer’s networking model being clientside is what he described, versus something like quake, or many other multiplayer games where you would in essence shoot at an enemy, and then the server would look at that shot, account for pings, and determine if that shot makes sense in its view, and it’ll do some backwards reconciliation and whatnot depending on the model. The downside of this being that sometimes it may drop shots you hit, or count shots that you didn’t hit, whereas in Sauer it’s instant for you. Yup. You have basically a zero ping for most of your gameplay actions, with the exception of things like picking up ammo. Those are definitely sent to the server. Nowadays, in well implemented first person shooter games, they have all these techniques of basically translating the game state backwards in time, depending on your ping to make sure that you get an as accurate as possible way of shooting at enemies and things like that. That for the most part solves these problems, but it's also incredibly complicated to implement all that. If you could magically solve the cheating problem, then a Cube way of doing networking would certainly be superior, giving everyone a local game. One way to do anticheat is to do regression / ML models to counteract cheating, but that’s something hard to do in real time, especially for a large playerbase where you just won’t have the compute to do it for everyone But the funny thing was like, I was at the time like, I don't give a shit. It's like, okay, this is going to be cheat sensitive, but guess what? It's like, this is what I have time for. This is how it's going to work. And we'll figure out the cheating thing later. And it turned out the cheating thing never became the biggest problem since it was mostly a question of the community policing itself. One other weakness of doing the server side netcode is that, for instance, one of the great things about Sauer is that I feasibly can play with Firefly, who pings 260 to a European server that I ping 140 to, and we can still have a good experience, versus on Diabotical, I remember notas (east coast) and starch (west coast) struggling to find servers where they both pinged well enough to be playing at a level they should be Yeah, that's a huge issue. I still play Quake multiplayer to this day. They have adopted this kind of client side projection mechanism, so it works pretty decently nowadays to play with something like 120 ping, but still there's certain gameplay features that are absolutely terrible, so finding fair servers is still a huge issue. Which Quake do you still play that lets you play with 120 ping? The first Quake, Quakeworld. Oh nice, QW TDM is really cool. Yeah, I play team games, 2v2, 4v4, whatever. It's a very small community, but for some reason I'm still addicted to playing it and I've been playing it for twenty-five years. Everyone knows each other, so it’s hard to be a dick in Quakeworld because it's a small family. When would you say Cube had a better editor than the Quake one you were trying to supersede? Well, I really had a better editor right from the start. When I started making the Cube engine, I played a lot of maps and also made tons of maps for Quake and DOOM, and this whole cycle of looking at a 2D CAD version of your map, having to pretend what it would be like in 3D, then having to go through a compilation session, which in Quake could easily take an hour or something like that to get the perfect compiled version of your map, I was just like, this is not how we're supposed to make 3D maps. And the idea that you could basically modify the map in real-time in the game, and later, even in multiplayer was one of the big motivations to structure the engine in the way I did. I wanted it to be such that there would be no pre-computation necessary to be able to play the map structure as you're editing, basically. I think that’s actually a very good way to go down. It’s interesting that a lot of engines even now, like the current Quake or Diabotical editors, don’t have much focus on real-time compilation of maps. There are still games whose objective is just to be the prettiest, biggest, most amazing kind of game ever. We're talking about Cyberpunk or those kinds of games. For those games to have in-game editing would be difficult with all their other goals - and then of course, there are the older games like Minecraft and all the games that come after, which are focused on in-game modification. But clearly, they're not trying to compete with something like Cyberpunk for graphics. They have a very different structure. Recently I was playing Valheim, which has a lot of in-game editing possibilities as well. It's a very different kind of game genre, and the same thing was the case for Cube when I was making it - I kind of had in my head, like I'm not competing with Quake 3 because Quake 3 was still on the trajectory of trying to be the most graphically advanced game that you could make at that particular moment given the current GPUs, and with Cube, because it was possible to make the editing in-game, I was clearly leaving performance on the table, so I was not competing with Quake 3 for being the prettiest. And at the time, pretty much all games were on that path of trying to be the prettiest, whereas nowadays there's tons of games coming out that just have their own unique art style and not even trying to be like the most photorealistic or whatever, which I think is great. It's like they can focus more. So Sauerbraten pops onto the scene, but Cube still had a release in 2005. How long did it actually take before Cube was basically "dead" - when did Sauer become the Cube game everyone plays? All the other parts of Cube that were not the world structure - so we're talking about the gameplay, the networking, sound, single-player, all these other parts - I was fairly happy with. Of course it could be better, but that was no motivation with the initial version of Sauerbraten. I really wanted to only overhaul the world structure. I just took a copy of Cube 1 and started replacing the world structure stuff with the octree stuff, just incrementally and all the rest of the stuff remained. The initial version of Sauerbraten probably shares at least half the code with Cube 1. We did not start over. It was all about the world structure. I started feeling that the world structure for Cube 1, being essentially 2D, was starting to get a little bit limiting. Particularly, I think that the worst thing for me about the Cube 1 world structure was the lighting. It basically had vertical lighting where there was like one light value for the entire range of the entire height of a particular column. Cube 1 has 2D lighting. It basically computes the lighting for any particular point in the world in 2D, and it also does the occlusion in 2D. While it works decently, it is very incorrect in all sorts of ways. All the good mappers from that time really had to work hard to try to make the most out of the lighting system of Cube 1. It was nice because it's super quick because doing the lighting in 2D meant that everything recomputed instantly. We even had lights on the rockets that would just recompute as the rocket was flying through the world, because it was so quick and simple. All very nice, but visually didn't look quite as pretty as any of the Quake games, mainly because of its very simplistic lighting. So that was the thing I wanted to fix, but the problem was that with the Cube 1 world structure, there was no easy way to do lighting in the third dimension because if you have like the side of a wall, there was no place to store individual lighting values along the wall. It would have greatly complicated the Cube 1 structure and made it way slower.. So then the question was, well, if we can’t do it in Cube 1, we must invent a 3D version of this to be able to store all these lighting values. And of course it has additional advantages, like being able to do room over room is of course also a very nice advantage. Sort of thinking about these possible 3D structures, octrees are really one of the simplest possible sort of these spatial structures. But just plain octrees, as in cubes, I wasn't satisfied with, because Cube 1 already had these nice facilities for being able to make slopes. And if you remember, even the first maps like aard1 had these beautiful arches that were kind of nice and round and stuff like that. I wanted to keep this ability to have slopes in there, but now things got more complicated, because in 3D, the slopes must be able to be placed in all six directions, basically. So that's when this system which I call the deformable octree was made, where basically every cube that sits inside an octree has a plane and a plane can be pushed along four edges to shape a cube in any possible shape, and I thought the combination of the octree and these deformable cubes would give mappers a suitable amount of power to make pretty maps while not being too complicated. I also found a way to store those six planes in the cube in a very, very compact way so that maps would not be gigantic. So that's kind of how that came to be. But yeah, that was motivated first by lighting and second by giving mappers more power to sculpt 3D worlds. That seemed like a natural progression from what had been in Cube 1. What was your involvement in the Sauerbraten community over the years? We noticed you pop into the community discord during Corona times, but for instance, I’ve never interacted with you before and I’ve been here for almost 12 years. When I was still involved with it, there was quite an active multiplayer community, but active leagues were something that was a little bit later. I must've gotten less involved around 2009 or something like that - that's just a rough guess. And of course it was not one particular moment. It was kind of gradual. I got less involved, and Lee became pretty much the sole maintainer. I would say that at least since 2010 or so, Lee’s been the sole maintainer. And even before that, he was way more active than I was. So, yeah, I've missed a lot of the last 10 years of Cube’s community, especially in terms of leagues and multiplayer. I've missed a lot of that, I must admit. It’s absolutely awesome that Sauerbraten keeps attracting new people and keeps them continuing. That’s amazing. I absolutely love that. I think that's generally the case with games now because the internet and open source, that games don't ever die; they might shrink a little. Notas and I dug through, and noticed that around 2011/2012, SourceForge downloads started dropping off, and not just in Cube engine games (but largely in Sauerbraten and AC). That is certainly very interesting. I'm thinking of larger developments that happened: One thing that might be related is just like the dominance of something like Steam. I know Steam already existed way before that time, of course, but it definitely has been getting bigger and bigger and bigger to the point where for a lot of PC game players, if it's not on steam, then it pretty much doesn't exist for them. And downloading something from SourceForge... I mean, it's still possible, but it's a bit ancient nowadays. Everyone expects things to be either on Steam or Itch or Gog, or any of these, any of these download sites. But other than that, I don't really have any clue that there’s something specific in 2011, 2012. So… what do you think of the 2020 release? Yeah, I downloaded it, and pretty much went through all the maps and checked out all the new ones. And man, it's amazing. Like, some of the maps, what they are able to get out of this engine is just absolutely gorgeous. What were your favourite maps from looking at them? I don't remember names from my session of going through those maps. I haven't played a ton. That's the sad part, I guess. I only tried it in single player. So I'm not actually aware of how it now feels different in multiplayer. Marc A Pullen has done the Cube and Sauer music forever. How'd you get such a talented dude? I think I knew him through DOOM. I had as ton of Quake and DOOM mapping friends back then, and I guess he came along with that. But yeah, some pretty cool music he’s made. Overall, what do you think of your legacy in the open-source game community? Cube, Sauer, and AC have been some of the most popular open source games for years, and all stemmed specifically from your engine. All this convinces me how valuable it is for games to have fun tools for users to create stuff like user generated content. Content is such an amazing thing that games should make more use of. I mean, the fact that Sauerbraten is not a commercial engine, is an open source game and still has this much content... I think if you go look for games that have custom maps, Sauerbraten is probably one of the games that has the most amount of maps available for it, even though it's not even a commercial game. It’s pretty amazing to think. The other thing I will say is I still love Sauerbraten’s physics the best of almost any game, probably even better than the physics in the Quakes that I play. The feel of running around - I remember when I got the 2020 download and the movement felt so great. It feels so precise for some reason, the ability to kind of like jump from one place to another, land on a thin pole and to be able to keep on jumping from that pole to some other spot, do a difficult jump, that's always been the best in Cube. So I'm also saying that because I'm actually working on something new right now and I'm totally reusing Cube's physics because it's just the best that I've ever experienced. Oh a new project!! What is it? I'm not going to say it's another game, because one thing I've learned through the ages is to not make promises on what you're going to make, because then you'll end up not doing it. So anyway, I'm not promising I'm making a game. That said, I am working on a new 3D game with graphics that are fully GPU raytraced in pixel shaders. The raytracing is going to happen entirely in pixel shaders. It could be done in compute shaders, but there's no advantage to using compute shaders for what I'm doing, so I do it just in pixel shaders, um, if anyone needs to look at what I'm talking about... It's again, made out of an octree, so it's all very familiar. The graphics rendering side of that is getting somewhere. It's not complete, but it certainly looks very pretty and interesting, so the next step is to add the physical world and physics. That's what I'm doing right now, and I'm actually using the Cube physics for that for multiple reasons. First of all, it fits very well because this game is also based around an octree and you're going to be jumping around on a bunch of cubes. So that works very well. Then the next step is to make sure that things like shooting and other things happen. So then before you know it, you'll have a very basic shooter game in the engine. Is that going to become a game again? Again, making no promises, but I would certainly like it to go in that direction eventually. This is not a “Cube 3”. No, this is not called Cube 3, even though there are some similarities between the Cube engines and what I'm making right now. Technically it's very different though, because like I said, it does raytracing for graphics. No polygons are involved. It's purely voxel based, and all the gameplay code is written, of course, in Lobster, my own program language. In terms of code structure, it's very different from the Cube engines, but you know, some people never learn and keep making the same game over and over again. And that probably includes me. And being fully raytraced via fragment shaders, this runs in real time suitable for gaming? Yeah, it works. Raytracing is totally viable nowadays. And again, like with the early Cubes, the secret of what I tend to do is keep things utterly, utterly simple. Here it’s the same thing; it’s just an octree with a bunch of voxels inside. I raytrace that. There's just two rays: A primary ray going through the scene and then a ray going to the sun for a shadow and then maybe a reflection ray, and that's it. So it's stupidly simple. The Quake 2 raytracer for example is already a lot more complicated than this because they used more rays than my two or three that I’m using. They raytrace through a BSP, which is decently fast, although not quite as fast as raytracing through an octree. It will cost them more to raytrace Quake 2, and it probably won't look as cool in the end. I'm guessing they use a lot of rays because they don't use light maps anymore to emulate that same kind of soft lighting that Quake 2 had, and they will have to flip trace water rays to two different light sources. And that's going to be very, very expensive and I'm just doing an outside world so that I can just say, well, I'm just going to have one light storage. And you’re doing this all in Lobster? The engine itself is still in C++. The raytracing shader is in, of course, GLSL. The lobster code is all the code in between. Basically it's all the code of organizing the world structure and it binds everything together. You’ve been writing programming languages for a while, and probably have seen trends of styles and languages come and go quite a bit more than most of us. What are your thoughts on that front, about new languages emerging? I'm still excited about new programming languages. I'm even making more languages beyond lobster still. It’s a very exciting field with lots of possibilities. Lots of progress has been made in mainstream languages becoming more powerful. That's all fantastic. On the other side is the fact that the amount of language out there right now is just so overwhelming and your abilities to affect change there with a new language is also kind of gone for that reason mentioned before, that you kind of need to have corporate backing to create a new language community. So while the possibilities are endless, it's not as meaningful anymore in that sense. Making a language is very much a personal project nowadays that you do for fun, and not to actually create a language that anyone going to use because that's simply just never going to happen, unless you're very lucky. So that sense making, making games is a little bit more productive because, you can make a game that's not necessarily better than the best game out there, but people will still play it because there's an endless desire for people to play new games… there's not an endless desire for programmers to be programming in new languages, it’s a very different situation. So, Rust… what do you think of it? Let me start with the positive. I think Rust is - if I had to pick one language that has made the greatest amount of improvement in the mainstream landscape, or brings the greatest amount of new, cool stuff to the mainstream, that would have to be Rust. It is an incredible achievement. It does a couple of things that are super important, and it does them so well in particular, combining, like, zero cost abstraction with safety, memory ownership... At the same time. I don't think it's perfect. I think for most programmers, I'd say 95% of programmers, at least, Rust is not suitable. It's a little bit too finicky to get stuff done. And I think it's possible to get most of the advantages of Rust with also most of its performance while making it easier for that other 95% of programmers that just don't want to deal with it. And in fact, of course, my idea of how to achieve that is actually what Lobster does. It has this thing called compile time reference counting, which is kind of like an automated version of Rust’s checker. At compile time, it will analyze your whole program and will determine who owns what, and how this ownership gets transferred. It gives you a bunch of tests, without having to think too much about it. For my day job. I spend all my time programming C++, and I definitely wish I could just magically convert it all to Rust or something like that, it would be a lot more pleasant. Speaking of your day job, what have you been doing at Google since you started? The first years that I was there, I was part of a games team, with my job particularly being to write libraries and other things and other tools to make it easier for people to develop games on Android and beyond. Later on, as part of that team, I got involved with the VR team and helped them with the libraries we're building as the underpinnings for a lot of the VR work that was happening at Google. I made a bunch of libraries. The funny thing is that, the simplest of those libraries, or at least one of the earliest ones that I thought was going to be the simplest, which is Flatbuffers, was also by far the most successful out of the work we've done there. That kind of started when I joined Google and we made up this big list of like all the amazing stuff we're going to build., and on that list was, it said “serialization library”. And I'm like, “huh, that looks like by far the simplest and smallest thing on this list. I've just started at Google, so why don't I start with a small, simple task, because I actually have a whole bunch of ideas on how to do serialization way better than we've done before, so let me start with that”. And that was supposed to be my initial project, maybe lasting a couple of months and then being done. And, that just kind of blew up. It blew up particularly outside of games as well, with a lot of large companies adopting it for their serialization needs. And because of that, I've been working way more on Flatbuffers. That was the start of when I was working there, then I got the opportunity to work with the guys making WebAssembly, and I just kind of had to jump at that opportunity because I've always been such a fan of programming languages and compilers, so I joined the WebAssembly team. I'm still doing flat buffers as well because it's simply too popular to not work on - but my main task is actually now working on WebAssembly, in particular, on LLVM and other related tools implementing WebAssembly, and that's been a ton of fun as well, because I do believe WebAssembly is going to be kind of the intermediate format between languages and platforms going forward . That's going to allow lots of new languages and lots of new platforms to have access to fast execution of things. So yeah, super excited about that, working on things like LLVM and, in general, compiler stuff is a lot of fun for me, especially since I've spent so much time working on games, so alternating these things is a good thing for me. These days, Sauer's pretty much entirely updated by eihrul with a little help from a few contributors, most notably Quin adding bots 12 or 13 years ago. Who was involved more heavily in the early development of Sauer? I'd say programming wise, not really, for the longest time it was really just Lee and me. That’s maybe my fault, because I've made Cube so much about simplicity that I was at least initially very defensive about people adding or modifying things that I wanted to keep things simple, and Lee was one of the few people that was able to do that, so we never had really a lot of programming contributors - like in the initial, early days at least there were more, but there were a ton of mappers and people making art and models and sound and music. Those were a much wider group of people that were really fun to work with, but programming wise... I personally never interacted with Quin too much. That was mostly Lee doing that. So for me, it's been mostly just Lee and me for as long as I know. I suppose that getting a lot of code contributors was also harder in the 90s and early 2000 without very refined tools like git I said I've managed projects, like flatbuffers on GitHub. And I think it has several hundred contributors and I reviewed our code and it's actually pretty easy nowadays because you have a reviewing interface, and you can just tell people like, “Hey, why don't you go and prove this? Or why don't you just implement this in a slightly different way”, and they tend to go do it. And then by the time you're done, the code looks pretty good. It looks close to how you would have written it yourself and you merge it, and it's great. Back in the early 2000s, when me and Lee were working together, we didn't have all those tools. And basically if you're going to have someone work with you on the code base, you basically just have to trust them that they're going to do the right thing, because you're not going to review all their code. And if they're going to make a mess, it's going to be hard to revert basically. So back then you were looking more for people that would keep on contributing, whereas nowadays, there's so many people that have contributed to something like Flatbuffers, where they just made one pull request, fix one thing, and then they never come back - so it's a very different structure of how people work together on code. I've become a lot more relaxed about not trying to be so difficult about wanting everything exactly the way I would do it, kind of thing. You gotta leave some room for other people to do stuff... if we were making Cube right now, for example, on GitHub, then it would have been a ton easier to have other people help improve the engine. I'm just going to say, it would be interesting to consider, like if Sauerbraten is going to survive for another 20 years, where it would be worth at some point to get it, to get it on GitHub. The problem with doing everything on GitHub is that it also requires a lot of energy for the head maintainer, so it would not necessarily be any less work for Lee to have it on GitHub because you know, rather than implementing it yourself, you can have someone else implement it, but then you need to do a lot of reviewing END INTERVIEW