Uhm.. Seriously? You are really kidding me.. I mean REALLY? It is not any of those things boasted--not remotely close. I worked with Sharepoint for the last two years, installing, administering, and using for a state university. It is absolutely the most unrecommendable software product I have EVER worked with. It has worked reasonably well (not great) only for one purpose for us: a document repository. Version control only really works when using Microsoft Office 2007. Otherwise, it'll wipe out your version histories.

(1) Ease of installation -- It's highly complex. You really do need to read the 700 page book Microsoft has to know how to install it. This is because numerous options at install time cannot be changed later except by re-installation. And I mean many numerous options that are very difficult to understand how each relates to the other.. We reinstalled so many times, paid for expensive consulting both with Microsoft and with an outside firm. We still couldn't get it right. The nuances are many and hit you repeatedly often with the only fix being a reinstallation.... and usually rebuilding of content, along with it.

AND users almost universally hate it. Management fights hard against the wishes of users to implement Sharepoint--not only at our organisation but also at every other organisation I've had to privilege to ask their sysadmins about. Management usually hails its success but on the ground, it's almost universally hated and a disaster. Oh, yes.. Our universities library system also had a successful use of a simple trouble ticket management system... so there were two exceptions. It's also easier to install and administer as a single server than as a farm, but still not so easy and no easier on users.

I cannot stress enough--the problem with Sharepoint are the many many MANY critical nuances.

(2) Inexpensive -- No. It's very expensive. The learning curve is quite high so training is really required. In our case, the expense was bundled in with a variety of other software licenses such as that for Exchange. Alone, the license is very expensive--particularly if you want to open it up to outside your organisation's intranet.

But the real expense is in administration. Both training costs, immense amounts of time spent with it, and dealing with problems ongoing are the highest costs I've ever seen for a server application. Upgrades are also a huge difficulty. They present as opportunities to resolve some former configuration problems but taking advantage thereof often means your data is not restorable.

Of all the alternative applications I've worked with, "Typo 3" is the most Sharepoint-like, functionally. It is, however, far easier to learn and it is reliable. Sharepoint is reliable only in the sense that its processes keep running--that doesn't mean it doesn't break regularly. The best general purpose CMS I have worked with is definitely Drupal. Drupal lacks some of the capabilities of Sharepoint (presuming those capabilities were actually usable in Sharepoint in any meaningful sense) but has many others.

The problem is that Sharepoint is not exactly a CMS. It is (and I am speaking in theory--not practice in practical terms) a collaboration environment. There really is a difference. Drupal itself has a learning curve that I don't like. It's more administrator focused and not user focused, as manifested by the fact that you cannot edit things were they are seen by users but rather must work through a back panel. Drupal also lacks a WebDAV document repository and the ability to do things like email in documents and other kinds of content and get email notifications of content or documents modified.

Drupal is about setting up a classical website for users to use and administrators to administer. Sharepoint (in theory) is about providing a service where users can create their own sites, document and data repositories and means of presenting and sharing the same (via tags and filters). It's about working together within an organisation or across organisations (for authorized individuals). So the open source world really doesn't have an alternative to this that I can find.. Except maybe Typo 3, I need to review that one more to know for sure. The most unappealing thing about Type 3 for me, so far, is it's hideously ugly default theme (hint: orange and white).

SO WHAT MAKES SHAREPOINT SUCCESSFUL?
From what I experienced, it's Microsoft's way of selling it. They focus on the decision-maker's carreer and vanities. They talk about the product, in theory--and it's a good idea, in theory. They offer him/her opportunities to talk about their experience with the product at prestigious conferences, trade shows, and to be interviewed by journalists, etc. Decision-makers take pride in these and put them on their resumes/vitas. This also leads to more marketing of the product for Microsoft--it's free and valuable labor for Microsoft. They hint on the prospect of grant opportunities to help develop specific uses for them, in Sharepoint--and never deliver. Once the product is sold internally and implemented, too much is invested to go back. Decision-makers find themselves in the awkward position of having to continually esteem the product regardless of emerging realities. This is for the sake of their own carreers. Oh, and they also offer to send people to help you out and to develop some of your requirements into the next release. Sometimes they do send one or two people, briefly but usually that's not technical help.. It's more selling. They took our requirements but utter ignored every one of them in the next release.

As you talk with other people's experiences in their organisations, with regard to implementing Sharepoint, you find their experiences are similar... at least, for those who were near enough to the decision-maker, to see this.

Matthew

Relational databases need to die. I loved them and preached the goodness of them 10 years ago, but they are just too rigid for contemporary needs. I've learned better ways of organizing and filtering data.. but the old RDBMS school is too canonical (stubborn) and self-indulging to realize that needs are changing and their model doesn't fit.

We need efficient attribute/value models. We need to stop referencing data by where it is and start referencing it by what it is. There is too much data that needs to exist in different views, based on policy--not explicit placement.

Dumb-tags (attributes without values) like those used with Delicious bookmarks are also broken. They are too vague.

My own approach is that every attribute may have any number of value instances. Each value instance may, in turn, have sub-attributes. So you can look up data based on its characteristics even with disregard for its name. For example: /mycompany/mailserver1/ip of zone = infirewall

This returns all IP addresses under the "zone" attribute while also under the mailserver1 attribute that is under the mycompany attribute.

When validating instances of the "ip" attribute, it looks backward in the path because it is extremely quick that way.

The data server's sole responsibility is storing and retrieving information (not just data) in context (aka filtering).

Sorting is the responsibility of the client. This makes sense because there are an infinite number of algorithms one could have for sorting data (e.g. alphabetic mixed case, ASCII order, etc). To facilitate this, I wrote a method to return the number of values that would be returned if the values were requested. If too big a bite for the client, it can re-request the size of a smaller chunk, segmented according to the client's ordering method. This is useful for scale, in any case. Processing in chunks makes sense whether over a network of limited capacity or from directly form disk with limited memory.

And--this is a columnar approach like Google's BigTable is.. That means you get 10+ times faster read performance.

Matthew