September 28, 2019

Problems and Solutions with the .NET Foundation Maturity Ladder

This is largely the text of an issue I posted related to the .NET Foundation’s new proposed Maturity Ladder for .NET OSS projects. I am fully supportive of the .NET Foundation’s stated mission and wrote this in the hopes of trying to help it achieve that through a little tough love.

After reading (.NET Foundation Directory) Jon Galloway’s reply here I want to raise a fundamental problem that exists with the .NET Foundation in its current form that makes some portions of the ladder proposal distasteful, in my eyes as both the proprietor of an independent .NET OSS business, a project contributor, and as someone who deeply cares about the success of the .NET OSS ecosystem as a whole (it’s why I started Petabridge.)

Microsoft and the .NET Foundation are effectively joined at the hip. Its day to day operations and run by largely by Microsoft employees and its interests are fully aligned with Microsoft’s. While the goals and intentions of the .NET Foundation are precisely intended to help foster a healthy third party ecosystem around .NET (Microsoft wants this too,) the fact remains that it’s largely Microsoft’s show and is viewed by users and .NET Foundation members as such. Let’s acknowledge this perception as fact and move onto why it’s an issue.

Microsoft’s Influence on the Behavior of .NET Users

Microsoft has singular influence on the behavior and perception of the .NET community, being the creator of the platform; the developer of the most popular technologies and frameworks on it; and through tremendously high levels of effort: a solid track record of high quality work.

This singular influence comes with what is now a widely acknowledged problem that Jon and the .NET Foundation board are attempting to address through the maturity ladder, per his comments I linked earlier:

We had some board members campaign and win a board seat with statements like “I’d like the .NET ecosystem to thrive with projects people consider and take dependencies on to be much wider than the narrow “Microsoft-blessed” scope that people and companies generally consider.” At our first board meeting, I asked the board to come up with some specific areas and action groups, and this was one of the seven that made the list. I had other things I’d expected to see on the list, but this wasn’t one of them.

I applaud this and I am certain the lion’s share of the .NET Foundation membership does too. Creating more “package publisher” diversity in the .NET ecosystem through normalizing the adoption of non-Microsoft technologies is essential to accelerating the rate of innovation in .NET as a whole, because Microsoft can only invent and maintain so much.

However, where this proposal goes sideways is it’s a roadmap for how to become a Microsoft-blessed project, with the .NET Foundation (Microsoft) acting as the certification authority. This is the opposite of the stated goal - it keeps Microsoft in the position of central influence over the .NET ecosystem, especially if the .NET Foundation’s maturity ladder gets coupled with pure Microsoft channels like NuGet’s user interface . There really would be no effective distinction between the two organizations.

Ultimately what I believe both I and the .NET Foundation leadership, members, and projects want is an rapidly growing ecosystem with projects that adopt good practices, are well-maintained, and regularly updated. That approach, necessarily, must be decentralized in order for rapid growth and innovation to occur.

The current maturity ladder is a centralized, top-down, and heavy-handed approach - because it defines fairly strict quality control rules that are a reflection of how Microsoft’s own organizations operate. And if it’s implemented in its current form, I’m afraid it will create monoculture among how .NET OSS projects are operated (i.e. they all have to be in the .NET Foundation to be a high quality project, must all use a permissive license, etc) and may further stifle the ability of new projects that don’t have a long track record to get off the ground.

Just to drive the point home about monoculture, a specific example from Tier 3 of the project maturity ladder:

  • Practices
    • Complies with .NET Foundation continuation policies.
    • Stable packages depend on libraries that are at level #2 or higher.
    • Signs packages (Note: this refers to digitally signing NuGet packages, not strong naming).
    • Uses static analysis tools to validate pedigree and safety.
    • Applies .NET API design guidelines.
    • Seeks and applies guidance from .NET Foundation design and architecture group.
    • Updates package references regularly to accommodate servicing updates in dependencies.

This requirement effectively eliminates an entire OSS business model: offering certified builds to enterprise users. Most small users (i.e. customers that won’t pay for OSS) are fine with the “buyer beware” culture of OSS. Big companies, who have much larger exposure, are willing to pay a company that contributes to / maintains the project for certified builds that are signed and more heavily scrutinized - that’s not going to be the case any longer if an OSS project needs to be tier 3 or higher for BigCo to adopt it, as much of that value is now expected for free under this model.

Running a sustainable OSS project (i.e. capable of funding itself, has natural business incentives to provide high quality work to users) is hard enough and I don’t believe the .NET Foundation ever intended to be in the business of telling those projects how they can and can’t make money, but that’s what introducing an explicit grading system and pushing that down to users will accomplish.

Additionally, I don’t believe the .NET Foundation is properly resourced to even execute such an effort in its current form. It’s a lot of work for a small team and will get worse the more projects being needing infrastructure - there’s a whole issue opened to address this already, so I won’t rehash it further.

Solution: Bottom-up Approach to Maturity

The .NET Foundation has its heart in the right place - widening the range of “acceptable” OSS beyond what is produced in Redmond. I want that too. Everyone does, most of all the developers who aren’t able to use that OSS today because of the historical conservatism of the .NET ecosystem as a whole when it comes to OSS.

The current proposal puts the .NET Foundation as a centralized certification authority for the entire .NET ecosystem. That’s heavy-handed and will ultimately undermine the .NET ecosystem’s ability to become “bigger than Microsoft.”

What I propose instead is a bottom-up approach:

  1. Never use the maturity ladder as a public grading system of any kind. No lists of “tier 4” or “tier 3” projects. And certainly don’t integrate that language into NuGet.
  2. If NuGet and other Microsoft interfaces into third party packages (i.e. Github) want to offer some kind of hint as to how well a project is run, I recommend using something similar to Github Pulse - show that the project has commits from multiple users, automated CI checks, new releases, responses to issues, responds to recent security incidents, etc. The reason why this is fine is because all of that activity is 100% under the control of the project developers themselves - no one had to seek out permission from the .NET Foundation to be rated as a “good” project. This decouples the .NET Foundation from being the arbiter of what is good and what is not. Instead, the project leads themselves decide if they want to put the time and effort into doing those things and act accordingly.
  3. Projects do not need to be part of the .NET Foundation to achieve everything in point 2; projects like NServiceBus, ServiceStack, RavenDb, EventStore, and so on are trustworthy because those developers can’t pay the bills if they don’t act accordingly. That should be good enough.
  4. Use the maturity model as a roadmap for guiding projects towards best practices, not a process to be strictly followed. If one project doesn’t want to sign its builds because its maintainers want to offer that as a paid service, let them and their users (consumers and contributors both) decide if that’s ok.
  5. Leave the forking policies et al in place for .NET Foundation projects, but leave that at a .NET Foundation member project consideration - not something that applies to “any trustworthy .NET OSS” project.

If a project dies or gets abandoned, the objective numbers in point 2 will decline and maybe that project will be forked by users who still have skin in the game. Let it happen - that’s allowing the ecosystem to run itself.

I believe in the .NET Foundation’s mission and that’s why we joined it and I very much want it to succeed. That’s why I felt the need to criticize it and say what might be a painful truth: that it’s still Microsoft’s show and this proposal only makes it further so. It’s in the best interests of the entire .NET ecosystem, Microsoft and the .NET Foundation included, to make .NET bigger than Microsoft. I hope you will consider my recommendation in the spirit of trying to help us all make that happen.

See the full issue on Github here.

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..