So last night before calling it a night I decided to post a tweet:
#IfIHadAYearAtMicrosoft...I would ensure #SharePoint UI was 100% W3C compliant & be able to develop remotely off the server
and got a reply within an hour from @LougeFlyZ aka Chris Johnson from the SharePoint Product team headed up by Arpan Shah (@arpanshah):
@jthake one year?!? You can't do these things outside of a release cycle. They effect millions of users and create back compat issues.
The reason I stated those two issues around W3C compliance and Remote Development is that these are two key issues that stop Development Teams using SharePoint and sticking with ASP.NET and writing it themselves. I am currently preparing a presentation for the Perth .NET User Group to discuss the pros and cons in more detail…I expect to have tomatoes thrown at me….so any ammo is greatly appreciated!
This got me thinking this morning on the way to work…
Immense pressure the SharePoint team is under
The boys in that team are under extreme pressure with Microsoft pinning its hopes on SharePoint for various Server products: Office Server, Commerce Server 2009, Reporting Services (integrated option), Performance Point (now been swallowed into SharePoint 2010) and TFS (now optional in TFS 2010). I’m sure the pressure alone internally from all the products they have to support is immense, let only from the MVP community providing early feedback and from the public community on releases!
Release cycles
Just yesterday the team posted more information on the April Cumulative Update which has caused some confusion so soon after SP2 was released (within a week). The diagram below indicates the CU’s to come before 2010 will be released. There is also the first public beta coming in July 2009.
Chris did make a good point in his tweet about making large changes like I suggested “outside of the release cycle”. I, along with a lot of the community who spend their working (and private lives) consumed by SharePoint, look forward to seeing what made it through to 2010.
Feature lockdown
Another thing to bear in mind is that due to these release cycles and the time that the MVPs and public see a release to give feedback, is often after the feature list has been locked down. SharePoint 2007 beta was released in November 2006 to the public and went RTM in early 2007.
This obviously did not give enough time for the public to sway much of the final RTM feature list and most likely Microsoft were bug swatting and ironing out the beta for release in feature lock down. With this in mind, come July this year…treat the Beta as a way of your organisation having some practice runs at migrating 2007 into it and playing with the new features to pitch ideas to your organisation. Don’t expect too much to change between the two.
Don’t believe it, until you see it
I think we can expect a similar time frame for the next major release in 2012 with service packs probably once a year. One thing to bear in mind with this, is when you are making architectural decisions and assume that you can just wait for the features that are promised by Microsoft or hinted at or on the rumour mill…that you shouldn’t always rely on them. The last thing you want to do is promise the CEO that it’ll be in the next major version and when it’s released, it’s not, and then you’re on the back foot having to build something quickly!
Effects millions of users
Chris other point about backward compatibility is also something to bare in mind. SharePoint has a HUGE user base now and as I’ve mentioned above…supports a large foot print of products on top of it. With the release of 2010, the team will have to ensure that they are backward compatible with 2007 implementations.
From a development perspective this means scenarios like:
Master Pages/Page Layouts
If you are not in the “cool” SharePoint blue for your organisation Intranet, you have most likely even developed your own theme and applied it…or copied the default.master and modified it. Between SP1 and SP2 there were NO changes to master pages. I expect changes to default.master this time round, this will mean your copied instance will not have the new controls in it…which may cause a breaking change to your environment. I’m guessing no migration path is going to simply just add those missing controls to your master pages so you’ll have to start comparing differences in files.
Style Sheets
Same deal as master pages, there’s bound to be new styles with the recently announced support for Internet Explorer 7.0 and more advanced support for FireFox 3.0. So if you’ve changed things like ItemStyle.xsl when using Content by Query Web Part…which I’ve seen it lots of instances…you’ll have some fun.
List Templates
One thing to bear in mind with this also, with the announcement of AJAX inpage list item editing, is List Templates with their defined <View> elements. I'm intrigue to see how they are going to modify not only existing List Instances to support this new AJAX view and also List Templates within the 12 Hive.
Web Services/API
If the organisation has any custom managed code that calls off to the web services in 2007 or uses the API for event receivers and feature receivers, the product team has obviously had to ensure that there are no breaking changes here. Again, I strongly encourage organisations to retest all of their managed code against 2010. I would also suggest if you have written some “funky” workarounds for bugs in 2007, they may have been fixed in Service Packs or Cumulative Updates…you’re “funky” workarounds might not work anymore and therefore you should be testing heavily in these scenarios too.
Source Control
How will this effect organisations who have these Master Pages, Page Layouts, Style Sheets, List Templates, etc. deployed by Solution Packages (as recommended) and stored in source control?
Their hands are tied
Following on from the backward compatibility restrictions…this will obviously mean that the teams hands are tied on certain feature requests. Most likely the two I’ve mentioned in my tweet.
The requests for a stronger replacement for SQL tables with scalability for SharePoint Lists has been met which was obviously a key business driven requirement.
Remote Development
It looks like for this release married with the release of Visual Studio 2010, to not expect any changes on the current approach to development where you require SharePoint server natively in your development environment.
COM Component
It would have been great also to drop the old COM component that the SharePoint .NET API wraps around for us developers…but I haven’t heard anything about this as yet. This will mean that the SPDisposeChecker tool will be at the top of our toolbox at all times!
Should have cut their ties with 2003
The whole “should, coulda, woulda” hindsight is always a kick in the balls…but I thought I’d raise it here regardless. The migration path from 2003 to 2007 wasn’t a pretty one…especially in two major scenarios: heavily customised MCMS to SharePoint 2007 and SharePoint 2003 to SharePoint 2007.
I guess what I’m trying to indicate here is that from a marketing and strategy point of view Microsoft wanted to make it as easy as possible for existing MCMS and SharePoint 2003 organisations to move to 2007. In doing so, they had their hands tied behind their back on a variety of things.
For us developers, one of the most obvious examples of this is the SharePoint API with SPSite meaning Site Collection and SPWeb meaning Site. Sounds trivial…but you explain this to .NET developers who have been used to .NET moving through framework releases without this confusion. It makes SharePoint a harder sell alright!
Sometimes I wonder what would have happened if they severed their ties with 2003 and started the product from ground up without worrying about a migration path from 2003…
In Summary
The team have done an amazing job and I’m looking forward to SharePoint 2010. I would absolutely love and be honoured to work inside the team on the product development at some stage, so don’t take this post as a rant on the team or Microsoft by any means!
I just guess as Developers who leverage the Platform we just need to be aware of the length of these release cycles and be conscious of the migration path between major releases..