Office SharePoint Server Developer Edition

This post has been a long time coming and a long time in draft. It all started about a year ago with an angry customer, some newsgroup queries and a discussion with a long time friend. Since then I've discused the "idea" with some Program Managers and MVPs on and off. At the SPC in Berlin earlier this month, Fitz also mentioned the topic, so it's now time to unleash the rant...

No (unfortunately) this is not me letting the cat out of the bag on a as yet to be announced new product from Redmond, but simply a rambling discourse on something I would love to see in order to stimulate discussion and feedback.

So what I'm after here is "Office SharePoint Server Developer Edition".
This would be installable on Vista and IIS7 and be limited to development purposes only potentially with enforced limits on incoming requests etc. Just like SQL Server, just like Commerce Server, just like CMS. Maybe it could even ship with a pre-baked ADAM. Note I'm not at all interested in XP support.

Now why do I want it? Well there are four key issues which come up over and over again, when developing SharePoint applications:

1. Codeheads (get up offa that thing)
Firstly, codeheads (sweeping generalization here) are not as familiar with key infrastructure enablers here as they need to be to avoid costly rework or lame solutions - I'm talking IIS fundamentals (process isolation), NLB, DNS etc. I can't count the number of times have I seen a solution built which can only work with a Web.config value for the site URL (duh!). In the current world they slap together a Windows Server box (or VM) make a mess of that (yup really) and then wonder why it doesn't work come deployment into a real world environment. It's the old chestnut - "well it worked on my box".

2. Platform Hygiene Baby
Secondly, a ton of developers like their client on their client - i.e Visual Studio on the client OS. This makes total sense. Their client is the box with the power, having to build a VM with all the bits which needs at least 2Gb RAM to be even barely usable it not really on. As they can do this for Commerce, SQL etc having to use a different approach for SharePoint is not as nice as it should be.

3. Adoption
Thirdly, there today is a barrier to entry for ASP.NET developers. Say they are curious - they should be able to install that sucka, fire up Visual Studio have a play, without the overhead of building a whole server setup just to see if there is anything funky in SharePoint. Removing the barrier to entry is also extremely important in terms of adoption and wide scale understanding of "best practices", which leads nicely into the next issue.

Aside regarding "best practices" - hmm, not many about in SharePoint Developer land. Oh how I'd love to see Enterprise Library SharePoint Edition...

4. Knowledge
SharePoint now offers so much stuff but many development shops (partners etc) are unaware of the feature set or available APIs. This leads to the development of bespoke solutions when WSS can do the business. Just like with .NET in general the sheer amount of APIs available often leads to hacked out code to do stuff that SharePoint does "for free", and to a far higher quality. Any one trying to hire SharePoint 2007 development skills in the UK knows what I'm talking about.

SharePoint as a enterprise application platform.
With the 2007 release, SharePoint is now truly a viable platform for enterprise applications, in a way that 2003 never was despite how many people wanted it to be and tried to make it. In my view this is the single greatest thing about this release (despite all the wicked cool features). The problem here however is that if average .NET developer has no exposure to it, it won't be a really successful one anytime soon. Regardless of the architecture, operational and governance benefits of such a platform, no technology is ever successful in this regard without a large development community which is capable of delivering solutions upon it.

Fixing the foundation of WSS by "embracing and extending" ASP.NET 2.0 was the absolute right thing to do, but was only the first step - the missing piece this time around is the lack of high fidelity Developer Tool integration and lifecycle management.

How does Developer Edition help?
Well, up front it could help isolate developers from "infrastructure" issues, allow development to take place on the client and both increase adoption and lead to greater knowledge of the products and their APIs.

Developer Edition could also be a great first step towards a complete Software Development Lifecycle for SharePoint applications. I'm talking about true integration with Team Foundation Server and/or other SDL tools which many enterprises simply must have.

Now, I'm not saying such a product doesn't present certain challenges, I know there are and in some cases what they are and how difficult they are to solve. One of the reasons it wasn't "possible" previously was that IIS5.1 didn't support Worker Process Isolation. However, just because it may be a lot of work is not a valid excuse for wussing out and not doing it. Bear in mind that the work to get SharePoint working on IIS7 will have (is) already been done, so that part is not an issue any more.

Anyone looking for methods or hacks to get things running on IIS7 today won't find them here regardless of them working nor their practical use. That's a licensing violation, and besides I'm a platform hygiene kinda guy.

It's all about trade offs and compromise, the benefits in terms of adoption and skills mandate it's consideration. Developer editions of Commerce and SQL, and to a lesser degree, CMS have proven the worth in the past. A few years ago whilst doing the infosec gig, I had this conversation with respect to ISA and it's appsec/regex stuff (ala Kavado) with the big shot PMs and got nowhere. Not surprising given that product's target market, but as SharePoint is being pushed as a development platform, things are different.

But hey, it's all VM goodness baby...
Now currently, SharePoint developers live inside a VM - because SharePoint only installs on Windows Server and this is generally considered the most appropriate approach to SharePoint development. In addition there are certain things (such a email integration and BDC) where "external" resources are pre-requisite. Additionally the ability to throw away the box and go back to a known good one when things go Pete Tong is a huge benefit.

I don't argue against this approach and indeed have been an exponent of this approach since way before SharePoint was called Tahoe. This is my current recommendation for all customers.

But there are problems with VMs - such as licensing and cost implications (even with MSDN) and what happens with Windows Virtualisation, or more importantly what doesn't happen with Virtual PC might have impact here. Sure. there are alternatives to Microsoft in this arena, but for Microsoft to have a developer story, they must have an appropriate recommendation (based on their products) here.

Now of course remote debugging is possible today, but it's not always appropriate, and sometimes it simply doesn't cut the mustard. There are problems with security principles and again SDL constraints. So for the meantime, VMs (or a box running Windows Server) is the way to go.

Ship it baby, ship it. You know you want to.
In summary, I believe there is merit to the idea of Office SharePoint Server Developer Edition, and indeed a Developer Edition of WSS, which would help drive the adoption of SharePoint as the platform for composite applications and as a enterprise application hosting infrastructure. I would also love to see, going forward, true Software Development Lifecycle tool integration for SharePoint, and such a developer edition could be an ideal vehicle for it's delivery. So bring it on.

If you agree that Developer Edition would be useful, please contact Microsoft and tell them so. The more people who ask for it, the more likely it is to happen. If you have feedback or think of other benefits Developer Edition would bring, please leave comments here.