Martin Woodward and Sasha Rosenbaum

Martin Woodward: Hi, everybody. We're going to talk about Survival of the Openest: Microsoft's Journey to Open Source. Hi, I'm Martin Woodward. You can get me on GitHub and Twitter @martinwoodward.

Sasha Rosenbaum: And I'm Sasha Rosenbaum, and you can find me on GitHub and on Twitter by the same name, DivineOps. So let's get started talking a little bit about the Microsoft history.

This was way before we had the fancy, colorful logos. This was more like the days when we didn't have any fancy colors at all. And back then, Microsoft actually had opinions on open source, and Bill Gates actually had opinions on the GPL license, which was that he did not agree with it. And then Steve Ballmer took it even farther by saying Linux is a cancer, and we fought Linux at every step of the way.

Thankfully, times have changed. Brad Smith recently said that Microsoft was on the wrong side of history. He was our lawyer during a lot of these times. He also said if you live long enough, then you can change, and you can make good on the things you were doing.

Martin Woodward: So, in the color world now, we have Satya Nadella, our CEO, who has a very different stance on open source, and it's great to see the company has really moved along. And what we want to do today is kind of show you some of this journey that we've been on.

The past five years, the last five years, in fact, that I worked at Microsoft before moving over to GitHub, were a great change as we went through that time. I was very lucky enough to create Microsoft's GitHub account back in 2014. So that's when we had project number one on GitHub. And by 2016, we were one of the largest contributors to open source on GitHub. And then in 2019, when I left Microsoft, there were 25,000 employees inside of GitHub contributing to open source and over 8,500 projects. So that's a massive change in a short period of time.

So what we wanted to do was just kind of take you through our journey in Microsoft and the steps that we went along, but hopefully in ways that you can kind of repeat some of these lessons and hopefully apply them to your organization if you want to get involved in open source.

Sasha Rosenbaum

So let's go to step one, which is consume responsibly. For every organization, when they start considering using open source, before contributing, they actually start consuming open source. Right? And I have an important life lesson related to this, and that lesson is, don't be a jerk.

Now, that's a good lesson for life, and it's also a good lesson for open source because these open source maintainers actually don't owe you anything. Many of them are working on the projects in their spare time and for free. So the last thing you should do is send them an angry email demanding support for your products. Instead, you should sponsor them. Now at GitHub, we've introduced GitHub Sponsors, which allows you to sponsor the projects that you're most passionate about and help these open source maintainers have more time dedicated to the projects they love.

So I want to ask you a question, even though I cannot see you. I wish I could, but do you use open source in your organization? So I can't see if you raised your hand, but I know that sometimes when I talk to large companies, they tell me that they do not use open source.

But that's actually not true. From software composition analysis, we know that 99% of all organizations make extensive use of open source, and then 90% of all application development leverages open source software. And actually, a very tiny percentage of your code is actually new code.

Now, there is an important message related to this, and that is that you must worry about the security of the open source packages that you are consuming. Sometimes these packages can be buried in your dependency tree, and you still must always make sure that you are consuming responsibly. And in fact, some of the biggest hacks we know in the last couple of years were done through cracking the software, through breaching the software, through the supply chain vulnerability. We also know that breaches are extremely expensive. So if you actually get all the way to getting breached, it could cost you millions of dollars to remediate the breach.

So the goal here is for us to shift security left and also to educate developers and make it easy for developers to contribute to security because there's a lot more developers than security researchers out there in the world. So with that in mind, at GitHub, we wanted to make it easier for you to secure your software in an automated fashion and consume open source responsibly.

So we have introduced Dependabot that is helping you to secure your software supply chain by alerting you on vulnerabilities and even producing automated PRs on your software supply chain vulnerabilities. And then we introduced code scanning with CodeQL, which is a static code analysis tool that can help you identify software security vulnerabilities in new code. And now you can run in the cloud with GitHub Actions. And we also introduced secret scanning for private repositories. So now you can identify secrets that were accidentally checked into your repository. So with that and with open source community in mind, we are making as many steps as we can to help you consume open source responsibly.

Martin Woodward

Next, we need to understand the business need to contribute. The first reason is around not forking. If you're consuming open source, quite often you'll take down an open source dependency, and maybe you'll find a bug fix or a security issue, and you fix it in a local version of that code because you need that fix immediately to run. If you don't take that fix and push it upstream, send it back to the upstream project, then it gets increasingly hard for you to take changes from that upstream project, bring them back down to your local version, and then merge them in with the changes you've made.

So that means if you don't push upstream, you miss out on gaining all that functionality that's been added to the new version of the open source project, and all the security vulnerabilities and security patches that other people have applied. Therefore, by contributing, you're able to consume the latest version later on and stay up to date more easily. So that's one of the main business justifications for contributing to begin with.

Next, we have the fact that open source communities value the code over everything else. If you're taking an open source dependency as a strategic dependency, you're basing a whole business around it, you want to have some kind of influence into the future direction of that open source project, so you can make sure it goes in the way that you want it to go. You make sure that different things work in a way that works really well in your system, and that it doesn't suddenly stop working for you because you've bet the business on this open source dependency.

And if we take a look at the contribution funnel, we can see as people consume open source, the vast majority of people can just consume open source, say, 99% of people. So you need to maximize the funnel of people coming to your open source project, maximize the number of people consuming, because you know only a tiny percentage of those will actually give you some time, will contribute time, whether that's logging a bug, raising an issue, creating documentation, telling their friend about your amazing open source dependency. Getting somebody to contribute time is a tiny percentage, and you want to pull people through that way in the funnel by making it welcoming, making it easy for people to contribute time.

Next thing you want to do is make it easy for people to contribute code. So give them contribution guidelines, have a CONTRIBUTING.md file that tells people how to contribute to you. Because of the people contributing time, a small percentage of people will actually give you code, so you want to maximize that number of people. They give you bug fixes, new features maybe, with any luck, or some tests. You want to be very welcoming to that code when it comes in, because only a tiny percentage of people who contribute code will actually stick around and help you maintain.

When you're a maintainer of the open source project, that's when you get to influence the product direction. That's when you are part of the core group of people that help decide the future direction of this project. And if you're taking a critical dependency on some open source, you might want to have some of your people be maintainers of that open source project. In Microsoft, we actually have occasionally gone out and hired people from the open source community who are the maintainers of particular projects we take critical dependencies on and bring them into the company, so that we can have them as part of the company and fund their contribution into that project.

If I take an example where we did that, Team Foundation Server, back in 2012, was leading the Gartner Magic Quadrant around ALM. It was the leading centralized version control tool, TFVC, and it was very popular, and we had lots of customers asking for new features within this distributed, sorry, centralized version control tool.

But actually, there was a new type of version control coming along in the market, and that was distributed version control. Now, at the time, I was reading a book called The Innovator's Dilemma by Clayton Christensen, and one thing that particularly stood out from that book was around managers blindly following the maxim that good managers should keep close to their customers, and if they do, sometimes that can be fatal.

And this is exactly what was happening in 2012 as we were seeing distributed version control coming along. If we were just listening to our customers, only wanting to build new and better features for centralized version control, then we could have missed this new trend.

Now, back in 2012, we had several options when it came to distributed version control. We could just ignore the threat. We could ignore Git and Mercurial, the leading distributed version control tools. We could create our own distributed version control. Believe me, we thought about it. I had to have lots of passionate discussions with people about why we shouldn't do that.

We could go and we could adopt Mercurial. We could back Mercurial as the distributed version control tool. In 2012, it wasn't clear which was going to win the distributed version control race, and if you look, Mercurial ran better on Windows and arguably is more user-friendly than Git. So that kind of made a lot of sense as to why Mercurial might make sense.

But then, with Git, GitHub existed, which had the pull request and a lot-- We were seeing a big network effect in open source around GitHub. But also Git was heavily used by the Linux community. Again, it was created for the Linux community by Linus Torvalds and some of the team. So we could go with Mercurial if we were going to go open source, which worked better on Windows, or we could go with Git, which had more people outside of our ecosystem using it.

And in fact, what we decided to do was, if the reason for not backing Git was because it doesn't work well on Windows, well, let's get the Windows team to use Git. Let's bring Git into Microsoft, make it a core part of our product offerings, have internal teams using it, and get the team that builds Windows to go use the version control tool written by Linus Torvalds, the creator of Linux, which is just crazy that that would even happen.

Have the team move over, and then you can guarantee by starting to contribute to Git, we get Git to work better on Windows, and we get to influence the future direction of the project, so that all of the customers on Windows who are using Git get a better experience. And that's exactly what we decided to do.

Now, when we contribute things to open source, quite often I get people saying, "Will we open source XYZ? Will we open source Microsoft Bob?" is my example here. And the answer to that is no. So when do we decide to open source things? What's our strategy around open source contribution?

Broadly, it fits into three categories: collaboration, distribution, and compatibility. So around collaboration, .NET is a great example there. By open sourcing .NET, we're able to get feedback on the very latest commits into master, into the root branch for .NET. So we're able to contribute there, get feedback straight back. Whereas before, if we contributed to .NET, we'd have had to wait until we got a release in the hands of our community and then wait even further to get some decent adoption before we can get feedback. So by releasing something as open source, it allows us to be much more agile.

Around distribution, in the old days, believe it or not, Microsoft used to ship software development kits, SDKs, using proprietary license terms. Whereas by making them available under a very permissive MIT open source license, that SDK, which essentially just gives you access to a Microsoft service or something in the back end, it can be included in any commercial application, but it can also be included in any open source application, including GPL and AGPL license code. So by putting the SDK available under a permissive open source license, it maximizes the distribution base. So again, that is the business reason for releasing that as open source.

Finally, around compatibility, that's where things like Git kick in, where we want to be contributing to open source so that we can work with an existing open source market and then collaborate with that entire market and provide software and services to them. So Git is one example. Linux, Azure is a big business that hosts Linux, more Linux than Windows. We needed to make sure it worked great there. Kubernetes, again, another growth market. And then finally, Chromium, which we'll talk more about later. So that's how the open source contribution fits into Microsoft's strategy.

Sasha Rosenbaum

Now, we want to also mention some of the dubious goals to open source a product, because not all the potential goals are equally worthy of making the effort to open source something. So the first dubious goal is public relations or goodwill. Now, it is true that you will get some PR blasts out of open sourcing a project, and you might get some goodwill from the community, but it's short-lived, and usually it is not worth making the effort to making something open source.

Then the other argument that we often hear is we'll get free work. Now we don't have to maintain this project anymore. We'll get free work from the community, and they will maintain the product for us. That's not really how it works. If you remember that contribution funnel, most people just consume your open source software, and then only small percentage of people makes it all the way to maintainers, and for them to make it all the way to maintainers, you need to actually invest in them and support them as a community. So if you want to get free work, you will have to make an engineering effort on your side to make it possible.

And then the third reason is recruitment. Now, sometimes if your project becomes really popular and a lot of people are using it, you could get to recruit people who already have experience with the project. However, most projects do not get that popular, and again, most people out there do not contribute to open source projects. So that means that recruitment is really not that great of a reason to open source something.

Now, with that, we are kind of wrapping up step two, which is understanding the business needs to contribute to open source. Now we're moving to step three, which is, in your organization, how do you convince your stakeholders that you need to actually open source something?

So first of all, you need to start with your immediate team, right? So you might have developers and operations professionals and such on your team, and these people might be kind of a little bit protective of their code or maybe a little bit worried that everybody's going to see their technical debt, and a lot of times you kind of hear the argument of, "Oh, this code is not pretty enough. We need to first fix all the issues." Now, all companies out there actually have technical debt, and maybe by open sourcing it, you're actually going to make a drive for good.

Now, since we already went through the business reasons to open source a product, and if you have actually identified the business goal for open sourcing, then you can actually start convincing stakeholders inside of your organization that not only will it be good for you in other ways, but it will also bring you some money influx if you open source the project. So you actually will be able to make more money by contributing to the community.

So once you've followed the money trail and convinced your team and your management, you can also work on convincing your senior leadership that open sourcing a project is going to be good for you. Now, in Microsoft's case, we got lucky, and we actually had leadership that already understood the power of open source and was ready to get fully behind it.

Martin Woodward

Fantastic. Now, next thing we need to make sure we do is to keep everything nice and legal. With open source, if you want people to respect your software license terms, then you need to respect their licenses. And lots of open source licenses come with obligations, even though you're not paying for the software. It may be ones around attribution, or it might also be certain obligations that come in when you distribute the code. Now, there are different types and different categories of open source licenses, so you should familiarize yourself with those.

Ignorance is no excuse. Not knowing about different licenses isn't an excuse for non-compliance. There's a legitimate business risk there. So educate yourself around the different types of open source licenses and the obligations that they have.

The next thing you need to do is talk to your legal team. Educate them, oftentimes around IP law and open source licenses and sometimes software, to be honest. Now, a lot of times they have lots of experience with contract law and not so much around the IP law. So help educate them, but also let them educate you.

My epiphany around lawyers was when I realized that lawyers are like developers, but they code in English, in language, rather than in a software language. So let them educate you, let them explain to you the risks, and listen to them, but also help them learn what you're trying to do, what the business needs are, and what licenses you're looking at using.

To understand the licenses, you need to make sure you understand your dependencies. You might have some licenses that are MIT license, some that have come in through a third party. But you might also have some projects which take dependencies on projects with a different license. Maybe Apache, AGPL, or Apache 2, or GPL, something like that. So you need to understand your dependency chain. You can get some software tools that can help with that. GitHub has built-in tooling to help you analyze your dependencies, or you can buy third-party tools that allow you to analyze your software dependencies. But that's key to understanding what your license obligations are, is to know what you're dependent on.

And then finally, don't be afraid of open source. Yes, you do have to learn some things to get used to being able to consume open source responsibly, but our open source contributors want you to use their software. That's why they're making this source code available. So don't be afraid to work with them. Don't be afraid to read the license terms and check with them and make sure that everything's good. But, yeah, just give it a try and work with the legal team.

I was very lucky inside Microsoft because my legal team were very, very cool. They were very developer friendly. This was long before they did the GitHub acquisition. So they love GitHub. They knew how to use it. They would send me pull requests to update licenses, that sort of thing. So I was very lucky there. You're possibly not as lucky in your team, but if you help educate them along IP law, it's definitely something that they're going to be interested in investigating and able to bring in some third party.

Sasha Rosenbaum

Yeah, and that picture actually testifies to another one of my favorite tricks of getting stakeholders on board. I actually like to ship people swag, so then they get all happy, and they're much more likely to help me with stuff.

So let's move on to step five. Step five is be the community. So this is really, really important. It's important to treat your community the same way you treat your internal developers. So you can't always make the arguments of us versus them. And it might not be that easy because sometimes you have to make considerations about the contributions of external teams and your own contributions to external software.

So in 2019, we actually announced that Microsoft Edge was adopting Chromium, which was a big change of direction because only in 2015, we announced that Microsoft Edge was going to be developed on a different engine from Chromium and different engine from Internet Explorer. And I was involved in web development at the time, and I still remember how frustrated I was because that meant that our testing matrix would get even bigger because we had to worry suddenly about another engine.

So this decision represents that in just five years, Microsoft had changed their mind on how they perceive software and were able to see that they are going to be benefiting from getting contributions from external community and also contributing to the external community, because building software together makes all of us better off together. Because actually, open source is not a zero-sum game, and we get benefits from working on the software together with other companies.

Martin Woodward

Now back with .NET. When I was working on the .NET team, we learned sort of how to work with the community. When we began, we actually just published our source code and made it available to read. We then went and made our design notes available and got some early feedback on that. Remember, one of the reasons for open sourcing .NET was to be a lot more agile. So this allowed us to get some good feedback on those early design notes.

The next stage was to publish our source code under an open source license, but we would have teams working on TFS in the back end, and then they would publish out as open source. So that worked okay, but it wasn't great for getting contribution. It just was available under an open source license and really wasn't getting the full business benefit.

Where we saw the big business benefits come was when we took our developers and had everybody move to GitHub to work in the open on a project in true open source. So this had the team following the same workflows that we want everybody else in the community to follow, submitting a pull request, having a pull request reviewed, and then merging it into the code base. Once we adopted a true community workflow for everybody in the team, we saw the numbers of contributions from outside of Microsoft massively jump within the space of the year. It went up to 60% of people contributing to .NET were coming from outside of Microsoft, and that was a huge change.

One of the things we learned when we did that was that we needed to get better at improving our documentation. And then finally, we needed to be prepared to share ownership, as we do with the .NET Foundation, to allow people from different organizations to have a say in the future of a .NET platform. And by doing that, the future of a .NET platform is actually more vibrant than it ever has been because there are more people contributing time, contributing resources, and can bet the company on the future of .NET because they're able to share in the ownership of it.

Sasha Rosenbaum

We also needed to be part of the community, so we would do things like we would ship swag to maintainers to help them feel like they're part of the intangibles. They are a part of this community. So we made these mugs that we distributed to them with the commit IDs on them. And then we also included pictures of those mugs, and we included the mugs actually in little Easter eggs that were inside of videos that our execs did at keynotes and conferences and that sort of thing.

Yeah. So a second book reference for this presentation comes from People Powered by Jono Bacon, which is a great book about building communities. And one of the things that he mentions in the book is that people initially come to communities for tangible value. So maybe they want to gain work experience or connections or maybe open free software licenses and stuff like that. But they stay for the intangibles. They stay for the sense of belonging.

And that's where it's really important to reward your community and make them feel like they're part of your team, and they can influence the direction of your products and stuff like that.

Now, we finished with the step five, be the community, and let's move on to a very important step, which is step six, having some success. Now, this is really important because after you sold your stakeholders on one project or one product that you want to open source, you must show them something that they can get behind for the next project.

Now, for Microsoft, we started in 2014 with barely any open source software projects, and now we have some of the most popular open source projects in the world. Among them is Microsoft Visual Studio Code, and also Azure Docs, which are fully open source, and you can go contribute to the docs right now, which is amazing to me, and has also greatly improved our documentation. And again, as we mentioned, documentation is hugely important.

So if we look at .NET, for instance, from 2015, there were some contributions from people outside of Microsoft. But then if we fast-forward to 2020, we can see that there's a huge number of contributions from all sorts of places in the world, and that means that we're getting people from very diverse backgrounds to contribute to the software. And so we truly are building software by everyone, for everyone.

Now, sometimes we also get things that are great unexpected. And like we said, it's not a great argument to open source a project for getting free work, but sometimes you get contributions that are very surprising. Now, Microsoft hires very smart people. So David Fowler is an amazingly smart person, but here he shares something that someone from somewhere in the world contributed a change to ASP.NET Core that sped up the engine by 0.001 millisecond.

Now, this is not something that any of the developers on the team working on it was familiar with or even thought about, but this has made the software better for everyone in the world who is using it.

Martin Woodward

Now we get onto the last step, which is around InnerSource. So what we did in Microsoft is we took our lessons of working with open source communities and applied that to how we work inside of Microsoft. If we look at the term InnerSource, it means sharing knowledge and skills and code inside your organization using these open source style techniques, and it helped us communicate better.

When I joined the company, it very much looked like this org chart that came when I joined. It was lots of different divisions, all not really sharing anything together, not really working together, and trying to move as a developer between those orgs was hard. Accessing code between them was also impossible. So we went from that to taking the open source style techniques and using those to learn how to communicate inside of Microsoft as well.

The problem with incentives, as Leonard Sherman said, is that they actually work. And you need to make sure you have an incentive model inside your organization that encourages sharing. Inside Microsoft, the incentive model set up for all engineers is that you need to provide not only what impact you've had, but you need to be able to prove what impact you've had on the work of others, and you need to say what work you've done was done by the work of others. You used other people's work to build on top of that and deliver something yourself.

It's not just the culture inside Microsoft that can change, though. We see lots of different companies who've benefited from InnerSource techniques. NASA and JPL is one of my favorites, where they managed to increase code reuse to greater than 90%, and collaboration increased over twentyfold.

Sasha Rosenbaum and Martin Woodward

Sasha Rosenbaum: So these are the steps for you that we've learned at Microsoft that enabled us to start contributing to open source, and you may use them as maybe a sketch map for the potential process that you could follow. And we must always remember that any of us is just a small piece of the puzzle, but really, there's thousands and thousands of people contributing to open source every day. And as a society, we all benefit from the diversity of perspective and from all of the work of the good people contributing to the projects.

So thank you very much, and you can find me on Twitter and on GitHub as DivineOps.

Martin Woodward: And you can find me, Martin Woodward, @martinwoodward on Twitter and social media. Thank you very much for your time.