Developers, Developers, Developers
Today we are announcing the availability of the Windows Home Server SDK. You can access it here.
As I stated in my Channel 9 video interview (and in this post) in January, enabling developers to build on Windows Home Server is an important goal for us. We include all sorts of developers in our definition, including pros doing it to make a living, hobbyists doing it for others just for the gratification, and makers who just do it for themselves.
I personally have fit into all three categories. I obviously build software professionally here at Microsoft (although my team would laugh if I were to suggest that I actually write code anymore), but I did write software professionally in the past. Over the years, I've built many freeware and shareware packages for things relating to making printing easier in Windows, to integrating Windows Media Center Edition into an all-house control system. I'm constantly dinking with hardware & software projects that are useful (or not) only to me. My office and workshop are littered with evidence of this, much to my family's chagrin.
My first 9 years at Microsoft was spent focused on developers. I started as a support engineer supporting the Windows 2x and 3.0 SDKs and DDKs. I was a developer evangelist. I designed and explained and got all religious about COM, OLE, and ActiveX. And so on. Made some mistakes. Learned a ton. So I get it.
Which is why I pushed so hard from day one that one of the fundamental tenets of Windows Home Server was it would be a platform for developers to build on.
In software development (there goes Charlie pretending he's Joel on Software again) there tend to be widely held beliefs, or truisms. I've written about some of them before here. One truism is when building a v1 product you have to decide between being a platform and a solution. You can't focus on both and be successful. I almost completely believe that.
The original vision document for Windows Home Server (back when the project was codenamed Quattro) made the following statement:
"Quattro" is not a platform. We are a solution. That said, there will be areas where 3rd party extensibility will be important and where we will do specific things to enable 3rd parties. This will likely be limited to our administration Ux.
Beyond that we will rely on the broad platform that Windows provides beneath our solution.
This told the team what to focus on: Build a solution for the problems our end-user customers have, do a few things to make sure the most important extensibility points are addressed, and let 3rd parties innovate deeply by using the rich, underlying Windows platform.
But, the reality is, 99% of what developers want to build on top of Windows Home Server will be done using the rest of the MSDN documentation. Our little set of APIs let you integrate your Add-in into the Home Server Console and interact with some of the elements behind the solutions we provide. But all the interesting work that great Windows Home Server Add-ins will do will be done using the standard "Windows API".
I'll post more later on using the SDK and building Add-ins...
[EDIT: For those of you direct linking here, I've posted a follow up here...]
-cek