Okay, this is pretty cool: the Microsoft Open Source website is now available for perusal. The initial focus is on the SharePoint Learning Kit, which looks like it will be a big help if you want to build an e-cirriculum site and want to use SharePoint.
The thing I find most interesting about this, though, is how Microsoft has a growing portfolio of products and initiatives that are blending the traditional lines (and I'm using lines here in the battle sense) of commercial software vs. open source. While the SLK is free, it does require SharePoint 3.0, which in turn requires Windows Server 2003 or better and the .NET Framework 2.0; while SPS 3.0 and .NET 2.0 are free, you have to buy Windows to get them. Many people will use that as a reason to dismiss any offering that Microsoft makes, which I think is incredibly short-sighted of them.
There's no intrinsic law of software that makes either the traditional commercial development model ("closed source" for short) or the open source model better than the other in every circumstance. Both models have many strengths and corresponding weaknesses to offer, all of which have been identified and discussed for years. What stands out to me is that an arguable number of the more successful open source projects have been backed by corporate resources of some sort or other, whether it be companies such as SGI contributing Linux kernel patches as they find and fix problems that limited SMP performance, or organizations that are formed to provide the financial resources necessary to allow full-time developers to work on a project. There's this image floating out there in the collective concsciousness that open source somehow equals a complete lack of centralized management, with priorities being decided by consensus and fiat ("Sorry that you don't think feature Foo is important, Joe but I finished coding it last night and checked it in.") and a continuing dependence on the goodwill of a vastly dispersed faceless crowd of geeks in basements to get unsexy, boring plumbing code finished. This may be true of many projects -- but they aren't the ones that make a name for themselves, that produce quality releases, and that get used.
I'm particularly interested in the projects whose success is directly attributable to a company that provides the developers and management skills to guide the day-to-day work of the project -- gathering requirements, writing specs, setting milestones, and assigning the responsibility for writing the deadly boring libraries and classes that form the heart of the project (without which performance will suffer and the code will bloat). It's this last part that is in my mind truly key: having developers you can hold accountable to write code and fix bugs even when individuals leave the project. There are ways to make this happen, but the most reliable way is a time-honored tradition: a paycheck. And whatever flaws you may think Microsoft has, they certainly have deep pockets and can afford a paycheck or two.