Some words on #nugate


As the author of what is now becoming an infamous PR, I thought that it’d be an idea to document my thoughts regarding both my motivations for it, as well as my thoughts on the reactions to it from all sides since then.

What’s #nugate?

tl;dr – a tiny and innocuous PR to the NuGet gallery that showed how to install NuGet packages when using Paket was closed abruptly by the NuGet team with an inadequate explanation, and then apparently ignored, despite large community feedback.

The Paket PR

Just a bit of background first on the PR. The idea came when looking at the new version of the NuGet site (which looks much nicer than the current one, I must say) and noticing a “tab view” for how to add a given package to your solution using either NuGet or the dotnet CLI. I thought that this might be a good opportunity (and pretty cool) to get a similar tab added for Paket.

nugate1Since Microsoft have publicly gone pretty much “all-in” with the whole OSS thing, I forked the NuGet Gallery repo, found the relevant file (just one razor view) and added in the appropriate two lines to add the new tab, before submitted the PR in GitHub. This took about 15 minutes to do in total. I believed (naively, as it turned out) that the PR would get in pretty quickly:

  • The tab was deliberately added to the back of the list, in deselected form. In other words, it wouldn’t explicitly affect what users saw, aside from the word “Paket CLI”- they’d have to click the tab to see what it meant.
  • It was two lines of mark-up. No custom logic or anything like that.
  • The content added was minimal. It didn’t provide any links to the Paket site, nor did it provide any discussion of what Paket is or why you might want to try it. In fact, I deliberately kept the PR like this, to avoid anyone in the NuGet team thinking that this was about trolling / NuGet bashing / Paket-one-upmanship. I simply wanted the site to acknowledge that, yes, Paket exists and a not-insignificant part of the community is using it. Let’s just make it that little bit easier for them to use.
  • It was an additive change – providing more functionality at no cost to the existing feature set.

It’s not me, it’s you

Within a relatively short space of time, I got the auto-approval from the MSFT bot since the PR was so small, followed by an approval by someone at Redmond – a positive sign. But the following day the PR received the following (now well-publicised) Kafkaesque response:

nugate2

I wanted to try to understand the motivation behind the reply, so I read through it again. And again. The key parts I could glean were:

  1. We want to focus on NuGet and .NET Core because of usage stats.
  2. At some unspecified time in the future, we hope to provide some guidance around other clients.

The usage stats point didn’t make sense to me. Aside from the official NuGet client, Paket is the most popular NuGet-API compatible client. We’re not talking tens of users, or even hundreds. Paket is used by thousands and thousands of developers and projects out there, both open and closed-source. It’s used heavily within the F# userbase because of several features that greatly aid working within scripts, but also within C# and VB.NET shops (funnily enough, I bumped into an old colleague of mine some months ago who now works at a tier-one investment bank in London, who without knowing I was even involved on the Paket project, told me about an alternative NuGet client that they’ve adopted that has massively helped them out).

The second point also confused me. The reply acknowledged that there are indeed other clients (let’s leave aside the fact that there’s really only one alternative client, but it’s not mentioned here by name…), and that they deserve to be offered guidance on the site. But not yet. Instead, at some point in the future (date: uncertain), we’ll reconsider this. My question: Why should we need to wait at all when we can get that guidance in today?

Overall (and forgive me for being a little sceptical here) I did not read this as a genuine commitment; instead, I interpreted it as rather as the bare minimum of a response that hopefully would not appear as a complete “go away”, but nothing more.

And lastly – with the greatest respect to the NuGet team – the people best placed to provide guidance on using Paket is obvious: the Paket team.

The Community Responds

I waited a few days (over the weekend) and then replied again, explaining clearly and politely why I thought that the project admins should reconsider their decision, or at least further justify their reasoning, because I genuinely didn’t understand the rationale behind not accepting it. Almost immediately after my post (I seem to recall within an hour or so), the PR was explicitly closed. No further comments or explanation – just closed. I was pretty surprised at this, not only because it was plain rude, but because I could see immediately that this would be a massive own-goal for both NuGet and Microsoft. Furthermore, dealing with the PR in this way would further only foster the perceived view (rightly or wrongly) that the NuGet team don’t like Paket, and will avoid doing anything that might possibly increase adoption of it.

Sure enough, this issue has had a clear view from the .NET community (note: not the “Paket community”. More on this later), with the only comment from the NuGet team earning over 200 negative feedbacks. Here are some comments I’ve picked from the PR itself and Twitterland:

nugate3nugate4

https://twitter.com/Aaronontheweb/status/889909598676688896

Other comments include ones like this:

This is not good feedback, Microsoft.

Why?

At the time of writing, there’s still been no official word from the NuGet team to elaborate on why this issue was handled in the way it was. So, all we can do is speculate at this point as to the reasoning behind it. Here are some of the possible reasons I’ve observed from people over the past couple of weeks, along with my personal views on them.

Support Costs

There’s concern about MS having extra support costs for Paket once this tab is added into the website. I’ve heard this from a few people, but it doesn’t make much sense to me:

  • Why would adding a tab with the most basic of guidance on how to install a package using Paket somehow mean that Microsoft supports Paket? The tab doesn’t even explain what Paket is, or even where to download it. In its current form, the PR is only realistically usable for people already using Paket. This was by design, because I didn’t want anyone to reject the PR simply because they saw it as a Paket vs NuGet client issue.
  • Paket is already mentioned in a several places across Microsoft’s online content. By implication, this presumably mean that either (a) Paket is already supported, or (b) is not supported, in which case another reference here shouldn’t affect that. In short – this isn’t the first site run by Microsoft to reference Paket.
  • I’ve been told by some people privately that they feel Paket has an insignificant usage compared to NuGet. If that’s the case, it’s a simple cost-benefit analysis – tiny usage of Paket and similar tiny risk of support costs versus negative PR and community relations.
  • Microsoft reference other third party tools in many places across their online content. Microsoft aren’t responsible for a bug in Paket any more than they would be for left-pad on NPM simply because they acknowledge NPM’s existence on some Azure documentation. Nor would Microsoft be able to issue emergency fixes for third-party open source tools, because they may not own the associated GitHub repository. So why the special treatment for Paket?
  • I’ve been involved with supporting Microsoft, both in terms of alongside a customer asking for support, as well as working alongside Microsoft delivering solutions to large customers. If a large customer has a live critical issue on their ASP .NET site that’s hosted in Azure, they do not care whether the issue is caused by a Microsoft product or some third-party package manager written in F# – they’re going to call Microsoft support anyway. And I’m pretty sure that Microsoft aren’t going to tell some customer with a million-dollar annual spend on Azure to go away just because the customer uses Paket. Do Jet use Paket? Are they supported by Microsoft? Has this been an issue? In this sense, Microsoft would be no more or less exposed after accepting this PR, than they are now.

It wasn’t me, guv!

Some people have suggested this was the action of a “rogue” individual on the NuGet team. I think we can rule this one out right now – it would have immediately been reopened had that been the case. This wasn’t a decision by one developer, and there’s no need to even reference the individual that closed the PR or try to make this personal. It’s about more than one person, and more than one team.

Paket? What’s that?

Could it be that the NuGet team don’t understand what Paket is, and are suffering from FUD or some other kind of disinformation? I sincerely hope that this isn’t the case, since as a team solely responsible for the de-facto package manager on .NET, one would hope that they are aware of the only other package manager out there.

You didn’t follow the protocol

Apparently, I should’ve followed the “best practice” protocol for submitting a PR – in other words, first submit an issue on GitHub, wait for it to be reviewed and processed by the powers that be, before finally getting permission to actually submit a PR. Mea culpa, but I wrongly assumed that I wouldn’t need approval to submit a two-line PR that changed some mark-up. And I really wouldn’t be especially bothered about wasting 15 minutes on a PR that gets rejected – I’ve spent more time on other PRs that’ve been rejected before; I know the drill. If repos force issues to be raised before every PR, we’ve got even bigger problems than I thought.

Forking the Ecosystem

This is something I’ve heard in the past several time. Related to the previous issue, might the NuGet team see the Paket product as divisive within .NET and / or a threat to their existence, and therefore not wish to see it grow? Again, this would be a gross mistake from anyone who thinks this. Paket simply offers an alternative option for .NET developers who are using NuGet packages, and would also like to benefit from some of the features that Paket offers that NuGet does not.

We no like Paket

Perhaps the most worrying possibility is the simplest – the NuGet team don’t like the Paket product, and therefore do not wish to see it grow. Again, I would hope that this isn’t the case, since it would mean letting personal feelings adversely affect the entire .NET community, not the mention what it would mean for the future of Paket if the de-facto package manager on .NET are actively working to thwart it. I sincerely hope that this is not the case.

The PR wasn’t big enough

I’ve also seen suggestions that the PR wasn’t enough – that it should have been included with some guidance as to what Paket was, how to use it etc. etc.. Possibly a fair point, except if we’re not going to get Paket accepted on the NuGet Gallery in it’s most basic form, what hope do we have for something more? The PR in it’s current form would’ve been fine as a way to appeal to existing Paket users; further PRs could easily introduce more details over time. Additionally – what’s to have stopped the repo admins saying that immediately?

Unfortunately, nearly two weeks after the PR was raised, we still have yet to hear anything from the NuGet team, or Microsoft at large, in response to this. This had led to fears that Microsoft are simply hoping that this problem will “go away”:

nugate6

The .NET Foundation

Some people have rightly brought to the light the fact that it turns out that the NuGet project is actually not owned directly by Microsoft, but by the .NET Foundation. In which case, people have asked, what’s the .NET Foundation’s take on all of this? Nothing official on the PR, but on Twitter at least there’s been some sort of response, although the last one was still almost a week ago:

Last minute edit: I now see that someone has raised a formal issue for the Foundation to address here, too.

Overall, I think people would love to hear what the Foundation has to say, and to clarify the role that they play on this project (and others) vis-à-vis internal Microsoft teams, and ownership. At the moment, it’s not entirely clear who owns the NuGet Gallery project, and who has the final say on things like this. Evidently the issue is being discussed internally at Microsoft, which suggests that ownership rests with more than just the Foundation:

https://twitter.com/shanselman/status/891550238225215488

It’s great to have some form of response from Jon and Scott. But we’d also love to have a little bit more information by now.

Community Affairs

One thing that I personally think it’s fairly safe to assume is that when this issue first appeared, more than one person immediately said something like “Not again. That Paket lot are on the warpath.”. This is really, really frustrating. Let me try to make a few points to explain why this is:

The Paket Community is part of the .NET community

I’d prefer that we think of it simply as “there is no Paket community”. Is there really some way to categorise a developer based on the package manager they use? Let’s think about this for a moment. Do we do this based on what web framework you use? What IDE you use? Whether you work in finance or health care?

What if someone is an enterprise developer working with in VB .NET in VS2015 but also uses Paket? What about someone that loves OSS and uses F# and VS Code, but uses NuGet? What about someone that users both NuGet and Paket? How do you define such people?

Doing something like this will only have negative effects – and risks fracturing the entire .NET community. It’s also an incredibly lazy (and to be honest insulting) to discount feedback from individuals simply by saying “oh, they’re part of this or that community. Take whatever they say with a pinch of salt”.

Please, don’t do it.

The Paket Community is NOT the F# developer userbase

The same goes for F# and Paket. Paket is written in F#. But it works across C#, VB .NET and F# projects, on both “full” .NET and .NET Core. For various reasons, there’s a higher correlation with Paket in the F# community than in C# e.g. Paket works better with scripts; F# users are more likely to be comfortable using command line tools; F# users are more used to working with tools that are not proscribed by Microsoft. However, I’m pretty sure that there Paket is used in many, many more C# projects than F# ones. In other words – Paket and F# are completely separate concerns. Don’t conflate the two, any more than you might do when saying “JSON.Net is written in C#, therefore the next time I have an issue with JSON.Net, I’ll go find Mads Torgesen”.

Let’s not hear this one again, please!

Who are Paket users?

A much better way of looking at Paket users is simply: people that use Paket are simply part of the .NET Community. There’s no closed meetings that Paket users have once a month where entrance is permitted through the top-secret handshake. There’s no WhatsApp channel where I message people and say “Here’s an issue that’s appeared on GitHub – everyone, flame Microsoft NOW!”. These people are part of the community that Microsoft have helped build over the years. Those people are only “outside” of the .NET community if community leaders choose to make them so.

I don’t know many of the people that have contributed to the discussion on GitHub or Twitter. The few that I do know, I might know through F#, or Paket, or the UK or German developer community. Others I know simply because they are well known in the .NET community. Some are enterprise developers. Some are MVPs. I have no clue if they all use Paket or not – probably a mixture of both. But they’re all interested in the outcome of it, because it speaks to wider issues (I actually wish that I could have heard more from some of the more vocal people that have been trying to drive the so-called .NET Renaissance recently).

Microsoft and Open Source

Something that I believe is incredibly important that we all understand is that this issue speaks to much more than just one PR.

Let’s recap briefly: A two-line PR to add a technically harmless piece of mark-up has been upvoted by a relatively broad spectrum of users by more than 4 times for the next most popular item in the NuGet Gallery repo. It was closed in controversial circumstances.

Timings

Nearly two weeks have passed and we still have no resolution to the issue, much less any clue that this issue is even being discussed internally at MS / .NET Foundation. Some people have suggested to me that Microsoft are simply waiting for the issue to die down, after which time they’ll simply lock the issue. I’m very hopeful that that’s not the case, and it is still being discussed internally (in which case, I would suspect that after this much time, it’s probably the case that serious discussions are happening). Nonetheless, it really doesn’t help that what probably should’ve been a slam-dunk PR has taken two weeks to not get a resolution.

https://twitter.com/Aaronontheweb/status/889911630250876930

This does not bode well.

Old and New MS

My original tweet after the closure of the PR was somewhat harsh, since it accused all of MS of not being believers in OSS unless it’s MS-owned code. I believe that MS still have a way to go, but big strides are being made in this area; slowly but surely things are moving forward. Lots of projects at MS are accepting PRs from external contributors, and it’s not fair to treat all of Redmond with the same brush.

Nonetheless when an issue like this comes along, all the fears about the “old” Microsoft come rushing back – that their idea of open source is simply what I call “read-only” open source, and that only Redmond staff, and only Redmond staff, know what’s best for .NET developers.

https://twitter.com/Aaronontheweb/status/889910063653019648

What now?

I’m waiting patiently for Microsoft to come back to us with a response. I get it – Microsoft is not a moped, it’s a super tanker. Things like this probably take some time to decide upon (although I must admit, I didn’t expect to be writing this two weeks after creating the PR).

Microsoft: It’s crucial that we receive a clear and honest reply from you. If you believe Paket is an evil project, something destined to divide the .NET ecosystem (more than, say, a new .NET SDK + runtime which isn’t entirely backwards compatible), or is not of a high-enough quality, or if you simply don’t like the product and don’t want it shown on the NuGet gallery page – just say so. I’ll respect you for doing that, and at least the Paket team (and users) will know where we stand. Plus, we’ll have a clear understanding of how we can expect Microsoft to work with the community when tools are written that overlap with existing tools that MS own in the future, or that aren’t owned by Microsoft.

Alternatively, if you think that Paket is a positive addition to the suite of .NET tools, and promotes a healthy .NET ecosystem that’s run with the community at the front of the pack, don’t just say so. Allow it to flourish. Don’t hold it back. Don’t pay the problem lip service by simply suggesting in public that you’re supportive of it whilst privately passively sitting by, or actively blocking anything which might see Paket grow. That’d only be delaying another incident like this occurring somewhere further down the line.

Summing Up

What started as a genuinely innocent attempt to simply improve the NuGet Gallery site (and make life a tiny bit easier for Paket users) has turned into a question about Microsoft’s commitment to open source, and their relationship with the community.

  • Microsoft, are .NET developers part of the community that have a say in the direction of .NET? If so, then your community is giving you a message, loud and clear.
  • Alternatively, are .NET developers part of your customer base? If so, your customers are giving you a message, loud and clear.

This is a great opportunity for you to respond in a positive manner, and silence cynics that say that Microsoft aren’t committed to open source. It’s also not a zero-sum game – Paket growing is not a negative for NuGet, nor is it a bad thing for .NET in general.

We’re all looking forward to hearing back from you.

3 thoughts on “Some words on #nugate

Leave a comment