The Truth about NuGet and its Future

open source, nuget, community, code 0 comments suggest edit

In my last post, I talked about the MonkeySpace conference conference and how it reflects positive trends in the future of open source in .NET. But getting to a better future is going to take some work on our part. And a key component of that is making NuGet better.

Several discussions at MonkeySpace made it clear to me that there is some pervasive confusion and misconceptions about NuGet. It also made it clear that there are some dramatic changes needed for NuGet to continue to grow into a great open source project. In this post, I’ll cover some of these misconceptions and draw an outline of what I hope to see NuGet grow into.

Myth: NuGet is tied to Visual Studio and Windows

This is only partially true. The most popular NuGet client is clearly the one that ships in Visual Studio. Also, NuGet packages may contain PowerShell scripts. PowerShell is not currently available on any other operating system other than Windows.

However, the architecture of NuGet is such that there’s a core assembly, NuGet.Core.dll, that has no specific ties to Visual Studio. The proof of this is in the fact that ASP.NET Web Pages and Web Matrix both have NuGet clients. In these cases, the PowerShell scripts are ignored. Most packages do not contain PowerShell scripts, and those that do, the changes the scripts make are often optional or easily done manually.

In fact, there’s a NuGet.exe which is a wrapper of NuGet.Core.dll that runs on Mono. Well sometimes it does; and this is where we need your help! So far, Mono support for NuGet.exe has been low priority for the NuGet team. But as I see the growth of Mono, I think this is something we want to improve. My co-worker, Drew Miller (also a former member of the NuGet and ASP.NET MVC team) is keen to make better Mono support a reality. Initially, it could be as simple as adding a Mono CI server to make sure NuGet.exe builds and runs on Mono. Ultimately, we would like to build a MonoDevelop plugin.

Initially, it will probably simply ignore PowerShell scripts. There’s an existing CodePlex work item to provide .NET equivalents to Install.ps1 and the other scripts.

I created a personal fork of the NuGet project under my GitHub account at This’ll be our playground for experimenting with these new features with the clear goal of getting these changes back into the official NuGet repository.

Myth: NuGet isn’t truly Open Source

This is an easy myth to dispel. Here’s the license file for NuGet. NuGet is licensed under the Apache version 2 license, and meets the Open Source Definition defined by the Open Source Initiative. The NuGet team accepts external contributions as well, so it’s not just open source, but it’s an open and collaborative project.

But maybe it’s not as collaborative as it could be. I’ll address that in a moment.

Myth: NuGet is a Microsoft Project

On paper, NuGet is a fully independent project of the Outercurve Foundation. If you look at the COPYRIGHT.txt file in the NuGet source tree, you’ll see this:

Copyright 2010 Outercurve Foundation

Which makes me realize, we need to update that file with the current year, but I digress! That’s right, Microsoft assigned the copyright over to the Outercurve foundation. Contributors are asked to assign copyright for their contribution to the foundation as well. So clearly this is not a Microsoft project, right?

Well if you look at the entry in the Visual Studio Extension Manager (or the gallery), you’ll see this:


Huh? What gives? Well, it’s time for some REAL TALK™.

There’s nothing shady going on here. In the same way that Google Chrome is a Google product with its own EULA that incorporates the open source Chromium project, and Safari is an Apple product with its own EULA that incorporates the open source WebKit project, the version of NuGet included in Visual Studio 2012 is officially named the NuGet-Based Microsoft Package Manager and is a Microsoft product with its own EULA that incorporates the open source NuGet project. This is a common practice among companies well known for shipping “open source” and all complies with the terms of the license. You are always free to build and install the Outercurve version of NuGet into Visual Studio should you choose.

Of course, unlike the other two examples, NuGet is a bit confusing because both the proprietary version and the open source version contain the word “NuGet.” This is because we liked the name so much and because it had established its identity that we felt not including “NuGet” in the name of the Microsoft product would cause even more confusion. I almost wish we had named the open source version “NuGetium” following the Chromium/Chrome example.

This explains why NuGet is included in the Visual Studio Express editions when it’s well known that third party extensions are not allowed. It’s because NuGet is not included, it’s NuGet-Based Microsoft Package Manager that’s included.

NuGet is not a Community Project

Ok, this claim is a toss-up. As I pointed out before, NuGet is truly an open source project that accepts external community contributions. But is it really a “community project”

As the originator of the project, the sole provider of full time contributors, and a huge benefactor of the Outercurve Foundation; Microsoft clearly wields enormous influence on the NuGet project. Also, more and more parts of Microsoft are realizing the enormous potential of NuGet and getting on board with shipping packages. NuGet is integrated into Visual Studio 2012. These are all great developments! But it also means lessens the incentive for Microsoft to give up any control of the project to the community at large.

So while I still maintain it is a community project, in its current state the community’s influence is marginalized. But this isn’t entirely Microsoft’s intention or fault. Some of it has to do with the lack of outside contributors. Especially from those who have built products and even businesses on top of NuGet.

My Role With NuGet

Before I talk about what I hope to see in NuGet’s future, let me give you a brief rundown of my role. From the Outercurve perspective, I’m still the project lead of NuGet, the open source project. Microsoft of course has a developer lead, Jeff Handley, and a Program Manager, Howard Dierking, who run the day to day operations of NuGet and manage Microsoft’s extensive contributions to NuGet.

Of course, since NuGet is no longer a large part of my day job, it’s been challenging to stay involved. I recently met with Howard and Jeff to figure out how my role fits in with theirs and we all agreed that I should stay involved, but focus on the high level aspects of the project. So while they run the day to day operations such as triage, feature planning, code reviews, etc. I’ll still be involved in the direction of NuGet as an independent open source project. I recently sat in on the feature review for the next couple of versions of NuGet and will periodically visit my old stomping grounds for these product reviews.

The Future of NuGet

Over time, I would like to see NuGet grow into a true community driven project. This will require buy-in from Microsoft at many levels as well as participation from the NuGet community.

In this regard, I think the governance model of the Orchard Project is a great example of the direction that NuGet could head in. In September of 2011, Microsoft transferred control of the Orchard project to the community. As Bertrand Le Roy writes:

Back in September, we did something with Orchard that is kind of a big deal: we transferred control over the Orchard project to the community.

Most Open Source projects that were initiated by corporations such as Microsoft are nowadays still governed by that corporation. They may have an open license, they may take patches and contributions, they may have given the copyright to some non-profit foundation, but for all practical purposes, it’s still that corporation that controls the project and makes the big decisions.

That wasn’t what we wanted for Orchard. We wanted to trust the community completely to do what’s best for the project.

Why didn’t NuGet follow this model already? It’s complicated.

With something so integrated into so many of areas of Microsoft now, I think this is a pretty bold step for Microsoft to take. It’ll take time to reach this goal and it’ll take us, the community, demonstrating to Microsoft and others who are invested in NuGet’s future that we’re fit and ready to take on this responsibility.

As part of that, I would love to see more corporate sponsors of NuGet supplying contributors. Especially those that profit from NuGet. For example, while GitHub doesn’t directly profit from NuGet, we feel anything that encourages open source is valuable to us. So Drew and I will spend some of our time on NuGet in the upcoming months. The reason I don’t spend more time on NuGet today is really a personal choice and prioritization, not because I’m not given work time to do it since I pretty much define my own schedule.

If you are a company that benefits from NuGet, consider allotting time for some of your developers to contribute back (or become a sponsor of the Outercurve Foundation). Consider it an investment in having more of a say in the future of NuGet should Microsoft transfer control over to the community. NuGet belongs to us all, but we have to do our part to own it.

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.



21 responses

  1. Avatar for Phil Patterson
    Phil Patterson October 23rd, 2012

    So if I wanted to go about implementing a client that can access the NuGet repository from a .NET 3.5 machine only, what would be the correct way to try to get this accomplished? Is it as easy as creating a work item in Codeplex, forking the repository on Github, and submitting a pull request when/if we the community can get it working (assuming I'm not the only person that wants/needs this functionality)?
    The only way I see to do this today is to download from a machine with visual studio 2010 and .NET 4 and to move the retrieved dlls to the machine in question.

  2. Avatar for haacked
    haacked October 23rd, 2012

    Hi Phil. I'd look to see if there's any existing issues related to this in CodePlex to see if others have interest in this.
    NuGet takes advantage of a lot of .NET 4 features and it'd be a lot of work to backport it and maintain both ports. So I don't anticipate the NuGet team wanting to pull that back into NuGet. But you can always maintain your own fork either on CodePlex or GitHub.

  3. Avatar for Steve
    Steve October 23rd, 2012

    I agree packages are crucial point for Mono to be what it can be.
    I think a CI can be important to some but wanting to pull from Git more I'm going to be poking around for some additional tools for reducing the friction to getting a Mono runtime up and running. I mean there are a lot of Chef recipes for non-.Net solutions on Git and while NPM might not do everything expressJS is pretty easy to get going out of the box. I think projects more like Chocolaty can really help encourage people to pull .Net from Git and use Mono.

  4. Avatar for John Watson
    John Watson October 23rd, 2012

    Phil, I have been championing adoption of NuGet at my company not only from a "consumption" point of view but also as an integral part of our packaging and internal deployment. Corporate development shops like mine *need* to be able to stand up internal repositories for internal-only use. Efforts by you, David Ebbo and others are awesome but the whole server-side aspect needs lots of attention to become as frictionless as, say Apache or Maven.

  5. Avatar for Slavo Ingilizov
    Slavo Ingilizov October 24th, 2012

    So is the home of the open-source project, right? Why then does the download link lead to the Microsoft VS plugin that incorporates the open-source project, rather than directly to the open-source one?

  6. Avatar for haacked
    haacked October 24th, 2012

    @Slavo: We should probably link to both. The VS plugin and the CodePlex page.
    The official VS plugin is simply the best way to experience the product. Trying to run the OSS version is a headache. For example, now that the VS one is built into VS 2012, you'd have to uninstall it to install one you built yourself. Also, the one shipped by Microsoft works in Visual Studio Express SKUs. The open source one cannot do that.

  7. Avatar for Steffen Forkmann
    Steffen Forkmann October 24th, 2012

    from : "Download and install the Visual Studio 2010 SDK"
    If I need to install the VS SDK in order to build nuget then I think it's fair to say "NuGet is tied to Visual Studio".

  8. Avatar for haacked
    haacked October 24th, 2012

    @Steffen: You only need that if you want to build the Visual Studio plugin. You don't need it to build NuGet.Core.dll and NuGet.exe.

  9. Avatar for Steffen Forkmann
    Steffen Forkmann October 24th, 2012

    Thanks Phil for this clarification. Maybe this should be clarified in the docs as well.

  10. Avatar for Chris Eldredge
    Chris Eldredge October 24th, 2012

    @John Watson: It seems like the vast majority of NuGet users are package consumers and only a small number of us are using it internally to produce and consume packages of non-public software. For those who want private feeds, TeamCity and seem to be the most commonly used.
    I've been working on a fork of NuGet.Server that I think performs really well even with 10,000 or more packages. You can get a zip of my fork from

  11. Avatar for Jonny Bekkum
    Jonny Bekkum October 25th, 2012

    You mentioned ASP.NET Web Pages and Web Matrix as examples for apps that have NuGet clients. I'd like to add that also SharpDevelop has builtin NuGet client and LinqPad Premium (licensed) also support NuGet
    For LINQPad 4.x Premium users, LINQPad is now NuGetPad! Just press F4 and click Add NuGet to download and reference any NuGet package. LINQPad automatically resolves dependencies and includes a dialog for importing namespaces from a list.

  12. Avatar for Maarten Balliauw
    Maarten Balliauw October 31st, 2012

    The MyGet team would love to join an advisory board of some kind. Feel free to reach out.

  13. Avatar for Steve
    Steve October 31st, 2012

    Lots of popularity in the java community...
    I've been working on an event sourcing system. Maybe a tie in with server deployment (including roll backs). Anyone have ideas what type of scripting environment would be a good match for a mono environment?

  14. Avatar for Raif
    Raif November 8th, 2012

    Please tell me how can I NOT use nuget. I just started a new projected and find that nuget is literally SHOVED DOWN MY THROAT! I think nuget is great, and when I'm ready to hand over control I will, but right now I have no choice about it at all as far as I can see.
    I just want to use my own library of dlls. I've been getting along fine for years like this. Sure, maybe I'm "resistant to change" but hell there are still people writing webforms with 1000 lines in a method in the code behind. Maybe Visual Studio should stop compiling those. In fact I think that would be great. I'll use nuget if VS stops compiling crappy code. how's that?

  15. Avatar for Daniel Lo Nigro
    Daniel Lo Nigro November 14th, 2012

    For an internal NuGet feed, MyGet looks good. What I did at my work place is set up an internal version of the NuGet gallery ( This was quite easy to set up and gives you all the features of the official site.

  16. Avatar for Rob
    Rob December 3rd, 2012

    Where do I "like" comments? I second Maarten's comments about an advisory board.

  17. Avatar for nicolas
    nicolas December 25th, 2012

    BIG +1 for a Monodevelop nuget plugin !

  18. Avatar for joey
    joey January 15th, 2013

    you can always maintain your own fork either on CodePlex or GitHub.

  19. Avatar for Stephen Hammond
    Stephen Hammond January 25th, 2013

    hurrah mrward -

    might need some folks on other platforms 

  20. Avatar for Mike
    Mike August 24th, 2014

    Myth:this blogpost dispells myths about NuGet

    You need to think about a way to add subcommands to a project, and package that in a NuGet package, that is NOT dependent on Visual Studio to run init.ps1, and not dependent on PowerShell period.

    I think *.ps1 thing that was added over time to NuGet should be migrated to scanning a .dll in a special package-internal folder (maybe /env) for interface-implementing classes, like IInstallCommand and IPackageCommand etc. Only then can we truly believe that NuGet is not tied to PowerShell, and hence not a Windows-only package manager.

  21. Avatar for drew
    drew March 8th, 2015

    I work with some of the folks that Drew, Brad and Jim Newkirk used to work with over at MSDN. We use this style of organizing tests and I really like it. It provides an organized way to quickly find a set of tests I'm looking for. Its far too easy for a single test class to fill up with a hundred tests and then lose track of any kind of order. This organization strategy goes a long way to solve this.