As any seasoned SharePoint Developers will point out, SharePoint has come along way in the Development journey since it's beginnings in 2001 to what it is today. It has still got a long way to go for a variety of reasons, some of which I have covered in my 8 part series.

vNext Hype

There is much hype surrounding Visual Studio 2010 starting to be spun by Microsoft after PDC with regards for its native support for SharePoint Development. This does indeed look like a great step from what is available in VSeWSS 1.2 currently.
The cynics among us would raise the fact that this support will only exist in Visual Studio 2010 and with lots still not making the move to 2008 will mean that this will not be available to the masses.

Compatibility

The same can also be said for Organisations that are running SharePoint 2007, a lot which aren't even on 2007 SP1 let along the Infrastructure or Cumulative Updates due to fear of breaking customisation's already created on the new 2007 version. Worse still I know of lots of large scale 2003 implementations out there still planning for migration!
Reality leads to a more uglier picture of Developers wanting to use these new tools when they are released but held back by not having the latest Visual Studio or developing to a 2007 SP1 platform and not vNext (whatever it may be called). I'm making a large assumption that the new toolset will leverage a lot of the new functionality and framework in vNext and I can't see it being fully backwards compatible to 2007 SP2 (due in Q1 09).

Information overload

What I am try to raise here is that "the time is now", we can look into the future and see the new tools...but we have to have solutions for today's developments. With Microsoft focusing on VS2010 tools we are stuck with the VSeWSS 1.2 toolset which is not the complete package by any means. The slurry of information available on TechNet and multitude of books, blogs and forums make it hard to see the wood through the trees.

Migration

There was a large step to migrate from 2003 to 2007, which I believe will not be as hard between 2007 to vNext. The hard part is all the new implementations built straight onto 2007 that have not followed best practice. This is due to the poor toolset which has pushed organisations to use the UI and hack at it using SharePoint Designer rather than following the Best Practice methods of Solutions and Features.
The use of customisation's over development has led to Organisations being unconfident of service packs and updates let alone a large jump to a new version. Microsoft will be focusing on migrations that use the correct methods, but realistically they need to prepare for the ugly truth.

More than one way to skin a cat

There's plenty of issues with using Solutions and Features also. You can get so far with Elements Manifest creating things, but you'll need to use Feature Receivers to clean up if you want to un-activate them.

So you find yourself as a Developer in either two camps, or directly working with the API and ignoring the Elements. It makes it debugging hell if you have to check two places, for example, to see what is creating the list or attaching the event receiver. And then you have PowerShell/STSADM extensions that could possibly do it too.

The Patterns and Practices Guidance is moving in the right direction with their Contoso sample, the problem I find with this is that some of it is seriously over-architected and not realistic for the large percentage of SharePoint Projects out there.

What we need now

What the community needs is a toolset that will help Developers move customisation's into managed Solutions and Features. This will ensure that customisation's are deployed correctly in a SharePoint Farm and ensure that migration to the next platform isn't going to be a nightmare.

We also need a single resource to fill the middle ground to explain the "best practice way" to do things with sample code and an explanation of why not to use the other approaches. With lessons learnt so people can understand why not to use them if they wish (this will stop turf wars for example Site Definitions vs. Site Templates vs. Features).

The Community Needs our Help!

Microsoft can hype as much as they like, reality means at least 9 months after release we'll start seeing it in the Market Place unless its a fresh install. So the community needs to act now!

We have some great community resources out there now with EndUserSharePoint.com and SharePointMagazine.net, but nothing that focuses purely on SharePoint Development.

I have the domain name and am currently locking down a host and a Wiki engine to collaborate on. Although it would be great to eat our own dog food, the SharePoint Wikis currently have their limitations.

I am progressing forward with a collaborative solution for this, if anyone is interested please contact me.