Should I create a single Power Toys for Visual Studio CodePlex project?

  • Article

As I prep for my EE talk, I find myself wondering what I would have done differently a year ago.  Looking at the huge success of the Ajax Control Toolkit, I wonder if I should have had one “Power Toys for Visual Studio” project on CodePlex, where all the power toys (as possible) fit into the collection.  Then, I could have opened up both the individual power toys and the overall collection itself up for contributions.

The thinking last year was to build the community around the individual power toys.  Well after we had released our first wave, I started thinking about building the overall community as a collection of power toys.  Shawn’s feedback (who runs the toolkit) to me has always been “where’s your critical mass?”  I thought I could build the community and the critical mass on the Power Toys Homepage as an eagle eye onto CodePlex, but maybe I was wrong or didn’t try hard enough.

Which brings us to the title of this blog entry.  We’ve just shipped Orcas Beta 1.  So, here I am again, looking at the lessons learned from the Whidbey Power Toys, trying to plan ahead for Orcas.

Question for the Power Toy Community

If we were to combine all of these power toys, what buckets should they fall into? Or should we leave well enough alone.

My knee-jerk reaction was to bucket based on which Visual Studio version they target.  Then I started realizing this should be a job for the pack installer to sort it all out.  And, tools are going to grow organically on their own, so it would defeat the entire purpose of codeplex to port these tools to a new codeplex project based on VS versioning (not that we would do this intentionally, but if I separated based on versioning, I would be “retrospectively” doing this, if that makes sense.)

Something else to call out is that the baseline commonality between all these tools (besides us writing them) is that they were picked and implemented based on customer suggestions. In other words, these are all after-market solutions for Visual Studio 2005.

Here are the options I’m considering:

Do nothing. Our current set of power toys are scattered across technologies, including what they target (MSBuild, TFS, VS IDE, ASP.NET, etc) and how they are built (stand-alone exes, add-ins, packages). The only way I could bucket all of them together is as a “Power Toy Solutions for Visual Studio 2005.”

Throw them all together into a single “Power Toy Solutions for Visual Studio 2005” Bucket, including the VS 2003 power toys migrated from GotDotNet.  Each power toy will have its own release in the CodePlex project.  We’ll utilize the pack installer as the primary means for downloading the power toys. 

Bucket based on targeted technology. All MSBuild open source power toys go into a MSBuild CodePlex Project.  All TFS open source power toys go into their own TFS bucket, and so forth.  Even if we don’t have enough power toys right now for this, consider it planning for any potential Orcas power toys. Then if we need to port a power toy to Orcas, the codebase stays within the same overall codeplex project.

Bucket only the ones that make sense to bucket – have all the power toys that target the VS IDE together in one bucket, and leave the rest as is. For example, we would have Breakpoint Manager, Resource Refactoring, VSCmdShell, and MSBee. Maybe even Managed Stack Explorer.

After having thought about this for weeks now, I favor option #4.  It builds a community around the technology, and allows these power toys to get updated to Orcas as needed. And it also allows for us to leave well enough alone.

Combined Power Toy Collection Mockup

Prototype Power Toy Homepage showing each Power Toy Image and Description

CodePlex Project Design

Homepage

  • Represents a quick overview of each project
  • Includes all the other content, like download, building, running, etc here
  • Includes a “Incubation Idea Wiki” based off of work items where people can vote, and discussion boards where people can discuss

Discussions (same model for work item tracking)

  • Each power toy represented in the collection will have its own discussion board. Only one discussion board per project
  • There’s a general discussion board for things not related to the design or usage of a power toy

Releases

  • Pack Installer is used as the download mechanism for getting all power toys, in lieu of a zip or global MSI
  • Each release will be available separately as its own release in the release tab

Source Code

  • We’ll have two branches – Incubation and Release. All projects start in incubation and when they hit “a certain level of quality”, we’ll branch to release.
  • All power toys will use a single settings.targets file for including any test and build tools.
  • We’ll merge back to incubation if someone wishes to experiment with an existing power toys as a new project. My current thinking is that this will be rare, as development should continue in the Release branch.

What to do about Orcas Power Toys?

It’s a tough question, but really, should it be? Given what I’ve learned in the past, what’s my recommendation to teams moving forward? Honestly, there isn’t a simple answer. In my perfect world, I would want each product group to have its own set of power toys that they build and allow for customers to add tools to the collection (just like the Ajax Control Toolkit model). Our team would contribute to these projects, rather than creating projects ourselves. Additionally, if a product group had a really cool idea, like a sunset technology or a toolkit collection, they would take it to the open separately from the existing power toys. But that’s just my current thinking and need to shop this around internally to get feedback.