The ReadME Project // @github

Here’s what’s in store for this episode:

00:00 - Intro: The hosts discuss AI image generators and draw parallels with GitHub’s pair programmer: Copilot. 

03:34 - First Commit: Neha and Martin discuss ARPANET’s 1980 crash, the first known network-wide crash. 

6:16 - Feature Story: The ReadME Project Sr. Editor Mike Melanson discusses his recent article: Don’t call it a comeback: Why Java is still champ.

21:52 - #AskRMP - Xavier René-Corail provides his insights on best practices for securing open source projects. 

26:14 - The Interview: GitHub CEO, Thomas Dohmke, discusses how his career as a developer enabled him to understand the challenges that businesses face.

Looking for more stories and advice from the open source community? To learn more from the authors and experts featured on this episode, check out:

• Don’t call it a comeback: Why Java is still champ by Mike Melanson

• Open source gaming by Klint Finley

• Developer Story: (Virtual) reality check by Johanna Pirker

• GitHub Blog: Research: quantifying GitHub Copilot’s impact on developer productivity and happiness

• Attend GitHub Universe—virtually or in person!

• Join Game Off 2022

---

Martin: Let's do it! The meeting after this—we have a hard ass I don't really want to talk to so... 

Neha: He's talking about me! 

Neha: This is The ReadME Podcast, a show dedicated to topics, trends, stories and culture in and around the developer community on GitHub. I’m Neha, and I lead GitHub’s Community Engineering team. 

Martin: And I'm Martin Woodward from Github's Developer Relations team. 

Neha: I'll tell you a little bit about what's been on my mind lately. I've been thinking a lot about the basics, right? Going back to the basics and getting the basics right when it comes to my personal life, when it comes to code, when it comes to building a great environment for communities. Right. What are those basic pieces that come together and make a great experience? What about you? 

Martin: Yeah, some of that as well. I mean, we've both been sort of growing our teams and things lately. And so going back to the basics and thinking about how you ship things is definitely something that's been on top of mind professionally. Outside of work, have you seen stable diffusion yet? Have you been playing with that?

Neha: Stable diffusion? 

Martin: Oh, man, Neha! It's like winning the Internet. So it's the latest… If you’ve played with like, you know, DALL-E and some of those kind of AI generated things. 

Neha: Yeah, I feel like I've heard about something related to this. I've heard about how there's like a bunch of artwork that's been recently created by AI that's won awards and stuff. Is that related? 

Martin: Yeah, it's using a different model. So people are probably, mostly, familiar with DALL-E, which is an open AI based sort of model that's kind of completely closed. This stable diffusion one is out there and available for people to play with. And so we're already seeing huge innovation. You know, 30 days it's been out. 

But it kind of got me thinking a lot about Copilot as well. So GitHub Copilot is our AI pair programmer and it doesn't just create code. You can't just put it in front of you and say, “give me my code.” You have to kind of explain what it is you want and then it can help you with the… the machining, the manufacturing of this creative work. But it's still down to you as a developer to be creative and to come up with creative solutions. Just like with these AI art tools, you have to still be creative and come up with the good ideas and the good kind of input into that model to get good output. 

Neha: Oh, that's really interesting. I think also what comes to mind, I think we got to play around—I saw some teammates playing around with DALL-E when it came to getting our logo right. Right, “the basics” of any team. It's so interesting that, you know, there's all these new technologies that are coming out and it's just a matter of us knowing what we want and understanding the parts of the system on how we want to use it and getting it right. So with that in mind, we have a great episode ahead of us. 

We're going to be talking to The ReadME Project's Mike Melanson on why Java is still going strong. We're going to get a listener question from our social hashtag #askRMP on securing your open source project and turn to Xavier René-Corail, the senior director of security research at GitHub for some answers. And then you're going to hear my interview with GitHub’s very own CEO Thomas Dohmke, where we talk about everything from GitHub Universe to his latest LEGO project. 

Martin: Alright everyone it’s that time—First Commit.

[Jingle] On your mark, get set. We're writing on the Internet. 

Neha: What do you have for us, Martin? 

Martin: Okay, it's a good one. So picture this, it’s October 1980. You probably weren't alive yet, I very much was alive. 

Neha: No comment. 

Martin: And the soon to be President, Ronald Reagan was hard at work campaigning for the highest office in the land, only an. 

[Audio] Only an all encompassing program, combining restraint in government spending with economic growth in the private sector, will work. 

Martin: Empire Strikes Back was the top grossing movie of the year. 

And I was a nervous little four year old just starting school for the first time in fantastic flares and a bow tie. The Internet at this time was still very much living behind closed doors to most Americans. But ARPANET, the name for the precursor to the Internet, housed at the Department of Defense, was the ripe old age of 11, which means that the network was about to hit its teenage years. And that teenage rebellion came a little sooner than expected. 

On October 27th, two separate message interface processes, or IMP, had some communication issues. “Does not compute, does not compute.” Functioning a bit like routers. IMPs were supposed to standardize messages throughout the network. IMP-29 was having a pretty rough day going through a hardware failure and that kind of put a damper on things for IMP-50 who received some bad information, which then repeated that information over and over throughout the network, like a gnarly game of telephone. Nodes were overloaded and eventually had to be manually restarted—that's computer speak for switching it off and on again. So for four scary hours, at least for those in the know, ARPANET malfunctioned in a way that was similar to the DDoS attacks we see so commonly today, which made this fateful day in history the first known network wide crash. 

Neha: All right, Martin, that was pretty good. And not to one up you or anything, but I have it on good authority that October is also a big month in the history of GitHub itself. October 19th, 2007 to be exact. At 10:24 p.m. that day co-Founder Chris Wanstrath put up an empty default Rails app committed to the github/github repository and at that time the co-founders were working on the project mostly on the weekends. You know how it is around your day jobs. And this communication was put out in anticipation of a Saturday morning working session. But it's important to GitHub in particular because it was the very first First Commit ever on GitHub. 

Martin: Right now. We've got a pretty important conversation today, and I'll give you a little hint: Don't call it a comeback. 

Neha: Oh, please tell me there is an L.L. Cool J angle on a developer story. 

Martin: Not quite, but it's still pretty fun, in my humble opinion. Today we're talking about Java. 

Neha: Oh, so not L.L. Cool J, but also a good topic. 

Martin: I mean, it definitely is. You know, before I was on the .NET, I used to be a Java developer myself. That's actually kind of how I got my start in professional I.T. So I was really interested in this article from Mike Melanson, Don't call it a comeback. Why Java is Still Champ. Mike joins us on the show today. 

Neha: Hey, Mike. 

Mike: Hey, how's it going? 

Martin: So before we talk about why we think Java is still relevant, Mike, tell us what their naysayers are saying. You know, why? Why might some people think Java is dead? 

Mike: I think one of the things about Java is it's been around forever. So people have had chances to call it dead again and again and again. Beyond that, I think it just has sort of an image crisis in some ways. You know, it's involved in the enterprise. It's not like an up and coming language. And at the same time, it doesn't have the hype that other languages have. You know, like even though Rust and Go have been around for a decade, they're still sort of new. And people love the new shiny things, right? So I think that takes up a lot of the mindshare. And then I think there's just the fact that we're in this new age of cloud native development being sort of a new thing that's gaining ground. And people see Java as this sort of bloated language that doesn't move as fast as these other languages. So they see it as not sort of, up to snuff, for the latest thing. I mean, really, beyond that, you know, there was an article I read somewhere and it was talking about a silent majority saying sort of, “if you're getting all of your information from Hacker News or from these other places, you might be tempted to think that Java is dead.” But in reality, there's just a whole lot of people out there still enthusiastically developing in Java, just not arguing on social media about it. 

Neha: Yeah, you kind of talked about, you know, the fact that there's like these silent devs that are working on it. And I want to contrast that with the fact that, you know, Java as a language debuted in 1995. So my question to you is like, is it still because it was the first mover and it was there first, and entrenched in so many companies from day one? Or are there other major benefits to it? 

Mike: I mean, that definitely doesn't hurt the fact that it's in all of these major companies over the past decade, it's been, you know, the main thing for big sort of high scale data infrastructure like Apache, Hadoop and Kafka and Spark. I mean, Java is also still being taught in school—so the pipeline is there. There was an Oracle employee who works on the JDK, the Java developer kit, who mentioned that while there's lots of people that talk about Java not being cool, not moving fast, that's actually an enticing feature for some companies. Hmm. They don't want a language that moves quickly. They don't want a language that changes. They want stability. And then beyond that, of course, it's been the primary language for Android development since the beginning. 

Martin: Yeah, I mean, my time as a Java developer was probably around like ‘97. So I think I stopped being a professional Java develop around 2012. And I remember in your article you were saying that a big turning point for the language was in 2014. So what was the big turning point? As far as you can see. 

Mike: The big turning point in 2014 was that they finally got Java 8 to come out. I mean, Java 7 had come out somewhere between there. Java 6 had come out in 2008. So it was almost a decade between those two. During that time period, Node.js had arrived. Ruby on Rails got sort of going. It was sort of at the peak of its hype, and they both had a bunch of features that, you know, Java developers started looking at and wanting: brevity of code and rapid prototyping, stuff like that. So it sort of was a contrast. And then when Java 8 showed up in 2014, that really sort of brought those new features, such as less verbose code. I mean, at the same time, the Spring Boot Framework also showed up and handled some of those issues. And beyond 2014, there was actually another big turning point that Mike Milinkovich from the Eclipse Foundation noted, which was, in 2018, Oracle changed the release cadence to a six month release. So, you know, you didn't have any more unknowable five year periods between Java versions. Every six months you had a steady release so you could depend on something new coming along if you needed. 

Martin: Yeah, I mean, it reminds me a lot of the innovation cycle or lack of it that happened with things like Internet Explorer and then, you know, when it became edge and stuff. You know, how this very, very dominant player got relaxed with its position of dominance and stopped innovating and stopped pushing forwards. And I think it takes these periods of the harder times to be handed some humility for a technology to then start innovating again. 

What about today? Obviously, I went from Java and I went to go look after C# and some of the .NET languages and things. So what do you think is sort of some of the, you know, the competitors to Java and what might be dethroning it? What might be taking over? 

Mike: I mean, today, I would say C# definitely falls into that realm of a direct Java competitor. There's lots of people that say it makes them be able to code faster. It has a slight performance advantage—although if you really look into that, it's sort of a toss up on whether or not that really matters in the end. I mean, as far as C# goes, it's like any, you know, “this language versus that language,” you're going to have pros and cons. Other languages, though, there's Go. Go accounts for 75% of the code in the Cloud Native Computing Foundation ecosystem. So you're talking Kubernetes, Prometheus, Vitesse, things like that. And all of that is sort of the future of infrastructure. So, while you have Java in those—you know, Apache Hadoop and things like that—all the new stuff (or 75% of it at least) is built with Go. In the realm of mobile development, you have Kotlin, which comes from the Java ecosystem and people have been really pretty excited about Kotlin in recent years. I spoke to Christina Lee, an Android engineer at Pinterest, and she had this to say about the relationship between the two languages. 

Christina: So Java was the programming language that most Android developers started with because it was the first one to be included and supported on the platform alongside some lower level languages. And Kotlin is an evolution of the Java programming language in a lot of ways, and it was introduced on Android a few years ago for official use. Although there were some renegades who started using it before that. Shout out to all of those people. It was, it was wild times. In terms of similarities, they both compile down to bytecode for the Java Virtual Machine. The differences are that Java is a lot more object oriented, whereas Kotlin takes less of a strong stance on that point. And Kotlin also adds a lot of layers of utility and safety on top of what Java was traditionally offering. 

Martin: Kotlin was really interesting because it kind of lived that promise of the JVM and bytecode in general. That's something that the .NET framework and the like, multiple languages always had going that we never really saw happening as much on the Java side. But with Kotlin it definitely was great to see, you know, the bytecode being used for what it was for and that sort of—coming to happen technically. But why do you think with things like Kotlin, that people are actually choosing it over Java? 

Mike: I mean, it doesn't hurt that Google added support for Kotlin in 2017 for Android development, and then two years later, they actually said Android development will become increasingly Kotlin-first. So new Jetpack APIs and features are offered first in Kotlin and things like that. So there's definitely a focus in mobile development on Kotlin being the preferred language. Beyond that, I mean, Kotlin runs anywhere that Java runs, you can sort of work interchangeably between Java and Kotlin if you'd like. Beyond the technical reasons, though, Kristina prefers Kotlin to Java for what she calls the “people reason.” 

Christina: I think that we contextualize language choices by what is technically better, what is faster, what is safer, what has the API, what is functional, what is object oriented? We make so many decisions about our technology based on these benchmarks that are just purely objective, or so they are in our own minds. Nothing's ever truly objective. But I think what actually gets overlooked a lot is that software is being written by people. These are people who are showing up 9 to 5, spending the majority of their waking hours doing this pursuit. And that matters because if people aren't enjoying what they're doing for the vast majority of their waking hours on Earth, that's not a great situation to be in. 

And so one of the clearest memories I have was that when we were talking about adopting Kotlin, in addition to Java at Pinterest, there was a lot of strife around that because it was big and it was scary and it was unknown. But we made the decision and I remember walking by a co-worker's desk who had been pretty vociferously against adopting Kotlin, and they stopped me and they said, “I just want to let you know, I have never enjoyed programming more than I enjoy it right now.” And so those aspects, they tend not to make it in the story because they're subjective, but they matter. Like I truly believe that they matter because you have hundreds of thousands of developers all over the world spending their lives doing this. And if you can make a difference in how much they enjoy doing it, if it can be less stressful, if it can feel like they're able to express themselves better, that's meaningful work. 

Neha: You were kind of mentioning that like one of the big reasons that Kotlin kind of became more of a first player was because of that support. It's making me think about how much the media affects our views and what we learn about it. And I actually saw quite a bit of chatter about this story on Hacker News and social [media]. So I'm curious, Mike, what have you learned from the GitHub community in response to this article? 

Mike: I mean, it's funny, you know, it goes back to that beginning thing where just Java has that image crisis in some ways. A lot of the complaints that people had, you know, against the idea of “Java still being champ” was that it was verbose and it couldn't run in these cloud native architectures and all these different things that it seems like it can do these days. And it isn't quite as verbose as it used to be and all these different issues. And then there's a lot of people that wonder if Java will go the way of Fortran and COBOL, sort of this, you know, just sort of ingrained in the “we can't get rid of it” infrastructure of the Internet and now we have to deal with it. You know, like at the early times of the pandemic, when there was a desperate need for COBOL programmers because there weren't enough to deal with the unemployment systems in New Jersey or something, you know? But I don't know that that's all that likely, at least not yet. It doesn't seem like Java is going anywhere. And actually things like Scala and Closures and Kotlin actually force Java to innovate. Java seems to be keeping up with the times rather than just sort of disappearing into the background and becoming a nuisance that we have to deal with forever. 

Martin: Fortran 77 for the win! That was definitely one of my early languages as well. You won't find that or COBOL on my resumé though, despite having been paid to write both. But there you go. So, you know, developers, we're absolutely binary. We hate shades of gray. And so, you know, it tends to be kind of one or the other. So, do we think Java is dead? 

Mike: You know, I'm going to let Christina answer that one, actually. 

Christina: Absolutely not. Absolutely not. Java is not in any stretch of the imagination, dead. Kotlin relies on Java, so there is no future for Kotlin without Java. And I think a lot of people pit them against each other. But I absolutely don't think that's true. The Java programming language has tremendous respect in the community, has tremendous stability, has tremendous support, and really has been proven across decades for use cases. I think it's really actually hitting its stride. It has all of these offshoot languages that are now able to work as these experimentation labs and Java as the kind of wiser, older mentor is able to sit back and say, “Oh, I like what you did there. Maybe, maybe I'll take that too.” So you just have so many ideas that are getting proved out in so many different aspects, and they're able to pull those back into the Java programming language as appropriate and on a predictable schedule. So I think Java is actually sitting in a very nice situation right now in terms of having these streams of information coming in about all of these experimental features and being able to pick and choose exactly what they want. 

Neha: All right. That’s The ReadME Project’s Mike Melanson, thank you so much. And before you go, give us a heads up of what's coming up next in The ReadME Project. 

Mike: So I don't know about y'all, but I'm a bit of a foul weather gamer. Like when the days get shorter and the weather gets colder, that's when my video game playing really picks up again. And it's definitely getting to be that time of year, not only for me, but also for GitHub and The ReadME Project. 

First, we have a feature story by the ReadME Project senior editor Klint Finley that explores how open source is democratizing game development. From game engines to game jams where developers work together to build open source games. Klint shows us how game development is more accessible than ever before. And speaking of game jams, GitHub’s Game Off is also coming up. Game Off is our very own game jam, where you build a game from scratch based on a theme over the month of November. Last year's theme, Moonshot, got nearly 500 contributions. And this year's theme, well, you'll find out about that on November 1st. If you head to gameoff.github.com, you can get all the details. Not to mention a handy list of free open source game engines and tutorials to get you started. 

Finally, Johanna Parker shares her story of how she went from launching games from the command line as a kid to working with and building virtual laboratories, to teaching game design and development at a university. Nowadays, she's not only teaching, but she's also exploring the ways that virtual reality can be so much more than just the future of gaming. These articles and more are available now on The ReadME Project at github.com/readme.

Martin: And it's time to #askRMP, the place in the show where we grab a listener question from you and get an expert to give us their advice. This month, Sonia from London asks: “What are some best practices for securing an open source project? For example, securing a project from supply chain attacks.” 

Security is obviously super important. So we went to Xavier René-Corail. He's the Senior Director of Security Research here at GitHub, and he had a bunch of things to keep in mind when it comes to securing your open source project. 

First, he says, to begin with the developer. 

Xavier: To protect your project from supply chain attacks, you should start with the developer. As they say, the problem is often between the chair and the keyboard. If you look at recent supply chain attacks, many of them started with social engineering and account takeover. To protect against that, the solution is to enable one or more forms of two factor authentication for the main contributors of your project and the administrators of your supply chain. 

Martin: Next, equip yourself with the right tools. 

Xavier: In order to find vulnerable pathogens in your code there are many solutions available on the market, free. But my advice, is to select a good solution for you is to, one, pay attention to the number of false positives. You don't want to waste your time on false alarms. And two, these tools must be integrated into your workflow because you don't want to be slowed down by using another tool or doing another step into your workflow. For example, if you're protected on GitHub, you can use GitHub code scanning with CodeQL. The checks are written by security experts from the community, and they are created to limit the number of false positives as much as possible. 

Martin: Third, make it easy to report security issues. 

Xavier: There is a big trend in the security community to help open source projects. To benefit from the help from the security community, you need to tell them how to contact you, how to work with you. You create what we call a security policy. It's just a plain security.md file where you tell them how to tell you about potential security vulnerabilities that they have found. And it can be as simple as, “Hey, send me a private email at this address, please.”

Martin: Fourth, make sure to think about the big picture. 

Xavier: Now, we’ve talked about you, about your code, but when we talk about supply chain attacks, of course, there is some sort of code from others that you are putting into your project—which are your dependencies. So the best practice for that problem is to keep up-to-date with these dependencies, right? There is public information of vulnerabilities found and fixed in open source projects. There is the standards-based National Vulnerability Databases to the GitHub Security Advisories. This information is public and available and there are a lot of tools. The Software Composition Analysis (SCA) tools that are reading this information and warn you about the presence of these vulnerabilities and your dependencies. You might know of GitHub’s SCA, Dependabot. Dependabot, will read this public information and inform you that, “Hey, you have had this dependency which is vulnerable. Please update to the fixed version of this dependency.” It can even directly open the pull request for you to do that. 

Martin: And lastly, he says, return the favor and pay it forwards. 

Xavier: You need also to warn people depending on you, using your or consuming your project, about vulnerabilities that you found. So whenever you find a vulnerability in your code and you fix it, then create (please) a security advisory and a CVE so that the SCA tools will pick it up and inform your dependents—your consumers—about the vulnerability in your project and tell them to update to a safer version. 

Martin: Do you have a burning question about open source development or GitHub? Share it on social using the hashtag #askRMP. That's a-s-k-r-m-p. Better yet, email your question as a voice memo to [email protected] and you could be on our next episode. 

Neha: So, Martin, I got the chance to talk to someone pretty fascinating and I'll give you a hint. 

Producer: We're rolling. [Thomas] I think this, we should keep this tone like this, not get too formal. 

Martin: That's Thomas Dohmke, CEO of GitHub. 

Neha: Bingo! I recently got to sit down with him face to face, partly in honor and in anticipation of the upcoming GitHub Universe—which will also take place IRL—to talk about his journey to the C-suite, what keeps him passionate, and where he sees the future going? 

Thomas: You know, you introduced me as the GitHub CEO, and I always introduce myself as, “I'm Thomas and I'm a developer.” That's how I identify. And, I—

Neha: Oh, I love that. 

Thomas: And I grew up in East Germany, in Berlin on the east side of the wall. And so for some time of my childhood, I didn't have any access to computers. I saw a computer in school that the geography lab, ironically, had and that's where we kind of started playing a little bit of [inaudible] and where we learned a little bit of basic and then the wall fell and I finally got a Commodore 64. I bought that actually in the grocery store, you know, like a Target kind of, the early 1990’s store. But yeah, I bought it on my allowance and hooked it up to TV. People might remember that you actually hooked up the old microcomputers to a TV with the antenna cable and, you know, started coding on this and then later got into a PC. 

Neha: So it sounded like you decided really early on that you wanted to build things. Do you have any moments, from when you were starting to tinker with technology, that the light bulb went on that said, “I really love building things?” 

Thomas: Yeah. I mean, you know, I started, you know, with a calculator, I guess, you know, I was a math nerd in school, and I had a calculator like one of those old school, very big calculators. And I collected the milk money in school early on and to always figure out if I have enough money to hand it to the janitor at the end of the month. And so I played a lot on that calculator. You know, all the stuff that kids do, like figuring out what all the buttons mean and then turning it upside down to read what the numbers say and stuff like that. 

And then I remember, you know, going to Berlin, to Alexanderplatz, with my parents and there's a bookstore there. And in the shopping window I saw the East German computers that were kind of sold and not sold at the time as in, people got to see them but the supply was so low that you couldn't actually buy one. So that was kind of like the moment in my childhood where I realized I want to do something. I want to create stuff for the computer and then build software. And obviously I saw the computer in school as well and started playing with this. And I had this moment that I remember when, you know, in the evening of the day, I went to my parents and said to them, “I want to become a software developer. That's kind of my profession.” And so from there on, the journey continued, then all of the sudden modems became available and you had a dial in connection through AOL and CompuServe and those kind of things. And all of a sudden a whole world opened up. I would meet people in Usenet and have conversations with them and could ask questions. 

I think, you know, thinking back to that time, the most frustrating thing was that if you got stuck somewhere, there was really no place to go, right? Like if you got stuck on a Saturday afternoon, you couldn't just go and buy another book or buy another magazine. And computer club was only on Wednesdays, you know. So it's not like as a 14 year old, I could just go somewhere and find the solution.

Neha: Yeah, I mean, I think that the minute you started saying that, what came to mind to me was LEGOs, right? Like you get the instruction manual as you start building things out. And I happen to know that you love LEGOs and that continues today. Is building what drew you into coding and open source? 

Thomas: Yeah, I think so. I mean, one thing is obviously creating stuff, you know. LEGOs are great because you can always take the set apart and build something else from the pieces, from the LEGO blocks. And I often think the best use of LEGO is just to have a very small type of blocks—whatever, two by four and a two by two and whatnot—and then just build something with that and create something that reflects your current state of mind. Or something that you want to resemble or just, you know, have your fantasy, you know, give your fantasy some room to explore new things. 

And I think, open source, in a way, the open source world that really started with the Internet is that we have all these LEGO blocks available to us as open source components. And it's so easy today to pull an open source component from GitHub, from npm, from NuGet, and build your app on top of this, right? Most of the projects you start today, you don't start from scratch. You start from figuring out what open source framework you want to use—like React, as an example, or Ruby on Rails—and then what libraries are already available for this. And you really just need to figure out, how can you assemble all these components together? And then what is your own creativity on top of that? And so I think those two things go really closely together. 

Neha: Yeah, I think so too. I think that, as you were saying, it dawned on me that building with LEGOs, for example, is like going back to the fundamentals, right? Like you have pieces, they can be reused, you can create amazing things with something so simple, right? And that is very similar to software, right? You can reuse the different parts. And I think there's almost like, evolution stages, where first you start with the basic instructions and what's at hand and you say, “Okay, cool with these pieces I can create this.” And then eventually I get to a point where like, “I've experienced so many pieces, I feel like I'm doing the same things over and over again. There's got to be an easier way. Maybe I can rebuild with what I have today.” Right?

Thomas: Yeah. I mean, it’s like software refactoring. Some of the best moments in LEGO is when you get to a stage where you have the courage to take your set apart and put all the pieces into a big stack, and then try to assemble something else from this. Which is a little bit like, you know, taking your software project that has been ordered, and refactoring it and hopefully you're not taking it all apart. 

Neha: So now we've been talking a little bit about software and we've been talking about, you know, your origins, but we should probably talk about this enormous or, you know, maybe natural leap right over to being the CEO of GitHub. And so I'm curious, right now, what comes to mind for your previous roles and how that informs how you approach your work as CEO?

Thomas: At GitHub, we put the developer first with everything we do. We know with every decision we make, with every feature we build, we always think about what does make the developer happy and really drives the developer happiness more than anything, right? 

We want people to really have joy when using GitHub and when using our features. I think, you know, my journey through different jobs was building systems at Mercedes that help you to prevent a collision. Or building HockeyApp which helped you test your apps. An then now in the last number of years working at GitHub, and acquiring companies like Semmle, where I understood, you know, why this helps us at GitHub to to explore new market insecurities. I think all of this helps me to understand where we are going as an industry and, ultimately, understand our customers and be able to talk to them at the same level. I often feel like, you know, many of our customers, naturally, are also building software, right? They are in the same boat as we are. They're also building software and they have all the same issues as we do as well. You know, as we all go through our journey, we're building up tech debt, we all have downtimes, we struggle sometimes with, you know, keeping the systems up for 24/7. And so, you know, being able to talk at that level and building a connection between me and the customers helps me to be CEO of GitHub.

Neha: I think that something that I guess shouldn't shock me that much but I was really impressed by, was hearing how much you still talk to customers today and how important that is in your day-to-day in order to make the right decisions. 

Thomas: Yeah, I mean, I love doing it. You know, it gives me a lot of energy to just talk with customers, whether that’s enterprise customers, whether that’s start-ups, or whether that's open source maintainers, you know, hearing from them and what's on their mind. Not only what's on their mind when using GitHub, of course, that's also super important for us and we want to hear feedback both positive and negative. Success stories are obviously a big part of getting us energy and motivation to build the next thing. 

Neha: And you kind of mentioned that you see a lot of the corollaries between what you've done in the past and in open source. And you still get to speak to open source developers and maintainers today as part of, like, staying in touch with our customers. What are your origins with open source? When did you first get into it and how have you seen it grow from that point? 

Thomas: You know,I don't know exactly the point in time, right? Because the ‘90s are kind of like a blur now. It's all so far away. But I remember moments, when I saw for the first time, Linux in computer magazines. I bought a computer magazine every month. And then I specifically remember the moment I bought my first SUSE Linux Distribution in a bookstore that was very close to a university. You know, we started at the university and everybody wanted to install Linux on their computers. You still had to go to a bookstore and buy, you know, CD-ROMs with Linux on it and then basically work from them. I think through all my time at university, I was using Linux as my main desktop, you know, sending emails [inaudible] and very, you know, terminal based stuff. 

And you know, at that point I got into this community to a certain degree and exploring projects on SourceForge back then and, you know, reading about how the engagement model is for the Linux kernel and reading Linux’ stories, and how he built Linux and those kinds of things. 

You mentioned earlier how I talk with customers and how we at GitHub in general engage with customers and put the developer first. And the thing with all these customers is that it's open source consumers and contributors. There's almost no enterprise out there that can live without open source anymore. No software project, or almost no software project, is not dependent in one way or another on open source—whether that runs on a server with Linux on it, whether that user uses an open source dependency, an open source compiler, you know, or an open source editor. In the lifespan of a piece of software, almost certainly open source is involved in one way or another. And so I think, you know, it's really important for us as GitHub and for many of our customers to be engaged with the open source community, as consumers of open source and as contributors or producers of open source. And often those two things go very closely together. Many, even big, large enterprise companies still are very interested in producing open source and being an active member of the open source community. 

Neha: Basically, what I'm hearing you say is that there are a lot of no matter what, you're going to be a passive consumer of open source, right? [Thomas: Yeah] And the question is whether or not you're ready to jump into the pool and become an active consumer and contributor to open source, right? And it seems like a lot of people are making that transition. 

Thomas: I think it's not even a question anymore. Like, I think, you know, whether you start a start up from scratch or you started a project at a big company, it's really no question that you wouldn't start with, you know, open source frameworks as a foundation. Like why—

Neha: Why not, it’s easier! 

Thomas: It is easier. You don't reinvent the wheel and you're basing your work off the work of thousands, if not millions of other developers that have already gone through the same thought processes, right? There's no reason to, you know, reinvent certain methods, you know? I guess the simple example is whether numbers or even, you know— 

Neha: I was thinking about math libraries, yeah. 

Thomas: Yeah, like math libraries. But like payment processing, webpage rendering… and sometimes people have new ideas of before React there were other JQueries and other frameworks that did the job in a similar fashion and that's fine right. Like we want to go through an evolution and to a certain degree, push us forward as a software developer community. But at the same time, I think when you start a new project and you have an idea of something to build, you want to build on the work of these open source developers and not start from complete scratch. 

Neha: And you're right that, because we have this limiter of time, tradeoffs and trying to make good decisions given what we have and the constraints that we have, is all the more paramount. If you're going to do that, you probably have some sort of vision for what the future holds or what direction that you want to head to. So, I'm curious, where do you think software development is headed and do you think the developer experience is changing? 

Thomas: Yeah. You know, Apple a number of years ago at their developers conference had a video. And one of the lines in the video is “There’s a thousand no's for every yes.” Like once you say one yes, you have to say a thousand times “no” to stay on track and stay focused. And I think in many ways, that's true. There's a thousand ideas in our heads and we can only achieve so much. I think, you know, for GitHub, one of the directions we're going to is AI, making AI part of the developer workflow. I believe that is a similar transition as we have gone through from assembler to higher programming languages or from building everything ourselves to the Internet and open source, right. That was a transition. We used to build much more stuff from scratch and now we are just pulling an open source component and leveraging the Internet. 

I think the next step of that is basically upleveling the way we're interacting with programming languages through AI. And with a tool like Copilot, you know, now helps developers to write code more efficiently and more productively. But ultimately I think it helps them to stay in the flow, stay in your editor, and not get distracted by going to the browser and trying to find the solution by giving you options of what you could type next. And if you haven't seen Copilot—I mean, I know you have seen, but if the listeners have not seen and the watchers have not seen Copilot—you type something in VS code on your editor and then it proposes whole methods, unit tests, and complex algorithms. And of course, you can just, you know, keep typing and not type the tab key and then it doesn't autocomplete and then it provides you a new suggestion. So it kind of like, you know, adapts to your style and it's super useful. 

We just recently published a blog post about research where we gave one group Copilot and another group didn't have Copilot, and they built an HTTP server and the group with Copilot finished the job in half the time or almost half the time. And actually more of them finished the job, than the group that didn't have Copilot even though we would say, you know, an HTTP server is something where you can just try to find the solution on the Internet. And so we see, you know, a lot of productivity gains. 

And I think those productivity gains, we're not doing that just for the sake of productivity like a factory worker. We're doing it because we realized that developers are only creative for a certain part of the day. For me, it's mostly in the morning, you know, after the first cup of coffee. That's kind of like the best couple of hours of the day. And then from there, it usually goes downhill and sometimes it comes back in the night, right? Like a lot of developers, I love working at nighttime and coding something on a Sunday night or something. Copilot helps you then to finish that job and unlock your creativity. 

Neha: And, you know, you were mentioning a bunch of different pieces that are like a core part of developer happiness. What do you think are some of those core pieces if you were to speak about them a little bit more abstractly? What is developer happiness and what parts are the ones that are often overlooked? 

Thomas: I think a big part is, as I already mentioned, a flow state is just being able to be creative, being able to build the things you want to build, and achieve the task that has been assigned to you in a creative manner. And not feel like a factory worker where you have to assemble the same thing over and over again. Being able to explore that creativity during the time of the day when you actually are creative and not having your morning spent in meetings when you actually want to build something—that you are basing your energy on conversations or discussions or arguments. I think an under-appreciated aspect of that is latency and how long you have to wait for things. Whether it's the user interface, or the build process or your CI/CD process—your deployment—if all of these things take long, that's really frustrating. Nobody likes waiting. We're living in a world where everything needs to be almost instant. And so the same is true for the developer experience. If I need to wait 7 minutes for my build process, I likely use those 7 minutes to do something else. And then often that takes more than 7 minutes. You get distracted. 

Neha: And then you interrupt the flow. 

Thomas: Interrupt the flow, and also, you come back. This is not only about the time you spend away from the computer where you could have created something. It's also that when you come back, you need to get back into that state of creative work, right? Like an artist that works on a canvas, doesn't have that issue. They don't have to wait for the build process. But developers will always wait to a certain degree, right? Like there's no zero build time—it’s hopefully close to zero, an optimization problem, if you will. But it needs to be really low and everything needs to be fast in a developer’s lives. GitHub needs to be fast, the compiler needs to be fast. All the processes within the company need to be fast, even code review. I mean, you know the feeling when you open a pull request and then you're waiting for a coworker to review your pull request. And oftentimes that works through social engineering and you're pinging somebody on slack and saying, “hey, can you review my pull request?” But if you have to wait for 24 hours or 48 hours, it gets frustrating. And you are like, “I want to ship this thing away.” 

Neha: I’ve already done all the work, it’s just the wrapping, right? 

Thomas: And so latency, I think is one of those under-appreciated aspects of developer happiness. 

Neha: Processes, figuring out the right tools to kind of improve that latency. 

Thomas: I mean, the internal processes, you know, decision making processes, control of your processes and obviously user experiences within the UI of your developer tooling need to get faster. They're often very slow in many companies. And you know, we are an almost 15 year old company at GitHub. First Commit was on October 19, 2007 you know so our code base is large, our number of unit tests is large. There's things like flaky tests where tests break every now and then. All those things we need to work on and other companies have the same challenges. And so it's good to talk with them about that. 

Neha: Well, that's a great transition because you're talking about how GitHub, you know, the first commit was 15 years ago. And we have a new big milestone coming up, right? GitHub Universe is right around the corner. It's on November 9th and 10th [2022]. And this is the first in-person Universe in a really long time because of the pandemic. What are you excited about? 

Thomas: For me? You know, the best thing about any conference, but of course, especially GitHub Universe is to meet other developers and engage with them. The sessions are obviously great and I'm really excited about our keynote and we're working on the talk track and the story for that. But you know, the best thing is really to talk with other developers to meet with them, to engage with them, to learn from them what's on their mind, to see their reaction to our announcements, and having a good time together. Having the open source community come together, having partners come, and really share with us and what's on their mind. 

Martin: That's it for this episode of The ReadME Podcast. Thanks so much to this month's guests, Mike Melanson, Christina Lee, Xavier René-Corail and of course, Thomas Dohmke. And thanks to you for listening. Join us each month for a new episode. And if you're a fan of the show, you can find more episodes wherever you get your podcasts. Make sure to subscribe, rate, and review or drop us a note at [email protected]. You can also learn more about all that we do at GitHub by going to github.com/readme. 

CREDITS GitHub’s The ReadME Podcast is hosted by Neha Batra and Martin Woodward. Stories for this episode were reported by senior editors Klint Finley and Mike Melanson. Audio Production and editing by Reasonable Volume. Original theme music composed by Zander Singh. Executive producers for The ReadME Project and the ReadME Podcast are Robb Mapp, Melissa Biser, and Virginia Bryant. Our staff includes Stephanie Morehead, Kevin Sundstrom and Grace Beattie. Please visit github.com/readme for more community driven articles and stories. Join us again next month and let's build from here. 

Thomas: Thank you so much for having me. And we can go to my office now and build some LEGO.