The present, past and future of GitHub

So GPT-3 came out right after the build conference in 2020. Kevin Scott and Sam Altman did a session about transformers and Dutch language models. And then after that, GPT-3 got into the preview and we got access to that through the OpenAI Microsoft partnership.

we realized together with OpenAI that it was able to write decent code in different programming languages and would not mix up the syntax between Python, Ruby, and JavaScript. And then OpenAI fine-tuned a model that was called Codex that was specific for these coding scenarios.

And so in 2020, in August, we wrote a paper with three ideas we had. Text-to-code, code-to-text as in describing code, and conversational coding is what we called it, which then today is known as chat. And those two letter scenarios didn't work very enough. But text-to-code as in prompting the model.

within the editor and ultimately building autocompletion that worked so well that very quickly we saw our internal hubbers adopting the tool giving it really high scores saying this is great i want to keep using this it's not the typical management says you have to use it and you don't

want to but ultimately writing in the early days 25 of the code in those files it was enabled and then shortly thereafter that number got into the 50 range or 46 i think early 2023 and so that was the early days of copilot and then june 2021 we went into the

the public preview. And within a few months, this had grown to a million users. And we saw more and more folks on social media saying, well, I was skeptical that this could ever work, but it actually is good enough that I don't want to work without it anymore.

start and how did a platform evolve? I sat down with GitHub CEO Thomas Zumke, who has been a GitHub user for 16 years, has been working at GitHub for seven years, and has been the CEO of the company for the last four years since 2021. In today's episode, we discuss... GitHub's remote-first and async-first engineering culture and why the company barely uses email.

why GitHub seemingly stopped shipping features between 2015 and 2020, and how they created GitHub Copilot in 2021. GitHub's interesting internal tools in the early days, like Haystack, GitHub TV, and HALP. How GitHub sees about 10 billion... API requests per day. That's about 120,000 per second. And why Thomas doesn't believe that autonomous AI tools would solve hard engineering challenges.

and many more topics. If you're interested in the past, present, or future of a high-growth company like GitHub, this episode is for you. If you enjoyed the show, please subscribe to the podcast on any podcast platform and on YouTube. Thomas, welcome to the podcast. Thank you so much for having me. It's great to meet a person after exchanging emails and putting a name to the face. And reading your newsletter every week.

Twice a week, I guess. I appreciate that. That's where interaction started. Before we jump into the history, I just wanted to go through a couple of just interesting things that people might or might not know about GitHub. Number one is a tech stack. It is pretty commonly known, or it used to be that this was Ruby on Rails monolith. At some point, it might have been the biggest in the world, and then I think Shopify might have come. But today...

Is it still a Ruby on Rails monolith, or have things changed? It's still Ruby on Rails, and I think it's still one of the largest Ruby on Rails applications. The other one you didn't mention was Twitter. It was in the early days also Ruby on Rails. In the early days, yeah. I think all three companies in one form or another have somewhat moved away from this being the only part of the stack. So we still have a large monolith with about 700 engineers within the company.

contributing to it at different times of the year. Not all of them are working constantly in the monolith. We actually just passed 2 million Git commits into the monolith and tens of thousands of pull requests. But we also have moved beyond just that one architecture. So for example, they're using more and more React on the front end.

We have a number of, you know, services that outside the monolith. For example, the Copilot API is written in Go, given it needs, you know, lots of API calls for inference. The GitHub Actions system are completely different tech stack. GitHub Actions. I would imagine Rails might not be the best for a very heavy workflow. And it has actually a history because a large part of the action stack came from what was back then.

Visual Studio Team Services and then became Azure DevOps and so Azure Pipelines. And so there was a lot of .NET code in that code base. And over time, we are now evolving that into a more modern architecture with the goal. of one of your other posts of getting to four nines and beyond. And so our tech stack is very diverse today. Obviously, we're doing also Swift for our iPhone app. We have Cortland for our Android app. We're using all the clouds beyond also having our own.

medal in commercial data centers and we have like a modern modern software company with all the complexity and all the challenges that that everybody else has as well and i guess all the not simple trade-offs for example it's easy to point you know the community loves to say

say, Rails does not scale, or why would you do it? But, I mean, you are one example. Obviously, there's other companies we mentioned that it feels like it's less about the technology itself, but what you're building on it and, you know, your history of it. I mean, we can spend a whole hour probably just talking. about the benefits of having a monorepo with a monolith versus hundreds of microservices.

You know, when GitHub in 2007 was founded for, I think, more than a year, it was only the three original founders, Chris, PJ, and Tom, plus Scott, who's now the... founder of Git Butler and Scott Charconnell, who is kind of like the first employee that was often seen as the fourth founder. And so, you know, a team of four is way better off of working in a single code base. You can move much faster. I think that was always the...

important for GitHub to be able to move really fast and ship new features. And it's much easier to get to learn the code base and try to understand the dependencies. As the company scales and the product scales, it makes more sense to move away from that architecture.

I'm so glad you're saying this. The other day I was talking with an early Amazon employee and he was saying the same thing, how early Amazon had made sense. And then as you grow, you figure out your trade-offs. If you want to build a great product, you have to ship quickly. But how do you know what works?

More importantly, how do you avoid shipping things that don't work? The answer, Statsig. Statsig is a unified platform for flags, analytics, experiments, and more. Combining five plus products into a single platform with a unified set of data. Here's how it works. First, Statsik helps you ship a feature with a feature flag or config. Then it measures how it's working.

from alerts and errors, to replays of people using that feature, to measurement of top-line impact. Then you get your analytics, user account metrics, and dashboards to track your progress over time, all linked to the stuff you ship. Even better, StatSec is incredibly affordable with a super generous free tier, a starter program with $50,000 of free credits, and custom plans to help you consolidate your existing spend on flags, analytics, or A-B testing tools.

To get started, go to statsig.com slash pragmatic. That is S-T-A-T-S-I-G dot com slash pragmatic. Happy building! This episode is brought to you by Graphite, the developer productivity platform that helps developers create, review, and merge smaller code changes, stay unblocked, and ship faster. Code review is a huge time sink for engineering teams.

Most developers spend about a day per week or more reviewing code or blocked waiting for a review. It doesn't have to be this way. Graphite brings stack pull requests, the workflow at the heart of the best-in-class internal code review tools at companies like Meta and Google, to every software company on GitHub. Graphite also leverages high-signal, codebase-aware AI to give developers immediate actionable feedback on their pull requests, allowing teams to cut down on review cycles.

Tens of thousands of developers at top companies like Asana, Ramp, Tekton, and Vercel rely on Graphite every day. Start stacking with Graphite today for free and reduce your time to merge from days to hours. Get started at gt.dev slash pragmatic. That is g for graphite, t for technology.dev slash pragmatic. Now, you mentioned something really interesting, which I also heard.

that you run your own data centers or historically have run your own data centers. But I talked with some current GitHub folks, and they said that you in some parts still do so. Why did you do this?

How is it changing? And are you, obviously, since you're now part of Microsoft as well, does it make sense to use some parts of Azure? And if so, what parts are you using? And you also mentioned other clouds. So like, how are you thinking of own data center, which again... We used to say, oh, it's just moved to the cloud, and there's now an opposite thinking as well. What's your take on this? GetUp started on the cloud. Really? In the early days, it was...

To my memory, it was engineered as a platform as a service provider and then AWS behind the scenes. Oh, okay. You know, it's easy to forget in today's world where lots of startups announce huge funding rounds. GitHub had no funding until, I think, five years into its journey. Oh, okay. Back then, unheard of $800 million. came from around led by Andreessen Horowitz. But until that point in time, GitHub was bootstrap. And it had very fast adoption when it launched in April 2008.

Very quickly, the number of users, the number of both public and private repositories kept growing. You can still find people talking about that they're begging the founders to introduce a paid tier. So they have the confidence that the company can survive, will be around. And so it was a natural business decision for the founders to say, how can we host this? or more optimized cost given that we are bootstrapping this and we're having to pay for the service from our own revenue stream.

And they couldn't be burning money because they had, you know, they had no money from venture capitalists. And so I think that was part of starting the decision. The other one is, you know, storing Git data, what we call today our Git systems team. in file storage in itself is probably not like the best use case for cloud services that existed, you know, in 2008, 2009, where you had limited access to that layout and where...

especially the networking part of having multiple nodes communicating with each other was much more complex than it is today. And so the decision was made to move to servers in commercial data centers. So we own the servers. We still own the servers and the racks and the storage and all that. But the data center is a commercial data center. So we don't own the data center. So it's owned in the sense of

I'm making air quotes for listeners. It's all in the sense of we managed, you know, the servers in those data centers. Now, today's GitHub still is a lot of that. The core is in these own data centers, but things like GitHub Actions, GitHub Port Spaces, GitHub Copilot. run on Azure in the cloud and leverage the scale.

that you naturally lead, whether it's CPUs in Actions or GPUs in Copilot. Of course, Copilot, given its multi-model choice and has anthropic models and OpenAI models and Gemini models. Not all of these models are on Azure, so naturally we're also working with other providers, often with both the first-party API, aka the API that OpenAI or the Topic provide.

and other clouds that have vertex, bedrock, and so on. And we, in fact, now have GitHub fully hosted on Azure for data residencies. If you, as an enterprise customer in Europe, want your data all stored in Europe, you're getting Kind of a big deal. You're getting a GitHub organization on a stamp that fully runs on Azure in the Netherlands and in Sweden. And we have the same for Australia. We've just announced a US stamp that will be FedRAM compliant. And we're going to...

expand into more regions in the years to come. Yeah, I feel these are the really kind of boring things, but they start to become really important when you are at a company that is now starting to care about these things. Well, they're not boring from an interesting perspective, right?

Not boring, but it's a thing that I think as a... from outside you know it's not the shiny features but i agree an engineering perspective that actually sounds pretty challenging the challenge you know if you go back to the ruby on rails conversation is and if you know a little bit about rails and how um

And we do not only run on Rails, we also run on MySQL. And so whenever you change the schema of a database table, a so-called migration is run. How do you do that if you not only have one stamp in one region, but you actually have five or 10 stamps? and we deploy hundreds of times per day. In fact, I think this year...

We're forecasting 12 million deploys across about 1,000 or so IC engineers that we have in the company. And so how do you do that? How do you deploy? How do you go from one central stamp on our US data center cloud, if you will? to having, you know, deployment that goes to all these different stamps and run the migrations and if you need to be able to hold back. So that was a lot of the engineering work that went into that.

So I'd say the actual work of moving this to Azure was less work than getting the engineering system, the DX, the developer experience, actually aligned with this now we are running in multiple regions. Yeah. One. Interesting thing that I always surprise people who don't know GitHub all that well is people think, well, it's now Microsoft, right? So it must work the same way as Microsoft. And then one fact that shows this is not the case, GitHub is still remote first. It started as remote first.

initially and it was actually one of the few companies that even before covid truly remote first and as i understand even today It's remote first. Tell me about this on how you managed to keep this, how it's working inside a larger company, which Microsoft is not remote first. There are, I understand, parts of it that are more supportive of it, but generally, people are often in the office.

The three founders, they actually met in San Francisco. So you could argue that very, very early phase was kind of three people in the same place. And that's often how that goes. But yeah, very quickly, GitHub started hiring. super fans, you know, people that were interested in GitHub, promoting GitHub, you know, helped drive in the communities. Those people got hired into GitHub and they were naturally everywhere in the world. And so very quickly GitHub moved from a

culture that was headquarter centric to a remote first culture. And that gave us an advantage when the pandemic came, COVID. because we were already used on being on video calls, on using Slack. In fact, I think GitHub is very different than Microsoft when it comes to how the company communicates. My joke always is when I wake up in the morning, because I'm obviously both, I'm a Microsoft expert. and I'm a GitHub employee.

When I wake up in the morning on the GitHub side, I have lots of Slack messages, DMs, channels to look into. And maybe, you know, a handful of customer emails or emails from you that cannot communicate with me in Slack. On the Microsoft side, it's the other way around. I have like... dozens of emails to pay attention to and maybe a few Teams messages. And so I think that shows the async part of our culture that has grown over the last 17 years and that is so important at GitHub.

We are using GitHub for everything. And so all employees across all the functions, not just engineering and product, but HR and comms. all the functions work on GitHub, and so they have repositories to describe their team. They're using pull requests to make changes, for example, to our terms of service.

You know, every company-wide announcement is a pull request against the repository that we call the hub that gets published as a pages page that is only internally accessible and that goes to our identity provider. And so even there, we don't. to company-wide emails. Almost never we do an announcement on the hub. There's a link that is posted in the Slack channel that everybody can see and then we take the conversation there. So yeah, today we are...

a very much remote-first company with people all around the world in different time zones. Almost everything is async. Obviously, there's meetings. Our town hall meeting is called the get-together. And that has to be in some time zone. And the challenge there is that if you do it, you know, adjusting it for the folks in the US, North America.

And Europe, you're missing out those in Australia and India because that's just impossible to meet. So we try, you know, different times of a year to have one that is in the APEC-friendly time zone and, you know, a few that are European-friendly. Often, you know, it's not the way.

When you do like one early in the morning on the West Coast, that's actually bad time for the Europeans because that's kind of like when you pick up your kids from school and go and have family dinner. So many of them actually prefer a later.

point on the day on the west coast so it is later in the evening when maybe everybody's watching tv or the kids are already in bed so yeah we're trying to really keep that spirit and that enables us to hire talent um you know in different places um in different uh phases of their life. And I think that helps us as a company to be as agile as possible.

Yeah, it is pretty cool to hear because GitHub, I mean, you can use GitHub in many ways, but like one popular way is to use it at this async way, right? So it's kind of cool that you're using it the same way as a lot of the startups are. I think one of the core pieces there is not only

startups are, but as the open source ecosystem is using it, right? But the open source ecosystem by design is async. And they're not all in the same place that would never work if an open source project could only... you know you could only be a contributor if you're in the same place in all the same time zone and so given that we're catering to both you know commercial customers startups enterprises

those that are paying us money for GitHub Enterprise and corporate business. But we're also catering, serving the open source economy, the open source ecosystem, and as such as a company, even though... You know, the GitHub core itself was never open source and we're operating pretty much like an open source project. One fun fact I've heard is you have some really kind of fun and interesting internal tools. Some are still here, some are not.

One tool that I understand is no longer there was called Haystack, which was an internal exception tracking app. And someone told me it was the best piece of software they've seen. Can you share a little bit about what passed?

fun internal tools you have and what kind of internal tools do you still have today, especially for what engineers use? If you look back into GitHub's history and we don't have the time to cover it all today, I can... I can recommend if I'm allowed to another podcast, the Acquired podcast. They had an episode on June. 5th 2018 so the day after the acquisition announcement that covers a lot of the history of github in the early days and uh it's in general a really good podcast um

And they actually mentioned this, that GitHub, when it started, had a very non-traditional way of operating. There were no managers. Everybody was encouraged to work on their passion projects. And as such, GitHub needed... you know, for many years, didn't have a traditional IT infrastructure company. Everybody was built in-house because there was the belief, you know, we can build, we as GitHub can do it better.

than a tool that we can buy off the shelf. Maybe we come back to this later when we talk about AI. That future might actually come back to some startups. So we had a tool. We had our own internal video streaming platform. It was called githubber.tv. And so all the townhards and so on were streamed on our own platform. And of course, that no longer exists. And we're using Loom. I was in Loon for that. Haystack, you already mentioned that was exception tracking.

And keep in mind, 15 years ago, there wasn't established players in that market that you could use, especially not in the Ruby Rails work. So, Haystack1 was my such tool today. Sentry that we're using for that. Another one was HALP, H-A-L-P, which was our internal support system where tickets got routed for folks to work on the ticket, have internal communication.

And now this is all in Zendesk and HALP has been retired. But, you know, some of these ideas have led to new startups. HALP is what we call GitHub employees, where HALP has taken the idea and maybe they're a bit frustrated that we're shutting down their internal passion project.

have taken that and created all of it. I think, you know, culturally, we are still encouraging folks pretty much to experiment and to incubate new ideas, but we're trying to make those external-facing products, and there's a number. Examples from GitHub's history as well there. Electron comes to mind, which came out of Atom, which was our editor. Oh, yes. Our desktop app, our command line interface, also open source projects. So everybody can...

see what we're doing there and can take the ideas and you know we mentioned stack tech stack earlier the cli for example is with mingo and so it also gives a you know whoever wants to learn how to build a cli can use the github cli as an example one thing that keeps surprising me about github

Every now and then there's a security incident that is in the press that is a big deal. Not always, but sometimes it starts with company X. had a security issue and it starts like oh they detected it because github alerted it for them and a very famous one was in 2022 heroku had a security incident And it started by not Heroku noticing that something leaked, but GitHub itself noticed.

some strange patterns. They contacted the Heroku security team, who then confirmed it. And this just struck me a little bit striking, like, hold on, like, how is...

GitHub having better or very strong security, I'm not going to say better, but in some ways in this case, clearly they got earlier. What is your approach to security? And this was, again, not even right now, this was years back. It just suggests to me... like you probably think about security a little bit differently than maybe some other companies security is part of our culture we have the saying again security

is priority zero for everybody. And in fact, our previous CISO, Mike Hanley, introduced this concept. He came from Duo.

the two-factor authentication company, he introduced this concept that when the question is asked who he is on the security team, every hover raises their hand and so we institutionalize that security is as part of what we do um of course we want to drive innovation and make customers happy but we cannot be in the market if we lose the trust and of course the worst day you know uh in my life would be that i get a call and say i lost you know the private repositories

We lost, you know, as a platform. It's so important to companies, your code. To an attacker and now have to do the damage control. And so it's really important for us, the CSO, the chief security officer reports. directly to me. And we have a team of about 150 or so employees that take care of security from multiple angles. One is of course, quite intelligence, working closely with the Microsoft security team.

the so-called Cyber Defense Operations Center, and those folks that look into finding security vulnerabilities, head teaming. not only for the traditional software building, but also for the AI pieces. And you can imagine at the scale of GitHub, but even more so at the scale of Microsoft, There's a lot of threat intelligence. When you combine all that intelligence, you get a lot of signal. And one such example is a very trivial example is that if you have a person...

If you, for example, you know, your user ID accesses not only the pragmatic engineer repositories, but also those of, let's say, BMW or Mercedes, that person is very unlikely to exist in the industry, right? Even if you're working for a systems integrator.

then you typically don't work on a BMW and a Mercedes project together. So there's a lot of intelligence that we can collect by having the holistic view, even more so when you combine it with all the other Microsoft systems. And we also have a security lab where we have a team of researchers. that are hunting for security vulnerabilities using our own security products like CodeQL, which is query language that you can use to find variations of existing code flaws, code vulnerabilities.

tries to find those in open source projects and then reports them to the open source maintainer in a responsible way, helping them to fix those. And then in time of disclosure, hopefully, you know, the bug is already fixed. So we are doing a lot of that. We are investing into a lot.

of that but of course you know nobody is perfect and so it's really crucial for us as a company to have this ingrained into our culture to not have secrets and source code in fact you're blocking all the pushes and exactly I guess open source might help here, your big focus on open source. But you mentioned 150 people working on security. As context, how many people or engineers are in GitHub roughly these days? Yeah. So GitHub all up is about 3,000 employees.

about half or so are in what I would call engineering product design or EPD. So that's about 10% if I just look at the security versus engineering. Engineers, I see engineers, it's a little bit under a thousand that work.

And then it's, of course, managers and product managers and technical program managers, designers and all of that. One interesting thing I've heard from a current GitHub employee is you are starting to look into hiring junior developers, developers with less experience, which is a little bit different because...

most of the industry, we don't hear this. Why are you deciding on this? This is just a really positive thing to hear. I'd love to hear more about your thinking. We're really excited about working with young people. You saw some of those. in the second day keynote yesterday as well.

And in fact, you know, just on Monday, our intern class for the summer started. We have three groups that start on different days and go through the internship. So those are the very early in career folks that often, or not often, that still go to college or university. This is a program that we institutionalized after the pandemic was over and you could bring people back in person. Because obviously, or half in person will at least have, you know, available.

to meet with folks at our San Francisco headquarters or here in the Pacific Northwest or elsewhere in the world. And so we have an interim program and often... You know, these interns get a full-time offer at the end of the internship, or maybe they come back for a second year. And so it's a lovely to see that, you know, those folks that bring fresh ideas, a great amount of energy, you know, the latest learnings from Kordosh University.

and often, you know, a different, you know, diverse background into the company and, you know, come in and often, you know, the folks, you know, that are younger in Korea.

bring a new perspective to the team and say, here, this is, you know, why don't we try this or I want to incubate this idea. And so we are excited about having... this kind of like both junior and senior population in the company and it's not only twin engineering you know it's the same in if you look into sales or into marketing obviously the way you know marketing works today

uh is very different um than it was you know five ten years ago when the press uh you know traditional media uh played a much bigger role uh today uh you gotta be you know in a podcast and You have to be on YouTube and TikTok. Just like today. But you see more and more of that happening. And of course, when you hire people earlier in Korea.

They give you those ideas. They give you that input. And you know how it is you talk to a lot of people in companies. There's always a debate. There's always a debate between those that are defending how we've always done it. in a 50-year-old company like Microsoft that obviously exists. And those that come in and say, hey, you know, nobody in my peer group, you know, watches TV anymore and or CNBC or whatever. And they're all watching just, you know.

three-minute videos on tiktok and so i think that's really important and then we're trying to have you know

a nice balance between early career engineers, senior engineers. We have a number of distinguished engineers and they all contribute back to our plan. I love it because when I worked both as an engineering manager or as an engineer, having an intern is just like boosted morale like we were so much more enthusiastic i'm not going to say that we necessarily did more work i think we we might have but we got fresh ideas and

It's just so rewarding looking back at those interns. I now see them many, many years later. Some are now principal engineers, some are CTOs. The one question that a lot of people who are maybe less technical than you and who have not seen the benefit of internships, they're thinking like, oh, I'm hearing all these AI things, including Microsoft is saying it's so efficient. You're now talking about AI colleagues on the keynote. Why?

and and now this is not microsoft people but we're hearing people at google say like oh it's now at a level of a junior engineer and they're thinking

Maybe let's hold off on hiring new grads because they're telling us, you know, some of these so-called experts that it's now at the level of a junior engineer. So maybe we don't need junior engineers. What would you... suggest to people who are in this thinking and maybe not as informed because clearly you've decided it makes sense and you know this this thing doesn't apply but their thinking is real

I think that's backwards in many ways. I think actually folks that go to high school now or to college or even kids earlier in... in their education, they get to use AI much faster. And they get it because they are, you know, taking this with an open mind. They don't have to, this is how we always done it, don't touch, never touch a running system. They haven't been in an experience where some change.

was applied from upper management or from the engineers themselves has led to a big outage and things like that. So they're more open-minded. You kind of see that when you look at media, as we already talked about. kids are much more uh open to just scrolling through charts um and and consuming the content they'd like to consume while you know when you and i were a child

had linear TV and you got to watch on the living room TV what your mom and dad decided is on tonight, right? And so they have much more freedom. And I think... This will lead to ultimately junior engineers coming or interns coming into the companies and thinking in like prompting skills, you know, experience with different models.

Intern doesn't mean I haven't worked for another company before. It might be my second or third internship, or I might have already been coding with a group of students on my own project, on my own app. So you get a lot of good new ideas and outside perspectives.

of that is ultimately crucial to compete in the market. And I think vice versa, you know, these interns then go back into college and they have worked on something real. I remember my time at university, I always had the feeling I got to get out in the industry. and learn how it's actually done. Because while you learn coding in university, but you don't really have an engineering system. You're not having tech debt. You're not working on a legacy code based engine.

Becoming an engineer in a company means you're working on somebody else's code. Often now, you know, GitHub 17 years old code. And you have to follow up on decisions other people made. And that's not how you learn coding in a university. And so I think it's both for us important to have those fresh ideas within the company, but also for us important to give back.

to those that in the future become GitHub customers. I love it. And I feel it's also just the cheapest way to do it. You're not going to have the highest salary for the new people. This is a silly way to think about it. I talked with the product manager recently.

I just had a deja vu when you said it. This product manager was saying, this is while we were doing the Gen Z research about the latest generation. She said, I love Gen Z. She's like, for years as a product manager, I'm sitting in front of engineers telling them,

oh, get product thinking, think about the customer, and they're like, just tell us what we need to do. And she's like, the new generation comes in, and they have opinions. They're like, I think our customers would like this. I have tested our competitor. Here's what they're doing. And she's like, I love it. So I wonder if by hiring these people and actually just ignoring, as you say, the backward thinking,

you might get the next generation of software engineers. Gen Z is already too old, I think, to some degree. Because Gen B, I think, starts 1980 or something like that, the millennials. Gen Alpha, right? Like, they're 60 years old, are coding today. And so that's Gen Alpha or, you know, soon. whatever the gen beta, I guess, is the next one. But you're right, you know, you're getting folks that didn't learn to code on a Commodore 64 on a PC that, you know, have...

have a lot of low-level thinking, but also learned in a different environment than those that grew up with smartphones, that grew up with being always connected. They just have, just from an expectation perspective, they're looking at this.

often systems problem they're trying to solve with a different perspective. Yeah, I wonder, just like a silly thing, would you rather hire an engineer with the same years of experience of like someone who has you know like has traditional coding and learned in university or the same years old you learned in university and did some university projects or

This engineer or this fresh grad who did a university, but they actually have before that five years of building programs in Roblox and they actually built this like 100 person. It's like the skills that that person brings and the mindset, you know, the way they think about things. And there's a third group and there's lots of folks, you know, at Microsoft and GitHub that don't have a formal university education and either dropped out or never went.

That goes back to the earlier discussion about being a remote-first company. You hire people because they're passionate about the product. You hire people because they have a great contribution graph on their GitHub profile.

Because they have shown they contributed back to the Ruby on Rails code base, to the Git, you know, open source code base where, you know, at GitHub, we traditionally have employed folks that are spending a lot of time on maintaining Git together with the open source community. But what actually plays a role to us is that folks have shown...

the right mindset to join GitHub. If you don't have a green contribution graph on your GitHub profile, that, I think, matters more to us than whether you have five years at one company and five at another company. Of course, we take people to an interview loop, and I think...

Increasingly, we're thinking about how do we leverage AI within the interview loop. There's nothing wrong about that from my perspective. In fact, I would say if you want to, you know... get a job in a tech company, very soon you're going to be asked to show your prompting skills, your co-pilot skills, if you will, and how you use something like agent mode or the coding agent that we introduced this week.

to get the exercise done, you know, to basically, because the goal of the future engineer is no longer to run it all from scratch. And the goal is to, you know, combine their prompting skills and agent. open source libraries into getting that problem solved much faster than they could have done two years ago. So with that, these were some of the like a bunch of interesting facts.

I wanted to talk about the past and then later the present and the future of GitHub starting with the past. I did a podcast episode with Linux kernel maintainer, Greg KH, and he told a story about how Git was created in 2005. In fact, recently there's a podcast with... a github a staff engineer at github interviewed luna store worlds yeah in 2005 luna store worlds

got frustrated with source control for the Linux project specifically. There were some commercial things. We can see the history. He sat down in 10 days, he wrote Git, which was obviously open source. It was meant for Linux only, but they released it and it turns out it's pretty good.

GitHub was founded in, I believe, 2008. Can you tell me about these early days? What happened then? What do you understand from talking with the early founders? The first commit was October 2007. So it was about two years after Linux had... done Git, right? And then, yeah, October 2007 to, I believe, February 2008 is when they started beta testing it with folks in the Ruby on Rails community. And then April is when the...

public version of GitHub launch. That was really fast as well. You know, October to April, five or six months. You know, if you go back, you know, to the history books, it's Chris and Tom. Tom Preston-Worner and Chris Wonstrad meeting in a bar, as I remembered, and having seen Git and figuring out that.

There isn't a place where you can host your open source repositories and your private repositories together. There was obviously things like SourceForge, which was the most popular open source platform back then. But also, you know... painful to use. I think that's fair to say, like those that I had a couple of projects on Salesforce as well, it was kind of designed for a different era of the web and didn't make the jump in that mode, ultimately, you know, became known as web.

as web 2.0 or cloud native and so i think the the idea was okay git is here git is amazing uh but i want to host it um and without you know setting up a server and installing you know the back end and managing you know, SSH access. And so they started building around that idea. What always made GitHub GitHub is that they put the developers first. Like if you go on the Wayback Machine and look at the first, you know, GitHub homepage.

It isn't very fancy. It looks like a commit log. It's a very short announcement of, hey, we shipped this new feature, try it out, let us know what you think. The story about our logo.

what is now known as the Octocad, you know, is a funny one. And I learned that actually from the Acquired podcast because they learned from the Twitter founders how they get their low when they bought it on some... a stock graphic page from a british designer i believe and so they looked you know for other graphics that the same designer had done and and bought you know this this hybrid of an octopus and

and a cat uh and and made that the logo um right so there was a lot of you know as a bootstrap startup that's scrappy that has a cool technology that might, you know, become the next, the future of version control. And then they built what is now known as cloud native, but a cloud native company. And, yeah.

It grew fast. And back in the day, probably the product was the fastest product market fit. Nowadays, you know, there's other companies that have similar, but it's a different time. It's a different time now. And I think it was... unheard of how quickly it spread like wildfire. I was in 2008 still working in the automotive industry. I was at Bosch, so I didn't use GitHub in the first year. And then I quit Bosch at the end of 2008, not because of GitHub, but because of the iPhone SDK.

And it became an ISV building apps for German companies. And so I created, I think, my GitHub account in early 2009. We can look it up, I think, March or April 2009. And then I was at RailsConf. the Rubien Reels conference in Las Vegas in 2009 and saw Chris Wonstrath giving a talk about GitHub and then what they were up to. And that's, I would say,

And I became a GitHub fan and when I started using GitHub in my projects. But until that point, you would use some help self-hosted tool, install it on some root server, or maybe you already had the cloud and maintain all that yourself. And ever since, people just...

you know login with github and then create repo yeah when i looked through the history of just the things that i could find what struck me as like you so like as the first couple of the 2007 and 2008 the service was launched i think you said march or something like that april sorry

And already in 2008, Reddit, Yahoo, Twitter, and Facebook already onboarded. Facebook was surprising to me because I knew they didn't use Mercurial, but apparently they used it for their open source things. And these were very hip and very trendy companies at the time. And obviously from there on, as you said, in 2009, this was the obvious place to find. Why do you think it was so popular? What was the reason? Was it open source? Was it...

Because Git wasn't even, like, we're talking 2008, 2009, like, now we know Git is great and it works, but back then, this was not clear. Everyone was using SVN, I remember, at the time, and Microsoft had their own really heavily invested, called TFS, Team Foundation. server. Why do you think this product market fit just hit so bad and devs were like, yeah, GitHub is the place to be? Solve the pain point that we have with all these other version control systems.

TFS had its own version control until much later when they added Git support. They were painful to use, especially when you had multiple teams working together within the same code base. Git brought this concept of you have the full repository on your machine so you can switch from one branch to another. even without having an internet connection and you get always everything on your computer so you know you could make changes to multiple branches and then then push upstream or

or shared with the co-workers. And in some ways, GitHub, I think, is the irony of software development tools because you have a decentralized system like Git, and then you have a central hub that the world depends on today. and where everybody pushes to. So this notion of decentralized systems is still something that sounds great when developers are chatting about technology.

But I think humans are longing for home. And, you know, today at GitHub, we have the saying, we're the home of software developers, where they collaborate human to human and soon human to agent. So I think that played a big role. You had a new version control system that people were intrinsically motivated to try out because they were frustrated with using some versions. Or even CPS, you know, and something like that. And just wanted something...

knew to solve that problem. And then it was just easy to shoot an account and try it out. And, you know, even user interfaces like browsing the repo, clicking the file tree. GitHub innovated a lot in that compared to what was there before and making that Ajax request so they would load really fast and you wouldn't wait for the full page to reload. GitHub invented the pull request, this notion of that you can fork a repo.

make your modifications. If you'd like to keep your fork, you can just do that. That's totally cool. Or you can send a pull request back. So we're asking the other maintainer to merge in your changes before that diff files for exchange. This episode is brought to you by Augment Code. You're a professional software engineer. Vibes will not cut it. Augment Code is the AI assistant built for real engineering teams. It ingests your entire repo, millions of lines, tens of thousands of files.

so every suggestion lands in context and keeps you in flow. With Augment's new remote agent, queue apparel tasks like buck fixes, features, and refactors, close your laptop, and return to ready-for-review poll requests. Where other tools stall, Augment code sprints. Augment code never trains or sells your code, so your team's intellectual property stays yours. And you don't have to switch tooling. Keep using VS Code, JetBrains, Android Studio, or even Vim. Don't hire an AI for vibes.

Get the agent that knows you and your code base best. Start your 14-day free trial at augmentcode.com slash pragmatic. Well, I think this is one of the biggest things that people miss, as I understood, like, understanding. So, like, Linistar's design git and a lot of...

GitHub or the Git functionality comes from there. But the Linux workflow was email-based. So actually in Git, there is a command. I don't remember the exact command where I think it's something email where you send an email with your changes bundled, with your Git change. is bundled and that's how linux works they just use email and github does not do this indeed github invented the the pull request which is

a big difference between, even today, how Linux uses Git and GitHub does. And yeah, it was a smash. When was the pull request invented? Do you know? Was it early on? I'm getting the date from it. I think it was a year or so into GitHub's journey. It definitely wasn't there on day one. It came sometime later. We can look it up and add to show notes. But it was a new thing at the time. And I think it's ultimately liberating for software developers.

You send a pull request, and if the maintainer doesn't like it, they can just close the pull request or just leave it open. But others can see it. And if they want to pick it up, they can just jump over to your fork and keep using it there. And so you see.

you know um i see a lot of that also happening that people just keep their forks independent because they want to they don't want to have the obligation to to engage with the main project like i have a bunch of forks where i made some small modification for my own hobby project, I don't see a big reason that that needs to go back into the main branch. Some of that might be just a bit hackery as well.

And so it makes it much easier for developers that want to collaborate, to collaborate with each other. And for the others, it democratizes how they engage with open source, how they learn from it, how they mix and match, and so on. So what kind of a gathering, if I'm putting it together, like open source? was clearly one thing, this new collaborative workflow, especially with open source, but also, and I think one thing you didn't mention, but I wonder if it is a part.

is how even if you use GitHub, you can always move to your own Git server. It's very easy to migrate. It also works offline. So even if GitHub is offline, like, yes, it's a central hub. But if there's a GitHub outage, I mean, we're not happy about it. And people complain these days and there's not many. of them to be fair but even when that happens i mean oh i guess i can keep working locally

Like, I can keep pushing. So you might not, if it's just, again, if it's just like a 30-second outage or a one-minute one, again, not advocating for it, but you might not even notice because you're just like doing your local thing. So I think as a developer, like... I think we appreciate when we know we are not locked into... Oh, by the way, it's free. Like a lot of the... Sorry, not GitHub per se, but for open source, it was always free, right? It was always free for open source.

You might say GitHub invented a version of the freemium model that is not ad-based, where traditionally freemium is ad-based. Yes. The free users get it. something for free with advertisement, and then the paid users get rid of the advertisement and get more features. GitHub originally had the separation between everything you do in public as free.

Because it helps the community, obviously helps the social network, quote unquote. Yes. GitHub growing. And then when you wanted private repositories, you had to pay for them. Shortly after the acquisition early 2019, we changed that. And instead of paying for private repositories, we actually made private repositories free as well. We did, yeah. Because we had a lot of individual developers giving us feedback.

especially when you travel around the world. For an American, $4 a month might not be a lot, but for somebody in a different country, that is much more money relative to their income. And so we were private repositories free, and today we charge for what you could call enterprise features, like single sign-on or branch protection, things that a student or a hobbyist, you know.

probably doesn't need. If I'm honest, when I work on my hobby projects, I barely write any tests. I certainly don't send myself a pull request. Then I'll have to review my own code. I just push into main branch, and that's cool. And so, but yeah, GitHub innovated in the business model space as well. And you mentioned that the scenarios where it's helpful to use GitHub or Git on your local machine. In 2007, 2008, flights didn't have Wi-Fi, at least in my memory.

No, no. Wi-Fi wasn't as prevalent. That's very recent. I don't know if Starbucks, maybe Starbucks already had it. But there was much more places where you would work just local on your machine. for quite a while and being able to commit into the repository. There wasn't, you know, subversion didn't have a push. You would always commit into the upstream, change branches, you know, roll back all these.

operations that are now natural with Git, they weren't natural in 2007, 2008. So GitHub started off, it started to get real big traction, 2008, 2009, 2010. The next big kind of... mouse and i remember from developers perspective is until then to use github you you could use the web version and you use the local command line interface you just learned all the commands you know there's books about like

The easy ones are easy and then like cherry picking and all that, I was always confused by that. And then in around 2014 was the first time that GitHub actually released desktop applications, but... Not only did it release desktop applications, it actually released the Atom text editor, which I loved. I used it for so long. It was a lightweight editor. it released the Electron framework, which powered ADOM, and then GitHub Desktop in 2014, 2015. Why do you think GitHub waited?

that long to have these desktop applications? What was the goal with AppTom? And how did this help? Did it actually help get more people who just liked a nice user interface and were not the command types? I don't know the history of all these apps. My suspicion is that You know, when you say waited this long, I'd make the counter argument in how long is long for a startup to meet one core product to having multiple other products that may or may not become a distraction.

I think each of those solved a specific problem that the team saw. Adam came out, you know, I think a year or so before VS Code launched. And so clearly the time was ripe, you know, for... a new generation of IEEs. Both of them are open source. For the acquisition, they both ended in the same company and then ODB made the decision. to continue our journey on VS Code and entire Atom. But it goes back to this developer-first culture. It goes back to GitHub's origins where...

You would join as an employee, and you wouldn't have a manager, and you wouldn't have a backlog. You would have the... So back then, really, there were no managers. Well, there was obviously a CEO, but that was very flat. And people, when they... Onboarding was always at headquarters. So even though it's a remote-first company, you would spend a week or so in our headquarters in San Francisco and you learned how to make...

An espresso. And that was literally one of the onboarding videos. And, you know, they kind of have some musical future, musical culture. And you got told, you know, pick something that you're interested in. And that naturally leads to developers picking things that they want to solve for themselves, that they care about. And so Adam was actually Chris Wonstrad, the CEO at the time.

uh and then for most of kitab's journey until the acquisition um uh was one of the you know core maintainers of the allen project And so I think a lot of that was about passion. A lot of that was about the passion of the people working there. I don't know exactly the history of desktop, but my assumption there would be that...

They saw a need to expand the people that can use GitHub without knowing all the intricacies of Git. In many ways, the GitHub user interface on GitHub.com also served that purpose. Think, for example, about blame views. Blame on get.com is just picking a button and see who modified which file, which line in the file. But if you do get blame on the comment line, it's much, much harder to figure out what's what.

especially if you don't know a lot about software development. So it's all about growing the user base and expanding the people that get utility out of it. I'll say that I use GitHub Desktop a lot. I mean, everything is different, and I know how... to use command line, but I just like that I don't have to think about it again. So I appreciated when it came out. I barely didn't use it, but I use the GitHub integration and VS Code a lot for the same purpose.

And I think even that, you know, Git as a protocol, SSH access and HTTP access, which also, by the way, wasn't something that was very prevalent in the early days of GitHub. and is now much more used because it's easier to access through http than then through ssh um i think all of these pieces you know ultimately helping to create the developer experience that we now consider normal, but by no means was normal 20 years ago. So then...

We're getting to the Microsoft acquisition. So we've now passed 2015. It's now 2016 or so.

You were in the inside of Microsoft. You were already working there. How did this come about? What was Microsoft thinking? Why was even Microsoft interested in GitHub? And then how did the purchase go from your perspective? It was 2018, early 2018, that...

Back then, Ned Friedman, my boss within Microsoft CDP in the developer division doing mobile developer tools, Ned came from Xamarin, so had joined Microsoft himself for an acquisition. I had joined for the Hockey App acquisition. So we were like a bit of a... you know, outside in team within Microsoft with lots of people coming from companies, lots of, you know, cloud native experience.

a non-traditional stack for Microsoft. At the same time, also Microsoft had changed. It was now about four years since Satya Nadal had become the CEO. Satya had very early on embraced open source, you know, then... VS Code was launched, .NET became open source. So a number of steps had happened where Microsoft changed its fundamental position on how it views.

open source, how it views, you know, the stack and where the future is going. You may remember this part of the strategy back then was cloud first, mobile first. And, you know, in many ways. that is still true today. We're no longer saying those two things. If you think about how you interact with Microsoft products today,

They are, you know, on every device, regardless of who makes the device and what upbring system. This was not obvious then because it was still Windows first. It was still a feeling that Microsoft is only Windows. I heard this was said everywhere, and I think outside the mic, we were skeptical, honestly. But, you know, and obviously the cloud stack, the compute stack that Microsoft offers today.

not only to its own products, but to any company in the industry, really. One thing I learned early in my journey at Microsoft is that when you're a small startup, you consider other companies in the space competitors. They're, you know, quote unquote, the enemy. At Microsoft, competitors are at the same time also customers and often partners. We are providing, you know, if you take, for example, Azure IA Foundry, our...

inference stack for larger English models. We're providing those not only to our own co-pilots, we're providing those to many other companies that may directly or indirectly compete with GitHub or with other Microsoft products. And so 2018, the worldview in Microsoft had changed. I think the reputation started to change. We at Microsoft started to believe that we could pull off an acquisition like GitHub.

you know, make GitHub part of Microsoft and not lose all the open source maintainers because they feel like Microsoft, you know, is not going to be with Stuart of GitHub. And we said very early on... clear principles of what that looks like. And 2018 was about two years after the LinkedIn acquisition, a bit longer since the Minecraft acquisition. So we had kind of like two examples of acquisitions where we kept the brand and the platform independent.

Even today, when you go to the LinkedIn homepage, you don't see a lot of Microsoft there. Seven years after the GitHub acquisition, there's no Microsoft on the GitHub homepage unless you're using... Entra ID as your single sign-on provider. Or, of course, we have blog posts where we talk about Copilot and the Microsoft file model and things like that.

And Minecraft is, you know, many kids I think realize much later, you know, in their childhood that one of their favorite games is actually the same. a company that also produces the operating system and the professional network and GitHub, right? But when you look at those two acquisitions and then you see GitHub, it feels like a natural consequence, like the natural next step. for Microsoft to go down that path. Microsoft always has been a developer-first company.

You know, the first product was basically for the Altair. And, you know, here at the conference center, I don't know if you had a 1975 experience where you work on a fake Altair and pass some coding tests. You know, then that was basic for the Apple II and obviously Visual Studio in the 1990s.

I think my first version of Visual Studio was Visual C. 1.0 came with a book and then had Visual J, which was like Microsoft's Java clone. And then I bought a full-scale Visual Studio 7 for way too much money. back then, at least, you know, for where I was as a high school student, right? Obviously in today's world, Selling an IE at a one-time price would be something that has no market fit anymore. Microsoft lacked access to the open source ecosystem.

it didn't have the same attraction to cloud native developers. It was just being not trendy at all. Yeah. And it was important from a business perspective to have that ecosystem. It was important for us, you know, to put developers first again. And so that was actually the first principle of free. principles and we believe we can re-accelerate GitHub because GitHub in 2018 had a bit of the reputation of not being able to innovate anymore for various reasons.

And we can talk about that more in detail. But it was really important to think about its acquisition, not a... Microsoft gets a lot out of GitHub, but Microsoft is willing to invest into GitHub. You know, GitHub in 2018, at the time to start the conversation with them, was about 700 employees all up.

And we mentioned earlier, it's now over 3,000 employees. So that investment surely has happened. And we have leveraged a lot of the Microsoft stack and Copilot comes to mind where we're using Azure AI Foundry and the relationship with OpenAI. to build our AI cogeneration product. And then the last one was, of course, also Microsoft wanted something back and so GitHub Accelerate Microsoft. And the easy answer there is how did we achieve that by growing revenue? And, you know, we announced that.

July. So about a year ago now that revenue has grown to over 2 billion annual recurring revenue run rate. And that, you know, keeps growing and we're very happy with these business results and, you know, contributing back to Microsoft's earnings, right? But in that order, right? Like developers first making great developer products, accelerate GitHub, and then eventually GitHub, you know, accelerating Microsoft.

giving back both on the product side with co-pilot or on the revenue side with our results but i think this is this last thing is just worth emphasizing in the sense that i think as a developer i i really like that I like using products where I know they'll be around. So you're saying that GitHub's revenue has been consistently going up, more enterprises, more companies, more teams paying for professional use cases to help their work. If I remember correctly, 2017,

was the last official revenue announcement that you have made before the acquisition, and they were at about 200 million run rate. And they announced at that time that they're looking for a new CEO. So Chris was... I was ready to step down and then ultimately, you know, resulted in the acquisition then in June 2018. through an acquisition and a new CEO, Ned Friedman. But like 2017, you know, 200 million to 2024, in seven years, revenue went up factor 10.

Yeah, well, this is which is also it's kind of reassuring to hear that because there's always a risk like we know Microsoft is a for profit company. such an adult report to shareholders, it's good to know that those things are going well as well. Well, and I think for a long time, developer tools were not seen

as a revenue driver in the industry. I think there were a few examples like companies in JetBrains comes to mind or JFrog. There's a bunch of companies that were focusing on developer tools, but I think if you... If we try to go back five years or before that, because let's say seven and a half years, and we talk with venture capitalists about an idea that we have, you and I, about a developer tool startup, they're going to tell you, you need something else.

beyond just developer tools, because that's where the big money is. And today, this world obviously has dramatically changed. Absolutely. But as I was talking with Scott Guthrie, the interesting thing was that the last company that was able to make developer...

developers pay for developer tools a lot of money. We're talking thousands of dollars was Microsoft in the 2000s where this was pre when internet was small and developers didn't just pay for developer tools, but they pay for MSD and documentation for access to the latest software. That time has passed and we were talking about Scott on some of the learnings, but it's interesting how Microsoft

figure that out. I feel Microsoft is very good at figuring out this great mix where, back then, I worked at a Hungarian company, we paid about $1,000 per developer in Hungary because it made us so much more productive. So we'll go to the AI part on this one. But you mentioned something interesting, which I also noticed. So looking back, and I remember back when GitHub Desktop came out, it was great. I think I started to use GitHub more. But then from like 2015,

Nothing really happened. Microsoft bought GitHub, great. And I remember on online forums as well, people were saying GitHub is not doing anything. And then the next thing, I looked at the change log and the only notable... thing I've seen shipped. It started in 2021. Then GitHub sponsors came out, the package registry, co-pilot, code spaces. But what happened there from 2015 to 2020? It almost felt like from...

I'm sure people were working, but from the outside, it just looked like nothing, like barren land and more people being hired. And you alluded to this. What was going on behind the scenes? I mean, obviously, the time before Microsoft, you know, 2015 to 2018, I only have hearsay and a little bit of insight. I think...

Big problem that GitHub had, especially before the Microsoft acquisition and for some time after that, was that the platform had grown so much and so many people were relying on it being available and not broken.

Plus, you know, many developers did the Big Ben and still are very much in love with the brand. Like the Octocad, you know, we call it Mona. How do you call it? Mona. Mona. Mona Lisa, you know, Mona. is something that is recognized. You get asked about it on the street or in a coffee shop or in the Lego store because obviously the employees there are often also college students and have been... I mean, I've been...

I had on an airplane, the crew member asked me about GitHub. I'm like, how do you know GitHub? She was like, well, I used that in college for some computer science course that I took. If you have something that is so beloved by the space, that also means the expectations are really high. It's often that the disappointment is even bigger if you actually care about something. If you don't give a damn about this thing, then...

Whether it's up or down or whether it's broken, it doesn't really matter to you because you hate it anyway. And so I think those two things combined led to people really being worried about shipping stuff because you would change something in the reaction.

from developers, when you change something, whether it's in the user interface or things work or hate limits and things like that, is often there's a loud minority yelling on the internet. And there's a silent majority that are actually fine with the change.

but don't say anything. And a small change might lead to an outage and then you're the one that made three languages of change in your first week and you brought GitHub down. That's obviously not encouraging in your journey. So I think that created an organization that...

actually still shipped a lot of things in what we call staffship, what Microsoft calls store coding, so features that landed within the GitHub organization that Hubbers would see when they use. One funny thing is we have, even today, As we're using GitHub every day, I actually don't know if that feature is...

available to you because I only see GitHub how I would see it. And there's a way to disable all these features. But how often I can hide the staff bar and then disable the features that you don't see. But how often do you really do that? And do you then remember that in a conversation that Gerginger doesn't have the feature, but I have it. And I thought it already shipped, but it is actually slated for next week.

I think that created a culture where things were internally shipped, but never made it to the public. Because everybody's worried, is that good enough to ship it? You know, CEO change was in flight. There were a number of cultural issues. And then...

As we closed the deal and we came in, we made private repos public relatively fast. That was a fast one. Yeah, sorry. That's true. At that universe in 2018, the first version of GitHub Actions was announced. That was even before the deal closed. But it was...

you know, hopefully the folks building it, forgive me, was a bit of a hack built on top of containers in Google Cloud. And we quickly saw from the data that... the the product wasn't actually meeting the the requirements from developers many developers One at full CICD, while GitHub Actions originally was designed was workflow automation. And we kept that workflow automation part, but evolved it into what it is now. And over the course of 2019, 2020 sponsors was announced in mid-2019.

the last ever satellite conference in Berlin. And then COVID came and that ruined the plans that we had as we came back from it. were very careful with bringing back Universe in a smaller scale, given that there was still lots of travel restrictions. But it took us a while, you know, to get the organization back into a state.

where we could both innovate really fast and keep the fundamentals in place, keep security, availability, other things like accessibility, things that you might not actually see have changed.

um because you know if everything is working you don't notice it um but that you know created a lot of investment behind the scenes so we are we're feeling good about the pace of innovation that that we have today but yeah it took us a while to turn turn the ship around and you know even in a team of 700 people that takes a while and certainly about 3 000 people that uh it is something that you know requires a lot of energy and and um

and focus. I think it's just a good reminder from the outside, a company that is doing great because GitHub, I think all developers can agree, from the outside it looked like it's doing really good. Like, yeah, you can have some things that you need to work through, right? And growing too fast is amazing. I think the best problem for any team to have. But it's still a problem, right, that you need to solve and you get through it. Now...

Co-pilot was the biggest flash that I can remember from the past few years, clearly. Especially because when it came out, it just felt so early. Did the beta come out in 2022? 21. 21, yes. People came out in 21, yeah. The beta came out in 2021.

because it was built on an earlier model before chat gpt launched it was on uh was it on gpt2 No, it was GPT-3. So GPT-3 came out right after the build conference in 2020, which was obviously given the pandemic.

uh fully remote uh but kevin's got uh in some augmented session about transformers and dutch language models and then after that gp3 got into the preview and we got access to that and through the OpenAI Microsoft partnership and we realized together with OpenAI that it was able to write decent code in different programming languages and would not mix up the same.

syntax between Python, Ruby, and JavaScript, which somebody asked me that earlier this week, was my biggest surprise that it can do that. even though it doesn't have a compiler built in. It's not able to validate the code it generates. It doesn't have the syntax. It just knows it from the training set and then OpenAI.

fine-tuned a model that was called Codex that was specific for these coding scenarios. And so in 2020, in August, we wrote a paper with three ideas we had, text-to-code, code to text as in describing code, and conversational coding is what we call it, which then

today is known as chat. And those two later scenarios didn't work well enough. We had a describe code, and sometimes it worked, and oftentimes it was wrong, and you know how it is. When developers see that, that the description is not actually what the code does. you quickly detract and you get a little net promoter score or whatever you're measuring satisfaction with. But text-to-code, as in prompting the model within the editor and ultimately building autocompletion, that worked.

so well that very quickly we saw our internal hubbers adopting the tool, giving it really high scores, saying, you know, this is great. I want to keep using this. It's not the typical. management says you have to use it and you don't want to. But ultimately writing, you know, in the early days, 25% of the code in those files, it was enabled. And then shortly thereafter, that number got into the 50% range or 46%, I think.

early 2023. And so that was the early days of Copilot. In June 2021, we went into the public preview. And within a few months, the debate just had grown to a million users. We saw more and more folks. on social media saying, well, I was skeptical that this could ever work, but it actually is good enough that I don't want to work without it anymore. Yeah, because the surprising thing for me is most of us remember the launch of

ChatGPT in November 2022. And everything exploded from there. It was the product that made people go, wow, inside tech, outside tech. And a lot of AI startups started up. And a lot of actually coding startups started after that. So like in early 2023. However, by that time, GitHub Copilot was already, I think,

It was beta in 2021, right? But in 2022, I think it became public. So it was GA already? It was generally available, yeah. It was generally available in June 2022, charging for it for individuals in August 2022. ChatGPT actually had two moments, but one of them was not noticed by many. So OpenAI showed at Microsoft Ignite conference, which is the fall event.

showed actually ChatGPT in the keynote. It wasn't called ChatGPT, but they showed a similar scenario that is what you see now the agent doing, where you ask it to write some code and make modifications to that code, and then it launched.

in late November and the world changed for us dramatically for once because we had a product and market that was really good for developers and so our customer conversations shifted from us having to convince customers that AI is actually something they should look into, to customers asking us to come talk about how we build Copilot, how it can help their developers.

the first you know user studies come in we were the first one the first company comparing a group without copilot with a group with copilot and the five percent number is obviously you know both well known and often used today as a productivity improvement, which was never intended to be. It's a case study in that month scenario. It made the developers 55% faster, right? There's lots of other things that developers do day in, day out.

where you don't get the co-pilot to make you that much faster. But it was a very exciting time. And then in 2023, we launched a chat, GPT-4, brought it into the CLI, voice came out, right? A lot of these things feel like they have been around forever, but it's only been a little bit over two years. Totally been. And then 2023.

on a post from GitHub. I'm not sure if it was you, so I don't want to miss out you. But it was written that just as GitHub was founded on Git, today we are refounded. Sorry, so it was you writing it that just as GitHub was founded on Git, today we are refounded on Copilot. This was in 2023, and Copilot was clearly very strong. What has this change meant since an announcement two years? This was at GitHub Universe at 2023. So I think in that year, the conference was in early November.

It is our biggest event of the year, and it was one of the lines in the keynote and I think in the press release or blog post. And we talked a lot about the early days of GitHub, right? The GitHub. Founders did not invent Git. Linus Torvalds did. But they realized there's a new technology that changes how developers work, not only to version the code, but how they collaborate.

GitHub, if you think about it, GitHub is designed for asynchronous collaboration of developers. That's what GitHub is really all about. And with Copilot, it repeated history because we didn't invent transformers. We didn't invent large language models. We didn't train GPT-2 or 3 or Codex, but we saw something that changes how developers work. And if you're honest, we saw an opportunity for ourselves to accelerate.

You know, my backlog is endless. There's lots of GitHub issues in repositories that were filed where the issue was filed in 2014 with customer feedback. every enterprise seller since then posted on it. I have the same problem and it's not like we don't want to get to that issue but it's like there's also a thousand other things that

are also a high priority. And we mentioned security issues and availability and all these things are also high priority. When we saw GP3 and then Codex, we saw an opportunity. to bring the effort down for our own developers and, of course, every developer on the planet to get more done.

Not that they actually get to an empty backlog, because I don't believe that, because Javon's paradox means more ideas will get stacked. In fact, now we have all the AI ideas. If you will, now GitHub and Microsoft are... closer together from the sense that Microsoft's developer division has for over 25 years produced IDEs and Copilot started as an IDE feature.

And while GitHub was the developer platform, now those are, you know, the Venn diagram of GitHub and VS Code and VS is much more overlapping. And we see that here at the conference and we see that in our day-to-day interaction between GitHub and DevDiv. Just on build, two big announcements related to GitHub. One, it was open sourcing the Copilot extension. Why did you decide to do that? What's the idea here? Because we have seen open sourcing with VS Code. In fact, open sourcing VS Code.

gave way to some of the competing editors that are also adopted. Windsurf, Cursor. I think there's smaller ones as well. What is your hope with this move? And why? It feels counterintuitive because... Copilot has kind of been an edge for Microsoft, right? Isn't it funny that it's counterintuitive? We live in a world now where Microsoft is embracing open source and is open sourcing its plant while startups are taking open source, forking it and making it closed source.

This is like if you had told me that 10 years ago, we would have said, you'll have it backwards, buddy. This is true. We're not open source. And look, we published VS Code in 2015. under the MIT license. So the license allows it. And of course, people can do with the VS Code code base what they want. That's fair game. And so we're stepping into our footsteps of VS Code over the last 10 years. And we felt the time is right to bring the co-pilot extension into the main.

editor code base. And that means it needs to be open source because we made a promise to the community when we published VS Code that we will keep it open source. You mentioned we co-pilot in 2021, 2022. It didn't take long until people reverse-engineered the DS Code extension, at the end of the day, JavaScript.

We write it in TypeScript, but it's delivered as obfuscated JavaScript. And so you still can find those blog posts of how we compose the prompt, how long the prompt context window is, that we're using adjacent tabs, all that information. It's already out there, but you couldn't take that information and contribute back or look at the code base, learn from it, or take Copilot and its APIs and its system prompt and put that into...

let's say code.org or the interview tool you're building because you want your applicants to use a copilot and maybe even show how they can sign in with GitHub at the same time and not give them the full VS Code experience. You want that scope experience for an interview loop.

from our perspective, it follows exactly the idea of open source, which is you can learn from it, you can contribute to it, you can fork it, you can do whatever you want with it. It ultimately helps the developer community to have that piece of client code available.

You know, now you're going to ask, or I'm going to ask myself the question, so where's the value generated and aren't we losing all the revenue? And we believe that the ultimate value generation for these AI tools is in the platform. the compute or inference layer, whether it's the security or control layer, right? Enterprise is one control of what model is enabled.

who can use AI, in which project you might use AI, given that you might have signed legal terms with whoever provided your source code that you aren't using certain technology. and inference layer, the security layer, and at the collaboration layer where people collaborate and you see that with human-to-human collaboration.

And we were going to see that with human-to-agent collaboration with our new coding agent. We're bringing that agent into the Gear platform and we're giving it certain permissions. And we are... uh protecting the agent from doing things that you might you know allowed for a human but you want control over that when the agent does it i do like looking back at the history of microsoft i do appreciate that microsoft has

been open always to the idea of being a platform but a good platform so for example jetbrains you know they they might disagree with this but i remember the first time i bought a jetbrains project for 200 a year was this extension called resharper yeah

So Microsoft opened up their IDE to allow extension points, and JetBrains honestly wrote a way better autocomplete than Microsoft themselves had, and they made a bunch of money off of it, and I think this helped them spin out these things. But when I look at, let's say, Apple's Xcode, the reason I don't like it, and I'm very... vocal about it there is no extensions i'm stuck with what it is i would sometimes pay money for someone i cannot so i i just really like like how

Microsoft seems to be keeping this idea of sometimes opening up the business so others can succeed, startups can do it. It's better for everyone, especially as for developers. We just want better tools. As you mentioned, Xcode, we actually have a co-pilot extension for Xcode. It's a bit of... hackery, given the extension system, is not as...

But it does have auto-completion. It has chat. And just this week, also, we ship agent mode as a preview into the Xcode extension. We have it in the JetBrains extension as well across all the different JetBrains ADEs. We even bring it to Eclipse, and that is something you know, including agent mode. Because if you look into larger companies, they have developers on all of these, and probably another dozen.

of other editors that developers prefer and where the company doesn't want to prescribe which IDE to use. But it is important for companies to standardize their engineering system stack and to have certain approved tools. Maybe it's multiple of those, obviously. If you think about, for example, Artifactory or JFog, often companies have that in the stack together with GitHub.

or HashiCorp Terraform. And of course, you have a cloud and a key store, a secret store, and a key value store and whatnot. But it is important to have a Copilot available across all these IEs. And our Xcode extension is already open source. source before this week because an open source maintainer voted and then we did a commercial agreement with that open source maintainer to take it over right so we you know the maintainer benefited from it we benefited from it

But so that means the system prompt, the APIs, all that, you can already find an Xcode extension. And so now we're continuing that journey with VS Code and others. The last question I wanted to touch on, this is...

Agent mode or GitHub agents was also an announcement and the agents are getting more and more autonomous now. As developers, there is a bit of this fear. There's some, not necessarily Microsoft, but there's this vision of in the future, the software engineer, you will manage all these agents and you'll be more of a manager than a software engineer. And there's two things here. A, a fear of like, are they taking away

the parts of the work that I like. Even if not my job, I'll have a job, but it just seems like a boring job to be a manager. And then the other thing is, what could happen with software engineering a job? And then you said earlier that you believe this will increase, actually, just recently in public. So what is your view on agents? And what advice would you give to software engineers who are, you know...

want to say software engineers but obviously want to up level like how should we look at this thing because it feels like a freaking big change i don't like the term autonomous because i think autonomous at least in my understanding means the thing figures out itself what it should work on

That's not how these things work. They have a level of autonomy when you assign a task to them of how they're implementing the task. But even that autonomy is restricted by... uh the mcp service model context protocol that you configure for it or the tools you allow it to use or you know the repository you give it access to because obviously it's an engineer it's a human engineer

I can look beyond the one repository boundary and see what has happened in other repositories, while the agent needs to get permission to do that, right? So we are definitely far away from... full self-driving, if you take cars as a metaphor here, we're certainly getting into more driver assistance systems. And as developers, we have always automated whatever we can automate, like a compiler. is a tool that helps me to not write assembler and I can write a much nicer language. Thank God.

But I'm sure when compilers and languages like BASIC and others were introduced, there were also skeptics saying, I'm losing control over... the instruction set and the optimizations that I can do in my app is so much faster. And I certainly remember my Commodore 64 days when there was a very active demo scene and you couldn't really have a successful demo, especially as, and I think even nowadays it exists where the size was limited back then.

Pro physical limitations, today it's artificial, right? Like you're limiting it because you want to create a challenge, but you could only win those demo challenges if you know how to do assembler and... You couldn't win that in BASIC. So agents will work as one of the tools that developers have available. Just like we have compilers, linkers, linters, and whatnot. They will pick up tasks that I don't want to do, like writing test cases.

Don't know many developers that want to buy test cases, and certainly not more than they've already written, right? Like unit testing is always a... How many do I write until I can get away with it when I go into code review? Because there isn't like a right answer. It's like not a dozen and you're good. It's like how many you need is actually very, very subjective thing. And those have tried to.

Holistically test all the edge cases, they're never shipping actual valuable software. Finding documentation, fixing security vulnerabilities, finding these security vulnerabilities when I didn't see them because I had a long day and I have obviously always my own...

bias that, you know, the code that I'm writing, it does exactly what I want it to be until you have even something simple like a pull request description, right? Like you have the AI describe the work that you have done and all of a sudden it shows, well, Thomas broke the behavior. It won't say it like that, but you get the idea.

Thomas changed the behavior of the checkout flow where I'm like, wait a second, I didn't touch the checkout flow. Why is this now changed, right? Because when it describes the code changes, it doesn't have the confirmation bias that you self had when you would write your own description.

We're heading into that world. And now we have these, let's say, I start four agent flows. I think that's what Jessica Dean did in the day two keynote. But now we have all this code generated by all these agents.

I'm the one now having to validate that what the agent did is actually the thing that I'm willing to merge into my code base. And we all know that this gets harder the more open pull requests you have in different branches that might have merge conflicts by the time you're merging those things.

understand all that code. You've got to understand how the system is designed. You need to know what the agent did to have the level of confidence, trust. We talked about security, availability, all these things earlier. Scale. At the end of the day, most companies are for-profit organizations, and even those that are non-profit operating under budget. And so you need the agent to write code that solves the business problem and still makes you a healthy margin. Sounds like keep an open mind.

And experiment and see how they can help you, right? The other thing that is, I think, super important to this is that we're already seeing this paradox because now we have all the AI.

requirements that come on top of what a full-sec engineer does, right? Like no longer just back-end and database and infrastructure and front-end and how the front-end communicates with the back-end. And, you know, at GitHub to give you one last data point is... we are seeing 120 000 api requests per second on an average day oh wow that's seven per minute that's uh 430 million per hour or 10 billion per day right and that's

API requests. And now that doesn't say, is it a cheap API, like listing the first 10 repos that you have? Or is it a GraphQL API that can take, you know, lots of complex queries to actually get another result, right? And so if you just take that example, like you've got to have engineering skills, you've got to have developed craft, you need senior people that know how to build large scale systems, you need people that take...

large complex problems, break them down into smaller problems. Maybe they use AI along the way and say, what's a good new SQL database? What's a good infrastructure? How do I do data residency? How do I do GDPR? That job is going to be break it down to the layer, but then now I can sign it to the agent that will provide high-quality code.

without me having to reprompt it 15 times. And then I can merge that into my code base and move to the next task. That's what engineering is all about. The coding skill will be part of that engineering skill set, but ultimately... Engineering means I can build a really large complex system and then evolve that into even larger system next week in today's world.

Love this takeaway. Abstractions and being able to take on more complexity. This was a really good conversation. Yeah, awesome. Really great to meet you. Great person and looking forward to stay in touch. Thanks very much to Thomas for this conversation.

The thing that struck me most is how despite GitHub building AI tools like Copilot, Thomas very strongly believes that there's a lot of value in hiring junior engineers. And he thinks that the future of software engineering will not be about autonomous AI. For more practical reading and listening to on AI engineering, check out Deep Dives from the Pragmatic Engineer linked in the show notes below. If you enjoyed the show...

it would mean a lot if you left a rating on the show on your podcast player. This helps more people discover the show. Thanks and see you in the next one.