We're looking into document management systems at work at the moment. We currently use a combination of a shared docs folder and a Wiki (which I setup when I started there), and some people (like me) use CVS for docs.
The idea is to unify this into a document management system that everyone can use, that supports versioning of documents.
The chosen system appears to be Microsoft Sharepoint. This appears to be an over-designed system built around ASP.NET that stores documents in SQL Server. It's more than just document management - doing lots of portal-like things such as managing discussion groups, photo libraries, and calendaring. From my initial testing of it, it looks "OK", but I'm not bowled over. It's very "busy" in its default layout, and it all looks like a lot of effort to me. For documentation I'm so used to the wiki-way now that anything like this just seems so... complex.
I'm not sold on it. It does versioning of documents but it doesn't do tagging. This is a showstopper as far as I'm concerned - how else can I label a particular version of a document as related to a particular version of a product? I don't really see the point of version control without tagging.
It also made me think about attachments on a Wiki. I had this great idea to add attachment support to the AxKit wiki codebase, and support versioning of attachments and so on. But then looking at sharepoint and its lack of tagging I realised that the same would be true of the AxKit Wiki code. So I'm scrapping the idea of doing versioning - and sticking with SIMPLE attachments - no versioning (this makes the code a lot simpler too!).
I'm not really sure why we aren't considering that all projects should have an archive in our source control system, with source code for that project under src/ and documentation under docs/, then you can create a wiki page for the project and directly link to the documentation that is held under a proper source control system (with tagging and branching along side the source code), assuming you have something like viewcvs installed. This makes much more sense to me. Why have two version control systems - one for docs and one for source code?
Perhaps the biggest barrier is persuading the people who use non-developer tools like MS Project that they should be using version control. These manager types aren't familiar with version control, and they've never seen anything wrong with just storing a copy on their hard drive. Perhaps it's time for that to change though?