Internally we have 2 groups pushing different wiki solutions: Confluence and Deki.

I like Deki from an ease of use/ visual appeal point of view but was wondering if anyone had done a more in depth evaluation of these 2 solutions.

I ended up with a list of three candidates:

Dekiwiki, Confluence & Mediawiki

Confluence seems to be very robust and scaleable but had to much reliance on third-party solutions for my taste. I also wanted to be able to distribute my wiki database and that woud have meant license issues. Though they do free single user licence for personal use that was my stumbling point.

Mediawiki is widely used but unless you have good access to experts I found it hard to configure - the support forum was frequented more by people with questions but only a small core of people with some soloutions.

Dekiwik as you can see is more active on community support and with a vibrant set of active helpful users. The online help can be a bit tricky to navigate around but search around and you can get some useful examples.

I'm not a coder by profession (I dabble when prototyping new projects) but I've been able to setup the wiki quite well and am pleased with the options to add scripts, api and extensions so easily.

Get the VM and let people have a play with it for a while.

Steve

I switched from Confluence to Deki for the several reason but the most important being it's ease of use and flexibility in allowing me to create something more than just a wiki, a wiki mashup with true collaboration. Neither MediaWiki or Cconfluence offer that IMHO.

In fact after providing a simple demonstration to an organization what Deki could do vs MediaWiki I had them convinced within no time.

Not to tout our own horn, but from customer reports we're getting, Confluence doesn't scale too well in content or number of users. Also beware on the small print of their licensing. If you setup Confluence with LDAP, you must get a license for all users in the enabled LDAP group, regardless if they are going to use it or not. Finally, Confluence also charges for disabled user accounts. I must say, I was shocked finding out about the latter. Frankly, if any of our business guys ever suggests that, I'll show him the door with a print of my boot on his posterior!

MediaWiki is the current scaling champion, but as was shown by Mozilla, Deki scales nicely too. If I recall correctly, their site has a million hits per day with twice that much headroom using a single application server. Not too shabby...

I'd just like to update Steve's reply as some of his information may give the wrong impression:

• Confluence licensing only counts enabled user accounts. Simply disable a user's groups and they'll no longer count. This has always been the case with our licensing.

• While most Confluence licenses are for small teams, the wiki scales right to the massive end of the corporate spectrum. Now with 6,000+ customers, Confluence is popular among Fortune 500 companies who put Confluence's clustering support to good use. For example, Accenture has 80,000+ employees using Confluence internally. IBM's internal wiki has well 50,000+ users and the high-traffic DeveloperWorks wiki at http://www.ibm.com/developerworks/wikis is running Confluence as well.
  
  You can see some of our large public instances for yourself at http://www.atlassian.com/software/co.../customers.jsp and visit http://blogs.atlassian.com/news/2008...ki_epidem.html to check the source of Accenture's wiki statistics.

• Confluence's LDAP integration is flexible and has always been able to authorise any combination of users and groups. No need to worry about unused accounts.

Hope this helps to clear things up.

I've been looking at this today. I'm using Deki at the moment and I was trying the Confluence standalone .exe eval install.

I like deki, the desktop connector is very useful and the office tools looks interesting as well.

Linking a single email to a single Page from Outlook is good and bad - good because the deki mechanism goods straight forward and easy for the user, plus the content is movable after the fact. Bad because it doesn't provide linking between emails in the Deki. It's a shame that the msgid or subject is not made into a tag when the email is import.

Confluence system is good for a bulk set of emails. Emails can be archived via POP or IMAP into a Space. However, doesn't seem to be a way to move emails or link them to pages.

They both have a good webdav server.

Confluence has a very nice mechanism for editing a page directly via Word or OpenOffice over webdav. Works well. This makes up for the fact that Deki has a much better Wysiwig editor. Deki's editor can handle pastes with images from webpages, the Confluence editor drops the images. Although Confluence does seem strip that crap from "pasted" content - whether this is good or bad depends on the purpose.

I think Deki have a better permissions model, although it still could be improved.


Finally, from my investigations today. One thing Confluence does much better than Deki at the moment is provide addon scripts. The Confluence Form Scaffold [1] is probably possible with Dekiscript, but it doesn't exist yet. This is a big shame, and one reason why I'd consider switching. Confluence is more along the lines of a Twiki application style wiki, with some extra tool functionality.

On the Deki side, the CRM integration looks very useful. Again this is probably something possible with Confluence, but is not avaliable.


I'm not sure about the price difference anymore as Deki removed the pricing from their website recently. Last time I checked though the price for standard Deki was very good.


At the end I'm not sure which is the best at the moment. I will probably stay with Deki as given the email archiving is not more useful than Deki's and the Word/OOo functionality not enough. the Form Scaffolding would be the only thing that might convince me. Their are some hints that Mindtouch have something like this, but I haven't seen any code yet.

If either wiki got an IMAP portal like OpsMailManager [2] for alfresco I'd probably jump on them. In fact given this major point that will be driving Sharepoint for Exchange archiving in the future I hope either does build something like this.


[1] http://confluence.atlassian.com/disp...+Form+Scaffold
[2] http://www.opsera.com/jsp/opsera_pro...ailmanager.jsp

stateless, thanks for the write-up! It sounds like adding editing over WebDAV would not be too difficult. What three features of Confluence do you think would be the best for the OSS community here to see if they could build on top of Deki?

The scaling problems inherent to Atlassian Confluence Steve is referring to has been brought to the attention MindTouch repeatedly by customers of MindTouch that came to us by way of Confluence installs. Obviously, it's hearsay and while many of the customers were very technically competent we have no way of knowing if the issues they experienced were inherent to Confluence or their configuration thereof. The most detailed explanation MindTouch received (that I can speak about publicly) was the NIH and Burnham Institute project http://topsan.org that couldn't scale Confluence past several thousand pages. They're now successfully scaling MindTouch to 700,000 deki pages. Moreover, Steve's mention of http://developer.mozilla.org , which received upwards of 30M pageviews a month, is surely a more trafficked site than any other wiki, excepting of course Mediawiki.

With respect to the users, etc. A common complaint from MindTouch customers converting from Confluence to MindTouch is that any user created in the system or in an LDAP/AD group or dir they expose is counted even if the user is deactivated (meaning, in perpetuity) or if (in the case of LDAP/AD) even if they're not accessing the system. Again, hearsay. To my knowledge no one at MindTouch has confirmed any of this.

All of this above is entirely irrelevant though. If you're comparing MindTouch Deki to Atlassian Confluence you're comparing an Apple to an Orange. MindTouch Deki, which happens to be the World's MOST popular open source collaboration platform (evidenced by ranking at Sourceforge.net and other 3rd party sources), is a full blown collaboration platform that is commonly used for enterprise/business automation, mashups, business intelligence, light weight integration, as a specialized application server for developing collaborative and social apps, web services framework, web services orchestration engine and more... Moreover, MindTouch is distributed, or developed with a WOA http://mindtouch.com/Technology, whereas Confluence is monolithic. Of course, the most relevant point for this conversation is: Atlassian Confluence, while I happen to think it is a *good* product, is just a wiki. MindTouch Deki, while it does have a very polished wiki-like interface is much much more and people are using it as a platform they can shape (without being overly technical) as their needs evolve. Big difference.

$0.02 for you.

P.S.- I think Atlassian is an awesome company and the guys over there are sincere, smart and generally make good solid products (all highly unusual in the "Enterprise 2.0" space).

Contact the pre-sales guys here at MindTouch. 866 MindTouch or jump into a chat at http://www.mindtouch.com/Products/How_to_Buy They're there to help you. They're not "let's make a deal" car salesman. They're all pretty technical guys.

Confluence probably have some convertor from RTF to their markup. It works very well.

Rather than just Confluence functionality, here three suggestions for a better Deki.
1. Add more dekiscript examples to the dev wiki. One of the reasons why TWiki and to a lesser extend Confluence seem more useful than Deki is the both have a good set of usable publically avaliable addons and scripts. Note the Tutorial [1] is not sufficent, you can't drop it in and have it work and there is not enough coverage.
2. Build more community. Twiki's Plugin Web [2] being the primary example. Following from 1. it is easier to develop new addons when you have old addons as an example.
3. Confluence's email threading mechanism is nice. EMail archiving will be an important future requirement for info silos - look at the change to Outlook Shared Folders and Sharepoint. [3] So, the option to store raw email data, and autolink/search this data would be good. Maybe store emails by default as dot-eml attachments. Build some dekiscript and template code to allow attached emls to be rendered in page. This keeps the power to move archived emails to the correct location in the silo and the flexibility to present it how you want.


Some other cool functionality.
4. Copy the Zimbra DnD [4]. Being able to drag files from the desktop onto the web browser would be cool. Maybe you can reuse their xpi?


[1] http://wiki.developer.mindtouch.com/...ript/Tutorials
[2] http://twiki.org/cgi-bin/view/Plugins/WebHome
[3] http://www.offlinesharepoint.com/usi...or-sharepoint/
[4] http://gallery.zimbra.com/gallery.ph...d&productId=68