The Changelog: Software Development, Open Source - Coding in the cloud with Codespaces (Interview)

Episode Date: September 11, 2021

On this special edition of The Changelog, we're talking with Cory Wilkerson, Senior Director of Engineering at GitHub, about GitHub Codespaces. For years now, the possibility of coding in the cloud seemed so close, yet so far away for a number of reasons. According to Cory, the raw ingredients to make coding in the cloud a reality have been there for years. The challenge has really been how the industry thinks, and we are now at a place where the skepticism in cloud based workflows is "non-existent." After 15 months in preview, GitHub not only announced the availability of Codespaces for Teams and Enterprise — they also showcased their internal adoption, with 600 of their 1,000 engineers using it daily to develop GitHub.com. On this episode, Cory shares the full backstory of that journey and a peek into the future where we're all coding in the cloud.

What's up, welcome back. We have a special episode of the Change Log for you today. Today we're talking with Corey Wilkerson, Senior Director of Engineering at GitHub. And we're talking about GitHub code spaces. For years now, the possibility of coding in the cloud seems so close, yet so far away for a number of reasons. According to Corey, the raw ingredients to make coding in the cloud a reality have been there for years.

The challenge has really been how the industry thinks, and we're now at a place where the skepticism in cloud-based workflows is, quote, non-existent. After 15 months in preview, GitHub not only announced the availability of code spaces for Teams and Enterprise, they also showcased their internal adoption with 600 of their 1,000 engineers using it daily to develop github.com. On this show, Corey shares the full backstory of that journey and a peek into the future. We're all coding in the cloud. Special thanks to our friends at fly.io for partnering with us to make this episode interruption free. Fly lets you deploy your apps

and your databases closer to users and their vision vision is simple all apps should run close to users in minutes you can run your ruby go node dino python or elixir app and databases all over the world no ops required you can launch most apps in about three minutes and they have a generous free tier so you can easily prove to yourself and your team that fly has everything you need to run your app globally give it a try and check them out at fly.io change changelog. All right, let's do this. Corey, welcome to the changelog. We've been looking forward to this conversation,

been paying close attention to Codespaces, been paying close attention to, I suppose, the right timing for devs to truly consider what coding in the cloud can do for them and when would be the right time to do it. So obviously, when I saw your post on GitHub's engineering team moving to Codespaces, you know, it's a big deal. I had to reach out, get you on the show. So welcome. Thank you very much. Happy to be here. Thank you for having us and your interest in Codespaces.

So the big news is that GitHub's engineering team, all 600-ish, have moved to Codespaces. Maybe we just start right there and you can tell us that story. Sure, yeah. I mean, there's all kinds of places to start. But I mean, I think the net of it is, if you look over the past 30 days right now, we have 600 GitHub engineers active in Codespaces,

which I think is just a really interesting and compelling story, right? Like we were just talking kind of before the show a little bit. Like I started off as a bit of a skeptic in this space. Like I was kind of roped into the effort and asked to kind of help move from what was effectively kind of no adoption into a real commitment to Codespaces. And that turned out to kind of be a heck of a journey and kind of where my story in Codespaces starts. What would be kind of most interesting to explore there?

Do you want to know kind of like ground zero, like what did it look like from day one and how we built momentum there? Like what all would you like to dig into there? I like the whys. Why are we doing this? Why did GitHub decide to do this? And then how did you get involved?

Yeah, I think the why here is basically we saw an opportunity to remove an entire class of issues, like productivity issues, that I think we've all kind of experienced as engineers, right? I've been doing this for 20, 25 years. Y'all have been in the industry for some time, right? And like a near constant is this friction you feel over development environment complexity, right?

Like it's an ever-present challenge. There's not a single day where you don't see some kind of signal of like environment complexity or challenge. And I think GitHub saw an opportunity with kind of where the industry was and a lot of tech that was out there to kind of bring these things together. So kind of the mentality in the industry and the tech that had emerged to remove this class of issues. And GitHub is around a thousand engineers, right?

So you can imagine that winning back productivity for us gets very valuable kind of very quickly, right? Like at a scale of a thousand engineers, we're not a huge shop. We're still relatively small. But still, you know, developer downtime costs a lot, right? And I think we saw here that we could, you know, bring this tech together and effectively just kind of remove this class of friction for GitHub engineers and of course, like the industry at large. Does that also speak to the lower barrier to entry? Yeah. In terms of class of issues?

Without a doubt, you know, like I think about one, one big benefit of code spaces is just accessibility into projects now. Right. So the idea is that the environment kind of ships with the project. You had to, for some time,

you know, for my entire career, you would have to bend your environment to the will of the project. You had to, for some time, you know, for my entire career, you would have to bend your environment to the will of the project, right? Your local desktop, you'd have to kind of like make the thing work to support the project, right? And that was oftentimes not a smooth transition whatsoever. And now the idea is like, hey, the environment's kind of attached to the project, right?

It's like part of the repository. We capture the environment and configuration. You click a button, we launch that compute for you out in the cloud, you attach your development. We capture the environment and configuration. You click a button. We launch that compute for you out in the cloud. You attach your development environment and you're up and running. Like that class of problems is now gone. So one, it solves friction. Two, it makes things far more accessible. And I'll say that I'm a, personally, I'm kind of a top-down learner and not like bottom-up, right?

I think many people are kind of top-down. Meaning like I like to start to, like in a new application that's unfamiliar to me, I like to start to tinker in it a little up, right? I think many people are kind of top down. Meaning like I like to start to, like in a new application that's unfamiliar to me, I like to start to tinker in it a little bit, right? And like change a thing here, refresh, see what happens and see if I can kind of gain purchase or traction that way. Right? And like Codespaces is a perfect tool for like exploring kind of new spaces.

Well, Adam, you can speak to friction when it comes to development, right? Because Adam, you hack on our code base just infrequently enough that every time you work on it, I think you hit friction, don't you? Yeah, if I accidentally homebrewed upgrade or something like that and I'll upgrade Postgres or something will happen in my database, I've learned enough now to navigate our setup scripts better, but as Jared said, so infrequently that, you know, I'm not always on the up and up, you know, and something will change.

I'm just not on, you know, on the tip of the code bases as much as I can be. And so I definitely hit this often. I mean, even within like older days, too, with like Ruby and, you know, pulling somebody's project with a Ruby version manager or, you know, RVM or whatever you would use. Like always trying to, you know, be in which version of language is supported in this certain code base. Doing that in the gem file or something like that, locking that thing, or even understanding the syntax to define how you would roll up to a different version so I can support this version of Ruby to this version of Ruby. It's just been a challenge.

And so when I spoke to barriers of entry, that's what it is. You have to learn so much ceremony, which is, over time as being a developer, you will learn these things. But on day one, if you can remove that friction, and this is one, a ton of time savings for existing engineers, existing teams, et cetera, but then also removing that barrier to entry. Like, it's just. Yeah.

Yeah, I can play on that a little bit. I mean, I was speaking to a principal engineer inside of GitHub yesterday. And I was like, he's been here for almost a decade. He's just excellent. You know, at some point he's going to turn into an Octocat. Like, that's just like, he knows GitHub through and through. And I asked him, I was like, you know, how many hours a month do you think roughly you kind of lose in productivity when like, it's like environment breakage issues, right?

Something kind of unexpected enters the environment and kind of throws you out of flow. Or maybe you have to like refit your environment to explore some PR or a new project, et cetera. I was like, give me your read. And now you have to remember, this is like one of our best engineers, principal level. Like this is like, you know, kind of a best case scenario, so to speak. Kevin said he's losing 10 hours a month, right? On basically like lost productivity time. And so at GitHub scale, you can start to do the math there, right? And assume again, that's best case. You know, we have 1000 engineers, right? So Kevin's losing 10 hours a month, you can do the math,

extrapolate that over the course of a year, and just getting back that time. And it's not just like the recovery of like engineering time, right? It's like the recovery of value creation time. And it's not just like the recovery of like engineering time, right? It's like the recovery of value creation time. And I think that's the most compelling part, right? So it's not just like, oh, well, you know, we lost this much kind of productivity time. Really, the loss is like, what did we not build in those moments? Like, what did we not get accomplished in those moments? And I think Codespaces, you know, kind of removes that class of issues again, and keeps us focused on creating value. And to me, that's like that's so refreshing.

Like that's what I want to be doing when I'm at work. Like I want to be, you know, building kind of my impact story and building software for the industry. Right. Like I want to like get up as this high leverage moment. Let me let me ship high leverage, you know, impactful code and not toil over my environment. Why do you think now is the time for code spaces or just in the cloud development? Yeah, I think all the raw ingredients are kind of like now there, right?

And like a lot of that, like the raw ingredients aren't just like tech. Some of that's just like how the industry thinks, right? So like containers have been on a tear now for years, right? Like containers are kind of everywhere. Like you see maturity across the industry with respect to like container-based workflows. So containers have been on a tear now for years. Containers are kind of everywhere. You see maturity across the industry with respect to container-based workflows. But I think another kind of critical part around this was skepticism around cloud-based workflows is basically non-existent at this point.

I've been in the industry for a while, and maybe a decade ago, you were like, oh, I would never move that thing out to the cloud. That's got to run on my precious kind of racked hardware here in this closet. Like that mentality is effectively gone, right? And like we're moving more and more precious workloads to the cloud on a daily basis. And like there's no reason we can't do that with our development environments today, which are kind of like single track, right? So we talk about these being, we think about the laptop being kind of a bit of a constraint, right?

It's like this one curated bespoke environment, the only place I can work. And it's like, what, like, why do we kind of have that arbitrary constraint when we don't have to? And then of course, like, you know, VS code out there is like, obviously another kind of key part of this, right? So it's like this super powerful thing. And like, we look at, you know, the idea that containers are everywhere. We have VS code, this really powerful tool that we work closely with, and we've got the fact that the industry now has broadly adopted, exclusively almost adopted the cloud. It felt like we had the raw materials in place to go pursue this. That's interesting that you mentioned that, too, because I was thinking about the timeline and just the perfect,

I'm not sure if this is the best way to say it, but the perfect storm, really. You've got the trajectory of Microsoft supporting open source and Linux. I'm not sure which came first, if it was Linux and it was open source, or open source then Linux, then obviously the acquisition of GitHub, the long-tail investment of VS Code,

and not just the investment into it, but then also the community's support of it. I mean, there's a lot of Vim users out there, but there's so many VS Code users out there, and they're diehard, and it's support of it. I mean, there's a lot of Vim users out there, but there's so many VS Code users out there. And they're diehard, and it's just so much. Yeah, I mean, VS Code is just a powerhouse right now. And I mean, it wins business because it's an incredibly powerful tool, right?

And that's what we're focused on with Codespaces, and you see it with VS Code. You just want to build kind of best-in-class product experiences, right? And then the users will follow, right? Like people are looking, developers especially, are seeking kind of productivity, right? Like if we gave them a tool that didn't make them more productive, they would just reject it out of hand, right? And that was kind of the North Star for, I think, Codespaces, which is like this has to unlock productivity for us, right?

Like it cannot at all create any kind of drag or we will just lose to to kind of like local desktop development flows like it has to be in parity with that and then add some uh for us to actually you know enter into this space successfully so you said something interesting about the preciousness of our development environments and i'm with you that we've commoditized the servers but we definitely have not commoditized dev because it's so it's so intricate it's so set up. Sometimes it's like, there be dragons, please don't touch my laptop, right? Because it works right now,

but I'm not sure if it's going to work tomorrow. I do hate that. I think it's almost a different skill set of maintaining that. I mean, there's overlap between development and the maintenance of a development environment in terms of things that you need to learn, but it's almost a different task altogether.

So I don't like that about it, but it's still very true that our development environments are precious to us and they're tweaked and configured and customized and all the things. So I'm sure there's probably lots of resistance to this. We talk about our setup, you know, We have probably tens of thousands of lines of code and very few dependencies in our stack. But GitHub is 14 years old and there's a million plus commits. And I'm sure the dependency list is very long. What kind of effort was this?

And tell us the story of bringing it along. It is. These are all very, very, very true points. Yeah. You know, the last thing I wanted to do was kind of be the vessel that went out to GitHub and said, like, I want to change your development environment. Right. Like, because these things are like so precious.

Right. Like, I'm an engineer, too. Right. Like, I think my environment is very, very much precious. Right. And here I was, you know, kind of the face in GitHub of saying like, well, we think we have a better way. Come join us over here. And, you know, I couldn't have done,

I started off on this journey as a skeptic, right? And I was, I think I shared some of this too. It's just like, it wasn't, I didn't think that, you know, I didn't think this would be a fruitful journey necessarily, right? I was just going to go do my level best as an employee, see if I can make it happen,

build momentum, et cetera, and see if I could find something out there. And now on the other side of this journey, you know, I feel like I'm completely on the other end now where I'm just like, this is the future, right? This is the way that we will absolutely kind of build software. But, you know, going back into the core of the story, like it was literally just me out there calling on my friends to begin with inside of GitHub. I've been there for five years, right? And the first few users were just me tapping into relationships saying like, hey, can you give this thing a shot?

Can you try this out? I want to get your kind of feedback and feelings about where this is at. And no one could yet use it on our core repository. We call it GitHub, GitHub, right? The organization's GitHub, the repository's GitHub. We didn't have this thing standing up in a code space yet, but we had other repositories that were compatible with code spaces.

And so I'd go out and ask, you know, favors of friends, right? And just be like, can you try this out and give me some feedback? And generally the feedback I would get back was, we have first resistance. Like, why would I do this? Like, it's just gonna, it's productivity loss,

tax on productivity. I don't trust HTTP. There's gonna be lag, like that kind of feedback. But then people would try it and they'd come back and be like, huh, like that was maybe better than I thought. Right. So that gave me some sort of like, you know, I was at the same time kind of, as I hacked in the space too, I was starting to get some of that like, oh, well, there's some, something here. Right. The big aha moment for me was connecting VS Code into my code space out in the cloud and still retaining that kind of local development experience, right? So it felt to me

like it was still very local, like, and the kind of magic is the synchronization that's happening between the local environment and the cloud feels totally transparent. But that aside, you know, it started with just a very small number of users. And so, you know, we would go back to leadership and GitHub and talk about the progress we were making. And, you know, the early days, the story was, I have five people that, you know, have responded positively to Codespaces. Right. So not much of a story, but like, you know, starting to kind of make a little bit of progress. And then maybe it was 10 people. And then, you know, the next kind of like iteration on this was like, well, let's go find a team, right? Like let's get a full team and Codespaces. Like how can we get a single team? So

six to eight people, right? Committed to using Codespaces and like stick in this thing. And at this point we'd had this kind of other effort running on the side to get GitHub, GitHub, the core GitHub.com repository compatible with Codespaces. And we'd gotten it to a point, we detail how we did this in the blog post, but we'd gotten it to a point where performance was mostly acceptable.

And so now we could go shop this with a team that worked primarily on GitHub.com and see kind of what their experience was. But I think we're making progress there. So we're ramping in. I think you all have talked to Kyle Daigle in the past. Kyle was the leader of that effort that kind of got this team spun up

inside of Codespaces on GitHub Core. And again, it was, you know, somewhat retentive. Like people were sticking and going like, wow, this is not what I thought, right? It's better than maybe what I thought. But I think the real kind of breakthrough moment came when we stopped calling this dogfooding, right? Like you hear this term all the time, like dogfood.

I think it actually originated, I looked up on Wikipedia, like I think the term originated inside of Microsoft. A number of years ago. But GitHubbers, my colleagues, just don't respond well to that term, right? Like dogfooding isn't really kind of like, doesn't inspire anyone to go do anything, right? Just like eat the dog food.

Like who feels good about that? And so what we did was we launched what we call the GitHub Computer Club. And I would love to like dedicate a full episode of this. It's like a really interesting concept and something I hope to bring out to the industry. But we asked people to join the GitHub Computer Club. And in doing so, so, they took this commitment or oath. I wrote up this script. I do solemnly

swear to never, no shadow compute, no desktop compute. I'll join this thing and forever be member of the elite exclusive GitHub Computer Club. We made a bunch of noise about it. People loved it. People straight up were just like, this is great. Let me in. I want a membership card.

Right. And in doing so, like we had to give them something in return. So they would join the computer club. But we offered to, you know, our exclusive quote unquote members, what we call the concierge team. And this team was built to kind of support their productivity and success inside of Codespaces. So the second these people hit friction, you know, one of the requirements of entering the computer club was that you had to kind of raise your hand.

Like you couldn't just disappear and go back to local desktop. Like you had to raise your hand, you know, virtually raise your hand and say, I'm about to opt out of this because like Codespaces can't keep my business right now. And the concierge team that we had built would like a swoop in, right?

Like respond to like, what's going on here? Like, let's dig into it. Why can't we keep your business in C spaces? And we continue to play that model back and forth between computer club and concierge team, right? Until we had built the product and built enough momentum inside of GitHub that like we, you know, one day we kind of looked around and we were like, whoa, we have hundreds of people developing github.com and GitHub code spaces. And I think the real story is there is just like, you know, commitment to make it happen, right? Like we wanted to be

successful with this and not just go talk about it in the market, but actually show that like this is a better tool for us. And the, you know, the Computer Club is still going strong. People are demanding that I give them like satin and denim jackets. I'll get around to that at some point.

Well, I hate to break it to you, Corey, but GCC is already taken as an acronym. So you've got a namespace on that one. Yeah. Well, maybe the code space is Computer Club, so we can go with GCCC. There you go. All the C's.

I like this aspect because you treat this like a customer scenario. Like you built a product and you have to retain customers. And you're actually exercising a great principle for anybody building a product, which is talk to your users. And when they have trouble, swoop in, as you had said, and understand those problems and be committed to fixing them. And I think that's a great way, a great story for how Codespaces became powerful inside of GitHub, because that's exactly how you build a product. Not just, let's just try this thing and hopefully our internal team adopts it by force. As you had said, you know, you,

you know, you wanted to go along with your employee card and be able to see if Codespaces could work. And out the other end, you became a believer, but you're not forcing GitHub engineers to use it. You're asking them to try it. In this case, the computer club with the oath. And then as you said, you look up and you see hundreds now. And I think that's right. Like the position was like, like no fiat, like we didn't want to lead with like, you have to do this. Like that's the absolute wrong way to get adoption in your product. Right. And like, we wanted to literally win the business of our colleagues right so like we wanted to build uh such a fantastic experience in code spaces that people would choose it right and yeah i think the computer

club probably you know kind of boosted adoption a little bit no doubt about it but like what made that word motion in there you gotta put emotion in there yeah exactly right i have a soul it needed some soul behind it right now? That was the idea. And the fact that we did respond to this, we actually did win business. When things didn't go well and when people wanted to opt out, they could.

They would for a week or whatever. But the goal was how do we get them back in here, kind of remove whatever that impediment is and get them productive in code spaces again. So what happens if you take the oath and you go back? Do you chop off a finger or what's the penalty? Well, you know, we leave that intentionally vague, right? So people can assume the worst.

No, I don't know that we've had any real regression there just yet, which is good. Codespaces is super retentive. I think we have people from time to time use local desktop. I had a colleague, this is actually I think in the blog post maybe, a colleague of mine reported the other day, she said I was using local development, my environment broke, so I opted in the Codespace or I switched over to Codespaces. And she was like, I actually shipped my task in my Codespace before my local development environment rebuilt and that was just like i think everyone was like wow that is such a good good story and so true it's like kind of the experience we're

all having right now with with code spaces we talk about it again in the blog post you click a button the environment's live right so like for every new engineer that joins github you know i think they all are probably fairly spoiled at this point because like day one, they click a button and they're able to run that environment, like the entire GitHub.com environment. It's just been like really incredible to watch. So Corey, the way you've explained the flow of this GitHub Computer Club seems a little smooth. I got to imagine you hit some friction. Can you share some of the struggle that you hit, some opposing forces in the process of rolling this out? Yeah, I mean, it basically started with a bunch of no,

honestly, kind of throughout GitHub. I think people had seen previous iterations of Codespaces. We announced it, I think, in May of 2020, right, at GitHub Satellite. Yeah, the first tweet I saw about it was Kelsey Hightower's, actually. Okay, yeah. That's May 2020. It's been out there for a while, right?

And I think when people first tried to use it inside of GitHub, there was a bit of friction, right? It didn't work for them. And I think first impressions can sometimes be lasting impressions. And so when I went out there and I was just like, use this thing, it's great, it's really evolved, right? We feel pretty proud of it. It was just a bunch of kind of no left and right right and so then it became like how are we going to build

this business and yes the computer club was a big boost and the concierge team certainly was just like a huge probably the most kind of high leverage kind of practice we we discovered along the way but a lot of this was just like startup style practices like we're building a business inside of github and i think that's maybe useful context for anyone that's looking for trying to build adoption of their, their own products in house. Right. Like you've got to think of this sometimes as like,

this is your own business. How are you going to build it inside of GitHub? And when, what is a very kind of stubborn audience? Like we're, I'm a developer. I can say that like somewhat stubborn. We find our,

you know, we find the tools that work well for us. And if someone comes and says, I want to change those, your response is going to be, don't. Don't touch my local dev environment, Corey. Yeah, and we'll get to this in a second. One of the great parts about Codespaces

is that we just commoditized the compute part of this. The environment is now running somewhere else. But dot files, VS Code setting sync, VS Code extensions, right? We bring those all to the environment, right? So you don't lose your kind of like curated workbench, right? If you've got a.files repo set up on GitHub right now, we bring that into the compute environment

and kind of like, you know, bring your environment and kind of your personality, your expression of yourself captured in code into that environment. We bring your workbench out to your compute, which i think is just like a really nice touch right so you get this like you get the the sort of unburdened compute out here running in the cloud so you freed up your local machine but you can still bring your preferences into that environment so i i digress going back to kind of building the business a little bit you know it felt like startup tactics

right so we had the concierge team we we had a computer club, we had effectively like, I would say guerrilla marketing. Like we were out on Slack kind of every day looking for opportunities to say like, have you tried Codespaces, right? So people were receiving, you know, M1 Macs, right? Like M1 Architecture Macs. And like the GitHub, GitHub build just would not yet work, right? We had not put in the investment to make this the GitHub, GitHub build on run on an M1 Mac and so we'd say hey have you tried to code space yet and people would be like well I guess I'll try that feels like my only path right now and they'd click a button they'd come back an hour later or day later and just be like what in the heck like this is incredible how like how is this even possible and those people you just win

for life like they're just like and now and like that's their their kind of like full mode of operating so that was the kind of guerrilla marketing angle we did pairing sessions like so we were up in front of everyone all the time saying if you want to get started like here we are like we're going to hold your hand through this and show you the ropes right like show you how we're doing kind of social proof i think was just really valuable there all hands would get in front of the entire company and demo the thing and be like look at this it's incredible you just try to build hype right connected with the right people so you know i'm kind of maybe loathe to call them influencers but you know the people inside of github that you know every engineer look up to right like they

look up to them and say like this is the person that you know i want like i aspire to be at some point you know we converted them like we won their business and they're kind of is the person that, you know, I want, like I aspire to be at some point, you know, we converted them, like we won their business and they're kind of like the trendsetters and tastemakers internally. And then really it boiled down to kind of like, I think, ruthless prioritization, right? So we listened to our users, what do you need? And we demonstrated that we could follow through on those things, right? For some reason, someone was trying to run some, you know, arcane karma test somewhere that wasn't executing for them. It's just like, all right, great.

Let's figure out how to make sure that works in this environment. Like that kind of thing, you know, even small tasks like that were important and kind of building momentum. And then I'll say it again. One day we just looked up and we'd gone from a bunch of no to a bunch of super fans inside of GitHub. Like we have cheerleaders. Like, if you go out and look on Twitter right now, the day after we kind of announced Codespaces to the world, there were just, like, GitHubbers were out there very enthusiastic about the thing.

And it was a very genuine response. Like, we didn't ask anyone to go do that. People are just that enthused about what we felt. Yeah, I saw a tweet from Kelsey Hightower. Again, I'll mention Kelsey. I don't know if this tweet was actually towards Codespace as the announcement but the timing was the same day I believe so I think it was a sub tweet around it but he said back in the day we wrote code on our own computers

so I had assumed that he was reflecting on Codespace as an announcement but I didn't I wasn't sure of that I saw that too I mean you used you used to run your server in a gray tower, beige tower underneath your desk too, right? Those days are gone. It kind of feels like this is the outset of this next wave of like, we're now moving development environments out into the cloud.

It just feels to me like two years from now, we're going to see some incredible adoption in this space. You mentioned a bunch of no's and the adoption flow. At what point was Nat a believer in Codespaces? You know, Nat holds a very high bar, right? So I remember as we were trying to get GitHub running inside of Codespaces, I'd go back to Nat. We'd show him like, hey hey it's now instead of 45 minutes it's 20 minutes

we've made these changes and he was like that's super cool not good enough right and like we totally agreed we're like yep

it's not good enough but like just wanted to show you progress get that feedback and then we'd come back again and say like we're down to 10 minutes that's great

it's not good enough and everyone's like yeah you're right it's not good enough it's got to be seconds right for it to to be the experience

we want. And so that was kind of the iterative experience. I think Nat has been a believer in this, like where this thing could go from kind of the outset, I think, of the journey. It's just been a bit of a slog as we weren't from the very early days of like, look, we have all this tech orchestrated that can produce this effect of a code space, right? The maybe early prototype down to like now the 10 second story inside of GitHub, right?

That didn't happen kind of overnight. But the good news is like most of that and almost all of that now has made it into the product itself, right? So like the changes that we've discovered along the way didn't just benefit GitHub, GitHub and the GitHub.com repository. It benefited the entire product.

So I think Nat's a super fan now. I've got some screenshots from Nat that I look at from time to time that keep me pretty enthused about the progress we've made. Even in your blog post, you took us on a journey from, I think, hours to 45 minutes to five minutes from five minutes to 10 seconds. And so I don't want to gloss right. i got a question around five to ten seconds but i don't want to gloss over the full journey is there anything in like the you know hours to 45 minutes to five minutes that journey is worth sort of shallow cloning sounds like it was a win yeah shallow cloning was a big win yeah

so like when i first got involved in this and i would just try to start a code space right i would sit there for 20 minutes staring at my terminal while I waited for the clone to complete into into a code

space. It's like gigs right 13 gigs. Yeah. Yeah. And that's like no way to like I mean I can't like

honestly I can't believe I had the perseverance to do this I was spinning up tons and tons of code spaces just like and kind of watching

this this churn by getting more and more frustrated. So no one else would I mean you wasted. You wasted your time on someone else's. I mean, you wasted a lot of your time. That's right. Yes, that's my love for Codespaces, right? There was no bounds.

I put in a lot of time just, you know, trying to get to the point where I could say this thing works. And so, yeah, shallow caching was a big, I think a big step forward for us where we went from 45 down to like 20 minutes or something like that. And then the next big leap for us was caching as much of the bootstrap activity as we could well ahead of time in a GitHub action.

So we have a nightly job that runs and basically sets up 95% of our environment. That got us down to like super tight times. And then the final step was this idea of pre-build, right? So when a code space is provisioned, you know, we clone your repository, we stick it out into some storage, we attach storage to compute, and we run some lifecycle commands on that. That's kind of the very high level overview. And with pre-builds, we kind of do all of that ahead of time, right? So the thing is built, like it's ready to go. There's really no startup time. You just connect the pre-built image to compute

and you're off and running. And that was kind of the last frontier for us in terms of speed. Now we're going to continue to invest in speed. I've said this a few times to folks recently, but fast and reliable never go out of fashion. And they're going to be absolutely critical for us in code spaces, right?

Like when you think about your ID, what do you want? You want fast and reliable, never go out of fashion. And they're going to be absolutely critical for us in code spaces, right? Like when you think about your ID, what do you want? You want fast and reliable, right? Like you don't want to feel lag in this environment. It has to be always on, always available, right? So, you know, we want to continue to invest in these things and we will over and over and over again. Pre-builds right now, I'll just go ahead and share that currently in beta. So we're onboarding customers into pre-builds, right? We're working with customers directly on their pre-build experience. We'll be getting this out to market relatively soon. Because this is the story of GitHub using Codespace.

That doesn't mean that every enterprise that is in the sweet spot, that has a large enough organization, that has the scale of an organization that can actually, you know, leverage the time savings. Sure, you know, small teams might win potentially by going to the cloud and that may prove successful, but this is GitHub store using it. And these are the things you've had to do to get there, which is pre-builds and, you know, shot cloning and whatnot. Yeah. I think, you know, I think that, you know, that's why we launched, I think, with teams and enterprises first, it fits that that's why we launched, I think, with Teams and Enterprises first. It fits that use case

super well, right? Like, no doubt about it. And there's lots of Docker competency in those organizations, container competency, etc. But I would also say that it's, like,

very easy to get started with Codespaces. So, like, I don't want to scare anyone away with a GitHub story. Yes, it took a ton of work, but a lot of that now is just part of the product,

right? So, like, we've done the discovery and then we've captured that in the product itself so even if you don't know like anything about like say docker containers for instance like you can launch a code space today and it drops you in kind of a default image that has the tooling for you know so many frameworks that you're used to kind of working with node or or Rails or Java, et cetera, right? So it's like a default option. And then we maintain a community-powered repository,

VS Code Dev Containers is the name of the repository, where there are, I don't have a number offhand, but let's say hundreds of community-powered images, right, that you can reference in your devcontainer.json and launch immediately into an environment that's, you know, well-suited for, let's say, Ruby on Rails, for instance, right? you can reference in your dev container dot json and launch immediately into an environment uh that's you know well suited for let's say ruby on rails for instance right so like it's not you know it's not this like oh you have to be a docker uh you know expert to be able to use code spaces whatsoever there are all kinds of you know kind of uh easy entries um intoodespaces. So there's a discrepancy in the numbers.

You have 1,000 engineers and 600 on Codespaces. So are there 400 holdouts or does it not apply to them? Or what's the situation with these 400 stragglers? Yeah, it's a good question. Our efforts have been primarily focused on GitHub, GitHub, right? The core kind of GitHub.com repository. There are literally thousands of repositories inside of GitHub, probably hundreds right? The core kind of GitHub.com repository. There are literally thousands of repositories inside of GitHub,

probably hundreds of active repositories. And so we need to go win the rest of GitHub's business, right? So like the story right now has been primarily focused on the majority of development inside of GitHub and that's through.com. So I think I mentioned this earlier too, but the intent is sometime in September to kind of sunset macOS development as the officially supported platform and pour all of our energy into Codespaces for.com development.

And this will start to kind of push out into other repositories inside of GitHub. This is a big push too, even internally. I think you mentioned a little bit in your blog post, the Mac OS-centric nature. Even the, I guess, the challenge of the transition was pulling away from a Mac OS-centric dev environment to something that was more Linux-based, Linux VMs that are being run inside of code spaces. Can you speak to that a bit? Yeah, I think there's years and years and years of assumptions

that we were always going to develop on macOS. And it's interesting because you think about CI, for instance. You try to get CI as close to your production, resemble your production environment as possible so that you're guaranteed that the integrity of your code in this environment is likely to transfer into production. But development, we had this weird gap where everyone was kind of on macOS, loves macOS.

I'm a big macOS user. I'm not going to convert to a Unix platform for development. Like that's just not kind of the way that I want to work. I quite enjoy being on macOS. And so the good news here is that we didn't have to convert anyone to a Unix platform. And in fact, maybe those on Unix also were quite happy now because they can continue to use Unix platform. And in fact, maybe those on Unix also are quite happy now because they can continue to use Unix

platforms. But you stick on Mac OS, you use VS Code or you use VS Code in the browser. It's the web UI for Codespaces. You're able to stay in your environment, so your Mac OS environment. But now we've just moved the compute away. The compute is running in a container

out on the cloud. And to me, again, maybe I've said this already, that was the magic moment for me with all of this. The kind of big aha breakthrough for me was I'm still kind of on macOS. I'm in VS Code locally. I'm getting this native experience. My dot files are synced out, right? Settings syncs running for me. I'm using my extensions and I don't feel any lag like that. Like to me, that was just incredible. The fact that I could just sit here and like bang away on my keyboard and know that that code was somehow you know kind of like magically synced out into the cloud without me taking any action and now i'm able to open up my terminal and run my code um directly from ps code right and your fans probably aren't running

at top speed exactly yes a lot of this is like it's just kind of strange suddenly you're just like this is all kind of working together and working. I'm used to my laptop being on fire while I'm developing and it's no longer the case. Yes, right. Like Docker's not running on my desktop, right? Docker's running out on a cloud, right? And like, just a really cool moment and experience.

And like, you know, I had some skepticism around this workflow because of prior experiences I'd had out there some number of years ago using cloud-based development environments that didn't quite meet, you know, I think the standard that maybe every developer holds for themselves. But I don't really, I haven't felt any of that in Codespaces. So you mentioned that the lens that you're speaking from here today and the blog post you put out so far is around GitHub.com development. So there's hundreds, thousands, I can't recall what you post you put out so far is around GitHub.com development.

So there's hundreds, thousands, I can't recall what you said, repos being used inside of GitHub. So is it safe to say that as organizations adopt and use Codespaces, they're going to have to get specific about which repos they support on Codespaces and each repo or team type might need, like an API team might need different love and support

or concierge than, say, the.com of their business. Yeah, I don't think so necessarily. I just asked someone on the team a couple days ago to pull the list of repositories that have been active with Codespaces over the past couple weeks. And there were dozens that have now at least started to explore if not fully embraced Codespaces. And I think what you need probably is

kind of the, what's the word I'm looking for here, the flagship offering in your organization, right? So you need the one kind of reference point where you can show and demonstrate to other people how you've been successful with that repository. And that's GitHub, GitHub, or the.com repository for us. So we've demonstrated we can be incredibly successful with what is the most challenging product

inside of GitHub. Anything after this actually should just kind of be fairly easy. I don't want to, there's still some effort. But it feels like we now have a great point of reference for other people to latch on and adopt. When you have a 13 gigabyte repository with a lot of dependencies

and a lot of engineers, 600 engineers at least, based upon this smaller sample size of 1,000 engineers within your organization, that's significant. That's going to be hard to get onto a whole new paradigm for developing everyday software.

I think so too and like you've got to do it though like you like that like we've got it like you win the business because you you build a better tool right and i think that's what it boils down to like uh it shouldn't be about necessarily preference like what you want is like value and productivity like did we build a better experience and like can we actually become the preferred experience right that's really kind of what we're after here is like, as long as you're building a fantastic product that gives developers, you know, that feels like that, like they're more productive, they've got a better tool in their hand, like they're going to, like, they'll use it. Like, there's no question about it. Like,

I would never say no to a better tool. And that's what, that's what we see inside of GitHub, right? And it's not just like, oh, I've taken my laptop now and I've moved it out to the cloud. And in fact, I think we discourage that model. Like, I don't want you just to recreate your laptop in the cloud. That doesn't make a ton of sense for us, right? Like when I say us, I mean the developer community. Like we want to be able to work

in parallel environments, on-demand environments, reproducible environments, et cetera. So you don't want to go curate this kind of like bespoke laptop replacement in the cloud. You want to think about a thousand laptops, the infinite number of laptops in the cloud that you can provision on demand for the task at hand, right? So we think about these as kind of like task-based.

So we have a one-to-one kind of concept between I've started a branch and here's the code space for that branch. These kind of maybe short-lived, right? You work on a branch for a week or something. And with it, you know, your code space. And at the end of that, you'd retire that code space, spin up a new one for your next set of work. So let's revisit this dot feature, which is very exciting.

You're on github.com and you're on a repo. For example, I have the FCF repo open right now. I'm looking at the readme and you hit the dot, the period button the dot on your keyboard explain what happens yeah i mean that is right now i don't i don't know that we've given it like an official name behind the scenes we refer to this as the web editor instead of github right many people have called it github.dev a few have called it code spaces right yeah but the idea was you know we're launching code spaces right yeah uh but the idea was you

know we're launching code spaces right we we know it's kind of well suited based on our experience internally for teams and enterprises at this point right but like the ethos of github is developer first without a doubt right it always has been um and so when we launched code spaces we wanted to make sure that we could give every developer on.com a better editing experience, right? So when you hit that dot button today, you move into VS Code, kind of multi-file editing experience, right? So that's VS, fully functional VS Code

and the browser attached to a repository. And from that repository, you're able to do basically any kind of Git operation, right? So like you can open a PR in that space. You can make changes in that space, you can commit from that space. So like, there's a lot of like, code spaces similarity here, where it falls short, right? Like what, like what we don't do here is offer compute, right? So you can't like actually execute the code that's in that environment, right? There's not a terminal in that environment. And those things, you know, we offer up in Codespaces itself.

So, you know, the next story for us is like, how do we kind of connect these environments, right? So we want you to be able to move from.dev into a Codespace kind of seamlessly. And so that'll be some of the next experience. So to answer the question, you know,.dev is kind of a multi-file editing experience and, you know, the best, you know, editor on the planet as far as I'm concerned in the browser.

And it's something that folks have wanted from GitHub for quite some time. Yeah, this has now become the de facto way that I will peruse some source code on GitHub. I used to just sit there and click through the little slide by file browser thing and had some cool stuff like the command T or the integration fuzzy finder stuff in that ui but why do that now you just hit dot and then it just takes you to basically vs code in the cloud pointed at that repo it's awesome we i think it's awesome too and you know we saw the same experience inside of github so we built the thing we shared it internally and we said can a few people use this and kind of give us your feedback and experience? So, you know, tell us where it needs to improve.

And then I think we looked at usage numbers a couple of days later internally. And we were like, oh, wow, like we're creating a lot of value here right away. Like it's just like immediate uptake inside of GitHub. And I think it is, you know, the primary means through which people do kind of explore code now.

And that just happened overnight effectively, kind of when we launched the thing. I was on an interview a few days ago with a candidate, and we had just announced this. It was the day of GA and announce. And he was talking about how he uses GitHub as kind of the center of his learning journey, right? Like it's always been like, he said,

GitHub and Stack Overflow are my two tools when it comes to learning. So he's sitting on GitHub and I'm like, have you seen the.dev stuff? And he said, no, what's that? And I had him hit the. button. I'll just never forget his reaction. So satisfied in that moment. He's like, what is happening? This is incredible. It's like so great. And it was just a really neat

kind of moment to have. This is very much an on-ramp then, I would say to comfortability with Codespaces. Life in the cloud. Life in the cloud, yeah. I mean, I feel like you will see that transition at some point.

Like, you'll be in some environment, you'll want to make a change to it or like you'll just kind of want to execute it, right? Right. And so you'll be like, now how do I move into compute, right?

Like, we want to make that transition seamless for you so you can attach compute into this environment, do what you need to do. And then, you know, in other cases, it's just this read tool.

I would imagine the dominant use case of.dev is going to be primarily for just kind of reading and browsing. Gotcha, yeah. When I saw Nat's tweet on this and I connected the dots, I was like, okay, timing of your blog post and the announcement of your team transitioning to use Codespaces and this dot, and we're a team organization on GitHub. I'm like, hey, we've got Codespaces.

So I was like, this is sweet. I like it. Yeah, there's been a little bit of confusion around that. But I mean, it's been fine for the most part. I feel like I didn't quite give it a name. And I thought people would probably call it.dev. And we're seeing people largely call it.dev. But at some point, it will fold into what I think is a comprehensive Codespaces experience.

So let's say I'm on the Codespaces product and I have my customizations in there somehow. And we haven't talked about how you do that or that team level, hopefully it's personal. Hopefully it's probably both with a CSS cascade. It's a bit of both, yeah. If this was tighter integrated with that like with my extensions i'm looking at this the it's a stock vs code right even is

missing some language support because you probably just put like the top 10 languages in there would i bring my extensions into this would i bring my custom my vs code config into this and what would it look like yes i think dot dev today supports like setting sync for instance um and i'm pretty sure and i can't say this the 100 confidence i should go look into this right now at least in the code space aside you know you codify in dev container.json right you capture your extensions that you want kind of available in that environment we specify them for every engineer right? And you're able to specify kind of machine profile or SKU that you kind of enter into.

And then we bring, using Settings Sync, Visual Studio Settings Sync, we bring your settings that you've configured as kind of like your development environment and VS Code into that code space with you, right? So like that's there present with you. And then again, the.files repository, and a lot of people don't know what that is,

so I'll just clarify a little bit. So the.files repository is literally called.files, D-O-T-F-I-L-E-S, inside of your repository, or sorry, inside of your GitHub account, right? So if you go to github.com slash Corey Wilkerson, for instance, right, and you create a.files repo there, then any repo that I provision,

you throw a flag somewhere in Codes, for instance, right? And you create a.files repo there. Then any repo that I provision, you throw a flag somewhere in Codespaces settings, right? Then any repo, or sorry, any Codespace that I provision kind of consumes that.files repository content and allows me to kind of configure my environment in the state that I want it to be to develop. Which is great because you took over a paradigm that everyone was already using. I think people have had.files repos

Yeah, that's right. for pretty much ever either sharing them or sharing them between themselves with different machines or just being a share of natural open source

tendencies. That's one thing I love about GitHub is that oftentimes there is that little bit of magic that someone

somewhere along the way someone says you know people already have.files repositories. Like, why don't we just give them an option to just pull that directly into the environment? And you're like, wow, that is brilliant. Exactly why I love GitHub, right? Like taste, aesthetic,

like we know what developers want and what's going to feel magical. And like those moments are always just very, very cool to kind of trip into. You get like, you get a couple per project like that. And it's what I think makes GitHub just really, really special. So this is interesting.

I'm on github.dev. I'm looking at the FCF repo. I installed the Vim emulation extension into that VS code instance. Then I visit another repo in another tab and I hit dot, go to github.dev. And that extension is installed in this instance as well is this like a local storage thing is this attached to my github account how's that working yeah that's actually i think at this point using browser storage okay right

so like that's all that's all attached to browser storage that's cool i mean it's a nice it's a nice step yeah yeah there's a lot about that that's it's a relatively new product right so we're listening to customers and iterating, et cetera. But that's the experience that we kind of launched with at this point. Most of what you see in that environment, GitHub.dev, right? We call it browser compute, right? So everything that we're doing is kind of supported by what we can do directly in the browser, right? Like the story kind of stops.

There's obviously API calls that are happening in the background out to GitHub to bring the repository contents and allow you to push, et cetera, and get operations. But for the most part, it's like, what can we accomplish in the browser? Well, it's a new product slash feature, but it's in the running for probably my favorite new feature in many, many years. I mean, this is just spectacular.

Yeah, it's part of my daily workflow now. It's hard for me to... I don't know the last time I've cl it's hard for me to like I don't know the last time I've cloned anything to my machine I just don't do that anymore

like I hop into a repository to either.dev to look at the contents or into a code space to actually like change a thing and in fact

like I find myself like engaged with many more repositories now just because I have that access right like I don't have to go through this additional step

of like grab a URL clone it down, open it in VS Code locally, like all that kind of stuff. It's just like gone for me now. So interesting to see, you know, at a macro level, what kind of impact this will have on like productivity, exploration, contributions in OSS. Like how is this going to like meaningfully change?

Well, like the in-browser editors definitely helped with the drive-by contributions, right? When there was a typo or there's like a thing that's missing and you could just edit it right there in your browser. It took you away from that friction. Again, doing the clone, all the things you just described. But when it came time to do slightly more complex things, we all went to the clone process, right? Whereas now maybe we just go into this editor

and like you said, it might really ramp up like slightly more complicated contributions i mean you couldn't be more right about this like i can tell you uh you know mr manager inside of github right a bit like i've been in management for a while and you know at one point yeah i was a very good programmer i like to think but maybe not so much anymore uh and it's nice to be able to hop into a thing and make a few changes right just like straight away without having to deal with all the environment complexity render the thing when i'm in a code space and see like actually that did have the kind of like intended or desired effect that i hoped it would and then maybe i knew that then

i have the energy to kind of like take it the rest of the way right so like there's all these kind of like the tech is super cool the experience is super cool the thing works really well and you're like wow this is incredible we're finally here as an industry like we finally made it this moment that that's great but this is like other story of like so what does that mean now now that we're here like like what happens like it seems incredible like the the the kind of second order effects we might see of having now reached this place where this is a viable option for development so here's a couple of grab bag questions about Codespaces, kind of the DevEx. If I'm actually using it, how does this work?

What does this feel like? The first one is test data. So when you're developing, you like to have like something that is like a snapshot or looks something like what Prod looked at at some point, or maybe you want to generate a bunch of test data. How does that work inside of the code space is set up so i can tell you the github

engineers today so for the dot com code base right we have a number of seed scripts right that we use to kind of see the database ahead of time right uh and those are executed in our bootstrap processes and those are done in pre-builds today so by the time you provision an environment today you're up and running on your your dot com code base you cdata ready to go um in your database i expect we'll see the same same pattern across you know anyone using code spaces and then like you can do the same thing like off on your uh off on a branch as well right so like instead of like this is really cool to think about so instead of now having having to destroy your local database environment because you want to review someone else's change that makes modifications to that database,

that doesn't happen anymore. You're looking at a different code space. You're experiencing these changes in a clean environment, clean context. You've got your stable code space over here, but maybe you have versions A, B, and C out here in discrete code spaces that are making what would otherwise be destructive changes to maybe your main branch that now you can explore without any kind of repercussions into your local environment. Well, it's like you said, you have access to infinite laptops.

Exactly. I think that's a different change in paradigm. It's like infinite branches at once versus like single branch. It is. And that is the thing that the industry is just like, it takes a second. It does. You're so used to working in this one model It is, and that is the thing that the industry is just like, it takes a second. It does.

You're so used to working in this one model, and you just have this mental model of that's how we do development. And then at some point on your Codespaces journey or whatever, you're going to find a moment where you're like, actually, no, the real model that I want is this kind of task-centric model. This pre-build, though, I'm thinking about it from a changelog.com perspective. We back up our database to S3 pretty four or five times a day, Jared, or on the hour. What's the time frame again? It's either hourly or every three hours, something like that. So I'll often literally go and hand-pull that from S3 down to local, and I'll run a script that we have in our repo.

I'm wondering if in a Codespaces environment, if we had pre-builds that we couldn't codify that into, say, a GitHub action or the process of creating that pre-build. Go grab that latest production database. Yeah, you wouldn't even need a pre-build necessarily. I mean, pre-builds will make it faster, right? Like at the end of the day. But you can do that without pre-builds

too, right? It's just a container, right? And there's lifecycle events in that container that we fire. One is called post create command. And then post create, that means the source has been provisioned onto your code space. The code space has stood up. It's live. It's ready to go.

And we can call this lifecycle event. You can hook into it and you can say, now go grab this thing from S3, pull it down, hydrate it in this environment to do whatever. Right? So like we give you kind of lifecycle hooks and I can't enumerate them all. There's several out in the documentation

you can read about that allow you to kind of hook in and do things at certain points of time. But it's certainly you could do it and just like you could build your own image right now. So GitHub does this. We have a base image that we use, that we specify in our devcontainer.json file, which is built ahead of time

that gives you most of the GitHub environment, right? And then with pre-builds and a few other tools, we take it just the last mile. But like 95% of this is built for us on a nightly basis and ready to go. And that's not pre-built. That's literally just building a Docker image. We publish it to the GitHub package registry

and then we consume it in our code space by referencing it in the devcontainer.json file. Sorry, I'm getting a little technical there. No, please go there. I think the next thing I want to ask you to do is just dream with us then. So if this is today, where will tomorrow be? Where will Codespaces take teams

that now have this capability today? That's unheard of. And the compute, a one-line compute chain based upon your blog post, a 16 gig memory instance to a 64 gig memory instance. Yeah, that's a really incredible experience like and like i you know i put in that that quote i think there's a caption in the blog post that says something like you know bypass config one config change and bypass the global

supply chain bottleneck yes yeah which is totally true right like you can now just say well we want to 16 cores or 32 cores or whatever and config and upgrade everyone's machine if you want. Assuming that you've got the approval to do so. Right, within your organization, sure. It's possible. Be responsible. You're describing the possibility, not the adherence to standards or internal organization opportunities. Yeah, exactly.

Right, right. This is just a thing that could be done. Well, dream with us. Where is this going to go? Yeah, you know, I I'm going to get out. I'll go so far as to say, like, I think the majority of the industry is probably using this model five years from now, right? And that actually feels pretty far out to me. There are a lot of people in this space right now kind of pursuing this same kind of thing.

And I think what we're going to see is just a lot of momentum as we kind of move this last frontier out into the cloud as people get more and more comfortable with it. It takes people like GitHub saying like, we're doing this and actually kind of like living the experience and doing it. I think the first folks we'll see, the early adopters

are going to be really high performance engineering teams that look to get, you know, every ounce of productivity and value creation out of their engineers that they can find on a daily basis, right? Like they understand that productivity loss is bad for the individual. It's bad for the business. Like people want to be focused on basis, right? Like they understand that productivity loss is bad for the individual. It's bad for the business.

Like people want to be focused on creating, right? That's why you kind of get into this. It's not like you want to toil over your environment. You want to go build something. And actually, if you look, you know, you kind of like, if you're in the industry, you understand that many of the top shops out there have built something like Codespaces.

I'm not going to name names here, but there's a few customers that we work with that would, for instance, run their CI suite, run CI tests out in some environment, and then just leave the environment for some developer to claim and work on at that point. The entire

thing's set up. You can just attach to it and work now. And other large shops, I think actually Google's well-known for their CIDR cider ide a web-based ide that they've used that they love as far as i understand that provides some of these same capabilities internal to google so like the early adopters are already there in many ways right i think github is kind of the the brings this out to the entire industry i think you'll see kind of a similar kind of maybe cloud adoption curve from like you know we move workloads from our precious server rack out into the entire industry. I think you'll see kind of a similar kind of maybe cloud adoption curve from like, you know, we move workloads from our precious server rack out into the cloud.

Maybe you see something here with the same kind of curve with code spaces, but maybe at a faster clip now because we have this kind of industry trust in the cloud. So I really do think like it's going to be, you see GitHub engineers, I'll say that's coming into the industry right now, right? They're coming straight out of school, straight into GitHub. And this is how they're starting their development experience. This is the way they know how to develop now. And we're going to see this more and more to the point that five years from now,

I feel like local development will have disappeared in the background. You'll still need it for some cases, but majority of developers will want to be in an environment like Codespaces. What happens if that environment goes away? It seems like you're hung out to dry if GitHub is down or your credit card expires and you lose access.

Oh, Jared, trust me, I heard this question many times as we were ramping developers on to GitHub. I feel like I have a perfect response for that. No, you know, that is like, so first, we will continue to invest in being fast and reliable. Like, no doubt about it.

Like, this thing has to be, what Microsoft has this language, a dial tone service, right? So it's got to be like, and it's a bit out of date, but it's got to be on, like constantly on

all the time. What we've done internally in the event that we were to lose it, you know, access to Codespaces, we build an image that's much like our Codespaces container image, right? Kind of like tracks that environment closely.

And it's available for any GitHubber to pull down right now out of the GitHub package registry internally at GitHub. And they can just run it in Docker or they can use VS Code remote containers, right? Which is like a large part of the tech that Codespaces is built on, but you can just do it locally. So you can launch VS Code, you plug it into a container, you're running locally now. This image that we built is our backup

and you can do, you know, perform GitHub, GitHub development in that context on your local machine. So if a GitHub was on a flight, which in this day and age is strange and anxiety-filled, but I'm sure one day we'll get to a point where it's less so. You're going to want to code. You're going to want to be productive on that flight. Is that how they do it then? That would be the path that I think I would

use, that we would use right now. Yeah, that would be the path. I mean, maybe the platform evolves to some point where you can imagine we have VS Code, right? Like that's something that we work on. And you can say like, oh, well, we're a Codespaces user. How do I pull this environment down to VS Code right now? So I'm going to go offline. And how can I, you know, I can imagine that being a thing that we ship alongside VS Code at some point.

But right now, just telling you how GitHub does it, we kind of keep this local image in the background in the event that we do need to use it. And, you know, we've used it a few times, not because Codespaces has been down, but because we have folks that aren't ready to move. They're on certain repositories where they don't feel like moving or they want to use Sublime still or whatever the use

case is. We maybe haven't won the business of one or two engineers yet. So it's a thing that we have. That's our fallback. How integral to all of this is VS Code? It sounds like it's right, like it has to be there. I know you've enabled Vim people

and Emacs people to connect via SSH, but that seems like a workaround, or like a, here you go guys, here's something. Yeah, VS Code I think will always kind of be the premier client in the code spaces. Like, it's just the paved path that we have right now. Today, it's essential to

the experience, right? We do have a number of Vim and Emacs users internally. We want to win their business as well. And we've done the work inside of GitHub to do that. So something we're working on right now, where you should be able to effectively just shell into your environment, use Vim and Emacs directly in the code space, right? Without the VS Code client. So that's definitely on the roadmap for us and something that we're pursuing. We've built it internally. We were able to convert our Emacs and Vim users,

those that develop on.com regularly. Nat's a Vim user, right? I want to win Nat's business, too. So that's a very important thing for us to pursue. So one thing VS Code has done which is awesome is a language server protocol and really separating the implementations of the highlighting and the syntax stuff into this protocol

that you can then plug into. And then everybody who's doing a, maybe I'm in charge of Golang and I just have to do that once and provide it. And all these different Vim can use it, VS Code can use it, etc. You almost could see a layer like that for these cloud integrations where maybe you could make Vim code spaces aware somehow.

Yeah, I will say that's an interesting thought and probably something that we would explore at some point like Vim itself being kind of Codespaces aware. I like the way that you're thinking, Jared. Well, because there are a lot of people that just will not use VS Code. And you just wonder, like, are you just leave them in the dust eventually? No, I mean. Because how integral is it?

I understand that today it's like a bastion. It's a huge part of it. But is that wise on the long term? Because we're trying to get everybody into this circumstance over the, you know what I'm saying? Absolutely. I mean, like it's early days,

I would say stay tuned on what we're doing here. The work that we're doing inside of GitHub right now to support SSH and Emacs users, the story does not, or sorry, BIM and Emacs users does not stop inside of GitHub. Like we have no intent of just saying like, this works just for GitHub.

Like that's not where this story goes. We want as many people on Codespace, we think this is the future, the way that people will work. And we want to bring that to a number of clients. Right now, the super paid path is VS Code, no doubt about it. But if the focus is productivity, the focus is on building the next generation of developer tooling, we've got to go support additional clients as well.

For sure. Yeah, I guess my thoughts around VS Code, I mean, it's an amazing piece of technology. It is. And my concern with it on the long term, as I see more and more things going in there, is like eventually Microsoft Word had too many features, in my humble opinion.

And so my concern as VS Code over time is like, how well will that be maintained? And I'm sure the motivations are there and the engineering is there and all the intentions are there to make sure it's like best in breed editor forever. But what if it's not? And are we locked into it?

Yeah, I mean, all I can say is the VS Code team is super passionate about what they've built. I work closely with those guys and they have remarkable taste, that entire team from top to bottom. They've won business because of their

taste and commitment to developers. Like I said, it's amazing and it's impressive and we spoke with those folks on the show before and I couldn't agree more with you. On the long arc of technology, things do change over time and so

I just would like to see, are there options? Is there escape hatches? Could we have a heterogeneous? Does it all have to be one thing in the future? Or do we have options as developers? Yeah, I think Codespaces at the end of the day, I'll just say is,

we're running development containers and the cloud, right? That's kind of the core of the product. VS Code today provides the kind of premium path into that. We want to meet developers where they are, no doubt about it, right? There's like premium path into that. We want to meet developers where they are. No doubt about it. Right. There's like no question about that. You know,

I feel very fortunate to work closely with the VS code people and kind of watch them work right in the work that they've done today at night. What's made them special is just their conviction of building something fantastic. So same inside of GitHub, right? Reason I was drawn to GitHub, hold a very high bar for ourselves and just want to ship fantastic product.

If we don't ship fantastic product, we won't win business. The goal is to build the best in class product for the best engineering teams on the planet. Well, Corey, thank you for sharing the story and giving us a preview of the future. I suppose even the now and the future, you know, really. Join us. Yeah, we would love to work with you, like help you, Adam, get your product up and running on Codespaces. Yeah, let's do it. We will entertain that for sure.

We have a whole entire show called Ship It that's really about taking our application to production. I kind of feel like this is somewhat there because it's where a developer meets, go into production, which is actually coding. So I think we'd love to dig deeper into this for sure. So it'd be awesome to make that happen. Let's ship it.

Yeah, Gerhard's been talking about us doing our coding in some sort of cloud setup for a while. And I've always told him, like, man, the cloud's not ready for us, you know? You're going to pry this terminal out of my cold, dead hands. But things change, and I can change too. So that would be fun to dig into that a little bit. I'm totally up for the challenge.

Let's get together and try to ship it. Nice. All right. Corey, thank you so much. It was awesome. Thank you. Thank you. That's it for this special episode with Corey Wilkerson on GitHub Codespaces.

Corey started this journey as a skeptic and didn't think this would be a fruitful journey. Now on the other side of this journey,ora sees Codespaces as the future. The proof? 600 of the 1,000 developers inside GitHub are developing GitHub.com on Codespaces today. And all that friction for new users, that value creation time wasted, and everything else being held back

by the brittle nature of local dev can now be lifted by the promise and future of coding in the cloud at scale. What do you think? Let us know in the comments. I want to give a shout out to a few people behind the scenes on this episode. Jenny Chow, Senior Manager of Corporate Communications at GitHub. She played a key role in helping us shape the narrative for this conversation.

And Kurt Mackey, Co-Founder and CEO of Fly. Kurt is awesome. He's a big supporter of the work we're doing here at Changelog. And if you haven't tried Fly yet, today's a good day to change that. Check them out at fly.io. Thanks again, Kurt, for making this episode interruption-free.

Of course, huge thanks to our awesome partners, Linode, Fastly, and LaunchDarkly. Also, thanks to Breakmaster Cylinder for producing all of our awesome beats. And last but not least, thank you to you for listening to the show.

If you enjoyed the show, tell a friend. We'd love to have them as a listener. Word of mouth is by far the best way for shows like ours to get discovered. That's it. This show's done. We'll see you on the next one. Thank you. Game on