Developer Documentation: Sharepoint Document Management vs. ScrewTurn Wiki

I'm hoping this is going to be some use - extra points or not :)

SharePoint Server (SPS) or Windows SharePoint Services (WSS) is VERY good if you are working with office documents - you can version, check in/out, share, search etc. I dont think there is anything on the market which comes close for that function (it also does custom lists and stuff really well).

But as you point out, the WIKI function is, well, sub-standard.

For developer documentation, a wiki is much better, as you can easily interlink documents, and even if for the sole reason that developers tend to LIKE the wiki markup! Makes it feel like they are writing code, not a document. Well, ok, I like it. Word documents? endless frustration, especially for code snippits and things like API's. Wikis' usually handle code and structured formatting really, really well.

But here's the main point of me posting:

If you can host ASP.NET - and if you have SPS you can already! - then just install BOTH OF THEM. Make a new IIS virtual host, put STW in that one ('cos SPS will be in it's own virtual host)*. Massage the DNS a bit (so you can hit http://wiki or something), and just go for it.

As it's all internal to your company, and STW has windows security and versions, security isn't a huge issue. Each page can be linked to from anywhere - it's an HTML page after all - so you can link to it from the SPS wiki if you really want to. There is some lock in, I guess, but not a lot.

Here at BBC Worldwide, we use a number of technologies:

• Atlassian Confluence (WIKI) for some projects. I love this wiki, but it IS a big enterprise-y system.
• Screw Turn for some intra-department stuff.
• Trac for some other stuff (someone else set it up with SVN on our source repo, so it's used a little - it's nice, I rather like it, but it's a a*se to setup)
• SPS/WSS for documentation management.

there are links between

First, check out this StackOverflow thread. A similar question was asked about Sharepoint wikis, and the answers there both pro and con are really useful and outline the "impossible in Sharepoint" part of your question.

I'm in the middle of trying to implement a team wiki in Sharepoint right now for almost he exact same thing as you, after having used Sharepoint for team documents for a couple years. My observations:

Sharepoint Document Libraries

My experience is that Sharepoint for documents is decent. It can be flaky and you'll sometimes lose edits or have performance issues, although a good Sharepoint support team can help with some of that. I did find the Sharepoint document libraries better than storing things on the network. It makes the docs and libraries easy to link to. Judicious use of the metadata properties can make a Sharepoint list view very useful for seeing what the document is, what it's for, and what status it is in, so our analysts, PMs, developers, etc., all know at a glance who has the ball and when something is waiting on them. That was started for a project a couple years ago; today Sharepoint 2007's workflows can probably provide notifications.

There's also version control for the documents. But as some others have noted doing things in documents has overhead and flaws involved in composing, downloading, and sharing. Check-outs of documents help, but loose cannon developers can download docs, edit them, and than store them elsewhere thus defeating the version control. This has happened to us, although that's a discipline issue and not Sharepoint's fault.

Sharepoint Wiki

Per the Chris Hynes answer, friction is a good word to describe the issue. For quick reference of a team's internal infrastructure details the wiki seems to work better for us. The wiki makes the data almost instantaneously visible, without having to

Nobody could ever be happy with the SharePoint wiki by comparing it to any other wiki system.

So, don't compare it. It has the basic features necessary for a wiki to be useful: you can enter (somewhat) richly-formatted text, along with links to other pages, whether or not they exist. Clicking a link to a nonexistant page will take you to an edit page for the new, empty page, allowing you to save the page.

Yeah, the picture support sucks. You have to create the picture first, then paste the URL of the picture. So, take two minutes and create a picture library to post wiki pictures in.

Remember the main goals for a wiki - not to compete with other wiki tools, but to get ideas written down, quickly, and without stopping to structure them. Structure can be added later, if at all.

As others have said, telerik offers a replacement for the Rich Text editor, there is a CodePlex procject working (slowly) on improvements, and, people, it's SharePoint - if you don't like it, you can customize it. It's ASP.NET, web services and Windows Workflow Foundation.

I don't recommend anyone go out and buy a MOSS license just to implement a wiki (or blog, for that matter). But if you've already got the SharePoint infrastructure (perhaps as part of Visual Studio Team System Team Foundation Server), then go for it. I've seen several SharePoint wiki libraries used to hugely improve the amount and quality of developer documentation available to several groups within a large software development organization. Once we shut down discussion on how great other wikis were, quite a lot of documentation just happened, by itself, just like it's supposed to do.