Why SharePoint Scares Me

For the past four years or so, at two different organizations, I've been evaluating Microsoft's Sharepoint 2007 as a Portal/Intranet/Business Process Management solution. It's a hard thing to ignore, for numerous reasons:

  • It's an instant, interactive content, document and data management interface out of the box, with strong interactive capabilities and hooks to integrate other databases. If you get the way it uses lists and views to organize and display data, it can be a very powerful tool for managing and collaborating on all sorts of content. As I said a year or two ago in an article on document management systems, it has virtually all of the functionality that the expensive, commercial products do, and they aren't full-fledged portals and Intranet sites as well.

  • Sharepoint 2007 (aka MOSS) is not free, but I can pick it up via Techsoup for a song.

  • It integrates with Microsoft Exchange and Office, to some extent, as well as my Windows Directory, so, as I oversee a Windows network, it fits into it without having to fuss with tricky LDAP and SMTP integrations.

All pretty compelling, and I'm not alone -- from the nonprofit CIO and IT Director lists I'm on, I see that lots of other mid to large-sized organizations are either considering Sharepoint, or already well-ensconced.

So, why does Sharepoint scare me?

  • What it does out of the box, it does reasonably well. Not a great or intuitive UI, but it’s pretty powerful. However, advanced programming and integration with legacy systems can get really complicated very fast. It is not a well-designed database, and integration is based on SOAP, not the far less complicated REST standard, meaning that having someone with a strong Microsoft and XML programming skill set on board is a pre-requisite for doing anything serious with it.

  • MOSS is actually two major, separately developed applications (Windows Sharepoint Services and Content Management Server) that were hastily merged into one app. As with a lot of immature Microsoft products, they seem to have been more motivated by marketing a powerful app than they were in making it actually functional. Sharepoint 2013 or 2016 will likely be a good product, kind of like Exchange 2007 or SQL Server 2003, but Sharepoint 2007 makes a lot of promises that it doesn't really keep.

  • Sharepoint's primary structure is a collection of "sites", each with it's own URL, home page, and extensions. Without careful planning, Sharepoint can easily become a junkyard, with function-specific sites littered all over the map. A number of bloggers are pushing a “Sharepoint invites Silos” meme these days. I stop short of blaming Sharepoint – it does what you plan for. But if you don’t plan, or you don't have the buy-in, attention and time commitment of key staff both in and out of IT, then silos are the easiest things for Sharepoint to do.

  • The database stores documents as database blobs, as opposed to linking to files on disk, threatening the performance of the database and putting the documents at risk of corruption. I don't want to take my org's critical work product and put it in a box that could easily break.

  • Licensing for use outside of my organization is complicated and expensive. MOSS access requires two or three separate licenses for each user - a Windows Server licence; a Sharepoint License, and, if you're using teh advanced Sharepoint features, an additional license for that fiunctionality. So, if I want to set up a site for our Board, or extend access to key partners or clients, It's going to cost for each one. There's an option to buy an unlimited access license, but, the last time I looked, this was prohibitively expensive even at charity pricing.

  • Compared to most Open Source portals, Sharepoint's hardware and bandwidth requirements are significantly high. Standard advice is that you will need additional, expensive bandwidth optimizing software in order to make it bearable on a WAN. For good performance on a modest installation, you'll need at least two powerful servers, one for SQL Server and one for Sharepoint; for larger installations, a server farm.

I can't help but contrast this with the far more manageable and affordable alternatives, even if those alternatives aren't the kitchen sink that Sharepoint is. Going with a non-Microsoft portal, I might lose all of that out of the box integration with my MS network, but I would jettison the complexity, demanding resources, and potential for confusion and site sprawl. I'm not saying that any portal/intranet/knowledge management system can succeed without cross-departmental planning, but I am saying that the risk of a project being ignored -- particularly if the financial investment was modest, and Sharepoint's not cheap, even if the software can be -- is easier to deal with than a project being fractured but critical.

if my goal is to promote collaboration and integrated work in my organization, using technology that transcends and discourages silos, I'm much better off with apps like Drupal, KnowledgeTree, Plone, or Salesforce, all of which do big pieces of what Sharepoint does, but require supplemental applications to match Sharepoint's smorgasbord of functionality, but are much less complicated and expensive to deploy.

After four years of agonizing on this, here's my conclusion: When the product matures, if I have organizational buy-in and interest; a large hardware budget; a high-performance Wide Area Network, and a budget for consulting, Sharepoint will be a great way to go. Under the conditions that I have today -- some organizational buy-in; modest budget for servers and no budget for consulting; a decent network, but other priorities for the bandwidth, such as VOIP and video -- I'd be much better served with the alternatives.


evaluate sharepoint

There are many Intranets solutions on the market, however if you are looking for a solid SharePoint based Intranet solution, check out SharePoint Implementeds’ product. I think it’s the best solution out for the price. They seem to have put a lot of thought into usability and filling in gaps that you would not know exsist in sharepoint until you start your implementation.

They offer a turnkey solution which provides a custom Home Site, Department Sites and Project Sites, installation, configuration and training all under $5,000 and even have a source code option.

One thing that I would love to see that they dont have now is a hosted solution

You can get more details at http://sharepointimplemented.com/AwesomeIntranetGorilla.html

very good article.

very good article.

Your article was helpful.Many

Your article was helpful.

Many Thanks

Peter,I'm glad you've decided


I'm glad you've decided to evaluate KnowledgeTree. A quick heads up: we've recently released a proof of concept Drupal integration module based on the original CMIS module work undertaken by the good folk at Optaros and Acquia.


We'll likely be working to extend this module, hopefully with the assistance of the community.

As an aside, all of the other open source tools mentioned in the comments of this blog are great products and well worth evaluating for this and other use cases. They have varying focusses, technology architectures and levels of "lightweight-ness", but all have strong communities.

Best regards,

Lightweight - I've

Lightweight - I've installed/evaluated AlFresco and I've done a lot with Drupal, but I've never mixed the two. Currently, I'm looking more seriously at KnowledgeTree, a product with a similar feature set and platform as Alfresco. It's certainly possible that I would eventually integrate that with Drupal at some point.

Bryan - I've looked at Liferay (and I brought it up here -- see the third comment). It's an impressive application.

Hi Peter, thanks for the

Hi Peter, thanks for the post. You and your readers might also consider Liferay Portal (disclosure: I work for Liferay) or Liferay Social Office. Both offer great open alternatives to Sharepoint, are more cost-effective and easier to customize than Sharepoint and allow file storage outside the DB as an option. There are tons of different ways to integrate into and out of Liferay and full REST support is on its way in Q4 2009.

Liferay was written from the ground up as a single product and licensing is either the very free and flexible MIT license or a very simple per-server model for our enterprise subscription.

You might also want to check out this link that compares the two products.

Yes, Peter, I'd be interested

Yes, Peter, I'd be interested in knowing whether you've compared a combination of Drupal + Alfresco vs. Sharepoint.

We're seeing more and more interest in that combination.

Disclosure: my business builds Drupal-based intranets for non-profits (and for-profits).

Excellent post. Although I

Excellent post. Although I thought you went easy on Microsoft.

Peter,I work with many


I work with many international NGOs using Sharepoint and they're (the end users) very happy (besides some IT zealotry )...

As many have said Sharepoint must be considered a software suite and as such might have too much functionality (and complexity) for small deployments ... so point solutions are perhaps better for you
but then:
when additional functionality is required which point solution 1 does not have?
what if different point solutions need to be migrated into 1 platform (e.g. Alfresco) ??

Not everything is shortterm and a point solution ...
if the functionality you require is more that simple you'd need to migrate to a suite, Sharepoint, Documentum or Alfresco ...

Hey, SharePoint costs are

Hey, SharePoint costs are scary even for for-profit organisations (although we do have a charitable arm; The Brightside Trust).

£10k for a 100 user SP system for internal users is a lot in anyone's book. Esp. as we'll be using it first for a simple intranet; it compares badly with even CMS systems like DotNetNuke.

Cheers, Rob.

By the way, TechSoup just

By the way, TechSoup just finished a webinar on Sharepoint - you can see the recording (for free)here: https://cc.readytalk.com/cc/schedule/display.do?udc=eqe9hwhgq6e5

Thomas - I knew going into

Thomas - I knew going into this that there would be disagreement. Sharepoint can be deployed well and, when compared to other commercial portals, more affordably and more easily. No argument. But I'd challenge the cost benefit analysis claim you're making by, first, saying "let's talk apples" and eliminate WSS. I'm talking about how a small, low budgeted IT staff can get an internal web site that serves as an Intranet, document management system, dashboard and web application platform, and WSS falls too short on the last two. I'll give that Drupal falls pretty short as well, but I'd pitch Liferay or Mindtouch as open source apps that, while needing hardware, planning and, most likely, some consulting to succeed with, are free of Microsoft's licensing costs and confusion.

PeterI did enjoy reading your


I did enjoy reading your article. You obviously have a very strong understanding of portal technologies and have enough understanding of SharePoint to give a very intelligent opinion; some of the best insights on SharePoint I have read.

One of the things that I think you kind of blew over was the small cost/benefit analysis that you did.

SharePoint will not be right for every company in every vertical.

However, it is almost always the most cost effective way to implement a portal (and so much more). Most companies already own the Office suite - therefore they own the SharePoint platform. Even if they don't have a liscense for MOSS, they can still get WSS if they have only 1 server license (check with your MSFT rep of course on these details). The only cost is really how much hardware you want to throw at it. Technically, you can install it on the same server using a sql server express database and not incurr any cost whatsoever. Now this would not be ideal for a large enterprise, but its an option.

I appreciate your review on MOSS. While I'm not sure I agree with all the points, I can appreciate your opinions and observations.


Thomas Holland

@Peter: Completely agree.

@Peter: Completely agree. SharePoint for tiny IT staff places with no budget is a no-win scenario. However I've found far too many times that people install SharePoint expecting it deliver the world and blaming their failure on it. Also, small IT staff grows. As with any tool, if you use it the way it was intended (or at least try to adhere to original intentions) then you'll never go (too) wrong. However SharePoint gets used as a swiss army knife by those that don't know what they're even trying to do with it. Those small IT shops can happily live with open source free easy-to-setup tools but don't expect them to succeed if they're trying to do enterprise integration with Office clients and seamless workflow and versioning. Applying add-on packs galore to Drupal to meet some need the tool wasn't designed for is not going to create a maintainable environment. The same is true for SharePoint, and well really, any software.

Laura, I haven't done more

Laura, I haven't done more than look at the marketing info for Box.net, so I can't really say. You can get hosted Sharepoint accounts as well, so the fact that they're SaaS isn't really a competitive point. I can imagine that they have a more intuitive interface, because I think one of Sharepoints' biggest problems is that the interface requires training -- hiding all of the commands behind subtlty-placed drop-down indicators is not very user friendly. Users GET links and buttons.

But my goals for Sharepoint -- or whatever replaces it -- are to do dashboards, application integration, and light application development,. I don't think Box.net is selling that - I think they're more like Central Desktop or BaseCamp, offering simple online collaboration. Sharepoint does that as well, but the portal/dashboard/dms/MS integration and application development features are what make it so compelling, not the collaboration features. So I think it's still apples and oranges. The only product I'm familiar with that compares to pretty much everything that Sharepoint is is Liferay.

The MOSS consultants offering

The MOSS consultants offering such great rebuttal/analysis here should remember that the forum we're on is Idealware, where we discuss software for non-profits -- my post could have been titled "Why I think Sharepoint is scary for nonprofits to invest heavily in", but I figured posting it here would make that evident. I work for a non-profit law firm, but I used to work for commercial ones. If I still did, Sharepoint would scare me a lot less - in fact, it would have the added appeal of being a platform that a lot of enterprise Document Management Systems (DMS) and legal-specific applications are bending over backwards to integrate with. And there's a lot of sharp, legal-specific consulting available.

My org doesn't have the budget for any of that stuff. We can't afford the consultants. We have a third of the IT staff, and I wear the CIO/Manager/Developer/Backup Sysadmin/Occassional Help Desk hat. And my org puts more resources and a higher percentage of budget into IT than most nonprofits.

So you can tell me about all of the great things Sharepoint does, and how any competing system will still require planning and investment, and I'll maintain that Sharepoint can only really succeed as an enterprise portal and BPM layer if you have more resources to develop, train on and support it than I am ever likely to have. Products with more modest feature sets that run on less demanding platforms are a safer bet.

Bill - those four years included building numerous sites on WSS, adding web parts, and using them for things like board engagement, project planning, resource scheduling, and information sharing. I've installed MOSS 2007 from scratch, done initial setup, integrated the Citrix MOSS add-on, connected lists to legacy databases, etc. We built a shared research portal for our Major Gifts department last year as a real test of the customization capabilities. We learned good and bad things along the way, all of which led to this article, along with my decision to develop on LAMP and look at Drupal and KnowledgeTree as better portal and DMS options that I can easily glue together. We're still setting up a Sharepoint Intranet, with a very limited scope, and the understanding that we will likely move to a different platform in a few years.

So, I believe that you have had great success with Sharepoint - I've seen impressive things done. But I haven't seen Sharepoint used extensively and well by orgs with tiny IT staffs and budgets, and I bet you haven't, either.

What do you think of box.net?

What do you think of box.net? http://friendfeed.com/scobleizer/e1d573ec/box-net-says-they-have-better-than-sharepoint

I agree with a lot of

I agree with a lot of Eugene's points; particularly that the CMS integration is much better than you'd expect. The previous version of MCMS gave you very little out of the box - to build a working system you had to start doing ASP development.

Also, without some sort of governance *any* enterprise grade collaborative workspace can become a junkyard. I've never seen a system where this wouldn't happen without governance. Heck, spend 5 minutes digging into the inevitable Network File Shares and you'll see that.

I would agree that SharePoint isn't for everyone. Not infrequently I have to point out that for specific tasks, other applications can be smaller, simpler, and better. If your needs are limited, and there is a more focussed app that does what you need, then use that. Or, to paraphrase a colleague "Why use SharePoint over Wordpress if all you want is a blog?"

What we find with some of our customers, though, is that they've taken that approach but for multiple requirements - a blog here, a wiki there, a CMS there - and they're now stuck with this mish-mash of products, technologies, backup strategies, upgrade paths, no centralized authentication, no (or limited) centralized search, etc.. Part of the appeal of SharePoint for them is to move things to one platform.

I work for a firm that does a lot of systems integration - it's a real pain sometimes, and that pain grows exponentially with the number of systems you've got interacting.

While talking about system interaction - don't undervalue the integration with Microsoft Office. To me, this is actually SharePoint's killer app (at least, if you're using Office 2007...)

I think your comment about SharePoint not being trivial hit the nail on the head. You do need to factor need for consultancy, developers, buy-in, on-going governance - and all this does drive up the cost. Ultimately, if you can't afford that - well it's better to try something else than slapping in a SharePoint system without planning.

Oh, and couldn't agree more about the licensing - all Microsoft licensing is absurdly complex...

My reaction/rebuttal/opinion.

My reaction/rebuttal/opinion. Not bashing you Peter on your points, all good discussion.


Peter, I was going to suggest

Peter, I was going to suggest you go the hosted route, until I reread your concern over bandwidth. If bandwidth is a concern, you should not go the hosted route. While you may have a 1000 Mb LAN, you probably have less than 10% of that on your WAN. That can really put a strain on accessing SharePoint, especially when users start working with documents. Also, depending on you user count, hosting can get expensive very quickly, especially for MOSS.

By the way, although I would not classify this as an API, SharePoint does allow you to expos list data as RSS feeds. This can be a very easy, RESTful way to expose SharePoint data to other applications. SharePoint can also consume RSS and other REST type data feeds with the XML Viewer and DataView Web Parts.

Tendaji, I appreciate the disclosure. There have always been communications standards and ways to integrate systems. That has seldom been the issue or the reason for the huge expense for systems integration. The expense usually stems from differing system authentication requirements, data representation, session lengths, widely differing APIs, and user expectations. I do agree with you that integration can be easier now, particularly in geographically distributed topologies, but I would still discourage any organization from even thinking about systems integration unless they are prepared to allocate dedicated resources to maintaining the integration over time. I don't want to put words into Peter's mouth, but I did not get the impression that this was a desirable outcome for him.

Hey, bsrweb (is that

Hey, bsrweb (is that Dean?),

My guess is that hosted Sharepoint would eliminate the opportunity to get into a lot of the trouble that I envision. Most hosting relationships are going to offer fairly out of the box options, ruling out legacy system integrations, custom applications, etc. Those are the things that really concern me. Basic Sharepoint isn't that bad. I still think the interface is arcane enough that it requires serious training, but, as I said, once you learn it, the lists are a good way to distill and share information.

So, yes, hosting is an option if you have modest goals and want an alternative to supplying your own hardware and bandwidth. Make sure that you understand what can and can't be done on the hosted system (can you add third-party web parts?), and make sure that it scales financially. If that met my needs (it doesn't), I'd sweat less. :)

Peter - thanks for a great

Peter - thanks for a great post! I'm glad you are enjoying the benefits of using KnowledgeTree as an easy to use, affordable alternative to SharePoint's document management functionality.

Eugene - great response. Some comments:
* "I began my IT career doing enterprise application integration. I can tell you from experience that getting multiple applications to talk to one another in a way that is meaningful to your end users is always much more expensive than procuring one application. You're generally looking at a 3X cost increase for the labor costs to do the integration."
** The great thing about many modern content management applications, KnowledgeTree included, is a drive towards open, well documented APIs based on lightweight easy to use technologies such as REST. Testament to the ease of use of these APIs is the depth of community that springs up around them.

Allied to this, are open standards around repository integration, namely OASIS sponsored standard, CMIS. CMIS is being rapidly adopted by many ECM vendors, and CMIS clients are now available for popular WCM applications such as Drupal.

Due to significant vendor awareness of the importance of ecosystem, enterprise application integration has in many respects got much easier in the last few years.

* "Don't underestimate the costs of losing integration with the Office desktop applications with which your users are familiar... SharePoint minimizes those costs by leveraging the expertise and familiarity users already have with the Office desktop applications."
** Again, many vendors (KnowledgeTree included) have invested heavily in ensuring that the Microsoft Office and Windows desktop experience is both familiar and rich, and often better than that provided by Office's SharePoint integration!

** Full disclosure: I'm the CEO of commercial open source ECM vendor, KnowledgeTree **

Jason, thanks for the

Jason, thanks for the clarifications. But you might have read some things into my post that I didn't say, such as "SOAP isn't a standard" or "SOAP is bad". All I said was "REST is easier".

I think the fact that Sharepoint 1.0 predates REST is somewhat irrelevant - we're discussing Sharepoint 2007, which came around long after REST was established. Blackbaud managed to introduce REST interfaces to their MS-based Infinity platform a few months back, and I think Microsoft has a few more programmers on the Sharepoint team than they do on BBEC/NetCommunity.

Also, while SOAP is not language-specific, you can only do so much with Sharepoint Designer, a program that we used to all know as FrontPage. For most Sharepoint customizations, you have to load up Visual Dev and, most likely, program in a Basic or C derivative, e.g., Microsoft tools and languages. And XML is required. Don't get me wrong - Microsoft has some powerful languages and XML is great stuff. I'm not knocking anything. I'm saying that you have to have that expertise on your staff to do things that might be available as free add-ons to a Drupal or Joomla Intranet.

I appreciate and agree with most of what you say here, but I stand by my claim that Sharepoint is a complex environment to extend. So only go into it if you know that the investments are justified.

"Integration is based on

"Integration is based on SOAP, not the far less complicated REST standard..."

That's because Sharepoint predates REST. Roy Fielding's dissertation, in which the "REST" concept was invented, was filed in 2000, and didn't really start getting peoples' attention until a year or two later. Microsoft had been investing heavily in Web services using SOAP for a couple of years by that point, and Sharepoint was a poster child for that work.

(Full disclosure: I was a beta tester for the original version of Sharepoint -- back when it didn't have a name yet and was just referred to as "Code Name Tahoe" -- at the same time Fielding was working on his dissertation.)

Also, note that it's not accurate to refer to a "REST standard". Unlike SOAP (which, while Microsoft did the original work on it, was released to the standards community and eventually became a W3C standard), REST isn't so much a defined protocol as it is a way of thinking about how applications should be designed. Because of this, while REST has been hugely influential, it's extremely rare to see a "REST" API that conforms 100% to the description Fielding laid out in his thesis. Far more common are "RESTful" APIs which adopt Fielding's broad principles but fudge on some details (like supporting the full range of HTTP verbs, not just GET and POST).

This isn't a knock on REST, which I believe is superior to SOAP for 99.9% of Web applications; it's just an explanation as to why it's inaccurate to set up SOAP v. REST as "bad Microsoft proprietary technology" v. "good open standard". It's more a clash of philosophies, with SOAP having evolved out of the "software components" model of systems like COM and CORBA, and REST having evolved out of the more loosey-goosey, Postel's Law world of the Web.

"... meaning that having someone with a strong Microsoft and XML programming skill set on board is a pre-requisite for doing anything serious with it."

This is a bit misleading too; just about every popular language has SOAP libraries available for it, though they usually take a little more work than a using a RESTful approach does. This includes open source favorites: SOAP libraries exist for PHP, Python, Ruby, and Perl, among others, either as part of the language's standard library or as an external add-on.

Hey, Eugene!I appreciate the

Hey, Eugene!

I appreciate the rebuttal, and agree that a lot of this is grey area; and some things aren't worth debating. You have your view of database blobs; I have mine; there are plenty of great technical posts out there arguing both of our sides on that one.

My take on this is couched in my understanding of the nonprofit environment - we lack funding, technical expertise, and, in many cases, the bandwidth of our users required to make complex technology rollouts succeed. So my main points are that it might not be worth getting the benefits of all of the things that Sharepoint has to offer. Drupal does a lot less, true, and it can become just as complicated, true; but I can put up a simple Drupal site that enables great communication and collaboration with minimal training required without making a serious investment of time and money; I can't and won't say the same for Sharepoint.

And I'll stick with the point that the 'sites" approach of Sharepoint gravitates toward siloed computing. Yes, you have enterprise search, if the user avails themselves of it. But if all of their departments' data is right on their own site, why will they?

And I also maintain that the expertise required to customize Sharepoint becomes complex very quickly, whereas, with a REST-friendly evnvironment you can do a lot before you need to pull out Visual Dev and start coding in C.

But my post wasn't a complete Sharepoint slam -- it's just an advisement that Sharepoint is not trivial. In environments where you have a big IT Department, programmers on staff, and decent budget for consulting and infrastructure, it's a powerful platform.

I'm concerned that some of my peers are seeing how inexpensive the software is on Techsoup (a site that facilitates software donations) and thinking that makes it comparable to open source. I think Sharepoint requires a much heftier investment than the products I mentioned in order to get the return, and it's an investment that many of us do not have the wherewithal to make.

Good post. Unfortunately a

Good post. Unfortunately a lot of people share your viewpoint. I wanted to share my perspective on some of your points...

"advanced programming and integration with legacy systems can get really complicated"
- I think this is true of all technologies, not just SharePoint.

"MOSS is actually two major, separately developed applications (Windows Sharepoint Services and Content Management Server) that were hastily merged into one app"
- CMS was integrated, but the integration is better than one would think. It works very well for intranet and extranet scenarios. SharePoint for Internet sites can still be a challenge, but a fair amount of large Internet sites use SharePoint today.

"Without careful planning, Sharepoint can easily become a junkyard"
- This is true of any content repository. The integrated search helps a great deal with content discovery, especially for new users, and the content expiration and records management features help to keep archives from cluttering up the works.

"Licensing for use outside of my organization is complicated and expensive"
- Check with you MS sales rep. If you're a non-profit, you may qualify for better pricing. The unlimited license is typically used only by public Internet sites that don't want to or can't track individual users. Intranets and extranets should use the per-user license. You may also get a volume discount as well. You can also start with WSS for core collaboration and document sharing, and move to MOSS later, if you need to. WSS is included with the Windows Server license.

"Compared to most Open Source portals, Sharepoint's hardware and bandwidth requirements are significantly high"
- The great thing about SharePoint is that you can start small and scale out as your neads grow. Start with a small pilot group of users. If more people want to join in (and they will once they see what SharePoint has), add hardware then. You can even scale up servers without taking the farm offline.

"The database stores documents as database blobs, as opposed to linking to files on disk, threatening the performance of the database and putting the documents at risk of corruption."
- This typically works better than storing the documents on disk. You are able to leverage database transactions, load balancing, backup, maintenance, and failover to guarantee uptime and ensure disaster recovery.

"I'm much better off with apps like Drupal, KnowledgeTree, Plone, or Salesforce, all of which do big pieces of what Sharepoint does"
- I began my IT career doing enterprise application integration. I can tell you from experience that getting multiple applications to talk to one another in a way that is meaningful to your end users is always much more expensive than procuring one application. You're generally looking at a 3X cost increase for the labor costs to do the integration.

"I might lose all of that out of the box integration with my MS network"
- Don't underestimate the costs of losing integration with the Office desktop applications with which your users are familiar. User productivity loss and user training costs are two very high hidden costs to deploying any CMS or collaboration system. SharePoint minimizes those costs by leveraging the expertise and familiarity users already have with the Office desktop applications.

For my company we took the opposite approach: we brought SharePoint in house and outsourced the VoIP. So far, that’s worked very well.

By the way, you should really check out the SharePoint 2010 videos Microsoft just posted:

I appreciate the bit about

I appreciate the bit about licensing. I recently came across an 86-page "Windows 2008 Server Licensing for Dummies" book, and was similarly dismayed that 86 pages was the "easy" version:


I'm with you; I have a long

I'm with you; I have a long planned post on "skinning Drupal", which I find to be the swiss army knife of CMS'es. I use it for diverse things like news aggregators (http://nptech.info) and, at work, document sharing extranets. The trick is that you can limit all sorts of functionality in order to make it very focused and easy to use, building an intuitive menuing structure on a simple taxonomy. great stuff.

There are some great products that I didn't mention in teh post -- if you like Friendfeed, butw ant something less public, look at SocialCast, which is kind of "Friendfeed for Corporate" and free for most uses.

If you really do need something that is powerful like Sharepoint, I would at least compare it with Liferay, an open source Java portal that includes a whole suite geared toward MS Office compatibility; and Mindtouch, an ASP.NET collaboration platform that glues legacy systems to a Web 2.0 interface.

Excellent post, thanks! I

Excellent post, thanks! I concur. As a user, I keep coming across the non-trivial problem that the visual design of the interface itself does not encourage collaboration and participation. All of the basic functionality is there, but it just is not fun or easy to use.

I'm a big champion of tweaking Friendfeed or Drupal for in-house sharing and collaboration. I realize these solutions may only cover a small portion of Sharepoint's potential, but organizations need to consider: if they build it (in Sharepoint) will people come? Because if they don't, that's a lot of wasted resources.

Nice write-up, Peter. Any

Nice write-up, Peter. Any thoughts on outsourcing Sharepoint hosting? It would lessen the costs not having to buy and maintain the hardware.