I vividly remember working in publishing in 2000. We had just survived what was supposed to be the cataclysmic events of the millennium. Of course, we were not plunged into some dark abyss where power plants stopped functioning and traffic lights started showing green in all directions. Microsoft was talking about moving Microsoft Office to the server. They wanted to play in the document management space. They also had a rag-tag group of folks from Vermeer Technologies who were demonstrating interactive web sites with FrontPage extensions. The result was Microsoft releasing SharePoint Team Services (STS) and Microsoft SharePoint Portal Server 2001 in relatively short succession.
The problem was that STS and Portal Server were as different as night and day. Portal server was built around the Exchange database engine and STS was built around SQL server. Portal server was focused on documents and had versions. STS was built around lists of items and didn't have versions.
Ten years ago there were expensive document management systems were expensive. You only implemented them if you had a major process to automate. Lists were being created with Microsoft Access – or more commonly Microsoft Excel but sharing and managing that list data was difficult. Inside an organization the spreadsheets would fly back and forth. The lists were shared externally via email as well – sometimes unintentionally. Coordinating changes was a huge challenge.
I started building on SharePoint in 2001 with a project designed to improve the ability for a packaging company to communicate with its partners. It was innovative at the time – and it meant struggling through the development on a platform that wasn't really ready for people to program on it. The version of the Exchange database engine that SharePoint used had issues – and it wasn't really designed for what it was being used for so we found quirk after quirk. I vividly remember that none of the monitoring tools would tell us that SharePoint was down because deep in the core SharePoint would send an HTTP 100 Continue message if it ever couldn't respond quick enough. That's great if you're waiting on the database to return a record but horrible if you're in a deadlock situation where the resources are all consumed. It meant that we had to write custom tools to plug into the monitoring tools to detect if SharePoint was down.
The 2003 versions of the software moved Portal Server to a SQL database engine but lost versioning in the process. The net result was organizations that really couldn't upgrade because they had built processes around the versioning – sure there were the backwards compatible document libraries in 2003 – but that was just the same as leaving 2001 around since they still ran on the Exchange database engine and had a completely different set of features which served to create confusion.
By about 2005 my entire world became SharePoint. Instead of doing ecommerce development I was building intranets and integrating systems into SharePoint. Mostly it was moving from a system designed to support external folks to supporting internal folks. The real benefit was that I was used to high-activity web development which most developers of the time weren't used to – and in many ways high volume web sites is still a rarity.
In 2007 portal server was dropped from the name and Office was added. This reflected the much stronger integration to the Office client applications than had ever been possible – but the loss of the word Portal was the definite signal that the world had changed. It used to be that everyone wanted a portal, a place from which everyone would launch into the corporate resources. However, by 2007 it was clear that the word portal was too fuzzy and confusing to be useful. After all, we were in the age of search, not the age of portals. Yahoo had lost to Google.
In 2007 we were finally back where we started with versioning with a few enhanced features along the way, like our new workflow engine. However, the big change was less about SharePoint and more about the transformation SharePoint had caused – or at least participated in. By 2008 the document management market was starting to soften. People realized that the big systems for document management weren't needed so much anymore. SharePoint 2007 might not handle large organization document management needs but most organizations could see value by using SharePoint.
By 2010 we finally had the set of tools in the product to support larger scale document management scenarios. Development tools were integrated into Visual Studio so we didn't have so much heavy lifting. No longer were we hand-crafting XML, Text files and creating CAB files. Finally we can focus on getting things done rather than dealing with the mechanics of SharePoint development.
I had the honor of spending 10 months working on the Microsoft patterns and practices SharePoint Guidance – so we've finally got some good guidance for SharePoint development. In short, I believe we've finally got a platform for development.
Today, we're thinking about enabling corporate developers to create solutions by developing code in the Sandbox. We're looking at enabling organizations to have SharePoint hosted in the cloud. Strangely while I'm having conversations with clients about Sandboxed solutions and the cloud very little of what I do fits in either of these categories.
It's a pretty different world than 10 years ago when I started – but I believe it is honestly a better one – at least when it comes to SharePoint.