Loading summary
Transcript114 lines
- [00:00]
Thomas Zumka
GPU came out. 21 yeah. So GPT3 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 GPT3 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 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 Swift 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 well enough. But text to code, as in prompting the model within the editor and ultimately building auto completion, 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 gets 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 public preview and within a few months this had grown to a million users. And you 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.
- [01:22]
Podcast Host
GitHub recently turned 17 years old, but how did it start and how did the platform evolve? I sat down with GitHub CEO Thomas Zumka, who, 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 Help, how GitHub sees about 10 billion API requests per day. That's about one 20,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 enjoy the show, please subscribe to the podcast on any podcast platform and on YouTube.
- [02:20]
Gergi
So Thomas, welcome to the podcast.
- [02:23]
Thomas Zumka
Thank you so much for having me.
- [02:24]
Gergi
It's great to meet in person after exchanging emails and putting a name to.
- [02:29]
Thomas Zumka
The face and reading your newsletter every week. Yeah, twice a week I guess.
- [02:34]
Gergi
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?
- [02:59]
Thomas Zumka
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 was in the early days also.
- [03:07]
Gergi
Ruby Rail in the early days.
- [03:08]
Thomas Zumka
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, we're using more and more React on the front end. We have a number of services that outside the monolith. For example, the Copilot API is written in Google given it needs lots of API calls for inference. The Git Actions sits on a completely different tech stack.
- [03:55]
Gergi
Git Actions I would imagine Rails might not be the best for a very.
- [04:00]
Thomas Zumka
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 into a more modern architecture with the goal of, you know one of the 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 iPhone app. We have Kotlin for Android app. We are using all the clouds beyond also having our own metal in commercial data centers. And we are like a modern, modern software company with all the complexity and all the challenges that that everybody else has as well.
- [04:48]
Gergi
And I guess all the not simple trade offs. For example, it's easy to point. You know, the community loves to say Rails does not scale or why would you do it? But I mean you are one example. Obviously there's other companies who 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 and then I mean we can.
- [05:05]
Thomas Zumka
Spend a whole hour probably just talking about the benefits of having a monorepo with a monolith versus, you know, hundreds of microservices. When GitHub was in 2007 was founded for I think more than a year, it was only the three original founders, Chris, PJ and Tom. Plus to Scott, who's now the founder of GitButler and Scott Charcoal, who is kind of like the first employee that was often seen as the fourth founder. And so a team of four is maybe better off of working in a single code base. You can move much faster and I think that was always 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.
- [05:56]
Gergi
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 it made sense. And then as you grow, you figure out your trade offs.
- [06:05]
Podcast Host
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 products into a single platform with a unified set of data. Here's how it works. First, statsig helps you ship a feature via 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.
- [06:40]
Gergi
Then you get your analytics, user account.
- [06:42]
Podcast Host
Metrics and dashboards to track your progress over time, all linked to the stuff you ship. Even better, Statsic is incredibly affordable with the super generous Free tier A startup 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.compragmatic that is S T A-T-S-I G.compragmatic 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.
- [07:24]
Gergi
Waiting for a review.
- [07:26]
Podcast Host
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@gt.devpragmatic that is G for graphite T4 technology.devpragmatic.
- [08:07]
Gergi
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 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 move to the cloud. And there's now an opposite thinking as well. What's your take on this?
- [08:37]
Thomas Zumka
GitHub, you know, started on the cloud really 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 loans. GitHub had no funding until I think 5 years into its journey. Back then unheard of 100 million came from around led by Andreessen Horowitz. But until that point in time GitHub was bootstrapped and it had very fast adoption. You know, when launched in April 2008, very quickly, the number of users, number of both public and private repositories kept going. 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 still be around. And so it was a natural business decision for the founders to say, how can we host this with 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, for cloud submitters that existed, you know, in 2008, 2009, where you had limited access to that layout and where, you know, especially the networking part of having multiple, you know, 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 and we still own, you know, 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 own in the sense of, I'm making air quotes for listeners. It's own 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, code spaces, get a copilot run on Azure Cloud and leverage the scale that you naturally, whether it's CPUs and Actions or GPUs in Copilot. Of course, Copilot, given its multimodal choice, and has anthropic models and OpenAI models and Gemini models. Not all of these models are on Azure. So naturally we also work often with both the first party API, aka the API that OpenAI or anthropic provider, and other clouds that have vertex backdrop 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, that's 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, just announced a US stamp that will be FedLamp compliant and we're going to expand into, into more regions in the years to come.
- [11:41]
Gergi
Yeah, I feel these are the like really kind of boring things, but they start to become really important when you are at a company that you know is now starting to care about these things.
- [11:50]
Thomas Zumka
Well, they're not boring from an interesting perspective.
- [11:52]
Gergi
Well, not boring but like 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.
- [12:02]
Thomas Zumka
The challenge, you know, if you go back to the Ruby on Rails conversation is and if you know a bit about Rails and how 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 ten stamps and you deploy hundreds of times per day? In fact, I think this year we are forecasting 12 million deploys across the about 1000 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 a deployment that goes to all these different stamps and run the migrations and if you need to able to roll back. So that was a lot of the engineering work that went into that. Less so I'd say the actual work of moving this to Azure was less work than getting the engineering system to DX the developer experience actually aligned with this. Now we are running in multiple, in multiple regions.
- [13:04]
Gergi
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 you know, one like 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 a. How you managed to keep this, how it's working inside a larger company which you know, Microsoft is not remote first. There are, I understand parts of it that are more supportive of it, but generally, you know, people are often in the office.
- [13:42]
Thomas Zumka
So the founders, they actually met in San Francisco. So you could argue that very, very early phase was kind of like three people in the same place.
- [13:49]
Gergi
And that's often, I guess that helps how that goes.
- [13:52]
Thomas Zumka
But yeah, very quickly GitHub started hiring superfans, you know, people that were interested in GitHub. Promoting GitHub helped drive in the community. 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 executive 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, 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, 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 and finance. All the functions work on GitHub and so they have depositories to describe their team. You know they're using pull requests to, 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 GitHub pages page that is only internally accessible and that goes through our identity provider. And so even there we don't do company wide emails. Almost never we do an announcement on the Hub. There's a link that is posted in the Slack channel but then everybody can see, then we take the conversation there. So yeah, today we are very much remote first company with people all around the world in different time zones. Almost everything is async. Obviously there's you know, meetings and our town hall meeting is called the get together. And so that has to be in some time zone and challenge there is that if you do it, you know, adjusting it for the folks in the US North America and, 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 the year to have one that is in the APEC friendly time zone. 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 a bad time for the Europeans because that's kind of like when you pick up your kids from school and go, go, 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, you know, in different places, in different phases of their life. And I think that helps us as a company to be as agile as possible.
- [16:53]
Gergi
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.
- [17:05]
Thomas Zumka
I think one of the core pieces there is not only as the startups are, but as the open source ecosystem is using it. Right, but the open source ecosystem by design is Async.
- [17:14]
Gergi
Async.
- [17:15]
Thomas Zumka
And they're not all in the same place. That would be never work if an open source project could only, you know, you could only be a contributor if you're in the same place and all the same time zone. And so given that we are catering to both, you know, commercial customers, startups, enterprises, those that are paying US money for GitHub Enterprise and Copilot 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.
- [17:46]
Gergi
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 past fun internal tools you have and what kind of internal tools do you still have today? Especially what engineers use?
- [18:12]
Thomas Zumka
If you look back into GitHub's history and we don't have the time to cover it all today, I can Recommend if I, if I'm allowed to Another podcast, the acquired podcast, they had an episode on June 5, 2018, so the day after the acquisition announcement. That covers a lot of the history of GitHub in the early days and in general a really good podcast. And they actually mentioned this that in the GitHub, you know, when it started had a very non traditional way of operating awareness managers. Everybody was encouraged to work on their passion projects and as such GitHub for many years didn't have a traditional IT infrastructure in the company. Everybody was built in house because there was the belief 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 GitHub TV. And so all the, you know, town halls and so on, you know, streamed on our own platform and of course that no longer exists. And we're using Loom. Using Loom for that Haystack you already mentioned that was exception tracking. And now keep in mind 15 years ago there wasn't like established players in that market that you could use, especially not in the, in the Ruby Alsberg. So Haystack1 was my such tool. Today it's Sentry that we're using for that. Another one was Halp Halp which was our internal support system where tickets got routed for folks to work on the ticket, have internal computer teams and yeah, now this is all on Zendesk and help has been retired but you know, some of these ideas have led to new startups where Hubbas is what we call GitHub employees, where Hubbas have taken the idea and maybe they were a bit frustrated that we're shutting down their internal passion project, have taken that and created a business out of it. I think 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 of examples from GitHub's history as well. There electron comes to mind which came out of Adam, which was our editor. Oh yes, our desktop app or command line interface. Those are all open source projects. So everybody can see what we're doing there and can take the ideas. And we mentioned 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.
- [20:44]
Gergi
One thing that keeps surprising me about GitHub is every now and then there's a security incident that is in the press that is like a big deal. Not always, but sometimes it starts with like 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, this was 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.
- [21:40]
Thomas Zumka
Security is part of our culture. We have the saying 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 hub raises their hand. And so we institutionalize that. Security is part of what we do. Of course we want to drive innovation and want to make customers happy, but we cannot win in the market if we lose the trust. And of course the worst day, you know, 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, 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 threat intelligence. Working closely with the Microsoft security team, the so called Cyber Defense Operations center and those folks that look into, you know, finding security vulnerabilities, threat 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 very trivial example is that if you have a person, if you for example, your user ID accesses not only the pragmatic engineer Repositories, but also those of, let's say BMW at Mercedes, that person is very unlikely to exist in the industry. Right. Like even if you're working for like 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 research that's that are hunting for security vulnerabilities using our own security products like CodeQL, which is query language that you can use to find variances like variations of existing code flaws. You know, 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. In the meantime of the closed disclosure, hopefully you know, the bug is already fixed in there. So we are doing a lot of that, we are investing into a lot of of that. But of course 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.
- [24:22]
Gergi
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?
- [24:33]
Thomas Zumka
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.
- [24:43]
Gergi
So that's about 10%. If I just look at the security.
- [24:47]
Thomas Zumka
Versus engineering function and then look at just engineers, I see engineers, it's a little bit under a thousand that work and build software. And then it's of course managers and product managers and technical program managers, designers and all that.
- [25:00]
Gergi
One interesting thing I've heard from a current getaway employee is you are starting to look into hiring junior developers. Developers less experience, which is a little bit different because most of the industry we don't hear this. Why are you deciding on this? And this is just a really positive thing to hear. I'd love to hear more about your thinking.
- [25:18]
Thomas Zumka
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, 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. And 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 where they at least have a way to meet with folks at our San Francisco headquarters or here in the Northwest or elsewhere in the world. And so we have an intern 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 cottage and university and often, you know, a different, you know, diverse background into, into the company and you know, come in and often, you know, the, 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 true in engineering, you know, it's the same if you look into sales or into marketing. Obviously the way, you know, marketing works today is very different than it was, you know, five, 10 years ago when the press, you know, traditional media played a much bigger role. Today you got to be, you know, in a podcast and you have to be on YouTube, at TikTok and like today, just like today. But yeah, you know, you see more and more of that happening. And of course, you know, the, when you, 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 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 we're trying to have, you know, a nice balance between early and career engineers, senior engineers, we have know a number of distinguished engineers and they all contribute back to our platform.
- [27:54]
Gergi
No, I love it because like 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 might have, but we got fresh ideas and it's just so rewarding. Looking back at those interns, you know, I now see them many, many years later. Some are now principal engineers, some are CTOs. But 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. They're now talking about AI colleagues on the keynote. Why? 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 thing doesn't apply, but their thinking is real.
- [29:01]
Thomas Zumka
I think that's backwards in many ways. I think actually folks that, you know, go to high school now or to college or even, you know, kids earlier and in their education, they get to use AI much faster. And they, 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. The CEO don't touch, never touch a running system. They haven't been in an experience where some change that was applied, you know, from, from upper management or from the engineers themselves has led to, you know, a big outage and things like that. So they're more open minded. You, you know, you kind of see that when you look at media as we already talked about, like kids are much more open to just scoring through charts and consuming the content they'd like to consume. While you and I were a child, we 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 prompting skills, experience with different models, you know, intern doesn't mean I haven't worked for another company before. It might be my third, my second or third internship or I might have already been coding with, you know, a group of students on my own project, on my own app. So you get a lot of good New ideas and outside perspective 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 know, 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 base. 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 flash ideas within the company, but also for us important to give back to those that in the future become GitHub customers.
- [31:08]
Gergi
I love it and I feel it's also just a very, it's the cheapest.
- [31:11]
Thomas Zumka
Way to do it.
- [31:12]
Gergi
Just like, you know, you're not going to have the highest salary for the new people. This is a silly way to think.
- [31:16]
Thomas Zumka
About it, but I talked with the.
- [31:18]
Gergi
Product manager recently and I just like had a deja vu when you said it. This product manager was saying, she 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, she's like, for years as a product manager, I'm sitting in front of engineers telling them, oh, you know, good product thinking, think about the customer. And they're like, just tell us, you know, 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 a competitor. Here's what they're doing, here's. And she was like, I love it.
- [31:47]
Thomas Zumka
Like they.
- [31:48]
Gergi
So I wonder if like by hiring these people and actually just ignoring, as you say, the backward thinking, you might get the next generation of software engineers.
- [31:56]
Thomas Zumka
Gen Z is already too old, I think to some degree fair, because Gen Z I think starts 1980 or something like that. The Millennials Gen Alpha, right? Like the 60 years old are coding today. And so that's Gen Alpha or soon, whatever. The Gen Beta I guess is the next one. And so but you're right, you're getting folks that didn't learn to code on a Commodore 64 on a PC that 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, but with a different perspective.
- [32:37]
Gergi
Yeah, I wonder just like silly thing, would you rather hire an engineer with the same years of experience of someone who has traditional coding and learned and university or same years old you learned in university and did some university projects or this engineer or this, this, this fresh grad who did a university but they actually have before that five years of building programs and Roblox and they actually built this like 100 person thing. It's like the skills that that person brings and the mindset, you know, the way they think about things.
- [33:07]
Thomas Zumka
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 it and either dropped out on an event. Right, that's. 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 green contribution graph on their GitHub profile, because they have shown they contributed back to the Ruby on Rails code base, to the Git open source code base where at GitHub we traditionally have employee folks that are spending a lot of time on maintaining Git together with the open source community. So I think a lot 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 years at another company. Of course we take people to an interview loop and I think increasingly we are 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 get a job in a tech company very soon, you're going to be asked to show your prompting skills, your copilot 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 to basically because the goal of the future engineer is no longer to run it all from scratch. And the goal is to combine their prompting skills and agent open source libraries into getting that problem solved much faster than they could have done two or three years ago.
- [34:39]
Gergi
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. So Git. I did a podcast episode with Linux kernel maintainer Greg KH and he told the story about how Git was created in 2005. In fact, recently there's a podcast with GitHub. A staff engineer at GitHub interviewed Linus Torworlds in 2005. Linux Torwards got frustrated with the 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 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 you understand from talking with the early founders.
- [35:29]
Thomas Zumka
The first commit was October 2007. So it was about two years after Linux had done git. Right. And then October 2007 to I believe February 2008 is when they started beta testing it with folks in the Ruby OS community. And then April is when the public version of GitHub launched. So it's really fast as well. October to April, 36 months. If you go back to the history books, it's Chris and Tom Kasten Warner and Chris Wanstrad meeting in a bar as I remember it 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, the most popular open source platform back then, but also painful to use. I think that's fair to say. Like those that I had a couple of projects on sourceforge as well. It was kind of designed for different era of the vat. Yeah. And didn't make the jump. And then what ultimately you know, became known as, as Web, as Web 2.0 or Cloud Native. And so I think the idea was okay, Git is here, Git is amazing, but I want to host it without, you know, setting up a server and installing, you know, the backend and managing, you know, SSH access. And so they started building around, around that idea. What always make GitHub GitHub is that they put the developers first. Like if you go on the Wayback Machine and look at the first GitHub homepage, it isn't very fancy. It looks like a commit log. It's 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 Octocat is a funny one. And I learned that actually from the acquired podcast because they learned from the Twitter founders how they got their logo and they bought it on some stock graphic page from a British designer, I believe. And so they looked for other graphics that the same designer had done and bought this hybrid of an octopus and a cat and made that the logo. So there was a lot of as a bootstrap startup that's scrappy, that has a cool technology that might become the future of version control. And then they built what is now known as cloud native, bought a cloud native company and then yeah, it grew fast. And back in the day, probably the product with the fastest product market fit nowadays 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, I 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, you know, 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 Ruby and Rails conference in Las Vegas in 2009 and saw Chris once tried giving a talk about GitHub and what they were up to. And that's, I would say when I became a GitHub fan and when I started using GitHub in my projects. But until that point, you would use some help, self host a tool, you know, 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, log in with GitHub and create a repo.
- [39:04]
Gergi
Yeah, When I look through the history, just the things that I could find, what struck me as like, so like as the first commitment was in 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 used 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 back 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 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.
- [40:02]
Thomas Zumka
Git solve the pain point that we had with all these other distributed version control systems. You know, Subversion TFS had its own version control until much later when they added git support were painful to use and were painful to use especially when you had multiple teams working together within the same code base. Git bought 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 could make changes to multiple branches and then push upstream or, or shared with your coworkers. 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 something and something like that and just wanted something new to solve that problem. And then it was just easy to shoot an account and try it out. Even user interfaces like browsing the repo, clicking through 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 to follow full page 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 asking the other maintainer to merge in your changes before that div files were exchanged.
- [42:07]
Podcast Host
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 a parallel tasks like bug 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@AugmentCode.com Pragmatic.
- [42:57]
Gergi
Well, I think this is one of the biggest things that people miss as I understood understanding. So Linux Store was designed 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 changes bundled. And that's how Linux works. They just use email. And GitHub does not do this. Indeed, GitHub invented 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?
- [43:34]
Thomas Zumka
I'm getting the date form. I think it was a year or so into GitHub pretty early. It wasn't definitely, it wasn't there on day one. It came sometime later. We can look it up and show notes. But it was a new thing at the time and I think it's ultimately liberating for software developers where you send a pull request and if the maintainer doesn't like it, they can just close the pull request or 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 a lot of that also happening, that people just keep their forks independent because they don't want to have the obligation 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. Because some of that might be just with hackery as well. Right. 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.
- [44:42]
Gergi
So what am I kind of 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?
- [45:38]
Thomas Zumka
It was always prefer open source. And 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 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 is 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 had a lot of individual developers giving us feedback. Especially, you know, 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, 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, you know, to review my own code. I just merge push into main branch and that's cool and so but yeah, GitHub innovated in the business model space as well. And you know, 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. Wi fi wasn't like you have wi fi as far as I remember. I don't know if Starbucks, maybe Starbucks already had it, but like 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 subversion didn't have a push. You would always commit into the upstream change branches, roll back. All these operations that are now natural with git, they weren't natural in 2007, 2008.
- [47:47]
Gergi
So GitHub started off, it starts to get real big traction. 2008, 2009, 2010. The next big kind of milestone I remember from a developer's perspective is until then to use GitHub, you could use the web version and use the local command line interface. You just learned all the commands it looks about. The easy ones are easy. And then 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 atom 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 Atom 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?
- [48:44]
Thomas Zumka
I don't know the history of all these apps. My suspicion is that when you say waited this long, I took make the counter argument in how long is long for a startup to move from 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 I think a year or so before Vs Code launched. The time was ripe for a new generation of IDEs of both of them are open source, you know, for the app position. They both ended in the same company and then ODV 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, you wouldn't have a backlog, you would have the.
- [49:37]
Gergi
So back then really there were no managers, there are no.
- [49:39]
Thomas Zumka
Well, there was obviously a CEO and like a little bit, 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 to learn how to make an espresso. And that was literally one of the onboarding videos. And they got to have some fun whimsical future whimsical culture. And you got told pick something that you're interested in and that natural leads to developers picking things that they want to solve for themselves that they care about. And so Adam was actually, you know, Chris Wanstrad, the CEO at the time and for most of GitHub's journey until the acquisition was one of the, you know, core maintainers of the Adam project. And so I think you don't hear.
- [50:31]
Gergi
That at all about passion CEO being a core maintainer.
- [50:33]
Thomas Zumka
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 serve that purpose. If you think for example about blame views, blame on GitHub.com is just clicking a button to see who modified which file which line in the file. But if you do get blame on the comment line, it's 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.
- [51:18]
Gergi
I'll say that I use GitHub Desktop a lot. I mean everyone 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 like I appreciate it when it came out.
- [51:29]
Thomas Zumka
I barely even use it but I use the Git integration, GitHub integration And VS code a lot for the same purpose. And so there's. 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 through ssh. I think all of these pieces, you know, ultimately helping, you know, to create the developer experience that we now consider normal. By no means was normal 20 years ago.
- [52:05]
Gergi
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?
- [52:25]
Thomas Zumka
It was 2018, early 2018, that back then, Nat Friedman, my boss within Microsoft, CDP in the developer division doing mobile developer tools. Nat came from Xamarin, so had joined Microsoft himself for an acquisition. I had joined for the Hockey app acquisition. So we ran like a bit of a outside in team within Microsoft with lots of people coming from companies, lots of 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 Nadara had become the CEO. Satya had very early on embraced open source. 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 the stack and where the future is going. You may remember this part of the strategy back then was cloud first, mobile first. And in many ways that is still true today. We're not no longer saying those two things. If you think about how you interact with Microsoft products today, they are on every device, regardless of who makes the device, what operating system.
- [53:44]
Gergi
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 of Microsoft, we were skeptical, honestly.
- [53:55]
Thomas Zumka
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 and they the enemy. At Microsoft, competitors are at the same time also customers and often partners. We are providing, if you take for example Azure AI Foundry, our inference stack for large language models, we're providing those not Only to our own copilots. We're providing those to many other companies that may directly or indirectly compete with GitHub or with other Microsoft products. 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 where you make GitHub part of Microsoft and not lose all the open source maintainers because they feel like Microsoft is not going to be a good steward of GitHub. And we sat 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 a single sign on provider or of course we have blog posts where we talk about Copilot and the Microsoft model and things like that. And Minecraft is. Many kids I think realize much later in their childhood that one of their favorite games is actually the same company that also produces the operating system and the professional network and GitHub. But part of 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, first product was basically for the Altair and you know, here at the conference center. I don't know if you had 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 1990s. I think my first version of Visual studio was visual C 1.0. Came with a book and then had Visual Jeff, which was like Microsoft's Java clone. And then I bought like 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 IDE at a one time price would be something that has no market fit anymore. You know, Microsoft lacked access to the open source ecosystem. It didn't have, you know, the same attraction to cloud native developers.
- [57:05]
Gergi
It was just being not trendy at all.
- [57:07]
Thomas Zumka
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 three principles. And we believed 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 the acquisition. Not a Microsoft gets a lot out of GitHub but Microsoft is willing to invest into GitHub. GitHub in 2018 at the time you start the conversations with them was about 700 employees all up. And you 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 code generation 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 we announced last July so about a year ago now that revenue has grown to over 2 billion annual recurring revenue run rate. And that keeps growing. And we are very happy with these business results contributing back to Microsoft's earnings. But in that order. Right. Like developers first making grid developer products accelerate GitHub and then eventually GitHub, you know, accelerating Microsoft and giving back both on the product side with Copilot or on the revenue side with our results.
- [58:40]
Gergi
But I think this is this last thing is just worth emphasizing in the sense that I think as a developer 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 as a professional use cases. Right. To help their work.
- [58:58]
Thomas Zumka
If I remember correctly, 2017 was the last official revenue announcement that GitHub made before the acquisition and they were at about 200 million run rate. And they announced at that time that they were looking for new CEO. So Chris was ready to step down and that ultimately resulted in the acquisition then in June 2018 through an acquisition and a new CEO Ned Friedman. But like 2017, 200 million to 2024 in seven years revenue went up factor 10.
- [59:29]
Gergi
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. If you're like such an adult report to shareholders, it's good to know that those, those things are going well as well.
- [59:43]
Thomas Zumka
Well and I think you know the. For a long time developer tools were not seen as a, as a, as a revenue driver in the, in the industry. I think you know there were a few examples like companies and Jackbrains comes to mind or JFrog. There's a bunch of companies that we're focusing on developer tools but I think if you time to go back five years or before that give up because let's just 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. To date this world obviously has dramatically changed.
- [60:20]
Gergi
Absolutely. But as I was talking with Scott Guthrie, the interesting thing was that the last company that was able to make develop developers pay for developers 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 paid for MSDN documentation for access to the latest software. And you know that time has passed and we were talking about Scott on some of the learnings. But it's interesting how Microsoft figured that out. I feel Microsoft is very good at figuring out this great mix where again back then and 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 I was looking back and I remember back at my GitHub issue 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 like GitHub is not doing anything. And then the next thing I looked at the changelog and the only notable thing I've seen ship it started in 2021. Then GitHub sponsors came out the package registry copilot 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.
- [61:43]
Thomas Zumka
I mean obviously the time before Microsoft, you know, 2015-2018 I only have hearsay and then a little bit of insight. I think a 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, many developers did that back then and still are very much in love with the brand. Like the Octocat Internal, we call it Mona.
- [62:16]
Gergi
How do they call it Internal?
- [62:17]
Thomas Zumka
Mona. Mona, like Mona Lisa, Mona is something that is recognized. You get asked about it on the street or like 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, you know, I had a, you know, on. On an airplane. The crew member asked me about GitHub. I'm like, how do you know GitHub? And she's like. She was like, well, I used that in college for some computer science course that I took. And I think if you have something that is so beloved by the. By the space, that also means the expectations are really high. Like, it's often that, you know, the disappointment is even bigger if you actually care about something, while if you don't give a damn about this thing, then whether it's up or down or whether it's broken 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 chipping stuff because you would change something. And 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 lines 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 and what we call staff ship, what Microsoft calls dog footing. So features that landed within the GitHub organization that hubbles would see when they use. You know, one funny thing is we have even today as we're using GitHub every day, I often actually don't know if that feature is available to you because I only see GitHub how a hubber would see it. And there's a way to disable all these features.
- [64:05]
Gergi
But how feature flags probably.
- [64:07]
Thomas Zumka
Well, no, I can hide the staff bar and then disable some features that you don't see. But how often do you really do that? And do you then remember that in a conversation that Gergen doesn't have the feature, but I have it and I thought it already shipped, but it is actually slated for next week. So I think that created a culture where things were internally shipped but never made it to the public because everybody was worried, is that good enough to ship it? 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.
- [64:43]
Gergi
That was the fast one.
- [64:44]
Thomas Zumka
Yeah, that's true at that Universe. And 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, it was a bit of a hack built on top of containers in Google Cloud. And we quickly saw from the data that the product wasn't actually meeting the requirements from developers. Many developers wanted full CI CD, while GitHub Actions originally was designed more 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 at the last ever satellite conference in Berlin. And then Covid came and that ruined kind of like the plans that we had as we came back from it. We 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 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, accessibility, things that you might not actually see have changed because if everything is working, you don't notice it, but it created a lot of investment behind the scenes. So we are feeling good about the pace of innovation that we have today. But yeah, it took us a while to turn the ship around. And even in a team of 700 people, that takes a while. And certainly with 3,000 people, it is something that requires a lot of energy and focus.
- [66:21]
Gergi
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. Yeah, you can have some things that you need to work through and growing too fast is amazing. I think the best problem for any team to have, but it's still a problem that you need to solve and you get through it. Now. Copilot 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?
- [66:52]
Thomas Zumka
21, 21 yes, beta came out in.
- [66:55]
Gergi
2021 because it was built on an earlier model before ChatGPT launched. It was on. Was it on GPT2?
- [67:04]
Thomas Zumka
No, it was GPT3. Was the. So GPT3 came out at the. Right after the build conference in 2020, which was obviously given the pandemic fully remote, but Kevin Scott and Sam Altman did a session about Transformers and large 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 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. 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 letter 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 low 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 auto completion. That worked so well that very quickly we saw our internal hubbles 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 that 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 this had grown to a million users. And you 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.
- [69:26]
Gergi
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. Startup 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 was. It became public.
- [69:54]
Thomas Zumka
So it was GA already. It was.
- [69:55]
Gergi
It was generally available.
- [69:56]
Thomas Zumka
Yeah, it was generally available in June 2022 and which started charging for us for it for individuals in August 2022. And then 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 called like. They showed like a similar scenario. That is what you see now. The agent doing where we ask it to write some code and make modifications to the 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 built Copilot, how it can help their developers. The first user studies come in. We were the first company comparing a group without Copilot with a group with copilot. And the 5% number is obviously 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. There's lots of other things that developers do day in, day out where you don't get the Copilot to make you that much faster. But it was a very exciting time. And then in 2023 we launched ChatGPT4, bought 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.
- [71:34]
Gergi
And then 2023, on a post from GitHub, I'm not sure if it was you, so I don't want to misatch you, but it was written that just as GitHub was founded on Git, today we are sorry. So it was you writing it that just as GitHub was founded on G, today we are refounded on Copilot. This was in 2023 and Copilot was clearly very strong. What has this change meant since then? And now it's been two years.
- [71:58]
Thomas Zumka
This was at GitHub Universe 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. Linux towels did. But they realized there's a new technology that changes how developers only to version the code, but how they collaborate, right? GitHub, if you think about it, GitHub is designed for asynchronous collaboration of developers. That what GitHub is really all about. And with Copilot repeated history because we didn't invent Transformers, we didn't invent large language models, we didn't train GPT2 or 3 or codecs, but we saw something that changes how developers work. And if you're honest, we saw an opportunity for ourselves to accelerate. My backlog is endless. There's lots of GitHub issues in repositories that were filed. Whether the issue was filed in 2014 with customer feedback and 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 high priority. And you mentioned security issues and availability and all these things are also high priority. When we saw GPT3 and then Codex, we saw an opportunity to bring the effort down for 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 developed platform now those are the Venn diagram of GitHub and VS code and NVS 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 and just on.
- [74:05]
Gergi
Build two big announcements related to GitHub one it was open sourcing Copilot extension. Why did you decide to do that? So 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. Windserve Cursor. I think there's some 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?
- [74:40]
Thomas Zumka
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 part while startups are taking open source, forking it and making the closed source. This is like. If you had told me that interesting years ago, I would have said, you'll have it backwards, buddy. This is true, right?
- [74:58]
Gergi
We're not open source.
- [74:59]
Thomas Zumka
That's not, you know, and look, you know, that's. 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 stepping into our footsteps, into our own footsteps of VS code over the last 10 years, and we felt the time is right to bring the Copilot 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 copilot in 2021, 2022. It didn't take long until people reverse engineered the VS code extension. It's at the end of the Day JavaScript, rewrite 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 is 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, not give them the full VS code experience. You want that scope experience for an interview loop. So I think 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 ultimately helps the developer community to have that piece of client code available. And 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. Whether it's the, the compute or inference layer, whether it's the security or control layer. Enterprises want control, 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 platform and we're giving it certain permissions and we are protecting the agent from doing things that you might allow for a human. But you want control over that when the agent does it.
- [77:39]
Gergi
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, 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. 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 just really like how Microsoft seems to be keeping this idea of like sometimes opening up the business to others can succeed. Startups can do it. It's better for everyone, especially as for developers. And as you mentioned, you just want better tools.
- [78:30]
Thomas Zumka
As you mentioned, Xcode, we actually have a copilot extension for xcode. It's a bit of hacker given the extensions, given the limitations, 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 IDEs. We even bring it to Eclipse and that is in preview now, 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 just. Maybe it's multiple of those. Obviously if you think about for example artifactory or JFK, often companies have that in the stack together with GitHub or HashiCorp, Terraform and of course you have a cloud and a keywalk, Keystone Secret Store and a Key Value store and whatnot. But it is important to have Copilot available across all these ies. And our Xcode extension is already open source and was open 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 the maintainer benefited from it, we benefited from it. But so that means the system prompt, the APIs, all that you can already find in Xcode extension. And so now we're continuing that journey with VS Code and others.
- [79:59]
Gergi
The last question I wanted to touch on this is agent mode or GitHub agents was also an announcement that 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'll just looks seems like a boring job to be a manager. And then the other thing is what will happen with what could happen with software engineering job. And then you said earlier that you believe this will increase actually just recently and in public. So what is your view on Asians 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 frigging big change.
- [80:52]
Thomas Zumka
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 the MCP service model context protocol that you configure for it, or the tools you allow it to use, or the repository you give it access to. Because obviously as an engineer, as a human engineer, I can look beyond the one repository boundary and see what has been happened in other repositories. While the agent needs to get permission to do that, right? 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, right? A compiler is a tool that helps me to not write assembler instead 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. And 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 this exists where the size was limited back then for physical limitations. Today it's artificial, you're limiting it because do you want to create a challenge? But you could only win those demo challenges if you knew 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. I don't know many developers that want to write test cases and certainly not more than they're already written. Unit testing is always a how many do I write until can get away with it? When I go into codalview 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 subjective thing. And those that try 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 the code that I'm writing does exactly what I want it to be. Until you have even something simple like a pull request description, 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 no change? Because when it describes the code changes, it doesn't have the confirmation bias that yourself had when you would write your own description. So I think we're heading into that world. And now you have these, let's say I start four agent flows. I think that's what Jessica Dean did in the day two keynote. Well, but note, so you have all this code generated by all these agents. I'm the one now having to validate that. What the agent 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 more merge conflicts by the time you're merging those things. So you got to understand all that code. You got to understand how the system is designed. You need to know what the agent did to have the level of confidence, trust. You know, 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 nonprofit, operating under budget. And so you need the agent to write code that solves the business problem and still makes you a healthy margin.
- [84:44]
Gergi
It sounds like, keep an open mind and experiment and see how they can help you. Right?
- [84:49]
Thomas Zumka
The other thing that is, I think, super important to this is that we are already seeing this paradox because now we have all the AI requirements that come on top of what a full stack engineer does, right? Like no longer just backend and database and infrastructure and front end and how the front end communicates with the backend. And 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 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, you know, listing the first 10 repos that you have, or is it a GraphQL API that can take lots of complex queries to actually run another result? Right? And so if you just take that example, you got to have engineering skills, you 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 no 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 where they now know. Now I can sign into the agent that will provide high quality code without me having to re prompt 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.
- [86:27]
Gergi
Love this takeaway abstractions and being able to take on more complexity. This was a really good conversation.
- [86:32]
Thomas Zumka
Yeah awesome. Really great to meet you Gergi in person and looking forward to stay in touch.
- [86:36]
Podcast Host
Thanks very much to Thomas for this conversation. The thing that struck with 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 agents, but software engineers directing AI agents on what kind of of work to do and staying in charge of this work. 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 enjoy 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.