Future .NET Foundation Initiatives

[Aaronontheweb]

Since I don't see a good repository for talking about how the .NET Foundation itself is run, I'm going to post this here.

I want to thank @jongalloway, @richlander, @JamesNK, @ImmoLandwerth and other Microsofties have done the thankless task of dealing with opinionated developers / malcontents like me in how this process has been rolled out thus far. One thing we can all agree on is how this proposal was rolled out and presented to the foundation memberships was disastrous and something all parties would prefer to avoid in the future.

I am intensely disinterested in using this thread for assigning blame to any individuals for how that happened, because that's a petty exercise in cruelty and belittlement.

What I am interested in discussing: how future ideas like this are socialized with the community and putting forth some suggestions that will help.

.NET Foundation Stakeholders

There are, in my eyes, four key stakeholders in the .NET ecosystem:

1. The ultimate consumers of .NET, the developers building applications with OSS work;
2. The project developers and maintainers;
3. The businesses who support those project developers (can't have sustainability without them;) and
4. Microsoft, the platform creators.

To have an ecosystem that works, all four of these parties have to have the freedom to experiment with new ideas, designs, business models, and so on. The .NET Foundation is here to align the interests of all four groups in service of building a better, more innovative, creative, and, most importantly, fun ecosystem. We are all onboard with this.

The communication failure that occurred here, speaking as someone who was never in the room during the discussions and only heard about it when it was announced publicly, is that groups 2 and 3 were underrepresented in the maturity ladder discussions leading up to is announcement, despite them also being major cost-bearing parties in the event of its implementation. This is how I and, I gather from the comments thus far, many of the other project members feel.

.NET Foundation "Initiatives"

Fundamentally, the proposal as it was presented from "day one" to the rest of the foundation was as a solution for a problem that is largely unknown and unheard of by those stakeholders, and an awfully heavy-handed solution at that.

In this respect, going forward the process for putting forth a foundation-wide initiative like this must start with socializing agreement that there is a problem prior to working on a fix. When I see comments from @haacked (not picking on you, just using you as an example) like this:

Unfortunately that's exactly what attackers are counting on these days. It's likely that a phishing attack enabled attackers to inject a remote code execution backdoor in bootstrap-sass. People trusted that package because it was adopted by many. I've written a series of posts on the topic of package security: https://haacked.com/archive/2019/06/11/package-manager-security/

Nothing is foolproof in protecting consumers, but as these attacks continue to be successful (and perhaps there are many that have been that we just don't know about), I think it's important to set some basic guidelines around good security practices.

I can absolutely see Phil, an original developer of NuGet and veteran Github employee, viewing package security as a critical ecosystem problem given his expertise. And he is not wrong. But would @ghuntley, myself, or a dozen other .NET project members say this is an issue of greater significance over day-to-day issues we deal with like sustainability? Probably not, and the people behind this proposal would have heard that loud and clear prior to spending nights and weekends working on this.

I would propose that's what we start with in the future - we socialize the problems first, not their solutions. Let's not create a giant, heavily structured proposal on how to deal with a problem that may not be an actual problem yet; first we gather input from all four groups of stakeholders, widely and publicly, when it comes to ecosystem-wide issues.

I'm sure I'd be surprised to learn from Microsoft or other project members what some of their OSS problems are, but that's the right place for a "proposal" to begin in the future and it should be done in the open.

Here's how we could have gone about starting this process, via an oversimplified example in the form of a Github issue / simple readme, written from the perspective of someone working on the .NET team at Microsoft:

---

Initiative: broadening the adoption of third party OSS among large enterprises and Microsoft

Internally at Microsoft, among some of our large enterprise users (Fortune 500), and among some of our Microsoft Consulting partners, we have heard the feedback that they won't adopt any third party source code for the following reasons:

1. Lack of reproducible builds;
2. Unknown or untrustworthy package ownership;
3. Lack of bug triage and activity; and
4. Infrequent releases.

We're assessing the extent, scale, and possible solutions to this problem.

If you're a package developer who's lost a user due to this types of issues (not exactly, but in this vein) or if you're a developer who's had to decline use of a third party project because of this issue, what were the objections and how often does this happen?

---

Can we imagine how different this entire rollout would have looked if we started the discussion this way? I would have immediately chimed in with how I lost a deal with a big company because they wanted to stick with MSMQ (because Microsoft made it) as their preferred messaging technology or how I lost one with a massive insurance company because they're worried about intellectual property issues with any OSS.

I suspect we would have buy-in from all four groups within a short period of time that this is a real issue, given the shared and readily visible data from all four groups of stakeholders. Having access to new information at our finger tips that would help us see common recurring patterns that are bigger than any one stakeholder within the .NET Foundation umbrella.

From there, a proposal on what to do about this problem could be proposed by anyone on that issue, but ultimately the .NET Foundation director and the team would need to culminate that feedback into something with structure, which should be socialized again. After enough of that has passed, put it up for a vote to the board.

I'd be excited to participate in that kind of process, because I would finally have an avenue to address an ecosystem problem that is bigger than what I deal with, alone, every day - and I would welcome the opportunity to work with our colleagues to do something about it.

I hope you consider this in the spirit of constructive feedback and wanting to see the foundation achieve its goals.

[glennawatson]

I believe https://GitHub.com/dotnet-foundation/home is more of a broader issues. There's also GitHub teams discussions as well

[glennawatson]

Also https://github.com/dotnet-foundation/projects/issues/18 is related

[haacked]

In this respect, going forward the process for putting forth a foundation-wide initiative like this must start with socializing agreement that there is a problem prior to working on a fix. When I see comments from @haacked (not picking on you, just using you as an example) like this:

I don't feel picked on and I think this is a very good suggestion. Thanks!

[haacked]

Just to follow up, we plan to take an approach more along the lines of what @Aaronontheweb proposed here. Here's the post on the .NET Foundation blog. https://dotnetfoundation.org/blog/2019/09/30/rethinking-project-maturity-as-a-community-process

Let me know if I can close this issue.

[Aaronontheweb]

@haacked I just finished reading the post. I think that is a perfect response and I appreciate that the board listened to the members who were critical of the proposal. I'll close this issue. Thank you. Looking forward to working with the foundation going forward.

As an aside, because I didn't know about it - working group for future initiatives like this: https://github.com/orgs/dotnet-foundation/teams/project-support

I just requested to join and everyone else who commented should too.

[glennawatson]

@Aaronontheweb Make sure you get this discussion opened up again on that project side. It's useful feedback.

[haacked]

Just to be clear, https://github.com/orgs/dotnet-foundation/teams/project-support will only work for members of the .NET Foundation. After the project support group decides on an approach to move forward, we will absolutely involve the larger .NET community with the implementation.

[haacked]

And shameless plug, here's how to join the foundation as a member: https://dotnetfoundation.org/become-a-member

[rubberduck203]

Thank you for posting this. It’s a much more eloquent way of stating what I was attempting to get at in my quote in #44.