Cross posted from @jthake

I've already posted a webcast and created a wiki page that has caused a lot of discussion on the wiki on "Why don't ASP.NET developers use WSS?". This post will reflect on the SharePoint 2010 conference last week and to nominate 12 factors that will hopefully be the tipping point for ASP.NET developers to start leveraging the SharePoint 2010 platform.
I will be using my ASP.NET Readify colleagues as a good bench mark on how successful the adoption of development in SharePoint 2010 platform is because these guys are classed as the elite of Australia.
One thing to note about SharePoint development is that it leverages the .NET Framework, specifically ASP.NET and all the other web technologies such as JavaScript, CSS, XHTML, XSLT. To become a good SharePoint Developer you not only need to have a base understanding of these technologies, but also the SharePoint platform.

The 12 Factors

Factor 1: Visual Studio 2010 Toolset

In SharePoint 2007, the toolset (VSeWSS 1.3) was used less than the community toolset called WSPBuilder due to its limitations
All developers love new tools and my ASP.NET colleagues at Readify would have all downloaded Visual Studio 2010 Beta on Monday 19th to check out how it's tracking from their perspective. Of course, most of these guys will be unaware that the SharePoint toolset is included in this offering, this is the first score on the scoreboard for the SharePoint product team.
The VS2010 SharePoint toolset has come along way since VSeWSS (thank god!) and the most compelling feature is the "F5 experience" of firing up a SharePoint page and being able to hit breakpoints in your code as you debug web parts, application pages, workflows etc.
More will be at Visual Studio 2010.

Factor 2: Team Foundation Server (TFS) 2010 integration

In SharePoint 2007, the toolset (VSeWSS 1.3) did not support source control in an "straight forward" way
ANY web development should include at least source control if not a more mature Application Life Cycle Management tool such as TFS. With the release of TFS 2010 in Q1 2010, the SharePoint toolset will integrate 100% with it.
With TFS 2010 Basic being "free"to use and including source control but none of the data warehouse reporting or SharePoint integration. It will encourage even the smallest of teams to get their SharePoint products into TFS.
More will be at Team Foundation Server Integration.

Factor 3: Windows 7/Vista workstation host

In SharePoint 2007, developers who wanted to debug realistically needed their own server environment deployed
With the announcement that SharePoint 2010 would be capable of being installed on Windows 7/Vista, the SharePoint Product Team thought they had cracked the biggest hurdle...there weren't that many cheers from the crowd when they mentioned this....I think they were expecting this to be huge.
Of course this is going to be great for organisations who can't provision server environments for each developer, or who do not have the virtualisation software or hardware to run one up locally on their workstation or on central infrastructure. I still need to get confirmation on what hardware is required to even run this from a RAM perspective.
To play devils advocate, Bamboo posted a solution for this in SharePoint 2007, how many Developers actually use this approach...and if not why not? Do these reasons change in SharePoint 2010?
More will be at Building a SharePoint 2010 Development machine.

Factor 4: Sandboxed Solutions

In SharePoint 2007, managed code was deployed to Production to find that under load it brought the web servers to a grinding halt
The Windows 7/Vista story is great, but most developers will have multiple customers and this typically meant having multiple environments. With the ability to isolate Solution Package Deployment in one environment and execution into Sandboxed Solutions, this has resolved this little issue.
Not only will it isolate Solution Packages for Developers, but it has allowed Administrators to do the same thing. Administrators can take these Solution Packages and put them into their environment wrapped in cotton wool and allow it to be executed with some defined controls to ensure it doesn't bring the server to a grinding halt.
More will be at SharePoint Sandboxed Solutions.

Factor 5: Developer Dashboard

In SharePoint 2007, the feedback a developer got basically came from page load times, CPU/RAM performance reports and ranting business users in Production
As with any development platform, a lot of developers do not like calling framework API's because they are not sure what they are doing in the background. The introduction of the Developer Dashboard will give Developers immediate feedback as they test their functionality on their workstation.
More will be at Developer Dashboard.

Factor 6: Visual Studio 2010 Extensibility

In SharePoint 2007, the VSeWSS 1.3 were not easily extendable and that is why a lot of Developers moved to WSPBuilder
Visual Studio 2010 provides a rich set of project templates and tools  that Developers can use to build SharePoint Solution Packages. Often there is a need to create new or extend existing ones, with this release there are hooks into: various events to do with packaging; to add and extend nodes in the Server Explorer (think SharePoint Manager 2007) and even create new designers.

Factor 7: Accessibility

Accessibility and SharePoint 2007 didn't really go in the same sentence without the phrase "not compliant" in it
The Product Team has invested a lot of time in ensuring that SharePoint 2010 is WCAG AA compliant. I have yet to test this and to ensure that all areas are compliant or whether it is just the end rendering areas. For example, is the InfoPath and Visio Web interfaces compliant, the Content Authoring screens etc.
I watched Sara Ford talk heavily about the focus of Visual Studio and Accessibility, but is InfoPath and the Microsoft Office products accessible too? Areas not really discussed at the Conference either.
More will be at Accessibility Standards.

Factor 8: Export to WSP

In SharePoint 2007, the divide between SharePoint Designer 2007 and UI customisations and Visual Studio Development was an ocean
The ability to export to a Solution Package customisations implemented in both SharePoint Designer and the UI gives the ability for Business Users and Designers to be part of the Application Lifecycle in terms of prototyping functionality. The ability to re-use work already done by these guys early on in the process and then to make enhancements in Visual Studio programmatically which weren't possible declaratively is going to be a compelling story!
The limitations of this Export to WSP aren't quite known yet, but I will endeavour to explore this as the SPSource tool that myself and Rich Finn wrote currently fill this void in SharePoint 2007 with Lists, Content Types, Site Columns and Module files.
More will be at Import WSP from SharePoint Designer including Workflow.

Factor 9: Client Object Model (OM)

In SharePoint 2007, interfacing from the client was limited to Web Services and involved a lot of knowledge of jQuery
The introduction of the Client OM in SharePoint 2010 is going to empower client Web Developers with mad JavaScript skills and Silverlight Developers the ability to build Rich Internet Applications (RIA's).
I was slightly disappointed with the 101 demos shown on this at SPC09 and also what is available in SharePoint 2010 out of the box. I thought a lot more of the interface would take advantage of this but obviously not.
More will be at Client Object Model (OM).

Factor 10: Application Services

In SharePoint 2007, the Shared Services Provider (SSP) had various issues around restoring in new environments as well as scaling within the farm
The introduction to the Application Services component into SharePoint 2010 and deprecation of the SSP will have a huge effect on how things are developed in SharePoint.
The main advantage I see is the ability to allow a SharePoint Farm to run an Application Service and other Farms to consume this. This gives the ability for Organisations to host Application Services in the cloud and other internal Farms to consume this.
More will be at SSP replaced by Service Applications.

Factor 11: Business Connectivity Services (BCS)

In SharePoint 2007, the BDC was limited to Read and the tools available to generate the connections were limited
Forget about the BDC, Microsoft did...they hardly mentioned the existing BDC functionality in SharePoint 2007 when they talked about BCS and what it could do at SPC09. BCS is extremely powerful with both read and write capability. Not only will this be able to be surfaced up into a BCS web part, but also as an "external list" in a Site and then directly into Office Client applications. It can also be implemented in SharePoint Designer now as well as Visual Studio 2010.
An amazing example was an external list of contact information being pulled from a SQL table and then surfaced up as an Outlook Contact list that could be edited and pushed all the way back to SQL.
More will be at Business Connectivity Services (BCS).

Factor 12: Platform Extensibility

In SharePoint 2007, there were various areas that you simply couldn't extend leaving dead ends where hacks were the only approach
The Product Team has focused on extensibility in this release to get around Developers having to hack away at the out of the box files so much. There have been a lot of changes to the User Interface to make it more extensible and also in the underlying framework with Event Receivers, Application Services, Solution Package Deployment Model etc.
Some areas were just playing catch up such as event hooks for Site Collection Adds/Deletes which really should have been there in 2007, it was such an obvious architectural need as they had it at List level.

The Ugly Truth

Backwards Compatibility

SharePoint 2007 is going to be around for a LONG time, I'm flying back to Perth from Las Vegas today and about to jump on a 2003 migration to 2007! The fact that Visual Studio 2010 SharePoint toolset does not support SharePoint 2007 is very very disappointing. Effectively it means although it's great that we can install SharePoint 2010 on Windows 7, we are still going to be having heaps of SharePoint 2007 environments with Visual Studio 2008 and VSeWSS if we play by the Microsoft rulebook.
The solution? Use Visual Studio 2010 with WSPBuilder for SharePoint 2007 stuff...the downfall for Microsoft is that people will start using it for SharePoint 2010 rather than having to learn two different toolsets...

Deactivate, Retract, Delete, Add, Deploy, Activate

One of the SharePointDevWiki.com shirt slogans was "Deactivate, Retract, Delete, Add, Deploy, Activate"..."SharePoint Dedication". There's no doubt you need patience to be a SharePoint Developer that's for sure! This story really hasn't changed and we saw plenty of pauses whilst the "F5 experience" was kicked in during presentations this week. Sure it's all in VS2010 now and it is a press of a key, but the speed in which it spun up hasn't changed much, it's no Cassini web server.

No .NET Framework 4.0 support

As much as all the existing SharePoint Developers can't wait to get their hands on SharePoint 2010, the ASP.NET Developers can't wait to get their hands on .NET Framework 4.0. So turning around and telling them they are stuck with ASP.NET 2.0 framework and Workflow 3.5 framework will certainly cause some grumbles. I can completely sympathise with the SharePoint product teams decision as the .NET 4.0 framework isn't out of beta and having this dependency to go live would have been tough. I spoke to Paul Andrew and he said at this stage it isn't even publically confirmed for SP1.

Workstation requirements

So it now works on Windows 7/Vista, but it still requires 64-bit hardware and realistically 4Gb RAM minimum. Not everyone is lucky enough to have this, of course all the Readify guys pretty much carry 8Gb RAM i7's already so this won't be a problem for them, but for governments who were struggling to host SharePoint 2007 32-bit 2Gb RAM development environments, there's going to be a few problems.

Unit Testing

One of the SharePointDevWiki.com shirt slogans was "I dream of ISPWeb"..."Legalise SharePoint Unit Testing", I did this in jest as ISPWeb interface didn't exist in SharePoint 2007 and I guessed it'd be put into SharePoint 2010 framework as there is a lot demand for unit testing in the Developer community.
The good news is that there is a solution, and it's the same pain staking solution for SharePoint 2007 that I have created a web cast for on the SharePointDevWiki.com.

Versioning

In my most popular posts on Leveraging the SharePoint Platform I discuss the issues around deploying a list template with associated content types, creating an instance from it, but then wanted to change the schema of this list instance. This topic still didn't come up last week which I was disappointed. I am aware it was discussed heavily at the MVP Summit, but didn't make it onto any presentations I've seen or anyone else I asked.

Documentation

The MSDN documentation is already up for Beta 2 and I was extremely disappointed with the death by GhostDoc approach to the documentation. Plenty of people gave feedback that having API framework driven documentation is not how Developers want to work. They can find this stuff out for themselves with Reflector! What Developers need is scenario based solutions for EACH functional area of the platform. Areas such as BCS, InfoPath, Excel Services never got this focus in SharePoint 2007, and from reading the focus so far it'll be the same in 2010.
One key message at the conference was around "Best Practices" and that they won't be available until at least SP1 time frame because this comes with the maturity of using the platform.

Certification

It is well known in the community that the MCTS exams are very poor and don't really test enough to guarantee the skill set of a SharePoint Developer or Administrator. There was hardly that much of a push in the questions around Solution Packages that was really mandatory in SharePoint 2007 to enforce quality.
The certifications are still being discussed and will definitely not be ready for April 2010 from speaking to a few at the conference. This is somewhat disappointing for me as I try to evangelise on the platform and encourage adoption. There are plenty of other courses such as the Ignite courses (non in Australia) and a bunch of courses by various vendors that will be available at RTM.

Disposing

SPDisposeChecker is alive and well with SharePoint 2010 as demonstrated by various presenters at SPC09. This has not gone away and will continue to bite Developers hard!
The Sandboxed Solutions will definitely help this out though, I can see it now...Administrators running around with print outs of Solution Packages that have gone higher than their point limits and pushing the blame straight to the source. Lets hope they have enough emotional intelligence to deal with this is a decent way ;-)

In Conclusion

Some feedback on Conference

So looking at the list of factors all of these apart from Windows 7/Vista and Application Services were well known via the Sneak Peek videos. Microsoft didn't really hold much back in my opinion, and in SharePointPodShow podcast it was quoted that only 10% had been talked about. Clearly from a SharePoint Developer perspective this wasn't the case.

A step forward

The SharePoint Product Team has taken a well needed step forward with the development tools, but don't forget that the community has had a decent toolset (WSPBuilder), source control integration (it worked in WSPBuilder), a developer dashboard (via ISV product), "install on Vista" via Bamboo, accessibility (by drawing blood from a stone for a long time), export to WSP (SPSource), a client OM (jQuery to RPC/Web Services) and a Server Explorer client (SharePoint Manager 2007).
In my mind, the Product Team have basically played catch up with an official answer. This will make the job of developers in Organisations who don't want anything but Microsoft products in there easier.
I've always been pretty hard on toolset in the past and I will continue to give my feedback as I know they listen, I've been told they do (so hello product team!).

The community will save the day

The blogging community, forums, podcasts, webcasts and wikis out there saved the SharePoint 2007 community and it will continue to save them in 2010. I was a bit disappointed in the keynote that they thanked the Product Team, Partners, and Customers, but not the community for their support with SharePoint. Without the community there is no way Microsoft Support would have been able to cope with all of the issues.
I'm hoping that the SharePointDevWiki.com will become a central collaboration resource for not only Developers, but Administrators also with lots of scenario based, recommended approaches content.
I finally got to meet some of my SharePoint heroes,one being Carsten Keutmann and he said he'd have a release of WSPBuilder with the public SharePoint 2010 Beta 2 available on November 16th. I've promised to help him release documentation and webcasts on this. I am also hoping to have SPSource ready not long after that as this gap has not been filled in full either.
There will be plenty of new voids to fill, such as a nice wizard to build all the plumbing that is needed for an Application Service. For sample: XSLTs for SharePoint views, jQuery calls to the Client OM, and lots lots more.