Commercial Wiki: ProjectForum and CourseForum

Mark Roseman of CourseForum Technologies, a commercial Wiki vendor, contributed via e-mail, his perspectives on the ongoing discussion over commercial vs. open source Wiki products and comments on using Wiki for blog comments.

The response from Ross about Socialtext touched on what a commercial system (like theirs or ours) can offer. As you say, issues surrounding support, hosting, integration, documentation etc. are fairly obvious. Let me elaborate a bit more about a few things.
Ease of use
Tools like TWiki do a reasonable job of covering the 'geek' market, but when it comes to making tradeoffs about adding more power features vs. keeping things simpler and more accessible, tend to lean towards the former. Our system tends to keep the markup simple, add features designed to help new users such as preloading forums with some default content, page templates, allowing people to post comments without going through the full edit interface, etc.
At the same time, the system is fully featured to suit what people need to do, has things like user tracking, decent security models, versioning, archiving etc. that aren't necessarily fun to code but are needed when Wiki's are used in "real" environments. But the application as a whole is designed in a way that features are presented in an accessible but not obtrusive way. You don't always get that mindset from developers who haven't done a lot of commercial systems before (ok, or some that have!).
Ease of install/setup/admin
This is one area where the open source packages usually fall down, because they rely on many other packages which must be installed and configured.  Something like Twiki usually needs setup of Apache, configuring MySQL databases, various other modules, setup CVS to do version control, etc. Further, most of the configuration is done through manually editing configuration files or variables at the top of code files.
We like to point out this article about what is usually involved as compared with ours (just double click a single executable, no configuration needed, and later administration done via a web-based interface).
On top of the configuration hassles and software dependencies, most of  the open source systems are fairly platform-specific; one differentiator for ours is that it runs well on not only Unix, but also Mac and Windows.
This (and the previous point) really help bring the whole Wiki concept to a much wider audience; going in to configure software and then making it hard to initially figure out really restricts who can take advantage of the software (and we've had more than a few hard-core geeks buy our stuff after getting frustrated trying to get Twiki or similar systems installed!)
Multiple workgroups
Most Wiki's grew out of personal use projects hacked together (your comments are astute; rip everything away and there isn't necessarily much there).
As such, they tend to hardcode a lot of assumptions. Many of these mean that its very difficult to setup multiple separate workgroups/wikis on a single server, or that you need to install multiple copies of the software to do so. Changing that would be a major redesign (and its not an issue for most of the open source developers working on those systems).
In ours, multiple distinct workgroups can seamlessly exist on the same server; this was designed in from the start and is important for our target audiences (in most places you'd have one person maintaining a server for a lot of other people, rather than everyone running their own copy of the software).
Wiki's replacing blog comments
I think this is on the right track. We've seen a comparable thing in our educational product, where instructors would post slides from a lecture on a Wiki page, and then students would post their comments and questions on the same page. The parallel with blog posts and followups is fairly natural.
The sticking point with doing this for a lot of Wiki's is that you don't necessarily want people deleting or changing each other's comments. Some of the more advanced Wiki's would help with this. In ours for example, you can:

  • make it so that people can post to the end of the page but not edit existing contents
  • have a more closed forum where users are authenticated
  • track a history of changes to the page, so if something was deleted or changed, you can find out what, when and who did it

Bottom line
Ok, I think I'd better stop before I overwhelm you. 🙂
But I really do want to second Ross' comments about commercial Wiki's complimenting rather than competing with open source alternatives.  I've been working on collaborative systems for a long time, and was really impressed with the potential inherent in the core Wiki idea (no matter, or perhaps because of, how simple that idea is).
What we're trying to do is take that core idea and make it a lot more accessible, bringing it to a wider audience, people who would never really be able to benefit from it with existing tools.

FYI, CourseForum Technologies has two products: ProjectForum for business (demo) and CourseForum for education (demo).  There is also a large public project based on their software.