Comments

1. Communication of Project Maturity Model

   Myself, and other members of the Dotnet Foundation (DNF) were genuinely surprised by this development. I found out on twitter. I notified other members, who are OSS maintainers as well, and they were shocked. This speaks to a larger issue that the project leaders are doing a big amount of work, with minimal assistance from the foundation (@devlead). It seems the foundation is making assertions in the best interest of those maintainers without asking for input. This is a communication break down.

2. Proposal of SLA's?

   The verbiage reads like the next logical step is SLA's. For consumers, SLA's are great. For maintainers they are not. What I forsee happening is SLA's will drive maintainers away, and without a healthy community of contribution around a given project, that project will die and the consumers won't have anyone to provide the SLA's they've come to expect. The community (which includes maintainers much to some peoples dismay) would benefit greatly from a better understanding of how open source software works. Nothing here talks about consumer commitment to open source, which to me is the biggest piece excluded from the .NET OSS narrative.

   To be clear: I think that the DNF proposing SLA's for any of it's projects is a bad idea.

3. Issues currently faced by the .NET OSS community

   We (ReactiveUI) struggled with getting support in the past for our projects from the DNF, so it feels like they aren’t holding themselves accountable to their purpose. ReactiveUI was one of the early adopted projects in the DNF. We've struggled with lack of communication from board members, no major promotion past spots in the newsletter. DNF project leads have been forth coming with our criticism and requests for what we feel would be helpful.

   Our consumers suffer when we haven't had time to look at a bug report. Our consumers suffer when our builds are on shared resources. Our consumers suffer when the documentation is lacking. Our consumers suffer because we don't have the resources to help them resolve issues in a timely enough manner. Consumer suffering is really a result of Maintainer suffering. It isn't that our desire isn't there. It's that our resources, community contributions and time are fixed.

4. DNF Mission

   The DNF seems to be getting away from maintainer needs of funding, internal product managers, grooming of contributors. I was under the impression the whole point of the DNF was to help maintainers, which helps consumers. This begs the question, how does this project maturity model benefit the project? It's appears to be written with a consumer focus. I'm of the thought that helping project maintainers is the most direct way to help the project consumers. So where is the sell for a project to buy into this model? It's clear the consumer wins, do the projects have to lose for consumers to win?

5. Ecosystem

   I see a lot of use of the term Ecosystem. Which ecosystem are we talking about? The Microsoft Ecosystem? The .NET OSS Ecosystem? Or the Ecosystem that will be managed and maintained by the DNF based on this model being proposed? These are all different worlds.

   • Ecosystem tiers have different concerns
     • Corporate Backed Open Source
     • Organization Backed Open Source
     • Individual Project Open Source

6. Proposal: Maturity Ladder

   • Level 1 - Any dual licensed software automatically is not eligble. How a product is licensed shouldn't dictate maturity. (@daveaglick)
   • Level 3 - We required you to join the DNF for us to promote your hard work, or consider you mature feels immediately exclusive and against the mission
   • This model level seems to be introducing a project tier without the appropriate foundation tiers to match. (@devlead)
   • If the maturity ladder will keep projects from the promise of DNF help, the consumers of those projects won't benefit from the efforts of the DNF.
   • Very little of the verbiage in this "Project Maturity Model" coincides with the DNF mission.

7. Proposal: Project Forge

   • This seems like a proposal to kill "free enterprise" in the OSS space.
   • I feel this would be better served as an advisory board rather than the proposed bureaucratic oversight committee.
   • I think it's hard to state that a project directly out the gate is worthy of inclusion in the "core framework". Which it sounds like the Project Forge is just a staging ground for things that will eventually become Microsoft operated.
   • The forge should be a place that helps any project that adds value to the community get off the ground.

8. Proposal: Maintainer "Bench" Program

   • I think we should look at it as a "Contribution Encouragement" program.
   • People who have the passion will move into maintaining (speaking from personal experience).
   • We should focus on creating a good pool of contributors, so that we have people on the "bench" as it were.
   • OSS continuity and project succession is the focus here, how do we incentivize users to become contributors, and contributors to become maintainers?

9. Benefits

   • For Maintainers
     • Adoption is generally about visibility. Contribution has little to do with maturity or quality of the project, and much to do with the willingness of the individual developer to roll up their sleeves.
   • For contributors
     • Hand hold them through the process, make them feel comfortable. Remove barriers to contribution.
   • For users
     • The only thing that makes sense here is the security. People select libraries because their application has a need that is outside of it's core purpose. They don't just go to nuget and see trends and add libraries because they are popular.

10. OSS Contract

    "I built it. You consume it. We maintain it."

I believe we ultimately want the same thing. I think the approach is a good first step that could use a bit of help from maintainers that are currently producing projects of these levels. We have an internal core of projects across the maturity model, we should use their experiences as a basis for how best to help other projects. This will help drive a better consumer experience.

About the DotNet Foundation

The .NET Foundation supports .NET open source in a number of ways.

- Promote the broad spectrum of software available to .NET developers through NuGet.org, GitHub, and other venues.
- Advocate for the needs of .NET open source developers in the community.
- Evangelize the benefits of the .NET platform to a wider community of developers.
- Promote the benefits of the open source model to developers already using .NET.
- Offer administrative support for a number of .NET open source projects.