One of the big new features in VS 2010 is the WPF based editor. With it, you can build all sorts of cool stuff like control the visualization of XML doc comments, change how intellisense looks, even scale the size of text based on the location of the caret. Huzzah for the WPF Visual Studio editor!

However, as wicked awesome as the new editor is, AFAIK it’s not going to be released as a separate component. So while the PowerShell, Intellipad and other teams inside Microsoft can reuse the VS editor bits, nobody else can. So if you want to do something like embed a colorizing REPL in your WPF app, you’ll have to use something else.

I’ve thought about putting a WPF based UI on top of ipydbg (though now I’d probably use the new lightweight debugger instead). So I downloaded John’s repl-lib code to see how he was doing it. Turns out his REPL control is essentially a wrapper around WPF’s RichTextBox control. It works, but it seems kinda kludgy. For example, the RichTextBox supports bold, italics and underline hotkeys, so John’s REPL does too. Though it is possible to turn off these formatting commands, I decided to take a look at modifying how the plain-old TextBox renders. After all, WPF controls are supposed to be lookless, right?

Well, apparently not all the WPF controls are lookless. In particular to this post, the TextBox is definitely NOT lookless. It looks like the text editing capabilities of TextBox are provided by the Sys.Win.Documents.TextEditor class while the text rendering is provided by the Sys.Win.Controls.TextBoxView class. Both of those classes are internal, so don’t even think about trying to customize or reuse them.

The best (and I use that term loosely) way I found for customizing the TextBox rendering was a couple of articles on CodeProject by Ken Johnson. Ken’s CodeBox control inherits from TextBox and sets the Foreground and Background to transparent (to hide the result of TextBoxView) and then overloads OnRender to render the text with colorization. Rendering the text twice – once transparently and once correctly – seems like a better solution than using the RichTextBox, but it’s still pretty kludgy. (Note, I’m calling the TextBox design kludgy – Ken’s code is a pretty good work around).

So if you want a colorized text box in WPF, your choices are:

• Build your own class that inherits from RichTextBox, disabling all the formatting commands and handling the TextChanged event to do colorization
• Build your own class that inherits from TextBox, but set Foreground an Background colors to transparent and overload OnRender to do the visible text rendering.
• Use a 3rd party control. The only one I found was the AqiStar TextBox. No idea how good it is, but they claim to be a true lookless control. Any other syntax highlighting WPF controls around that I don’t know about?

If you’ve compiled IronPython from source recently, you may have noticed a new DLL: Microsoft.Scripting.Debugging. This DLL contains a lightweight, non-blocking debugger for DLR based languages that is going to enable both new scenarios as well as better compatibility with CPython. Needless to say, we’re very excited about it.

When I was actively working on my ipydbg series, I got several emails asking about using it in an embedded scripting scenario. Unfortunately, the ipydbg approach doesn’t work very well in the embedded scripting scenario. ipydbg uses ICorDebug and friends, which completely blocks the application being debugged. This means, your debugger has to run in a separate process. So either you run your debugger in your host app process and your scripts in a separate process or you run your debugger in a separate process debugging both the scripts and the host app. Neither option is very appealing.

Now with the DLR Debugger, you can run all three components in the same process. I think of the DLR debugger as a “cooperative” debugger in much the same way that Windows 3.x supported cooperative multitasking. It’s also known as trace or traceback debugging. Code being debugged yields to the debugger at set points during its execution. The debugger then does whatever it wants, including showing UI and/or letting the developer inspect or modify program state. When the debugger returns, execution of the original code continues until the next set point wherein the process repeats itself.

The primary point of entry for the DLR Debugger is the DebugContext class. Notable there is the TransformLambda method, which takes a normal DLR LambdaExpression and transforms it into a cooperatively debugged LambdaExpression. LambdaExpressions can contain DebugInfoExpressions – typically we insert them at the start of every Python code line as well as one at the end of the function. When we run IronPython in debug mode (i.e. –D), those get turned into sequence points as we saw back when I was working on ipydbg. When using the DLR Debugger, those DebugInfoExpressions are transformed into calls out to IDebugCallback.OnDebugEvent. The DLR Debugger implements the IDebugCallback interface on the TracePipeline class which also implements ITracePipeline. In OnDebugEvent, TracePipeline calls out to an ITraceCallback instance you provide. The extra layer of indirection means you can change your traceback handler without having to regenerate the debuggable version of your functions.

Of course, we hide all this DLR Debugger goo from you in IronPython. Python already has a mechanism for doing traceback debugging – sys.settrace. Our ITraceCallback, PythonTracebackListener, wrapps the DLR Debugger API to expose the sys.settrace API. That makes this feature a twofer – new capability for IronPython + better compatibility with CPython. Instead of needing a custom tool (i.e. ipydbg) you can now use PDB from the standard Python library (modulo bugs in our implementation). I haven’t been working on ipydbg recently since you’ll be able to use PDB soon enough.

For those hosting IronPython, we also have a couple of static extension methods in our hosting API (look for the SetTrace functions in IronPython\Hosting\Python.cs). These are simply wrappers around sys.settrace, so it has the same API regardless if you access it from inside IronPython or from the hosting API. But if you’re hosting IronPython in a C# application, those extension methods are very convenient to use.

This debugger will be in our regular releases of IronPython as of 2.6 beta 2 which is scheduled to drop at the end of this month. For those who just can’t wait, it’s available as source code starting with yesterday’s changeset. Please let us know what you think!

I *LOVE* the new boot from VHD feature in Win7. I am primarily using it for doing some VS 2010 dogfooding without messing up my primary drive partition. But man, the process for setting up a VHD for booting is brutal. Scott Hanselman did a great job laying out the steps, but I wanted something a bit more productive.

First, I created a clean Win7 RC VHD and zipped it up for easy storage. The basic Win7 RC VHD is just under 5GB, but compresses down to about 1.5GB with 7-zip. I used the ImageX process Aviraj described though in the future I’ll use the Install-WindowsImage script. Install-WindowsImage is more convenient to use because it will list the indexes within a given .wim file instead of making you grovel thru an XML file like ImageX does. Also Install-WindowsImage is 27k download while ImageX is part of the 1.4 gigabyte Windows Automated Installation Kit. Look, I’m not hurting for bandwidth, but I don’t see the point of downloading 54442 times more data for a utility that isn’t as useful.

Once you’ve created the VHD, you need to update your Boot Configuration Data, or BCD for short, using the appropriately named BCDEdit utility. The process is fairly straight forward, if tedious. You have to run BCDEdit four times, copy the configuration GUID to the clipboard and type out the path to the VHD in a slightly funky syntax. Blech. So I built a PowerShell script to automate updating the BCD, called add-bcd-vhd. You can get it from my skydrive. Pass in the name of the BCD entry and the path to the VHD and add-bcd-vhd will do the rest.

I was whining on Twitter yesterday that there’s no PowerShell specific tools for managing the BCD data. Add-bcd-vhd just runs bcdedit behind the scenes and processes the text output with regular expressions. Ugly, but effective. I decided to spend some time trying accessing the BCD data from its WMI provider, but that turned out to be way too much of a hassle to be effective. If someone else out there knows how to use the BCD WMI provider from PowerShell, I’d appreciate some sample code.

In my last post, I added support for custom attribute positional parameters . To finish things off, I need to add support for named parameters as well. Custom attributes support named parameters for public fields and settable properties. It works kind of like C# 3.0’s object initalizers. However, unlike object initalizers, the specific fields and properties to be set on a custom attribute as well as their values are passed to the CustomAttributeBuilder constructor. With six arguments – five of which are arrays – it’s kind of an ugly constructor. But luckily, we can hide it away in the make_cab function by using Python’s keyword arguments feature.

You’ll notice that make_cab now takes a third parameter: the attribute type and the tuple of positional arguments we saw last post. This third parameter “**kwds” is a dictionary of named parameters. Python supports both positional and named parameter passing, like VB has for a while and C# will in 4.0. However, this **kwds parameter contains all the extra or leftover named parameters that were passed in but didn’t match any existing function arguments. Think of it like the params of named parameters.

As I wrote earlier, custom attributes support setting named values of both fields and properties. We don’t want the developer to have to know if given named parameter is a field or property, so make_cab iterates over all the named parameters, checking first to see if it’s a property then if it’s a field. It keeps a list of all the field / property infos as well as their associated values. Assuming all the named parameters are found, those lists are converted to tuples and passed into the CustomAttributeBuilder constructor.

In addition to the change to make_cab, I also updated cab_builder slightly in order to pass the **kwds parameter on thru to the make_cab function. No big deal. So now, I can add an attribute with named parameters to my IronPython class and it still looks a lot like a C# attribute specification.

As usual, sample code is up on my skydrive.

Now that I can support custom attributes on classes, it would be fairly straightforward to add them to methods, properties, etc as well. The hardest part at this point is coming up with a well designed API that works within the Python syntax. If you’ve got any opinions on that, feel free to share them in the comments, via email, or on the IronPython mailing list.

The basic infrastructure for custom attributes in IronPython is in place, but it’s woefully limited. Specifically, it only works for custom attributes that don’t have parameters. Of course, most of the custom attributes that you’d really want to use require additional parameters, both the positional or named variety. Since positional parameters are easier, let’s start with them.

Positional parameters get passed to the custom attribute’s constructor. As we saw in the previous post, you need a CustomAttributeBuilder to attach a custom attribute to an attribute target (like a class). Previously, I just needed to know the attribute type since I was hard coding the positional parameters. But now, I need to know both the attribute type as well as the desired positional parameters. I could have built a custom Python class to track this information, but it made much more sense just to use CustomAttributeBuilder instances. I built a utility function make_cab to construct the CustomAttributeBuilder instances.

In make_cab, I build a tuple of CLR types from the list of positional arguments that was passed in. If you haven’t seed the *args syntax before, it works like C#’s params keyword – any extra arguments are passed into the function as a tuple names args. I use Python’s built in map function (FP FTW!) to build a tuple of CLR types of the provided arguments, which I then pass to GetConstructor. Previously, I passed an empty tuple to GetConstructor because I wanted the default constructor. If you don’t pass any positional arguments, you still get the default constructor. Once I’ve found the right constructor, I pass it and the original tuple of arguments to the CustomAttributeBuilder constructor.

One major benefit of this approach is that it simplifies the metaclass code. Since _clrclassattribs is now a list of CustomAttributeBuilders, now I just need to iterate over that list and call SetCustomAttribute for each.

The only problem with this approach is that specifying the list of custom attributes is now extremely verbose. Not only am I specifying the full attribute class name as well as the positional arguments, I’m also having to insert a call to make_cab. Previously, it kinda looked like a C# custom attribute, albeit in the wrong place. Not anymore. So I decided to write a function called cab_builder to generates less verbose calls to make_cab:

The cab_builder function returns an anonymous lambda function that closes over the attrib_type variable. Python lambdas are just like C# lambdas, except that they only support expressions [1]. The results of calling the lambda returned from cab_builder is exactly the same as calling make_cab directly, but less verbose. And since I named the function returned from cab_builder Obsolete, now my list of class custom attributes looks exactly like it does in C# (though still in a different place). As usual, the code is up on my skydrive.

If you’re only using the attribute once like this, it is kind of annoying to first declare the cab_builder function. If you wanted to you could iterate over the types in a given assembly, looking for ones that inherit from Attribute and generate the cab_builder call dynamically. However, I’m not sure how performant that would be. Another possibility would be to iterate over the types in a given assembly and generate a Python module on disk with the calls to cab_builder. Then, you’d just have to import this module of common attributes but still be able to include additional calls to cab_builder as needed.

[1] The lack of statement lambdas in Python is one of my few issues with the language.

I know it’s been a while since my last __clrtype__ post, but I was blocked on some bug fixes that shipped as part of IronPython 2.6 Beta 1. So now let’s start looking at one of the most requested IronPython features – custom attributes!

Over the course of the next three blog posts, I’m going to build out a mechanism for specifying custom attributes on the CLR type we’re generating via __clrtype__. All the various Builder classes in System.Reflection.Emit support a SetCustomAttribute method that works basically the same way. There are two overloads – the one I’m going to use takes a single CustomAttributeBuilder as a parameter.

For this first post, I’m going to focus on the basic custom attribute infrastructure, so we’re going to use the extremely simple ObsoleteAttribute. While you can pass some arguments to the constructor, for this first post I’m going to use the parameterless constructor. To keep things less confusing, I’m going back to the original version of the Product class, before I introduced CLR fields and properties. The one change I’m making is that I’m adding a list of attributes I want to add to the class.

Python list comprehensions use the same square bracket syntax as C# properties, so it kinda looks right to someone with a C# eye – though having the attribute specifications inside the class, rather than above it, is totally different. I wish I could use Python’s class decorators for custom class attributes, but class decorators run after metaclasses so unfortunately that doesn’t work. Also, I can’t leave off the “Attribute” suffix like you can in C#. If I really wanted to, I could provide a new type name in the import statement (“from System import ObsoleteAttribute as Obsolete”) but I thought spelling it out was clearer for this post.

Now that I have specified the class attributes, I can update the metaclass __clrtype__ method to set the attribute on the generated CLR class:

I’m simply iterating over the list of _clrclassattribs (if it exists), getting the default parameterless constructor for each attribute type, creating a CustomAttributeBuilder instance from that constructor and then calling SetCustomAttribute. Of course, this is very simple because we’re not supporting any custom arguments or setting of named properties. We’ll get to that in the next post. In the mean time, you can get the full code for this post from my skydrive.

There is one significant issue with this custom attribute code. Attributes are typically marked with the AttributeUsage attribute that specifies a set of constraints, such as the kind of targets a given attribute can be attached to and if it can be specified multiple times. For example, the MTAThread attribute can’t be specified multiple times and it can only be attached to methods. However, those attribute constraints are validated by the compiler, not the runtime. I haven’t written any code yet to validate those constraints, so you can specify invalid combinations like multiple MTAThread attributes on a class. For now, I’m just going to leave it to the developer not to specify invalid attribute combinations. Custom attributes are passive anyway so I’m figure no one will come looking for a MTAThread attribute on a class or other such scenarios.

However, I’m interested in your opinion: When we get to actually productizing a higher-level API for __clrtype__, what kinds of attribute validation should we do, if any?

Today was the Presentation Idol competition I blogged about a couple of weeks ago. Unfortunately, I didn’t win - but believe me when I say I was up against some serious competition. I think I was about in the middle of the pack – better than some but clearly not as good as others.

Since I made a big deal about asking for people ideas on how to present my topic of choice – external contributions to Microsoft Open Source projects – I decided I’d post my deck and my script. Yes, I said script. Usually, I don’t script what I’m going to say word for word like this. But with only three and a half minutes to present, I thought I’d be as precise as possible. You’ll notice some lines near the end are in italics – those are ones I planned on cutting if I was in danger of going over the time limit.

Feedback, as usual, is most welcome.

Hello, my name is Harry Pierson. I’m a program manager in the Visual Studio Languages group and I’m here to talk about what I would most like to do to improve Microsoft.

At Microsoft, we care an awful lot about the software ecosystem. Searching for the word “ecosystem” on Microsoft.com returns nearly eight thousand results. We talk about the ecosystem in our marketing and in our press releases.

In 2007, we commissioned a study of the global economic impact of the Microsoft ecosystem. In a word, it’s massive. It’s responsible for nearly 15 million jobs and drives over half a trillion dollars a year in tax revenue worldwide.

No wonder we care about the ecosystem so much.

But clearly, we’re not the only ones who care. Microsoft represents a fairly small percentage of the overall ecosystem. We earn just over 11% of the total revenue and account for half of one percent of the total employment within the ecosystem.

That means there are an awfully large number of people with a vested interest in the continuing success of the Microsoft platform.

With this vast ecosystem in mind, I want to talk about Open Source. Microsoft and Open Source are often portrayed as enemies. But in DevDiv, we have several high profile Open Source projects. I work on IronPython, which has been Open Source for over four years. More recently, the ASP.NET and Extensibility Framework teams have decided to release some projects as Open Source.

I believe we should have more Open Source projects at Microsoft. But more importantly, I feel that we need to go beyond the textbook definition of Open Source. Our Open Source projects are typically closed to external contributions. But for the ecosystem at large, Open Source isn’t just about the availability and distribution terms of the source code. It also implies a collaborative development model - parties working together across organizational boundaries, contributing directly to projects in question.

The thing I would most like to change about Microsoft would be to let members of our ecosystem contribute code to our Open Source projects.

I can tell you from personal experience, there are members of the IronPython community who would leap at the opportunity to contribute code. And their engineering prowess and real world would benefit the IronPython project tremendously. But the legal process for getting permission to take contributions is onerous. Worse, the legal stigma attached to code that isn’t 100% pure Microsoft intellectual property makes it nearly impossible for any other group inside Microsoft to build on it.

I realize the onerous legal process is there for a reason: to protect Microsoft’s interests. But improving IronPython and Open Source projects like it isn’t just in Microsoft’s best interest; it’s in the best interest of our ecosystem as well. We need a legal framework that protects Microsoft while allowing for code contributions. Developing such a framework will be a challenge. But competitors like Sun, Google and IBM have already demonstrated that it’s not insurmountable.

Half a trillion dollars annually. 15 Million jobs. 42% of the IT workforce. The Microsoft ecosystem is the envy of the industry. And Microsoft is in a unique position to harness the collective experience and engineering prowess of that ecosystem while simultaneously dispelling the myth that we are an enemy of Open Source.

It’s time we make this change.

Thank you very much.

Yesterday was my 39th birthday. Among other things I got a vasovagal syncope (aka I fainted), a trip to the hospital and an MRI.

Yeah, I’ve had better birthdays. But I’m feeling much better now.

Since Monday, I’ve been having weird numbness and tingling in my hands, feet and midsection. Ever have your foot fall asleep? You know how it feels when your foot wakes up again? It’s kinda like that. After three days of that, I decided it was time to go see the doctor. My doctor is right by my daughter’s school, so I try and schedule my appointments so I can drop her off and save my wife the trip. But the only appointment they had yesterday was thirty minutes before my daughter’s school starts, so I ended up going alone. That turned out to be a very good thing.

Diabetes is one of the things that can cause this numbness and tingling, so my wife and I figured that I shouldn’t eat anything in case the doctor wanted to check my blood sugar. Sure enough, they wanted to run a few blood tests. My wife called as they were drawing my blood – she had dropped off our daughter and wanted to know if I wanted her to stop by.  I told her to stop by if she wanted, hung up, and promptly fainted. Luckily, Jules had decided she wanted to stop by so she was there when I came to.

Apparently, vasovagal syncope is the most common cause of fainting and having your blood drawn is a common trigger. I’ve never had that reaction to having my blood drawn, though I can’t remember ever having my blood drawn while fasting. But I tell you what, I don’t ever want to go thru that again. All I really remember was trying to get my brain to focus, and it wouldn’t. Pretty scary.

Playing it better safe than sorry, I was sent off to the hospital to spend two hours crammed in the MRI machine to get an scan of my brain and spine done. Also not a pleasant experience, but much better than fainting. There was much more ominous talk like “admitting for observation” and “lumbar puncture”, but apparently the MRI didn’t show anything requiring all that so I was sent home.

I still have the numbness and tingling, though it’s somewhat better today than yesterday. The good news is that it’s not diabetes or my thyroid or anything like that and they don’t think the fainting was related at all. Since the tingling and numbness is a little better today, I’m thinking it’s something like a pinched nerve. My doctor wants me to go see a specialist, so I’ve got an appointment with a neurologist in a couple of weeks. We’ll see how it feels by then - in the meantime, I’m taking it easy. I even skipped work again today – five day weekend FTW!

As for my birthday, we did decide to postpone my “FANTASTIC surprise”. Jules had arranged for us to go camping on Orcas island over the weekend. I’m really excited for the trip – it’ll be our first real camping trip outside of the back yard - but I’m not sure if I’ll be up for it this weekend. My parents sent me a bunch of Capitals gear as well as some money for new hockey equipment – I really need a new helmet and elbow pads. My kids both made me awesome cards – Patrick’s new thing is to make pop-up cards. He also made me a paper “cake” crown.

So even though that whole tingling/vasovagal/hospital/MRI thing was a less than fun way to spend the day, I still ended up having a pretty decent birthday. I’m especially thankful for my awesome wife, who does an amazing job taking care of me when I’m sick – much better than I am able to do for her when she’s sick I’m afraid.

In addition to the IronPython CTP for .NET Framework 4.0 Beta 1 I blogged about earlier, we also released the first beta of IronPython 2.6 today. How about that – two IronPython releases in one day! This is our second preview release as we work towards our 2.6 RTM in September. 2.6 Alpha 1 was released back in March.

There are two big new features in this release. The first is our implementation of the ctypes module. The ctypes module is like P/Invoke for Python. It allows Python code to call into unmanaged DLL functions. Here, for example, I’m calling into the standard wprintf function from msvcrt.dll

Between ctypes and Ironclad, I think we’ll eventually be able to load most native Python extensions in IronPython. Woot!

The other big new feature in this release is a real implementation of sys._getframe. _getframe lets you write code that inspects the Python callstack. Previously, we supported _getframe only with a depth of zero which is to say you could inspect the current frame, but no others. Now, by default we don’t implement _getframe at all unless you pass in –X:Frames or –X:FullFrames on the command line. Removing the version of _getframe that only worked for depth zero fixes an issue with collections.py that broke much of the 2.6 standard library in IronPython 2.6 Alpha 1.

The difference between Frames and FullFrames is in what is returned by frame.f_locals member. If you’re running with FullFrames, we hoist all local variables into the heap so they can be accessed by our frame walker. If you’re running with Frames, our ability to access locals up the stack is limited. Sometimes they are available - If you called locals() in a frame up the stack for example, then f_locals will be available – but usually not. There’s a performance difference between the default (i.e. no Frames), –X:Frames and –X:FullFrames, hence why we provide the user fine grained control over the Frame support.

Our performance has gotten better relative to 2.6 Alpha 1. Our PyStone numbers have improved 80% from Alpha 1, similar to where we were in IronPython 2.0.1. We’ve also been able to cut our startup time about 25% from 2.0.1. We’re still an order of magnitude slower than CPython on startup, but we’re getting better. We’re significantly worse on PyBench than we were in 2.6 Alpha 1, but that’s primarily because there’s now a second exception test. As I described back in March, we get killed on the exceptions benchmarks – the two combine to consume nearly 62% of our total run time. Ouch!

Finally, there are bug fixes. Of particular relevance to readers of this blog are a series of fixes that allow me to continue on with my __clrtype__ series. Watch for that soon.

As I said back when we released Alpha 1, the release cycle on 2.6 will be much shorter than it was for 2.0. 2.0 had eight alphas, five betas and two release candidates over the course of around twenty months. We expect 2.6 to have one alpha, two betas and a release candidate over eight months. So please start trying using the beta as soon as you can so you can give us your feedback and we can fix your bugs!

The .NET Framework 4.0 and Visual Studio 2010 Beta 1 is now generally available for download. Jason Zander has a very thorough rundown on some of the new features in this release. Of course, my favorite new features in VS2010 is the new dynamic language support in C# and Visual Basic, which let’s you easily call out to IronPython code from those languages.

For anyone who wants to experiment with interoperating C# or VB with IronPython, we released IronPython 2.6 CTP for .NET 4.0 Beta 1 today. There’s also a walkthru showing how you can use the standard Python library module random from both C# and VB. Note, there’s currently a URL bug in that walkthru – it links to IronPython 2.6 Alpha 1 rather than the .NET 4.0 Beta 1 IronPython CTP. Make sure you pick up the right version of IronPython if you want to try out the walkthru. Looks like they fixed the redirect in the walkthru.

FYI, this is a CTP quality release with about the same functionality as IronPython 2.6 Alpha 1.  Essentially, this is the version of IronPython that was in the source tree when the VS team branched for Beta 1.

If you’ve got any feedback, please drop us a line on the mailing list.

In a couple of weeks, I‘m participating in an internal “Presentation Idol”competition. It’s a contest of presentation skills against impressive competition (I can’t name names, but rest assured it’s a strong group) being judged by Microsoft executives (again, I can’t name names, but this time it’s because I don’t know who’s judging) in front of what I assume will be a large technical internal Microsoft audience. To top it off, we each only get three minutes and thirty three seconds each to deliver our presentations.

So yeah, no pressure.

The topic we’re all presenting is “What is the one thing we should do to improve Microsoft?” For those who know me, it should come as little surprise that I picked a variant of “more open source” for my presentation. More specifically, I’m planning to present the following:

1. Any product Microsoft gives away for free should also be Open Source.
2. Open Source Microsoft products should accept contributions from the community.

I realize that many people consider this separation between “source availability” and “community contributions” completely artificial. Sure, the accepted definition of Open Source only addresses the availability and distribution of source code, but most Open Source advocates consider the ability to collaborate and contribute – what Wikipedia calls “Commons-based peer production” - a critical aspect of Open Source. For example, with respect to the announcement that ASP.NET MVC would be released under the Ms-PL, Keith Elder tweeted:

“Giving someone your source code is NOT open source. So although Asp.Net MVC's source code is out there for download, not open source.”

In what now seems like a huge coincidence, Keith and his co-host Chris “Woody” Woodruff interviewed me later that day for their podcast Deep Fried Bytes. As you might imagine, while we started with talking about IronPython, we eventually started discussing open source at Microsoft more generally. It was a great conversation, and we found lots of common ground.

Personally, I think Microsoft is making small steps in the right direction when it comes to Open Source. Not only have some high profile Microsoft projects go Open Source like ASP.NET MVC and MEF, but we’ve even started taking baby steps for including external intellectual property. Releasing ASP.NET MVC under Ms-PL is a big deal, but I think including jQuery “in the box” is a much, much bigger deal. It remains to be seen if it’s a one-time-only deal or if it’s a new trend inside Microsoft.

Obviously, I hope it’s a trend. Going from “include jQuery in ASP.NET” to “accept community contributions in ASP.NET” seems like a relatively achievable goal.

Now, here’s where I need your help.

I can easily fill three and a half minutes talking about Open Source community collaboration. But since my presentation is about taking contributions from the community, I decided to put my money where my mouth is and crowdsource it:

What is the elevator pitch *you* would make for including community contributions in Microsoft Open Source products?

Leave me a comment, send me an email, tweet it, whatever – I’ll be keeping an eye out for responses. Please remember that I only have three and a half minutes to present, so keep your ideas short and sweet.