ASP.NET Core Community Architecture

Project page: https://asp.net

Dotnet Community: https://dotnet.microsoft.com/en-us/platform/community

GitHub: https://github.com/dotnet/aspnetcore

We picked ASP.NET Core as our stadium project. It is a stadium because development nearly entirely happens by paid Microsoft employees, the development direction is dictated by Microsoft and its enterprise customers, and the project is tightly integrated with the paid Visual Studio Enterprise and Azure services. We picked it because we thought it exemplified all of the traits that we would expect from a stadium. It also has a fascinating history, due to Microsoft’s historical aggression towards FOSS and Linux. We wanted to see how a product that historically has been the keystone of proprietary software adopted an Open Source model, while remaining highly profitable.

Background

ASP.NET Core is a reimplementation of the proprietary ASP.NET library for Windows, Linux, and MacOS. The framework relies on the open-source Dotnet Core Common Language Runtime (CLR). Microsoft developed it to allow Dotnet development teams to deploy on platforms other than Windows Server to get the ubiquity that Java previously achieved.

History

Microsoft launched ASP.NET in 2002. This project was a proprietary framework that aimed to allow for more intensive web pages to be developed. It brought features like Object Oriented programming and DLLs to Web servers. For much of its history, ASP.NET grew with Dotnet and Visual Studio updates. While used in public-facing applications, it had close integration with Active Directory and CardSpace, which made it a prevalent language for enterprise applications. (https://en.wikipedia.org/wiki/ASP.NET)

Dotnet spent much of its history under the “Rotor” Shared Source license. This meant that the Dotnet source code was available for very limited use, and commercial use was not permitted. This led to the development of third-party CLRs for platforms like FreeBSD (https://learn.microsoft.com/en-us/previous-versions/dotnet/articles/cc749640(v=msdn.10)?redirectedfrom=MSDN), but it was not Open Source. Commercial usage still requires commercial licensing on Windows Server.

In late 2014, Microsoft pivoted Dotnet, including ASP.NET, to the MIT License (https://devblogs.microsoft.com/dotnet/net-core-is-open-source/). They aimed to build more of a community around Microsoft’s open-source offerings, including shifting development to GitHub and adopting UserVoice to help guide long-term decisions. At the time, they were working with the team behind Xamarin/Mono (a FOSS Mac and Linux reimplementation of the CLR) to bring Open Source Dotnet across platforms, and Microsoft eventually bought Xamarin.

First and Latest Commits

The first commit happened in 2014. The most recent commit happened today.

Leadership and Structure

Benevolent Dictator

ASP.NET Core is a stadium that is highly reliant on Microsoft’s development efforts. Microsoft uses ASP.NET Core in many of its services, so they have a strong financial interest in ensuring its success. They also have built various services, including Azure and Visual Studio, to ease ASP.NET. Thus, while they have a strong financial interest in its success, they may prioritize the needs of Microsoft and its enterprise customers over the community at large. Given Microsoft’s centralized control over the project, the development team follows the same general trends as any other major software development project. There is some turnover in core contributors, but generally, no trends are alarming.

Core Team Members

The project’s most prominent contributors have all had extensive experience with Microsoft and Dotnet. For example, Chris Ross, one of the most significant contributors, has been involved with the Dotnet project at Microsoft since 2009 (https://www.linkedin.com/in/tratcher/). Some other high-profile contributors do not even have LinkedIn profiles, indicating they do not intend to move companies soon.

The most recent commit to the main was a caching test, and it was merged four hours ago. James Newton-King wrote the commit. Microsoft employs him, and he is based out of Singapore, working on the GRPC implementation in ASP DotNet Core. The commit includes unit tests for Krestrel, the ASP.NET Core native web server.

Responsible Stakeholders

The project is run by the Dotnet Foundation, which has a variety of sponsors, including Microsoft. Most of the board members have some affiliation with Microsoft. Any “community contributions” must be approved by a random set of Microsoft employees. However, it is important to note that most contributions are not from the community. Rather, they mostly come from Microsoft. Microsoft handles all security reports and does not publish them to the public issues list.

Unique Knowledge: Git-by-a-Bus

Pranav K, Steve Sanderson, and Chris Ross have unique knowledge. They have thousands of commits. Chris and Pranav started their commits in 2014, with Steve starting in 2016.

The project would likely continue if the top 20% of contributors could not contribute. This reality is because Microsoft backs the project and the importance of the project within enterprise settings. This importance extends to Microsoft’s products. Microsoft is incentivized to rehire and keep the project going since they cannot deliver many of their other online services if ASP.NET Core fails. Similarly, many of their enterprise customers rely heavily on ASP.NET Core with expensive Visual Studio subscriptions, which would directly affect their bottom line if they cannot deliver ASP.NET Core.

Commit Access and Patch Approval

Commit access is reserved for a select group of insiders, most of whom work at Microsoft. External merge requests require approval from a Microsoft employee. All merges, including those from Microsoft employees, require human and CI.

Quality Control

The library has historically relied on UserVoice for bug reports and feature requests. GitHub Issues now handle that. Microsoft reviews issues and assigns them to Microsoft employees.

Front End

ASP.NET Core is a library. Thus, the owners do not maintain “front end” code. The onus for front-end development lies on the IDE. The most common IDE for ASP.NET Core is Visual Studio 2022, a proprietary software developed by Microsoft.

Stability

• Source Code > 100MB (+5)
• Compressed Source Code > 100 MB (+5)
• Builds using the DotNet Core Build System (+10)
• Source Code cannot be built without first building DotNet (+10)
• No make install (+20)

The project achieved a Calloway Coefficient of Fail of 50. This is much higher than ideal for open-source projects. However, there were a number of factors that make the real risk much lower than the Calloway Coefficient of Fail would suggest.

The primary issues occurred because ASP.NET Core is a Dotnet project. Dotnet projects tend to be large and rely on the CLR. While ASP.NET Core is a large library, it is within reason for such a powerful web framework, especially one built on the Dotnet library. Anyone using the library knows the drawbacks and benefits of such a large project. Thus, the scale is largely justified.

The second factor negatively affecting the Coefficient of Fail is the CLR. Much like the Java Runtime Environment (JRE), the CLR allows different syntaxes to be interpreted on multiple platforms. The Calloway Coefficient of Fail only grants exceptions to languages that run on the JRE. If the project were evaluated under the rules of a JRE-based language rather than as a compiled system, the score would fall from 50 to 10.

Major Issues

Microsoft Security handles security issues. The contents of security vulnerabilities are confidential until fixed. The project has a running list of issues publicly accessible on GitHub. Currently, there are 5,969 open issues and 144,749 closed issues.

Participation Trends

Commits are down 9.75% relative to last year. This is because Microsoft is in between Long Term Support releases. Microsoft released Dotnet 6, a Long-Term Support (LTS) build of Dotnet and its core libraries like ASP. This means there was an increase in developer productivity to meet the Dotnet 6 ship date. Dotnet 7 is a standard support length and has a much smaller changelog across the board than Dotnet 6. ASP.NET Core 7.0 similarly has a relatively small change log compared to ASP.NET Core 6.0. Microsoft tends to have larger changelogs for their LTS versions of software than for standard support software, as standard support is less likely to be used in enterprise settings.

Onboarding and Documentation

User Onboarding and Documentation

The project has onboarding examples for using the library. It also has documentation for the general framework and more specific use cases (Web APIs, Blazor, Razor, MVC, and SignalR). It includes extensive documentation with code samples. The documentation is in line with Microsoft’s developer documentation, and a person could reasonably write many apps without any third-party documentation. The organization of the documentation takes some time to get used to, but it becomes intuitive, and finding anything is simple.

New Contributor Experience

While the project welcomes pull requests, Microsoft tends to push people to file issues. Pull request authors must also fill out forms if their contributions require meaningful changes beyond simple bug fixes. The contribution guidance is minimal. If I needed help with a contribution, I would likely ask about it on Discord, though no direct guidance on what to do is provided. Given the culture, any PRs that needed help would be rejected or thoroughly reviewed. It could be a better repository for people new to FOSS to contribute to.

Code of Conduct and CLA

The project has both a code of conduct and a Contribution License Agreement which are shared with all other Dotnet Foundation projects.

Summing Up

The decision-making process is very hierarchical, and the project is a stadium. While Microsoft uses “Open Source Software” terminology to describe the project, and the Dotnet Foundation technically owns it, it is clear that Microsoft holds the decision-making power. It is deeply integrated with Microsoft internal tooling (such as GitHub bots and CI/CD pipelines) and any changes require approval from Microsoft. Similarly, documentation is hosted by Microsoft rather than the Dotnet Foundation. I would dissuade contributions from novices. Microsoft and its customers need rock-solid stability and security, and there are gates around the contribution pathways to facilitate this. Pros highly familiar with the Dotnet framework can contribute but should expect contributions to take longer to be written and integrated than other projects may require.