First: I'm sorry. In the post below, I took a fun little journey comparing SharePoint's built-in wiki with MediaWiki. After some first-hand pain with wikis and reading the comments I received on the post, allow me to flip-flop my position and clearly state: SharePoint 2007's built-in wiki will impede any attempt to build a real wiki.
To put this statement in context, your main problems when deploying a real wiki will be to get critical mass. This means, you'll want to get hundreds or thousands (or tens) of individual contributors on your wiki. And you won't want them getting frustrated with the software. You don't want them trying to figure out the 4-step process to uploading an image; you don't want them attempting to build an HTML table (or anything really) using the source view; you don't want them to lose data when someone 'deletes' a page to the Recycle Bin and no one notices for 4 months. Preferably, you don't want them thinking about anything but 'how do I best contribute to this group knowledgebase?' And SharePoint will get in their way.
So, my new statement is: if you need MediaWiki, or something like MediaWiki, invest the time and effort to do so. Don't try to build on top of the minimalist SharePoint wiki. But…
But, with the most basic of needs, and given the assumption you already have SharePoint, and that Integrated Windows Authentication works for everybody, SharePoint is your best bet. Once you start doing 'fancy' things like adding images or attempting to go beyond the built-in WYSIWYG editor, you'll experience pain. Even with some pain, SharePoint's a good choice for small wikis. The original article (starting in the next section) lays out this argument in heavy detail.
Second: The new SharePoint will be out soon, invalidating whatever points I made in this article. Consider yourself on notice: this article is about the 2007 version, folks.
Third: I'm really trying to stop writing these "op-ed" pieces that really don't help anyone. I don't think I introduced any valuable concepts here, just pushed a lot of hot air into the atmosphere. How does this article (and those like it) help? They don't. So, I'll stop.
Final note: I've also flip-flopped on Wiki syntax. It's not that bad after all. WYSIWYG is much more important than markup. And while you're at it, everyone just copy PBWorks, because they have a sweet setup.
A while back I came across this direct comparison of MediaWiki, the wiki engine powering Wikipedia, and SharePoint's built-in wikis.
As you might imagine, the comparison favored MediaWiki. And, as I left an embarrassingly passionate comment rebuttal (in which I link directly back to this address), I feel compelled to write the following post.
The summary is: you probably don't need MediaWiki's extensive featureset for your corporate intranet. Assuming limited needs, SharePoint's wikis are a great, no-maintenance, small-learning curve solution to the "informal team wiki" problem. You can do better feature-wise, but why would you want to? Plus, you already have SharePoint—this is a no-brainer.
Well, let's get with the details.
So, let me start off by saying I hate wiki syntax. Actually I need to clarify: I hate any markup syntax built on top of HTML, and that includes MediaWiki's wiki syntax, the FlexWiki syntax I've used, whatever syntax ScrewTurn Wiki uses (it's different from FlexWiki), and the perennial favorite, [BBcode] markup. I hate all this for two reasons:
We are now presented with the question: but Peter, what alternative do we have?
Just use HTML! Allow me clarify in the next section:
I'm not saying to throw wide the gates and allow everything. It's perfectly reasonable to parse input and allow only specific markup, negating any and all security concerns! And when I say "parse", I don't mean some kind of abomination involving substring searches or even regex.
So if someone types: "Hey, I like to <strong>bold me up some text!</strong><script><!— some nasty js virus bomb —></script>", you know what? You can figure out which parts are legitimate and which parts are no-no! Don't just give up and say "oh forget it, let's just change the <b> to [b] and make our 1 billion users learn this new, inferior syntax." You know what? YOU CAN FIX IT, DON'T GIVE UP!
It's possible; look into it—it's better than inventing Yet Another Markup Language. [[Insert your own awesome YAML joke here!! Ha ha, good one!]]** for the purposes of this bit, YAML stands for "Yet Another Markup Language"
So with Peter's Fundamental Law #14 ("Don't invent yet another YAML") out of the way, let's get back to the comparison.
What are you looking for in a wiki—are you attempting to build "wikipedia for my global enterprise"? If so…I don't actually believe anyone's attempting to do this. Leave me a comment if you are, and if you have implemented MediaWiki in a corporate environment to accomplish this goal. There probably are people attempting to do this, which is fine. I haven't met them, but I'm sure they're out there. Maybe.
But I'm here today to tell you that most of you don't need MediaWiki. You may think you do, but if you actually go out and talk to some of your users, you'll find out: you don't. Your corporation is not filled with anonymous trolls—the trolls are still around, but [[insert your own boss joke here]]. Ow, my sides!
Anyway, MediaWiki is built to work with the semi-anonymous internet, and on a massive scale. You, on the other hand, have a grand total of 30 people in your enterprise who are clued into the fact that the mouse sitting on their desk has a right mouse button, and have a solid understanding of how a folder can contain other folders, and files. There's 30 of you.
The corporate intranet is not the same as the raw, unfiltered wilderness of crazy that is the internet.
Let's just state this as a fact: your IT department does not have linux admins. Or if they do, they're hidden so well you may not recognize them. The point being: when you ask someone to install MediaWiki, you'll be asked: does this thing run on Server 2003, or does it require Server 2008? Um, gusty* gibbon or newer? That sort of answer will not register; please try again.
Oh, and while we're talking corporate IT politics, you may want to avoid using the words "Open Source" or "free" or "third-party" or "custom" or pretty much anything. Also, try and somehow pretend MediaWiki is made by Microsoft. If you say the wrong word, or fail to say the correct ones, you may alert your IT group to the fact that this software is unapproved!
* this is hilarious, think about it
Something else to keep in mind: if IT actually goes off and actually installs the thing, how are you ever going to get access to it? If you haven't learned by now, the easiest application to support is the one with the fewest users. And a good approach to keeping your user count down is to prevent them from crowding in too much in the first place. Zero is the best number!
Let's get down to business: actually comparing SharePoint's wikis to MediaWiki, head to head. I'll take the SharePoint perspective:
If there's one thing you get through your skull—actually, if there's one thing, let's make it Peter's Fundamental Law #14 ("Don't invent yet another YAML")—okay, let's try for two things. If we have room for two things, the second one should be: the intranet is not the same as the internet. When comparing wiki engines, keep this in mind! The intranet is not the same as the internet!
b, blockquote@cite, strong
© Copyright 2014, Peter Seale