Comparing SharePoint to Confluence?
March 6, 2009 5:29 AM
Last week Martin Seibert at Seibert Media wrote an interesting blog post where he evaluated SharePoint as an enterprise wiki.
He posed the question, is SharePoint really a good alternative to a fully developed company wiki? He draws his conclusion early and then presents a list of compelling arguments as to why SharePoint is not a good wiki alternative. He cites many feature-specific examples like
it cannot be implemented as a an extranet wiki because it only supports Internet Explorer.Martin's post is a must-read for anyone considering using SharePoint in place of an enterprise wiki.
What about future versions?
While Martin does a great job describing the state of things today, the question remains as to what tomorrow will bring for SharePoint wikis. After all, Office 14 is supposedly just around the corner, right? Can't Microsoft just address some of these feature gaps in their next release? How hard can it be to add Firefox support or support for wiki markup?
A Different Approach
In all fairness to Microsoft, SharePoint is not designed to be an enterprise wiki alternative. That's why the The SharePoint Dev Wiki is built on Confluence. SharePoint 14 will address many of the complaints made by SharePoint wiki users, but an enterprise wiki is not so much a bundle of features as it is a philosophical approach to collaboration. It's about transforming your corporate culture into an opt-in culture. Here are four reasons why SharePoint doesn't try to be an enterprise wiki:
- Security model - Martin explains that:
In MS SharePoint, new elements are often published and available only for the user themselves.
SharePoint takes a security approach opposite to that of an enterprise wiki. An enterprise wiki assumes openness within your company and restricts access only on an as-needed basis. As Walton Smith of Booz Allen Hamilton told me this morning,The goal of Enterprise 2.0 is to have complete openness and transparency within the confines of a secure employee community.
In other words, keep the bad guys out but ensure that your employees can see content from all across the organization. - Desktop focus - SharePoint was designed as an extension of MS Office to provide online storage and better sharing of Microsoft Office documents. In fact a recent report shows that SharePoint customers primarily use it for file sharing. While Microsoft may invest in improving the SharePoint wiki template, their core focus will remain on desktop integration. The majority of your SharePoint content will continue to reside inside Word, Excel and PowerPoint files uploaded to SharePoint. An enterprise wiki like Confluence, on the other hand, strives to make all your content viewable and editable right inside of the browser. (Confluence 2.10 even lets you view MS Office documents without opening them.) A wiki is browser-centric while SharePoint is desktop-centric.
- Overwhelming Economics - Microsoft's desktop approach is understandable when you look at the underlying economics. About 30% of Microsoft's total revenue (~$18 billion annually) comes from Office, most of which is comprised of desktop productivity apps. Why in the world would Microsoft suddenly tell customers to start creating and sharing content inside of a browser-based wiki when they make literally billions of dollars from their Office desktop apps? It would be corporate suicide to transfer their devoted corporate Windows/Office users at $300 or more per seat to a browser-based wiki at <$50 per seat.
Others have noted this challenge in other areas of Microsoft's business. As Robert Scoble once identified:
Being tethered to its Windows cash cow limits Microsoft from competing effectively against Google in online advertising.
- Comments - Martin points out that:
SharePoint has no comments - or discussion function, which is the norm in well-developed wiki systems.
SharePoint does have built-in discussion boards but they're much different than comments at the bottom of a Confluence wiki page. Comments in a wiki page allow a conversation to evolve from the content in the body of the page. For example, if I write a marketing white paper in a Confluence wiki page, other Atlassian employees can contribute by commenting directly in the page or even editing the page itself. This notion is quite different than the SharePoint approach which treats your documents and conversations as separate entities.
Understand the Difference
Document-centric collaboration systems like SharePoint certainly have a place in the universe. Atlassian has always maintained that SharePoint is an excellent tool for storing and managing online Office documents. That's why we partnered with Microsoft to build the SharePoint Connector. Martin's post forces us to think about the differences between the wiki way of collaborating and the SharePoint way of collaborating. Those differences run deeper than a few superficial features like browser support and wiki markup. At it's core, Sharepoint strives to be something different than an enterprise wiki.
***Added on March 7, 2009***
Coincidentally, the day I posted this ThreeWill launched their SharePoint Depth Community built on Confluence. Read the full press release here.
Copyright © 2009 Atlassian Pty Ltd.
14 Comment(s)
Great article. This is perfect ammo for use at work where I'm struggling to get Confluence in under the radar while management pushes Sharepoint.
By Jim Priest at March 6, 2009 1:07 PM
Bill,
This is right on time, as I'm currently in a discussion comparable to Jim.
I understand that the concepts behind document management and wiki are completely different, but people tend to compare features. I.e. sharepoint advocates tend to say that sharepoint has a 'wiki' option, and therefore there is no need to go to confluence ...
Do you know if there is a feature to feature comparison between sharepoint and confluence, which helps making an objective decision.
By Francis Martens at March 6, 2009 7:16 PM
Great article Bill! Another thing to factor in is the total cost of ownership - SharePoint generally costs an enterprise in excess of $500,000, whereas TCO for Confluence is generally around $125,000 (if you include a 24/7 SLA for staging, development and production environments). Not something to be overlooked in the current financial climate ;)
By Guy Fraser at March 6, 2009 11:00 PM
@Francis - Are you trying to get me into trouble with Microsoft? :) I honestly haven't been able to ever find a comprehensive list of SharePoint wiki features (not even on the wikimatrix). At this point I understand the SharePoint wiki to basically have:
* a text editor with with basic formatting options
* upload and embed images
* link to other pages with [[link]] syntax
* basic versioning with rollback
* change notifications
There may be more but it's not apparent. To quote this wikisym article, the end user features lacking are:
This is according to the article, however...not from my own experience.
By Bill Arconati at March 7, 2009 7:59 AM
This article completely misses the point and falls into the same "SharePoint is a Wiki/Blog/Enterprise 2.0 app" trap, because it isn't. It's a framework with some rudimentary functionality covering many areas like document management, enterprise search, WCM, workflows, etc. Yet, it does not perform great in any of these areas because it is intended to be customized to meet the companies requirements.
Microsoft has done a great job in selling it as something different and CIOs just love document management, workflows and enterprise search being available out-of-the box, which again, isn't. You'll need some highly trained specialists to deploy and maintain a high available and reliable SharePoint infrastructure. It is therefore not feasible for small companies; they are better off with other solutions especially in less MS-centric environments.
Apparently, the author of this post fell into the same trap, assuming that the built-in Wiki is comparable to other well-established solutions. Unfortunately, while most anticipated, the Wiki and Blog functionalities are the worst parts of WSS/MOSS. They are actually useless.
By Steve at March 7, 2009 8:11 AM
@Steve - thanks for the comment, Steve. You raise a good point that the built-in SharePoint wiki is NOT comparable to other well-established solutions. In fairness to the folks at MicroSoft, it wasn't intended to be a best-of-breed wiki. The goal of my post was to think beyond the feature set and distinguish between the SharePoint approach to collaboration and content management and the wiki approach to collaboration and content management. Comparing the features of Sharepoint's wiki to the features of an enterprise wiki is like comparing Apples-to-Oranges, just like you see in the picture:)
By Bill Arconati at March 7, 2009 9:54 AM
Bill,
I am the first to admit, as you say, that SharePoint Wiki is not (and was not intended to be) "best of breed". In particular, the lack of "wiki markup" beyond page references, and no comment facility are granted as marks against it (though the comment issue is addressed by a community add-on, this is not supported by Microsoft, and therefore not considered truly mitigating for purposes of this discussion).
However, your article takes as givens several incorrect or potentially misleading statements carried over from Martin Seibert's article. In addition, you are making certain generalizations of the SharePoint wiki site's philosophy based on other aspects of SharePoint.
1. "it cannot be implemented as a an extranet wiki because it only supports Internet Explorer."
This is not entirely accurate. While by default Firefox editing support is limited to plain-text, Microsoft has contracted with Telerik to provide a free version of RadEditor, which provides full rich text support. This component also addresses several other SharePoint Wiki weaknesses, as I describe in a blog post: http://woodywindy.spaces.live.com/blog/cns!773832677F575173!485.entry The use of RadEditor is fully supported by Microsoft.
2. In MS SharePoint, new elements are often published and available only for the user themselves.
This statement is very misleading. SharePoint does have an option in certain lists to enable an "only their own" permission. However, the Wiki library is not one of those lists. In addition, even where it is available, that option is not enabled by default.
Or, perhaps he refers to enabling an approval workflow? This also is possible, but is not the default state of a SharePoint wiki.
3. You further state: "SharePoint takes a security approach opposite to that of an enterprise wiki. An enterprise wiki assumes openness within your company and restricts access only on an as-needed basis"
This is incorrect. While SharePoint does support user authentication ("a secure employee community"), restricting the access is a choice made by the people deploying the Wiki site, not by SharePoint or Microsoft. It takes the mere addition of the "Authenticated Users", or any other appropriately scoped group, to the Members role to make a SharePoint Wiki fully accessible to anyone in the organization.
Or is this a case of "damned if you do/damned if you don't"? Microsoft has taken a great deal of heat in the past for having security defaults set to "open", so they chose to require you to turn on user access. Now you tell them that this makes their product incompatible with the wiki philosophy.
4. "Desktop focus - SharePoint was designed as an extension of MS Office to provide online storage and better sharing of Microsoft Office documents…An enterprise wiki like Confluence, on the other hand, strives to make all your content viewable and editable right inside of the browser…A wiki is browser-centric while SharePoint is desktop-centric."
No again. While SharePoint has document library capabilities, and Office has the ability to see these libraries as if they were a file system, this has nothing to do with the SharePoint Wiki functionality. In fact, of the many list types supported by SharePoint, only a few are designed around storing documents from desktop applications. Other than the "true" document library, almost all of them, even the ones that *can* interact with desktop applications (e.g. Outlook calendar sync), are fully browser editable and have no *dependency* on desktop applications what-so-ever.
Additional Comments:
Because SharePoint Wiki is available both as a stand alone site type, as well as a library, you have a great deal of flexibility around how much "extra" SharePoint functionality you include. For example, you can include document or picture libraries along with your Wiki library to allow the uploading of supplemental information.
The Telerik control I mentioned earlier, in addition to providing rich-text editing for non-IE browsers, provides significantly enhanced resource management, so that you CAN upload and re-use images, and browse easily for links directly during the page editing process.
As for your commenters, for now, I'll just say that I disagree with @Steve and @Guy with regard to SharePoint as an application rather than a platform (I believe it is fully usable as both), and the amount of support it takes to deploy in a SMB environment. I challenge them to show me another system that does what SharePoint does and is easier to deploy with comparable levels of over-all functionality. If all you want is a Wiki, you don't have to spend anywhere near $500k to get it on SharePoint. But a wiki is very rarely the only thing that you want, and so you have to add the total effective cost of whatever else you are implementing to that 150K TCO figure for Confluence before you start comparing it to a full MOSS Enterprise deployment.
- Woody -
By Woody Windischman at March 7, 2009 12:15 PM
Bill, good post. Out of curiosity, is Confluence the apple or the orange?
As someone who uses both SharePoint and Confluence and as a contributor to the SharePoint Connector I agree that Confluence is clearly a superior wiki. There really is no comparison. If you use the SharePoint wiki, it can get frustrating pretty quick (believe me, I know). Some clients of mine will stick with the SharePoint wiki, but that's usually because they are not willing to undertake another system or because they don't know what they are missing (i.e., they believe a wiki is not that important). Yes, I'm sure Microsoft will improve their built-in wiki vastly, but doubt it will come close to Confluence anytime soon (if ever).
On the other hand, as already mentioned, wikis are not SharePoint's focus. In fact, many people do not realize SharePoint's full power and think it is just a document management system when it is much, much more.
My hope is that decision makers choose the best of breed and realize that the two can work together. I have seen tremendous growth in both Confluence and SharePoint and expect that to continue in the future. Here's hoping that the SharePoint Connector for Confluence continues to grow and improve over time and allow us to use the two together without worrying (or even noticing) which technology is helping us be productive.
With regards to Guy's remarks about TCO, make sure you take into consideration what the enterprises are using Confluence and/or SharePoint for as they are not really interchangeable; hence the apple and orange image that Bill so deftly provided. I have also seen several small and mid-sized companies use SharePoint with very low TCO. Some opt for the license free version (WSS v3 instead of MOSS 2007) and only have to pay for the Windows Server and SQL Server licenses which they typically already have as well as the in-house expertise on those systems. Some of these companies have *very* thin IT departments. Of course there are hosted solutions available as well.
With regards to Woody's comments (gosh, I hope mine aren't as long), I agree completely with #1 through #3 and agree partially on #4 :-). Microsoft does want to keep people using the Office client and pushes that compatibility with SharePoint.
In closing (I'll get off my soap box now), I would not look at this as Confluence vs. SharePoint, but rather what business problem do I want to solve, what are my options for doing so, and who can I partner with to help me get there (that's where ThreeWill likes to come in). Sometimes a hybrid approach is best.
By Kirk Liemohn at March 7, 2009 2:34 PM
@Kirk,
Nice response! FWIW, I think SharePoint is the Orange. Oranges look like a monolithic fruit, but inside that tough skin are lots of juicy segments, just like the many aspects to SharePoint that become apparent when you look under the covers. Confluence is the Apple. It does one thing, and does it very well indeed.
My point in number 4 wasn't that Microsoft doesn't push the compatibility. Of course they do. I simply meant that the compatibility wasn't the "driving force".
Yes, SharePoint and the Office client suite are synergistic. But neither is "lost" without the other. That is what I felt @Bill was trying to imply in his Point #2 - that SharePoint was so tied to the Office client that it wasn't worthwhile to deploy on its on merits.
By Woody Windischman at March 8, 2009 11:22 AM
Hi Bill,
thanks for picking up my blog post here. What a pleasure. :-)
That said, I also have to admit and to disclose, that I have been criticized for it just as well as I received praise for it (see here in the German post: http://blog.seibert-media.net/2008/11/arbeitstechniken/ms-sharepoint-als-wiki-wenig-funktionen-nicht-kompatibel/). Everybody should know, that a lot of things in the article, do not stem from my own expierience but from an open space session on WikiSym 2008 in Portugal, that I led. There were a lot of people, that were talking out of frustration about Microsoft Sharepoint as a collaboration and enterprise wiki solution and I picked up their complaints in my blog post.
Then I was passed a MOSS 2007 account, to test MS Sharepoint myself. I only did in an empty "space" and for not more than 90 minutes. That is, why some of my criticism might be wrong or shallow.
But the message remains stable: "Do not use Sharepoint as an enterprise wiki!" :-)
And yes, it has been a reaction to clients that are pushing for Microsoft Sharepoint, but wanting an enterprise wiki. Hear my words: You are better of, when you keep your Sharepoint instance and enhance it with Confluence and the sharepoint connector. There are lots of good consultants to help you with that out there. :-)
I hope, that my contents will be picked up, analyzed and discussed to clear out errors in my argumentation. I am looking forward to joining this discussion.
I envision, that eventually, Microsoft will come up with a reasonable solution. But I do not expect that anytime soon. :-)
Bill: Keep up your perfect work on Confluence and Jira.
Best regards
Martin Seibert
By Martin Seibert at March 8, 2009 11:20 PM
At CustomWare - We work with both (Gold Certified MS Partneres and Lead Atlassian Services Partner)
We see the typical scenario as: SharePoint top down, Confluence bottom up and there is room and need for both in the enterprise.
By Rob Castaneda at March 10, 2009 9:24 AM
@Bill - of course I'm running a head-to-head against MS.
Great comments here, it is very helpfull to help the customer make a choice. What I'm getting out of it, is that both Atlassian and MS are providing a framework for easy sharing of information. Each with there own flavors of underlying technologies, support models and costs. Atlassian's use of, and compatibility with, open source technology (databases, application server, plugin framework, ldap...) are strong arguments in favor of Atlassian, and need to be incorporated in any objective decision a customer might make. Customers who have the capability to invest in both technologies should do it to benefit from their integration.
Francis.
By Francis Martens at March 10, 2009 9:41 PM
Hi Bill,
nice post, and it certainly started an interesting discussion. I totally agree with you that comparing the features of Sharepoint's wiki to the features of an enterprise wiki is like comparing Apples-to-Oranges. By definition, SharePoint is something completely different than an enterprise Wiki.
If all you want is a Wiki, you don't have to spend your time on implementing SharePoint. There are better solutions out there. But a Wiki is very rarely the only thing that a company wants, and if SharePoint does the most things you as a company want, then it is very easy to add some 3rd party Wiki functionality and that way satisfying your need for an enterprise Wiki as well.
So no, in my opinion it does not matter that SharePoint out of the box is not suitable as an enterprise Wiki because SharePoint was, and is, not intended to be a best-in-class Wiki engine.
Cheers,
Henrico
By Henrico Dolfing at May 2, 2009 2:18 AM
Bill,
I took the time to read Martin Seiberts post and to summarize his post in a few words:
"I never read something comparable with that huge amount of mistakes, wrong information and personal opinion"
My opinion ?
His post is worthless !
I am sorry to use these strong wording but he really compares apples with oranges. I basically agree with lot's of opinions in this thread (SharePoint wiki is absolutly not best-in-class), but his summary is based on VERY VERY limited knowledge of SharePoint. I am very surprised that you ask the people to read it and understand it as a "must-read"
"Martin's post is a must-read for anyone considering using SharePoint in place of an enterprise wiki."
How can somebody who seems to have never worked longer than 5 minutes with SharePoint set up such a comparison and such a summary ? And you start to run into the same direction ?
Man, I would NEVER EVER compare one product with another when I know only one of it - would you ?
If you REALLY read his post with some SharePoint knowledge in mind you would understand me.
Coming back to your "must-read-MartinSeiberts-Posting" request.... I can anwser:
"Read it if you are NOT interested into a fair comparison of both technologies and if you don't want to re-think your opinion !"
Regards
Martin
By Martin Schlenker at May 31, 2009 5:39 AM