title: The sinkhole that is SharePoint link: https://onemoretech.wordpress.com/2009/02/16/the-sinkhole-that-is-sharepoint/ author: lembobro description: post_id: 376 created: 2009/02/16 20:24:12 created_gmt: 2009/02/16 20:24:12 comment_status: open post_name: the-sinkhole-that-is-sharepoint status: publish post_type: post

The sinkhole that is SharePoint

If corporate Information Technology is a swamp, Microsoft SharePoint, the big software vendor’s wannabe-wiki, is a sinkhole. Not only will it gobble up all your valuable knowledge assets in its cumbersome, impossible to customize, proprietary document-centric framework, but it will siphon off what’s left of your collaboration solutions budget in the process.

Oh, if only you’d deployed MediaWiki instead! What I’d like is a count of all those companies who started out using SharePoint to share documents and then had to dial back because of the crushing expense of licensing as the user base grows.

So, what would it take to convert a SharePoint site to MediaWiki anyway? The trials and tribulations of at least one guy who did can be found in sharepoint to mediawiki. The basic issue with converting from SharePoint to MediaWiki (or any other information sharing framework, for that matter) is pointed out by the author:

When I first looked at converting a SP page to MW, I figured I could just read the HTML and do an HTML->Wiki conversion. Since MS adds a proliferation of style-related junk this is not so straight-forward. My opinion is that font-effects should be tied to styles, and so now the issue is to remove all extraneous styles, and just keep the basic document information and hierarchy.

The problem, of course, is that most SharePoint “pages” aren’t HTML pages at all. They’re binary documents in one of Microsoft’s proprietary Office formats. SharePoint is, after all, really just an Office document management system. Of sorts.

Some more commentary can be found here and here.

Another problem with SharePoint is only partly Microsoft’s fault. This is in how it’s deployed in many corporate environments, but does flow from the different design philosophies involved. From the first thread linked above:

MediaWiki espouses openness and access, whereas SharePoint has a rigid hierarchical, siloing access control system. MediaWiki handles both edits to content and hosting that content; SharePoint expects content to be edited elsewhere and manually imported.

The SharePoint approach becomes a real problem when taken to it’s natural end, as pointed out by the same list member:

Speaking from experience, I used to work for a company that used SharePoint. It was horrible as a documentation distribution solution due in large part to the corporate attitude towards ownership and permissions. So documents would stagnate as the corporate structure would shift (people changing teams, responsibilities, etc). Then, even if the document you need exists, there’s a fair chance you wouldn’t be able to find and view it due to read permissions - and if you could, it was a near certainty you wouldn’t be able to upload a new version if info therein was bad.

I sometimes think that most SharePoint users would be just as happy with a WebDAV share or two (or three or four…). The whole website edifice seems superfluous to the basic use to which they put it. And WebDAV can be deployed without paying for licenses to cover all your users.

For those IT departments that just must spend real money (as opposed to the internal allocation of salaried employee hours) on whatever solution they implement, there’s always Alfresco or Atlassian’s Confluence. Both use J2EE rather than PHP (MediaWiki), Python (MoinMoin), or Perl (Slash).

Copyright 2004-2019 Phil Lembo