Talk: Survival of the most open - Microsoft's open source journey by Sasha Rosenbaum, GitHub

Lauri (00:04): Welcome to the [DevOps Persona 00:00:06]. My name is Lauri and I am the Chief Marketing Officer of Eficode. Not too long ago, we held a hugely popular two-day DevOps 2020 event. In the event, we had awesome speakers from around the world, telling stories about DevOps tools and culture for over 1000 people online. Since then, we have made these recordings available at the Eficode website and due to the popularity of these speeches we have now made them also available in our podcast. You can find the links to the video recording and to the materials referred in the speech in the show notes. We're also keen to feature topics that you find interesting in the area of DevOps. Do let us hear about you in our Twitter, Facebook or LinkedIn pages.

Lauri (00:46): Open source is an integral part of every software application. GitHub has become the largest developer community on the planet. And Microsoft is one of the largest contributors to open source. These are good words to tune into our next talk. Our speaker is Sasha Rosenbaum. She's a product manager at GitHub. Let's hear her out.

Sasha (01:11): I'm Sasha Rosenbaum. And today I'm going to be talking about the Microsoft Open Source journey. To introduce myself, I did a few years in Dev, a few years in Ops or DevOps, and then I was in cloud architecture. I used to work for Microsoft. Now I work for GitHub. So you will see me say we interchangeably about Microsoft and GitHub and that's just because of my background.

Sasha (01:34): So right now I work for GitHub as a product manager. So let's talk a little bit about the history of Microsoft before the fancy logos. And even before that, when we were all doing ASCII characters. So it all started with Bill Gates and Paul Allen. And back then they wrote software for Altair, one of the first commercially available mini computers. And back then they did it with hobbyists. And these hobbyists just basically copied software over from one another. And Bill Gates really thought that basically these hobbyists were stealing software and that software engineers should ideally be paid.

Sasha (02:14): So basically he did not believe in GPL license and Microsoft was not fond of open source. Then his successor took it kind of even farther with some statements like this one. But then fast forward to today, we see a very different Microsoft and Satya Nadella is standing in front of a slide that says Microsoft loves Linux. And how did we arrive at such a different turn of events? Also, this is one of the quotes from Satya is, "Judge us by the actions we have taken recent past, our actions today and in the future and not by what we might've done 20 years ago."

Sasha (02:56): So if we look at these events in progression, so back from where we said, Linux was a cancer to saying Microsoft loves Linux and creating the first Microsoft Open Source organization on GitHub in 2014, to joining the Linux Foundation. Who would ever think that Microsoft would join the Linux Foundation? And then basically to 2019, where we had over 25,000 Microsoft engineers contributing to Open Source and over 9,000 Microsoft Open Source projects, which is kind of an insane progression over here.

Sasha (03:34): So let's talk a little bit about how we went on this journey and hopefully this will be helpful to you in your organization as well, how you could adopt some of these lessons. The first thing that companies usually do when they start on their journey is learning to consume open source. So first the question for you, unfortunately, I can't see you, but I can kind of predict the answers. Do you use open source? So if I ask it in a big room, most hands go up and then if I ask it in enterprise and sometimes in regulated industries and stuff like that, people say, "Oh, no, we don't use open source." But if we look at the reports from software composition, we see that 99% of all organizations use open source and 90% of all application code that you ship actually is open source. So you only write about 10% of your business logic and the rest of it is open source.

Sasha (04:30): And that kind of introduces us to a new world in which we have to make sure that we also consume open source responsibly. We can no longer close our eyes and say, "Hey, we're just not using open source. This is not happening." Instead, we need to adapt. We have in GitHub now some products that are specifically tailored to use the job open source because we realized that there's some common problems. So one of the most common problems is this software package vulnerability. So these vulnerabilities get shipped and then open source maintainers may or may not have lots of time to fix the issues.

Sasha (05:08): So we acquired Dependabot last year and rolled it into GitHub. It highlights your vulnerabilities coming through different packages that you consume. And it also highlights the security fixes, and it will even create an automatic pull request for you if you have a vulnerability that it can fix such as by upgrading a version of a package. So this takes care of a lot of things that would otherwise be manual and consume a lot of time for people. The other thing is GitHub also acquired SAML. So it's a pattern recognition analysis company basically to once a vulnerability is discovered, you can search your entire code base and you can identify if some of your code looks like it might have the same allowability. So this is tremendously helpful in different projects.

Sasha (05:56): And then the other thing that is, again, the common issue is how do you report a vulnerability to an open source project without zero-danging everybody else into that vulnerability? So there's a huge problem because you don't want to announce it to the public and have bad actors take advantage of that. So GitHub is now a CNA, a CVE numbering authority. So you can report vulnerabilities directly to us. And there's also a way that we can communicate with maintainers now without announcing that publicly to everybody else. So these are kinds of steps that we are taking to make open source projects more secure for everyone. And all of these stores are available for free, for open source projects. And they're also available in GitHub enterprise.

Sasha (06:46): I have an important insight for you. It pertains to open source and also life. So my advice is to not be a jerk when you're consuming open source. So open source maintainers really don't owe you anything. They're not signing support contracts with you and you can't go on their site and do their GitHub issues and start complaining about them, not shipping fast enough and stuff like that. If you want to be a good citizen, you could instead consider how do you contribute and help them. This is also one of the reasons why we introduced GitHub Sponsors. So basically you can now help fund the open source maintainers, and you can basically help on their projects. So if you have favorite projects or even... and then price level, if you're consuming things that are highly relevant to you, you can now sort of pay for that and help the open source maintainers have money to live their life while they're contributing to these open source projects.

Sasha (07:44): The step two in a progression is understanding the need and the business value of contributing your open source. So if you're progressing to that, it's important to think through the business case and why you may want to contribute. So I'm going to give you an example of something that Microsoft was faced with a few years ago. So we had a version control system called TFVC. It's a centralized version control. This has been around since '70s, so five decades and it worked pretty well for everybody. In the 2012, they were considered lead in the Gartner Magic Quadrant. But then we can see that in 2011/2012, distributed version control system started gaining traction and it was good and mercurial to add the helm of this all. And back in the day, it was hard to tell which one's going to win. They were both pretty popular.

Sasha (08:41): So basically the options Microsoft had was first, we're going to ignore the distributed version control and say, "Hey, we're just going to continue with a centralized version control." Then we could create our own distributed version control system. So distributed version control systems enables certain workflows, such as pull requests, which are really hard in the centralized version control. And this makes them ideal for open source maintainers. And so that was the reason they rose in popularity so much. So then the other choices we had was to back mercurial, which actually ran better on Windows. And the last probably was to back Git, which was popular in the Linux ecosystem.

Sasha (09:25): This is an example of something called The Innovator's Dilemma, right? It's a book by Clayton Christensen who says, "Managers making good decisions sometimes is the very reason that you have problems," right? Because you listen to your customers, your customers will tell you that they're perfectly happy with your product and they just need these small incremental improvements. And then you see the new technology and you go like, "Barely anybody uses it. I don't need to invest in this." So to prevent disruptive technologies from disrupting your company, you need to pay more attention to things such as the rise and solve different customer problems. So basically what Microsoft chose is to use Git and Git for Windows. And so that also may get better on Windows. And this was a sort of a historic mind shift from trying to build roller on product here and compete with everybody and stuff like that.

Sasha (10:18): And the other advice would be don't fork. Once you fork a project, you basically are developing inside your own firewall and it becomes harder and harder for you to get the updates from the main project. So the suggestion is you should definitely contribute your stuff, merge it back to upstream so you don't become a different version of a software that can't get security updates and things like that.

Sasha (10:46): So there's boats-full cases for pitching the open sourcing some part of software. So collaboration, distribution, and compatibility would be the three main. So for instance, with visual studio code, when Microsoft open sourced it, the biggest thing was distribution. So we wanted to make the editor run on every possible version of systems. And we wanted to make sure that we allow people to build in this compatibility, but now actually it's when they most highly contributed to projects in open source. So you eventually get the benefits of people if it takes off, people contributing engineering effort to you as well.

Sasha (11:24): Dubious business goals, so don't do it for public relations. It's a very short-lived public relations boost. Don't do it for recruitment. Yes, it may make it easier to recruit people, but it's probably not a good reason to open source something. Definitely don't do it. If you say, "I don't have time to maintain this project, so I'm going to open source it," that's not how it works because just managing PRs is a full-time job. And so you trying to open source a project for the reasons that you think that other people are going to maintain it is definitely not going to work.

Sasha (11:57): You need to convince your stakeholders. So your coworkers, your management, your lawyers, and your senior leadership. So for a lot of times, the argument that really works is that if you can prove that it will make you have a benefit financially, then you can convince people. And a lot of times what works is, if you convince your salespeople that open sourcing a project will be beneficial for them, money-wise, then they could become your allies and help you convince everybody else.

Sasha (12:29): Then you have to convince your customers, which may or may not be easy. In the case of Microsoft, it actually was one of the hardest things was to convince our customers that open source was safe and they could consume it legally and stuff like that. Keep it legal in the sense that also you consume open source licenses. So if you consume open source licenses and then you roll it out as open source, you need to make sure that you're keeping the license legal. In our case, we have a nice legal team and we gave them some T-shirts. So they, I know are very happy to work with us on open sourcing projects.

Sasha (13:01): The step five is to be the community. So Microsoft Edge adopted Chromium engine, if you may know, and this is again an example of change in mentality. So in 2015, Microsoft released Edge as a separate engine, right? So diverting from Internet Explorer and from Chromium, and basically just introduced another engine into the front end ecosystem, which is hard because the front end developers already have to test on so many browsers, so many different environments. But now we're seeing a different mind shift at Microsoft where we are actually going to contribute to Chromium, which is again, the most popular browser based on it is Chrome. And we still see this as a benefit to us and the entire ecosystem, if we choose this, because doing open source is actually not a zero sum game. In the end of it, everybody wins.

Sasha (13:58): So when we open sourced .NET, we started in small steps. So first we did source opens to just publishing source. Then we allowed people to actually contribute. And then we sort of started being true to open source or actually involving our community and allowing them to be part of the planning and part of the team entirely. Basically, you also need to remember to have fun with it. So just as an example, we ship little mugs with the Commit ID, to people who made major contributions. And then we actually buried one of these mugs in the mail from Scott Guthrie, doing a video for a conference. So just, basically these things matter to people. Having thank you for the contribution is important. And so you need to remember to also have fun with your community.

Sasha (14:44): It's important to have some success. So this is .NET contributions. You can see grew tremendously in 2017 and even more so in 2019 to the point where now we're basically benefiting from everybody's contribution. So it's not just that we are contributing to everybody and allowing people to have open source project, but also getting the contribution back. Git, currently it's obvious it was the right decision. And maybe Microsoft also contributed to the fact that it took off the way it did. Sometimes you get unexpected benefits. Someone contributed here to .NET as something that sped it up by like a microsecond. And that was amazing. And also this was outside of the skills of the very smart team that was working on SP .NET core. So you get these kind of contributions from smart people all around the world that you would not otherwise be able to tap into.

Sasha (15:41): The last thing that I want to mention is open source. This is an organizational chart for different organizations. And this is what Microsoft used to look like, and people who used to work with myself 10 years ago, chuckle at this because it's so accurate. And basically this was because people were incentivized to compete with one another. So one of the best ways to get promoted was to build a test framework or something like that and ship it. So every little organization built their own test framework because they had no incentive to collaborate with one another. So now we can change the incentives to not only say what you have accomplished as a person at Microsoft, but also how did you build on the work of others and how did you allow others to build on your work?

Sasha (16:28): Open source mentality was a big part of this change in terms of people collaborating between different orgs and contributing to one another. And so we just went through entire transition really quickly, but these are the basic steps. We can benefit from tremendous selling from all around the world when we open source our projects and also give back to that community and allow them to leverage these projects in the different software that they're billing.

Sasha (16:57): I'm on Twitter as DivineOps. This is also my GitHub handle and this slice of talks can be found on Speaking at sasharosenbaum.com. And thank you very much.

Lauri (17:07): Such an interesting story, wasn't it? As a matter of fact, I have myself done a bit of development for my own fun, but also during my studies, all of my source code is available publicly under one of the open source licenses out there. And it feels so natural to work that way. Let me introduce you to our next speaker. He is Jordi Mon from GitLab. Jordi is a Senior Product Manager and he talks about multi-cloud maturity model. I'll see you again next time. Until then, remember to collaborate and give back to community.