Last week at cmf2007 Raimond Kempees, a developer and consultant at Radagio, gave a nice talk assessing MOSS 2007. Among other things, Raimond relayed some of the challenges he and other developers have experienced with Web Parts. It all reminded me of the love/hate relationship customers endure with portlets in the Java portal world. On the one hand, the Web Parts framework is very attractive for plugging widgets into dashboard-type pages. In addition to what ships natively with SharePoint, you can find lots of 3rd-party Web Parts. But their quality and safety varies substantially, and inevitably you need to extend them...and then how do you handle support? There is also perennial confusion and inconsistency about how much logic to put in presentation tier, and how much to place in objects behind the scenes.

So, Microsoft's portal is no more or less complicated than, say, Sun's.

What was more interesting to me was the crowd's reaction. Some end-user customers nodded their heads, but some Redmond integrator partners seemed apoplectic that someone would criticize MOSS. A typical riposte (which I have heard from MOSS developers around the world) went, in effect, "A .NET developer who really knows how the product works can fix all that!" And what about the lack of a published roadmap and consistent best practices? "If you're a Microsoft partner, you'll be the first in the know!"

SharePoint may be marketed to LAN Administrator, but it is really a boon to consultancies. What you might dislike about MOSS, a consultant might actually favor. One integrator at the session remarked lovingly on a 4-month / 4-developer MOSS customization project they just completed. Of course, many ECM/WCM/Portal projects take far longer with more bodies. But it puts to rest any misapprehensions that MOSS is plug-and-play for anything serious beyond simple collaboration.

I happen believe the world really needs a .NET development platform, but is that what you thought you were getting when you installed MOSS?