October 2010 Blog Posts
The polls have closed and we now have a new name for our project, NuGet (pronounced “New Get” and not “Nugget” and not “Noojay” for you hoity-toity) which had the most votes by a large margin.
For those who missed it, the following posts will get you up to speed on the name change:
Over the next couple of days we’ll start transitioning the project over to the new name. We’ll try to minimize the impact of the change and make sure existing links to the CodePlex project redirect to the new URL. If you have a local clone of the repository with work in progress when we rename the project, don’t worry. All you have to do is push your changes to the new URL for your fork rather than the old one.
Thanks for your participation and support! I’m glad to have this behind us so we can continue to focus on delivering a great product. I’ve even thought of a tagline we can use until one of you come up with a much better one. 
NuGet: A new way to get libraries.
OR NuGet The caramel goodness of open source in your projects.
Just a quick follow-up to my last posts about naming NuPack. Looks like the community is not content to sit back and let the project be labelled with a lame name. I’ve seen a couple of community inspired names created as new issues in the CodePlex issue tracker.
However, NFetch has a huge lead, but the community chosen NRocks is a close second. The name I like the best so far is NuGet.
(vote for it here)
As before, voting still closes on Tuesday 10/26 at 11:59 PM PDT. If you feel strongly enough around a name, rally your friends to vote for one. 
There are only 2 hard problems in Computer Science. Naming things, cache invalidation and off-by-one errors.
I’m always impressed with the passion of the open source community and nothing brings it out more than a naming exercise. 
In my last blog post, I posted about our need to rename NuPack. Needless to say, I got a bit of angrypassionate feedback. There have been a lot of questions that keep coming up over and over again and I thought I would try and address the most common questions here.
Why not stay with the NuPack name? It was just fine!
In the original announcement, we pointed out that:
We want to avoid confusion with another software project that just happens to have the same name. This other project, NUPACK, is a software suite by a group of researchers at Caltech having to do with analysis and design of nucleic acid systems.
Now some of you may be thinking, “Why let that stop you? Many projects in different fields are fine sharing the same name. After all, you named a blog engine Subtext and there’s a Subtext programming language already.”
There’s a profound difference between Microsoft starting an open source project that accepts contributions and some nobody named Phil Haack starting a little blog engine project.
Most likely, the programming language project has never heard of Subtext and Subtext doesn’t garner enough attention for them to care.
As Paula Hunter points out in a comment on the Outercurve blog post:
Sometimes we are victims of our own success, and NuPack has generated so much buzz that it caught CalTech's attention. They have been using NuPack since 2007 and theoretically could assert their common law right of "first use" (and, they recently filed a TM application). Phil and the project team are doing the right thing in making the change now while the project is young. Did they have to? The answer is debatable, but they want to eliminate confusion and show respect to CalTech's project team.
Naming is tough, and you can't please everyone, but a year from now, most won't remember the old name. How many remember Mozilla "Firebird"?
Apparently, we’re in good company when it comes to open source projects that have had to pick a new name. It’s always a painful process. This time around, we’re following guidelines posted by Paula in a blog post entitled The Naming Game: Things to consider when naming an open source project which talks about this concept of “first use” Paul mentioned.
Why not go back to NPack?
There’s already a project on CodePlex with that name.
Why not name it NGem?
Honestly, I’d prefer not to use the N prefix. I know one of the choices we provided had it in the name, but it was one of the better names we could come up with. Also, I’d like to not simply appropriate a name associated with the Ruby community. I think that could cause confusion as well. I’d love to have a name that’s uniquely ours if possible.
Why not name it ****?
In the original announcement, we listed three criteria:
- Domain name available
- No other project/product with a name similar to ours in the same field
- No outstanding trademarks on the name that we could find
Domain name
The reason we wanted to make sure the domain name is available is that if it is, it’s less likely to be the name of an existing product or company. Not only that, we need a decent domain name to help market our project. This is one area where I think the community is telling us to be flexible. And I’m willing to consider being more flexible about this just as long as the name we choose won’t run afoul of the second criteria and we get a decent domain name that doesn’t cause confusion with other projects.
Product/Project With Similar Names
This one is a judgment call, but all it takes is a little time with Google/Bing to assess the risk here. There’s always going to be a risk that the name we pick will conflict with something out there. The point is not to eliminate risk but reduce it to a reasonable level. If you think of a name, try it out in a search engine and see what you find.
Trademarks
This one is tricky. Pretty much, if your search engine doesn’t pull up anything, it’s unlikely there is a trademark. Even so, it doesn’t hurt to put your search through the US Patent office’s Trademark Basic Word Mark Search and make sure it’s clean there. I’m not sure how comprehensive or accurate it is, but if it is there, you’re facing more risk than if it doesn’t show up.
I have a name that meets your criteria and is way better than the four options you gave us!
Ok, this is not exactly a question, but something I hear a lot. In the original blog post, we said the following:
Can I write in my own suggestion?
Unfortunately no. Again, we want to make sure we can secure the domains for our new project name, so we needed to start with a list that was actually attainable. If you really can’t bring yourself to pick even one, we won’t be offended if you abstain from voting. And don’t worry, the product will continue to function in the same way despite the name change.
However, I don’t want to be completely unreasonable and I think people have found a loophole. We’re conducting voting through our issue tracker and voting closes at 10/26 at 11:59 PM PDT. Our reasoning for not accepting suggestions was we wanted to avoid domain squatting. However, one creative individual created a bug to rename NuPack to a name for which they own the domain name and are willing to assign it over to the Outercurve foundation.
Right now, NFetch is way in the lead. But if some other name were to take the lead and meet all our criteria, I’d consider it. I reserve the right of veto power because I know one of you will put something obscene up there and somehow get a bajillion votes. Yeah, I have my eye on you Rob!
So where does that leave us?
We really don’t want to leave naming the project as an open ended process. So I think it’s good to set a deadline. On the morning of 10/27, for better or worse, you’ll wake up to a new name for the project.
Maybe you’ll hate it. Maybe you’ll love it. Maybe you’ll be ambivalent. Either way, over time, hopefully this mess will fade to a distant memory (much as Firebird has) and the name will start to fit in its new clothes.
As Paul Castle stated over Twitter:
@haacked to me the name is irrelevant the prouduct is ace
No matter what the name is, we’re still committed to delivering the best product we can with your help!
And no, we’re not going to name it:
UPDATE: The new name is NuGet
The NuPack project is undergoing a rename and we need your help! For details, read the announcement about the rename on the Outercurve Foundation’s blog.
What is the new name?
We don’t know. You tell us! The NuPack project team brainstormed a set of names and narrowed down the list to four names.
I’ve posted a set of names as issues in our NuPack CodePlex.com site and will ask you to vote for your favorite name among the lot. Vote for as many as you want, but realize that if you vote for all of them, you’ve just cancelled your vote. 
Here are the choices:
Voting will close at 10/26 at 11:59 PM.
Note: Everything I write here is based on a very early pre-release version of NuGet (formerly known as NuPack) and is subject to change.
A few weeks ago I wrote a blog post introducing the first preview, CTP 1, of NuGet Package Manager. It’s an open source (we welcome contributions!) developer focused package manager meant to make it easy to discover and make use of third party dependencies as well as keep them up to date.
As of CTP 2 NuGet by default points to an ODATA service temporarily located at http://go.microsoft.com/fwlink/?LinkID=204820 (in CTP 1 this was an ATOM feed located at http://go.microsoft.com/fwlink/?LinkID=199193).
This feed was set up so that people could try out NuGet, but it’s only temporary. We’ll have a more permanent gallery set up as we get closer to RTM.
If you want to get your package in the temporary feed, follow the instructions at a companion project, NuPackPackages on CodePlex.com.
Local Feeds
Some companies keep very tight control over which third party libraries their developers may use. They may not want their developers to point NuGet to arbitrary code over the internet. Or, they may have a set of proprietary libraries they want to make available for developers via NuGet.
NuGet supports these scenarios with a combination of two features:
- NuGet can point to any number of different feeds. You don’t have to point it to just our feed.
- NuGet can point to a local folder (or network share) that contains a set of packages.
For example, suppose I have a folder on my desktop named packages and drop in a couple of packages that I created like so:
I can add that director to the NuGet settings. To get to the settings, go to the Visual Studio Tools | Options dialog and scroll down to Package Manager.
A shortcut to get there is to go to the Add Package Dialog and click on the Settings button or click the button in the Package Manager Console next to the list of package sources. This brings up the Options dialog (click to see larger image).
Type in the path to your packages folder and then click the Add button. Your local directory is now added as another package feed source.
When you go back to the Package Manager Console, you can choose this new local package source and list the packages in that source.
%20(2)_thumb.png "MvcApplication7 - Microsoft Visual Studio (Administrator) (2)")
You can also install packages from your local directory. If you’re creating packages, this is a great way to test them out without having to publish them online anywhere.%20(4)_thumb.png "MvcApplication7 - Microsoft Visual Studio (Administrator) (4)")
Note that if you launch the Add Package Reference Dialog, you won’t see the local package feed unless you’ve made it the default package source. This limitation is only temporary as we’re changing the dialog to allow you to select the package source.
Now when you launch the Add Package Reference Dialog, you’ll see your local packages.
Please note, as of CTP 1, if one of these local packages has a dependency on a package in another registered feed, it won’t work. However, we are tracking this issue and plan to implement this feature in the next release.
Custom Read Only Feeds
Let’s suppose that what you really want to do is host a feed at an URL rather than a package folder. Perhaps you are known for your great taste in music and package selection and you want to host your own curated NuGet feed of the packages you think are great.
Well you can do that with NuGet. For step by step instructions, check out this follow-up blog post, Hosting a Simple “Read Only” NuGet Package Feed.
We imagine that the primary usage of NuGet will be to point it to our main online feed. But the flexibility of NuGet to allow for private local feeds as well as curated feeds should appeal to many.
In my last post, I described how we’re trying to improve and streamline contributor guidelines to make it easy for others to contribute to NuGet.
Like all product cycles anywhere, we’re always running on tight time constraints. This helps us to maintain a tight focus on the product. We don’t want to the product to do anything and everything. However, we do want to deliver everything needed (along with double rainbows and unicorns) to meet our vision for this first release.
The best to meet those goals is to get more contributions from outside the core team. And the best way to do that is to remove as many roadblocks as possible for those interested in contributing.
What’s Up For Grabs?!
When approaching a new project, it can be really challenging to even know what bugs to tackle. So much is happening so quickly and you don’t want to step on any toes.
So we’re trying an experiment where we mark issues in our bug tracker with the tag “UpForGrabs”. The idea here is that any item marked in such a way is something that none of the core team will work on if someone else will take it. Some of these are assigned to core team members, but we hope that someone externally will come along and start a discussion and say, “Yeah, I’ll handle that and provide a pull request with high quality code.”
That would so rock!
So how do you find out about our Up for Grabs items? It’s really easy.
- Visit our issue tracker.
- Search for “UpForGrabs” (sans quotes) as in the screenshot below.
Once you find an item you’d like to tackle, start a discussion and let everyone know. That’ll make sure that if anyone else has started on it, that you can work together or decide to choose something else.
Note that if the status is “Active”, it’s likely that someone has already started on it.
Another way to search for these items is to use the Advanced View on the issue tracker and add a filter with the word “UpForGrabs” and set the status to “Proposed”.
Improving CodePlex.com
This reminds me, it’d be really nice if I could create an URL that took you directly to this filtered view our issue tracker. That’s something I need to log with the CodePlex.com team.
In the meanwhile, we have a list of issues we’d love for you to vote up that would help us manage NuGet more effectively on CodePlex.com. 
A couple days ago I wrote a blog post entitled, Running Open Source In A Distributed World which outlined some thoughts I had about how managing core contributors to an open source project changes when you move from a centralized version control repository to distributed version control.
The post was really a way for me to probe for ideas on how best to handle feature contributions. In the post, I asked this question,
Many projects make a distinction between who may contribute a bug fix as opposed to who may contribute a feature. Such projects may require anyone contributing a feature or a non-trivial bug fix to sign a Contributor License Agreement. This agreement becomes the gate to being a contributor, which leaves me with the question, do we go through the process of getting this paperwork done for anyone who asks? Or do we have a bar to meet before we even consider this?
None other than Karl Fogel, whose book has served me well to this point, and whose book I was critiquing provided a great answer,
One simple way is, just get the agreement from each contributor the first time any change of theirs is approved for incorporation into the code. No matter whether it's a large feature or a small bugfix -- the contributor form is a small, one-time effort, so even for a tiny bugfix it's still worth it (on the theory that the person is likely to contribute again, and the cost of collecting the form is amortized over all the contributions that person ever makes anyway).
So simple I’ll smack myself every hour for a week for not thinking of it. 
Unfortunately, the process for accepting a contributor agreement is not yet fully automated (the Outercurve Foundation is working on it), so we won’t be doing this for small bug fixes. But we will do it for any feature contributions.
I’ve updated our guide to Contributing to NuGet based on this feedback. I welcome feedback on how we can improve the guide. I really want to make sure we can make it easy to contribute while still ensuring the integrity of the intellectual property. Thanks!
When it comes to running an open source project, the book Producing Open Source Software - How to Run a Successful Free Software Project by Karl Fogel (free pdf available) is my bible (see my review and summary of the book).
The book is based on Karl Fogel’s experiences as the leader of the Subversion project and has heavily influenced how I run the projects I’m involved in. Lately though, I’ve noticed one problem with some of his advice. It’s so Subversion-y.
Take a look at this snippet on Committers.
As the only formally distinct class of people found in all open source projects, committers deserve special attention here. Committers are an unavoidable concession to discrimination in a system which is otherwise as non-discriminatory as possible. But “discrimination” is not meant as a pejorative here. The function committers perform is utterly necessary, and I do not think a project could succeed without it.
A Committer in this sense is someone who has direct commit access to the source code repository. This makes sense in a world where your source control is completely centralized as it would be with a Subversion repository. But what about a world in which you’re using a completely decentralized version control like Git or Mercurial? What does it mean to be a “committer” when anyone can clone the repository, commit to their local copy, and then send a pull request?
In the book, Mercurial: The Definitive Guide, Bryan O’Sullivan discusses different collaboration models. The one the Linux kernel uses for example is such that Linus Torvalds maintains the “master” repository and only pulls from his “trusted lieutenants”.
At first glance, it might seem reasonable that a project could allow anyone to send a pull request to main and thus focus the “discrimination”, that Karl mentions, on the technical merits of each pull request rather than the history of a person’s involvement in the project.
One one level, that seems even more merit based egalitarian, but you start to wonder if that is scalable. Based on the Linux kernel model, it clearly is not scalable. As Karl points out,
Quality control requires, well, control. There are always many people who feel competent to make changes to a program, and some smaller number who actually are. The project cannot rely on people’s own judgement; it must impose standards and grant commit access only to those who meet them.
Many projects make a distinction between who may contribute a bug fix as opposed to who may contribute a feature. Such projects may require anyone contributing a feature or a non-trivial bug fix to sign a Contributor License Agreement. This agreement becomes the gate to being a contributor, which leaves me with the question, do we go through the process of getting this paperwork done for anyone who asks? Or do we have a bar to meet before we even consider this?
On one hand, if someone has a great feature idea, wouldn’t it be nice if we could just pull in their work without making them jump through hoops? On the other hand, if we have a hundred people go through this paperwork process, but only one actually ends up contributing anything, what a waste of our time. I would love to hear your thoughts on this.
NuGet, a package manager project I work on is currently following the latter approach as described in our guide to becoming a core contributor, but we’re open to refinements and improvements. I should point out that a hosted Mercurial solution does support the centralized committer model where we provide direct commit access. It just so happens that while some developers in the NuGet project have direct commit access, most don’t and shouldn’t make use of it per project policy as we’re still following a distributed model. We’re not letting the technical abilities/limitations of our source control system or project hosting define our collaboration model.
I know I’m late to the game when it comes to distributed source control, but it’s really striking to me how it’s turned the concept of committers on its head. In the centralized source control world, being a contributor was enforced via a technical gate, either you had commit access or you didn’t. With distributed version control it’s become more a matter of social contract and project policies.
UPDATE: This post is a out of date. We recently released the Release Candidate for ASP.NET MVC 3.
Wow! It’s been a busy two months and change since we released Preview 1 of ASP.NET MVC 3. Today I’m happy (and frankly, relieved) to announce the Beta release of ASP.NET MVC 3. Be sure to read Scott Guthrie’s announcement as well.
Credits: Image from ICanHazCheezburger http://icanhascheezburger.com/tag/onward/
Yes, you heard me right, we’re jumping straight to Beta with this release! To try it out…
As always, be sure to read the release notes (also available as a Word doc if you prefer that sort of thing) for all the juicy details about what’s new in ASP.NET MVC 3.
A big part of this release focuses on polishing and improving features started in Preview 1. We’ve made a lot of improvements (and changes) to our support for Dependency Injection allowing you to control how ASP.NET MVC creates your controllers and views as well as services that it needs.
One big change in this release is that client validation now is built on top of jQuery Validation in an unobtrusive manner. In ASP.NET MVC 3, jQuery Validation is the default client validation script. It’s pretty slick so give it a try and let us know what you think.
Likewise, our Ajax features such as the Ajax.ActionLink etc. are now built on top of jQuery. There’s a way to switch back to the old behavior if you need to, but moving forward, we’ll be leveraging jQuery for this sort of thing.
Where’s the Razor Syntax Highlighting and Intellisense?
This is probably a good point to stop and provide a little bit of bad news. One of the most frequently asked questions I hear is when are we going to get syntax highlighting? Unfortunately, it’s not yet ready for this release, but the Razor editor team is hard at work on it and we will see it in a future release.
I know it’s a bummer (believe me, I’m bummed about it) but I think it’ll make it that much sweeter when the feature arrives and you get to try it out the first time! See, I’m always looking for that silver lining. ;)
What’s this NuPack Thing?
That’s been the other major project I’ve been working on which has been keeping me very busy. I’ll be posting a follow-up blog post that talks about that.
What’s Next?
The plan is to have our next release be a Release Candidate. I’ve updated the Roadmap to provide an idea of some of the features that will be coming in the RC. For the most part, we try not to add too many features between Beta and RC preferring to focus on bug fixing and polish.
NuGet (recently renamed from NuPack) is a free open source developer focused package manager intent on simplifying the process of incorporating third party libraries into a .NET application during development.
After several months of work, the Outercurve Foundation (formerly CodePlex Foundation) today announced the acceptance of the NuGet project to the ASP.NET Open Source Gallery. This is another contribution to the foundation by the Web Platform and Tools (WPT) team at Microsoft.
Also be sure to read Scott Guthrie’s announcement post and Scott Hanselman’s NuGet walkthrough. There’s also a video interview with me on Web Camps TV where I talk about NuGet.
Just to warn you, the rest of this blog post is full of blah blah blah about NuGet so if you’re a person of action, feel free to go:
Now back to my blabbing. I have to tell you, I’m really excited to finally be able to talk about this in public as we’ve been incubating this for several months now. During that time, we collaborated with various influential members of the .NET open source community including the Nu team in order to gather feedback on delivering the right project.
What Does NuGet Solve?
The .NET open source community has churned out a huge catalog of useful libraries. But what has been lacking is a widely available easy to use manner of discovering and incorporating these libraries into a project.
Take ELMAH, for example. For the most part, this is a very simple library to use. Even so, it may take the following steps to get started:
- You first need to discover ELMAH somehow.
- The download page for ELMAH includes multiple zip files. You need to make sure you choose the correct one.
- After downloading the zip file, don’t forget to unblock it.
- If you’re really careful, you’ll verify the hash of the downloaded file against the hash provided by the download page.
- The package needs to be unzipped, typically into a lib folder within the solution.
- You’ll then add an assembly reference to the assembly from within the Visual Studio solution explorer.
- Finally, you need to figure out the correct configuration settings and apply them to the web.config file.
That’s a lot of steps for a simple library, and it doesn’t even take into account what you might do if the library itself depends on multiple other libraries.
NuGet automates all of these common and tedious tasks, allowing you to spend more time using the library than getting it set up in your project.
NuGet Guiding Principles
I remember several months ago, Hot on the heels of shipping ASP.NET MVC 2, I was in a meeting with Scott Guthrie (aka “The Gu”) reviewing plans for ASP.NET MVC 3 when he laid the gauntlet down and said it was time to ship a package manager for .NET developers. The truth was, it was long overdue.
I set about doing some research looking at existing package management systems on other platforms for inspiration such as Ruby Gems, Apt-Get, and Maven. Package Management is well trodden ground and we have a lot to learn from what’s come before.
After this research, I came up with a set of guiding principles for the design of NuGet that I felt specifically addressed the needs of .NET developers.
- Works with your source code. This is an important principle which serves to meet two goals: The changes that NuGet makes can be committed to source control and the changes that NuGet makes can be x-copy deployed. This allows you to install a set of packages and commit the changes so that when your co-worker gets latest, her development environment is in the same state as yours. This is why NuGet packages do not install assemblies into the GAC as that would make it difficult to meet these two goals. NuGet doesn’t touch anything outside of your solution folder. It doesn’t install programs onto your computer. It doesn’t install extensions into Visual studio. It leaves those tasks to other package managers such as the Visual Studio Extension manager and the Web Platform Installer.
- Works against a well known central feed. As part of this project, we plan to host a central feed that contains (or points to) NuGet packages. Package authors will be able to create an account and start adding packages to the feed. The NuGet client tools will know about this feed by default.
- No central approval process for adding packages. When you upload a package to the NuGet Package Gallery (which doesn’t exist yet), you won’t have to wait around for days or weeks waiting for someone to review it and approve it. Instead, we’ll rely on the community to moderate and police itself when it comes to the feed. This is in the spirit of how CodePlex.com and RubyGems.org work.
- Anyone can host a feed. While we will host a central feed, we wanted to make sure that anyone who wants to can also host a feed. I would imagine that some companies might want to host an internal feed of approved open source libraries, for example. Or you may want to host a feed containing your curated list of the best open source libraries. Who knows! The important part is that the NuGet tools are not hard-coded to a single feed but support pointing them to multiple feeds.
- Command Line and GUI based user interfaces. It was important to us to support the productivity of a command line based console interface. Thus NuGet ships with the PowerShell based Package Manager Console which I believe will appeal to power users. Likewise, NuGet also includes an easy to use GUI dialog for adding packages.
NuGet’s Primary Goal
In my mind, the primary goal of NuGet is to help foster a vibrant open source community on the .NET platform by providing a means for .NET developers to easily share and make use of open source libraries.
As an open source developer myself, this goal is something that is near and dear to my heart. It also reflects the evolution of open source in DevDiv (the division I work in) as this is a product that will ship with other Microsoft products, but also accepts contributions. Given the primary goal that I stated, it only makes sense that NuGet itself would be released as a truly open source product.
There’s one feature in particular I want to call out that’s particularly helpful to me as an open source developer. I run an open source blog engine called Subtext that makes use of around ten to fifteen other open source libraries. Before every release, I go through the painful process of looking at each of these libraries looking for new updates and incorporating them into our codebase.
With NuGet, this is one simple command: List-Package –updates. The dialog also displays which packages have updates available. Nice!
And keep in mind, while the focus is on open source, NuGet works just fine with any kind of package. So you can create a network share at work, put all your internal packages in there, and tell your co-workers to point NuGet to that directory. No need to set up a NuGet server.
Get Involved!
So in the fashion of all true open source projects, this is the part where I beg for your help. ;)
It is still early in the development cycle for NuGet. For example, the Add Package Dialog is really just a prototype intended to be rewritten from scratch. We kept it in the codebase so people can try out the user interface workflow and provide feedback.
We have yet to release our first official preview (though it’s coming soon). What we have today is closer in spirit to a nightly build (we’re working on getting a Continuous Integration (CI) server in place).
So go over to the NuGet website on CodePlex and check out our guide to contributing to NuGet. I’ve been working hard to try and get documentation in place, but I could sure use some help.
With your help, I hope that NuGet becomes a wildly successful example of how building products in collaboration with the open source community benefits our business and the community.