Package Namespace Reservations

Topics: General
Oct 16, 2014 at 10:58 PM
Edited Oct 16, 2014 at 11:37 PM
Microsoft teams have asked NuGet dozens of times to implement "package namespace reservations" on nuget.org. The desire has been for Microsoft Corporation to be the only ones who can publish packages with package id starting with Microsoft.

We've repeatedly said "no" to this request, but it's come back up again. Before we say "no" again, we wanted to ask the community what your thoughts are on the matter.

I informally asked about this on Twitter a while back and even included a twtpoll. The results of the poll were about 85% in favor of reservations, but with the caveat that any company should be able to create a reservation.

Obviously, if we were to create a reservation system, there will be ongoing maintenance of such a system.
  1. What are the rules for when you can or cannot make a reservation?
  2. Would the system allow for exceptions?
  3. What would you do for existing conflicts?
So, we ask you two questions:
  1. Do you agree that Microsoft should be the only ones permitted to publish Microsoft. (and maybe System.) packages?
  2. What are your quick thoughts on how we'd implement the reservation system?
Oct 16, 2014 at 11:32 PM
Do you agree that Microsoft should be the only ones permitted to publish Microsoft. and System. packages?

I have no real issues with this. For historical reasons, those namespaces are very much associated with Microsoft The Company. One could argue about System.* being agnostic of organizations - what about Mono? should they be allowed to contribute packages in this namespace?

What are your quick thoughts on how we'd implement the reservation system?

Perhaps a process not unlike patent approval, where a group (internal or external or a mixture of representatives) reviews applications for namespaces - these should outline why they desire a namespace - and permits a window of opportunity for the public to raise objections that might invalidate the application (say, squatting or questionable relevance).
Developer
Oct 16, 2014 at 11:42 PM
Edited Oct 16, 2014 at 11:43 PM
I don't think Microsoft would own the System.* namespace moving forward. Rather, the .NET Foundation would. In the beginning, this would effectively be same as we're the founding fathers of the .NET Foundation. However, eventually others, such as Xamarin would join us. The key would be that System.* is reserved for agreed upon components that represent the .NET platform itself, rather than extensions on top.
Oct 17, 2014 at 2:37 AM
Edited Oct 17, 2014 at 2:38 AM
Why? Are they worried about fake/trick/dangerous packages and copyright issues?

Then how about implementing a "verified" status like Twitter instead? Sort verified packages to the top of search results. Show an obvious check mark with a tooltip stating "Official Package by [Company X]".
Developer
Oct 17, 2014 at 2:51 AM
The concern is around us being blocked to upload a package whose ID is already taken. In some cases, there simply isn't a meaningful alternative. Recent examples include System.Collections.Immutable and System.Threading.Tasks.
Oct 17, 2014 at 3:32 AM
Ah, that makes sense. How did you end up getting the "System.Collections.Immutable" ID anyway? It appears to be yours now, though the other ID isn't.

I find it amazing that some people have the nerve to grab package IDs like those anyway. I'm sure that it does trick some people into thinking that the packages are official MS products. Shame on them.

A package ID reservation feature seems like it could be more trouble than it's worth though. Is a package's ID really all that important? After all, packages have a friendly display title anyway (shown in the GUI) and they're presumably searchable. In the shell environment, I doubt people would be able to guess the package ID anyway even if it's simply a namespace, thus defeating the purpose of any notion of "friendly or hackable IDs". I mean, if people are going to have to look up package IDs anyway, then what does it really matter if it's "Microsoft.Widgets" or something else like "Microsoft.Widgets-Official" or "GoodPackageIdTaken.Microsoft.Widgets"?
Oct 17, 2014 at 12:34 PM
Do you agree that Microsoft should be the only ones permitted to publish Microsoft. and System. packages?

Sounds fine to me for Microsoft.*, but System.* packages should be owned by the .NET Foundation like @terrajobst said.

What are your quick thoughts on how we'd implement the reservation system?

First come, first served. If a user reserves a namespace that he/she is not entitled to (whatever the criteria are) then it can be handled like the existing "report abuse" system, i.e. by contacting NuGet.org.

Or maybe couple it to the user account? The Microsoft account owns all the packages starting with Microsoft.*, so you could block other users from uploading packages starting with an ID that matches with an existing account.
Developer
Oct 17, 2014 at 4:28 PM
First come, first served. If a user reserves a namespace that he/she is not entitled to (whatever the criteria are) then it can be handled like the existing "report abuse" system, i.e. by contacting NuGet.org.
Besides the problem that it causes fire drills on both our side, as well the owner's side, it also punishes the customers who use a package whose owner made a questionable naming decision. We'd rather create a system that avoids this problem by construction.
Or maybe couple it to the user account? The Microsoft account owns all the packages starting with Microsoft.*, so you could block other users from uploading packages starting with an ID that matches with an existing account.
I don't think we want a user called "system". I think having a user named "dotnetframework" or "dotnet" makes a lot more sense. Besides, I'm not sure this works in cases where a package has multiple owners.
Oct 17, 2014 at 4:42 PM
I don't think we want a user called "system".
Well, I agree system is a bit of an edge-case here, it works much better for Microsoft.*, Xamarin.*, Telerik.*, etc.
Besides, I'm not sure this works in cases where a package has multiple owners.
As long as you're one of the owners along with the one that matches the first part of the package ID you're trying to upload, I don't see why this wouldn't work, but maybe I'm missing something here ;-)
Developer
Oct 17, 2014 at 4:43 PM
Edited Oct 17, 2014 at 4:47 PM
Ah, that makes sense. How did you end up getting the "System.Collections.Immutable" ID anyway? It appears to be yours now, though the other ID isn't.
We've talked with the current owner. Turns out that this package was uploaded by mistake, so it was already unlisted. The intended name was System.Collections.Immutable.Net40. This name still isn't ideal, but it doesn't conflict with our packages. In other words, we were simply lucky that the current owner didn't use the 'good' name for production purposes.

For System.Threading.Tasks the story is a bit more complicated. I'll have a phone call later today with him to sort things out.

Just to be clear: we don't just take the names back, especially not when the package has thousands of downloads. We intend to work with the owners to find an acceptable solution. But that's a lot of work, and that's why we feel it would be better to prevent situations like this.
Is a package's ID really all that important?
Absolutely. Package IDs show up in many places, such as ASP.NET vNext's project.json file, it's recorded in packages.config file. It's also showing up in the UI now (e.g. in ASP.NET vNext's solution explorer).

Looking at the .NET Framework it really pains me that WPF isn't consistently named. After all, .NET's productivity is, to a large extent, a result of us being super obsessed with naming and consistency. So we feel quite strongly that naming is extremely important.
I doubt people would be able to guess the package ID anyway
That's why we've re-designed the factoring of the .NET packages. No more names like Microsoft.Bcl.Immutable. Instead, the name of the package will match the assembly name it contains. And yes, that means we're shooting for a 1:1 relationship between packages and assemblies. We plan to add meta-packages that allows grouping them together, similar to what xunit does.
Developer
Oct 17, 2014 at 4:46 PM
Edited Oct 17, 2014 at 4:46 PM
As long as you're one of the owners along with the one that matches the first part of the package ID
The problem is the initial upload, because that's where name checks are relevant. For subsequent uploads, any user that is an owner can upload a new version. The problem is that this model forces that the initial upload must be done by the account that represents the prefix, such as "Microsoft". At Microsoft that policy would create a significant bottleneck.
Oct 17, 2014 at 4:49 PM
The problem is that this model forces that the initial upload must be done by the account that represents the prefix, such as "Microsoft".
Ah, so the "Microsoft" account is literally a single user account with a single password? I assumed this was some sort of federated/meta-account that many Microsofties had access to. Yeah, my idea doesn't work well in that case :)
Oct 17, 2014 at 4:56 PM
Edited Oct 17, 2014 at 4:57 PM
Ok that makes sense. Based on my points and your other conversation, it seems the only logical solutions are either:
  1. Microsoft and perhaps a few other partner companies are given exclusive rights to use certain package ID prefixes. (I'm sure lots of people won't like this idea though.)
  2. {"#1"} and also any company or individual can request exclusive rights to use certain package ID prefixes and NuGet.org will review and grant them on a case-by-case basis.
It seems like there is no good way to automate this. Am I wrong?
Oct 17, 2014 at 6:24 PM
Ah, so the "Microsoft" account is literally a single user account with a single password?
It's a single user account, but it's backed by an email address that goes to a distribution list of the users who have been "granted" permission to the account. There's a small list of users behind the account. We then use secondary accounts that are backed by the teams that maintain the packages. The workflow is generally for the team accounts to publish the packages and then invite the 'microsoft' user to become a co-owner.

We would want to do what MyGet did, which is to allow multiple API keys per user account, and assign those API keys to other users and/or systems.
Developer
Oct 20, 2014 at 5:53 PM
Edited Oct 20, 2014 at 5:54 PM
We just resolved the package ID conflict with the owner of System.Threading.Tasks. Here is the solution we came up with jointly:
  1. We take ownership of a higher version but leave the existing versions there so that we don't break package restore for existing customers.
  2. The current owner uploads his binaries under the package name System.Threading.Tasks.Unofficial. The unofficial suffix makes sure that it groups nicely. In the future, NuGet could also add a feature that adds a UI indicator that says something along the lines of "This is an official package provided by the community".
So the proposal that davedev outlined could add an exception for packages that end with .Unofficial.

Thoughts?
Oct 20, 2014 at 6:21 PM
.Unofficial seems like a good compromise. Would that only be used for conflicts that arise from a new reservation/during transition? Or would I be able to upload a new package System.Threading.Tasks.MyMuchBetterTaskLibrary.Unofficial in the future even when MS owns the System. namespace?
Oct 21, 2014 at 12:37 AM
Edited Oct 21, 2014 at 12:40 AM
+1 Sounds fine to me. (Edit: CodePlex editor sucks. Should be "Plus 1")

I could even imagine using such a feature myself in the future; e.g., Rxx could be System.Reactive.Unofficial instead.

However, what about other devs who want to grab an "unofficial" name first? It just pushes back the problem to us "lesser" users :-)

So how about semname instead? It would be like semver but for naming; e.g., completely different projects could grab different semnames:
  • System.Threading.Tasks-Unofficial
  • System.Threading.Tasks-Extensions
  • System.Threading.Tasks-Contrib
  • System.Threading.Tasks-Experimental
  • System.Threading.Tasks-MoreStuff
Oct 21, 2014 at 12:40 AM
Edited Oct 21, 2014 at 12:40 AM
That looks pretty nice, @davedev!