Evaluating Microsoft’s Transition to Open Source with Microsoft RD and MVP Mark Michaelis
Microsoft made the monumental corporate strategy shift to open-source several years ago. Looking back on the decision to go “all in” on open source, now is an excellent time to evaluate if this has been a good decision for the tech giant. Let’s review some of Microsoft’s contributions to open-source software.
The Argument for Going “All In” on Open Source
As a long-standing Microsoft RD and MVP, I believe it’s hard to imagine the technology landscape, or where Microsoft would be as a company, had it not committed to open source. On the other hand, not all Microsoft software is open source. Microsoft continues to have significant revenue streams from closed-source software such as Windows, Office, and SQL Server.
Microsoft’s platform services on Azure run the gamut from closed-source proprietary software to open-source software such as Azure-hosted Linux, Azure Kubernetes Service, or Azure Machine Learning.
Regarding Azure, one can’t be faulted for thinking the open-source decision from Microsoft is primarily about driving Azure Committed Revenue (ACR). The expectation is that open-source software development leads to sales in Azure. And, in this regard, the move to open source has been an overwhelming success for Microsoft.
The positive impact doesn’t stop with Microsoft, however. The open-source development process improved both the quality of the software and the speed of its development. It has also enhanced feature prioritization and definition by giving voice to the community.
Key Learning with Open-source Software
Microsoft’s journey in open source has produced some valuable lessons for all organizations and developers engaged with open-source software.
Trust the Process
Microsoft’s early CodePlex effort hosted code but failed to open-source it because developers could read but not contribute to the code. By making code open source and publishing it on GitHub, Microsoft transformed its process. Teams discussed requirements, designed, coded, fixed defects, and even exposed occasional problem areas.
Budget for Success
Open source requires resources and commitment. Who supports the software and is responsible for maintenance? What is your plan for the long-term maintenance of a project? When the .NET Foundation takes on a project, it does so only if the project meets eligibility criteria, including quality, community, and consideration of the project’s health. You don’t need to fund it, but there must be a plan. Even in cases where Microsoft switched code to open source and did not continue to commit their resources, it designated individuals (sometimes outside of Microsoft) to continue to actively manage the project.
Providing documentation on how to work with a repository is vital. Programming guidelines, development workflow, issue logging, guidance on getting started, and even tips and tricks are critical. Don’t skimp — documentation is a significant contributor to the success of any open-source project. In Microsoft’s case, even their documentation is open source. While Microsoft is still responsible for the vast number of documentation commitments, the community can also make big and small changes to it because it is open source.
As with any source code repository (open or not), automated continuous integration and a continuous delivery (CI/CD) pipeline are vital. Build, test, and code analysis should occur with each check-in to increase the chances of the project’s success. Over time, I frequently find that CI/CD analytics provide a key indicator of whether a project finishes as planned.
Of course, many other factors help. Still, those mentioned above are a sizeable portion of Microsoft’s contribution to their projects. Focusing on these has made a significant contribution to the community interaction and the quality of the resulting library.
I worked to build a new open-source System.CommandLine API with several Microsoft and IntelliTect team members, including Microsoft Principal Software Engineer Jon Sequeira and Microsoft MVP and IntelliTect Architect Kevin Bost. This API includes a command-line parser and console rendering engine. The code is currently available in beta and alpha releases.
System.CommandLine is maintained as part of the open-source .Net framework on GitHub. While the project was starting up and in its early phases, the source was kept private. Keeping the code private allowed the team to explore ideas while finding a good direction for the project and work out the implementation. As soon as the project direction was clear and enough code was developed, the source was made public.
One of the things I appreciated most about that project was Jon’s leadership. He was kind and appreciative of our all contributions while ruthless in his quest for quality in all dimensions.
Similarly, in your open-source projects, be careful and explicit in selecting the project’s leader or leadership team. It makes a world of difference.
Is Microsoft’s Open-source Software a Democracy?
I still think it depends on how you look at it. At its most fundamental level, everyone can vote on one of Microsoft’s open-source repos with “their feet” — if they don’t like something, they can fork the repo and run it as their own in whatever way they choose.
Microsoft repos, however, are what the company is choosing to support long-term, so Microsoft is responsible for what ends up in the repo. It can’t allow anything and everything, and as a community member, I admit I am grateful — even if they reject my contributions. Despite some criticism, I think the community at large is thankful for the approach.
Take the example of someone submitting a pull request (PR) to the C# repo for attribute-based programming that includes unit tests, conforms to coding standards, doesn’t break any existing tests, and introduces a potential security hole. I believe we are all better off that no direct push is possible, and Microsoft rejects the PR. After all, when you write code destined for millions of machines, the quality and security bar must be very high.
A Question of Commitment
The Microsoft open-source website (what is now open.microsoft.com) launched back in 2007. However, serious consideration for open source occurred asearly as 2001, if not before. Things took off in November of 2014 when Microsoft first released .NET as an open-source project. The company established the .NET Foundation and published source code. These sources included .NET Core, ASP.NET Core, Entity Framework (EF Core), Roslyn, C#, and others. Those in the open-source community were suspicious at the time.
It’s been several years now, and although there are still critics, it’s indisputable that Microsoft’s move is so much more than lip service. The company now boasts a library of more than 550 open-source projects in the .NET Foundation, including essential efforts such as Xamarin, PowerShell, VSCode, and even portions of the Azure code base. The company has about 5,000 people committing source code on GitHub. Although most Microsoft employee commits are to Microsoft-specific projects (as one would expect), Microsoft employees’ list of independent projects is long. Their projects include more than 8,000 non-Microsoft projects, including Bootstrap, Vue.js, Kubernetes, Angular, Webpack, and Selenium.
Microsoft has a mixed history in open-source projects. Still, its commitment has been strong and increasing over the last four years — reflecting the strategic benefit open source provides to all involved.
This new direction in coding is not your parent’s Microsoft. The company has made a tangible commitment to align around open source and open systems. That commitment is visible in the efforts of the individuals who head up hundreds of open-source projects at Microsoft.
Ultimately, fellow programmers want to use the libraries themselves and want them to be excellently run open-source projects. There’s a natural incentive to follow the golden rule with fellow community members and treat others the way you’d like to be treated.
Furthermore, Microsoft employees frequently contribute to libraries that aren’t part of their job, making them “community members” like the rest of us. In both cases (as employees and community members), they strive for the same thing — guidelines and processes that make sense for everyone.
Read more about System.CommandLine in this blog: Essential .NET: Parse the Command Line with System.CommandLine (MSDN). Also, check out Kevin Bost and Jon Sequeira’s presentation on System.CommandLine at the Spokane .NET Users Group.