Weaknesses of SharePoint

After dismissing a weak collection of complaints about SharePoint in a previous post, let's take the other side and identify some real issues (Bil has the positive). I won't rip into specific features, that would be too easy and made irrelevant with links to the third-party solutions. Instead, let's focus on the solvable, foreseeable problems that hampered the WSS 2.0 product cycle.

1. WSS 2.0 was released without a timely strategy for educating people on its use, maintenance, customisation, and extension.
Until late 2004, no comprehensive resources existed for WSS. It was left to the dev team to spread the word, and for developers to hack the platform to figure out how it works. I saw a great presentation on deploying custom site definitions at TechEd 2004, really wonderful stuff. Someone asked where the contents of that presentation were documented. The answer? They weren't, the first good resource would be the TechEd DVDs. That was the message for too many topics until good books and online resources started appearing in late 2004.

Compare this to the story of Whidbey (ASP.NET version 2.0, now in Beta 2), which already has a collection of excellent books, resources and thought leaders (e.g. the ASPInsiders) positioned to evangelize and facilitate adoption of the product. When Whidbey lands, people will know how to take advantage of its features. The SharePoint teams needs a strategy up-front that gets the same depth of knowledge into the hands of authors, speakers, and leaders. Both WSS and ASP.NET are free components of the Windows Server 2003 platform. If the purpose is to sell the platform, WSS 2.0 did not get the job done, and a failure to enable potential adopters and evangelists with knowledge is the #1 reason.

2. The built-in Site Templates and Web Parts are feature-based, not scenario-based.
The site templates intended to be used as team hubs are not usable for any scenario out-of-box. How many times have you deleted or changed the Site Image on the Default Team Site? Too many. And why is it on the definition for Blank Team Site? The team did a better job with the plentiful meeting workspaces as the "Social Meeting" and "Decision Meeting" definitions describe and meet actual scenarios. The web parts suffer a similar fate on a different level (e.g.: no built-in web parts for breadcrumb or subsite navigation) A month of scenario-driven testing or usability testing would have demonstrated this.

If the out-of-box web parts were designed for real-world scenarios, Site Template libraries would exist online. But because WSS sites tend to rely on third-party web parts for some feature or other, there are no such sites. Site templates should meet specific scenarios. There should be enough Site Templates available that they require categorization.

3. WSS 2.0 is really WSS 1.0, and it didn't help MSFT customers to market it as 2.0.
SharePoint Team Services (STS) was version 1.0, and it was a different product that happened to be in the same space. It didn't use SQL Server as a data store and used different paradigms (e.g. the dashboard). The move to ASP.NET and SQL Server was a good idea, but when the platform is a rewrite, backward compatability is an extension and not inherent, users lose features (e.g. weaker, flawed versioning) and you're attempting to recreate a file system in a database for the first time, it would be correctly called WSS version 1.0.

What will bring the platform back to solid ground? WSS 3.0 must function as a document management system. If WSS 3.0 arrives and does not improve upon both STS 1.x and NTFS for document versioning, approvals, file-access auditing, backup-restore, and granularity of security, it will be considered a failure. The point is to move users away from NTFS, Exchange Public Folders, their C: drives, and filing cabinets. Help me do that and I will help you sell platforms.

4. Social aspects of deploying a successful intranet or collaborative web were not addressed in WSS 2.0.
Granted, I wouldn't expect this to be a theme during any given development cycle. But it's been four years since SPS 2001, and most everyone I know who is successful at building great Intranets learned the hard way.

I see no Intranet, Collaboration, or SharePoint references in the Patterns and Practices Center. Elsewhere a document exists which describes how SharePoint was deployed at MSFT, but that's infrastructure and infrastructure is but a slice of a successful deployment. There's an  End-User Training Resource Kit, but it inexplicably describes scenarios (when users need help this is the one time they tend to search for specific features. Example: When you need to create a hanging indent in Word do you look up Proposals or Hanging Indent?) Tools for successful deployment are sorely lacking.

Successful deployments -- where "team site" does not become the new phrase for "data dump" -- require tools to encourage participation. Let users rate content and provide feedback. Let me measure who accesses what content, and when, without writing custom queries. Get the PAG team or Sam's team writing about the social engineering aspects of a succesful deployment. Help potential adopters achieve success.

That's it, only four. Note that these are issues of unrealized potential, and not limitations of the product. All can be overcome by people who care, and all have been overcome by people known for SharePoint expertise. SharePoint is a terrific product. It provides an excellent base to extend, and is the best application integration tool available. SharePoint is a true enterprise hub. It unifies the user interface. It reaffirms .NET as the development platform an IT shop can standardise on. It's just another ASP.NET application, so the maintenance scenario is the same for the infrastructure team. SharePoint simplifies, no question.

Could the skills be easier to learn? Yes. There is room for massive improvement with WSS 3.0. Today there are user groups and other grassroots efforts to facilitate the flow of knowledge. We're lucky in a way that the people who tend to want to master SharePoint have some interest in enabling people and facilitating the flow of knowledge. What surprises me is that the product team itself (with notable exceptions, and another) isn't as involved in the effort as it could be. At the risk of sounding corny, let's collaborate on this.

[Updates: Rewrote the 2nd last paragraph to clarify the scope of the issues and balance the discussion.]