I have always wondered what it was (is) like to be one of the last ones to get access to electricity or to be able to have a telephone line at your house. I own a piece of property that got access to electricity in 1940, telephone lines didn't come until after World War II. Today, the best dial-up connection that I ever get is 40 kbps, and the only way to get broadband (aka "a high speed internet connection") is to sign up for satellite service - which is a little too expensive for my tastes. A "wired" broadband connection is only 3 miles away, but it seems like a long 3 miles as it may be years before that trunk line gets extended to my house.
Broadband access and capabilities differ from neighborhood to neighborhood, city to city, county to county, and state to state in the United States. More often than not, it is the rural communities that are the last to gain access to these "wired" innovations. The speeds and availability of broadband also greatly differs from country to country. South Korea is the "most connected" country in the world with 70-80% of the households have a broadband connection.
To help understand all of the differences, perhaps you could respond to these questions as a comment to the blog:
t.
Great news! Today we're broadly rolling out a new test build of Windows Home Server - a Community Technology Preview (CTP.) If you've been following Home Server press coverage, or seen the subtle hints from the team in postings to the forums, you knew it was coming soon.
CTP provides a wide range of code fixes, user interface improvements and feature enhancements, such as:
CTP is an exciting milestone for the team on the road to final release. As always, those interested in participating in the beta program can apply here. We're looking forward to hearing the feedback!
J
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