Tags:
competition1Add my vote for this tag create new tag
view all tags
How does TWiki compare to ConfluenceWiki?

discussion moved here from HowToGetInternalBuyInForTWiki.

I'm currently trying to get support to install a wiki at my very large company (over 100,000 total, but closer to 2,000 in my division's area). So far the IT department is actually the biggest barrier, with management in love with the idea. The biggest complaint (surprising to me anyway) is that the software is free and open source. This creates fear that the software is not well-designed or robust enough to use. The popular opinion is that using pay-to-play software such as Confluence will mean a more stable product with better support when things do go wrong. After comparing the pay-to-play options (Confluence, Socialtext, and Jotspot) I selected the one I thought would be the most accepted at my company, which is Confluence. I then put together a comparison chart of several issues such as ease of install, cost of wiki software, cost of additional software needed (i.e. Confluence requires a database), support offered (Confluence doesn't offer any more support than TWiki does, blowing that opinion right out the window), etc. That comparison chart won my case for TWiki versus pay-to-play at least as far as managment is concerned.

My next IT barrier is the actual work of installation/support. IT doesn't want to allow any software products beyond the few company approved applications (mostly Microsoft) because they would then be expected to support it. Unfortunately for me, I'm not a sys admin and don't have the skills necessary to simply install and be my own sys admin for the wiki. While I could handle most issues once the site is up and running, I would need periodic help from a sys admin.

However, I do have very enthusiastic support from the bottom two rungs of management and I'm preparing to show presentations to levels of management that are much higher (and have the power to tell IT to do it anyway). One of the ways I generated management support has been to follow the suggestion at the near top of this page, of specifically stating what the wiki will not do. I've been very careful to craft the plan in such a way to highlight the fact that it does not compete with existing company standards, including the (failing) use of Livelink for collaboration. My use of the wiki is based on the idea of Wikipedia. It will be an encyclopedia-plus for the engineers. Hope this long-winded response helps someone.

-- AmandaSmith - 15 Nov 2005

Amanda - Thanks for that "report from the field"! It's very helpful and it would be great to hear more such reports. Any chance of posting your comparison chart?

-- LynnwoodBrown - 15 Nov 2005

I had to think about the attachment of the doc (I had already considered that before your response) but it doesn't have any of my company's info in it so I think it should be okay.

I'm still in the fairly early stages of getting this approved. My next plan is to set it up on a temporary server to create a live demo (which could then transition into permanancy!) to show IT and upper management.

-- AmandaSmith - 16 Nov 2005

This is very timely Amanda! Our central corporate IT group is playing with Confluence and the idea of it perhaps becoming "the" standard wiki for our organisation. I'm personally quite attached to twiki because of my prior history with it but the greater good must prevail of course. Thank you for providing info which makes an informed decision more probable. smile

(BTW Crawford, if you're reading this thread, one of my co-workers who is investigating wikis for the first time says your WysiwygPlugin is better than Confluence's rich text editor, especially when it comes to lists)

I haven't actually gotten my meat hooks into confluence yet, but from reading around and going through the feature lists where I think Confluence has the edge is:

  • free form tagging, which they call labels (a la http://deli.cio.us/)
  • dynamic rss builder
  • personalisation way beyond what the pattern skin sidebar offers (e.g. personal rss feeds and labels and conversation tracking)
  • export to xml is purported to do everything, including attachments (but I wonder how they deal with binaries, e.g. images)
  • export to Word documents
  • look and feel is more polished (PatternSkin is good, but Confluence's is more consistent across a greater range of pages)
  • the JIRA Issue Tracking and Project Management addon looks a lot more complete and extensive than the ActionTrackerPlugin (JIRA is good enough that the Apache Foundation is using it)

For fun: according to Google Smackdowns, twiki is currently the leader to confluence wiki by an even 100, garning 419 to Confluence's 319; comparing twiki wiki to confluence wiki increases that lead by 799.

-- MattWilkie - 18 Nov 2005

Amanda, thank you for bringing this up here! First of all, run (don't walk) to the nearest book store and get "Open Source for the Enterprise" by DanWoods and Gautam Guliani, ISBN:0596101198. It covers exactly the issue of IT being reluctant to open source, and how to address that. Very nicely written book. And BTW, TWiki is covered too, in a favorable light.

Thank you for posting the comparison chart, very useful. As for support, there is no "for fee" support plan. However, you will find that the TWikiCommunity is very helpful in the Support web and in TWikiIRC. If you need training, customizations and installation assistance you can contact one of the ConsultantsForHire. Contact me for details if you wish.

-- PeterThoeny - 18 Nov 2005

Peter, When I refer to the "for fee" support plan, I'm actually referring to the ConsultantsForHire. In the comparison, I also make note of the online documentation--though perhaps it isn't as obvious in the spreadsheet. When I discuss this with the people I'm trying to convince, I do tell them that the online documentation here is very extensive. Far better in fact than on the Confluence site.

As for feature comparisons between the two, that is a little more challenging to rate. Each has some features that I like better than the other. Ultimately I think it comes down to how you intend to use the wiki and which one has better features for your particular needs.

-- AmandaSmith - 21 Nov 2005

http://www.atlassian.com/software/confluence/features/ says... (plus quick view of TWiki)

  • Pages - Easy to create, easy to edit, easy to organise. DONE
  • Spaces - Because your organisation is too big for just one wiki. DONE
  • News Timely information - notices, bulletins, blogs. NEW
  • Mail - Archive and index team email conversation. :|
  • Attachments - Attach, track and search your files. :| what's track?
  • Comments - Turn any page into a team discussion forum. :| not easy
  • Organisation - Cross reference, index, search, hierarchify! :| not out of the box
  • Search - Everything is searchable. Everything. :| grep search lacks. others not integrate
  • Images - Because a picture is worth a thousand words. DONE
  • Links - Links should never, ever break. Ours won't. frown Ours will
  • Administration - Powerful, simple admin. No geniuses required. :
  • Security - Enterprise grade permissioning and control. ?
  • Openness - Confluence plays well with others. ?
  • Integration - From daily workflow tools to enterprise systems.
  • RSS - Produce and consume RSS newsfeeds. smile
  • Plugins - Just a wiki? No, an application platform.
  • Polish - Not just a pretty face. It works well. It feels right.

-- MartinCleaver - 01 Feb 2006

The comparison spreadsheet is a year out of date isn't it? I, too, am bouncing back and forth between TWiki and Atlassian Confluence. I have both running on our corporate web server for evaluation.

The first thing I noticed is that Confluence is easily two to three times faster at delivering a page (topic). TWiki is so slow to respond that I can easily measure the speed difference between the two products.

I understand that mod_perl can be used to improve performance but not without some tricky script changes (please correct me if I'm wrong).

The second thing I noticed is that the WYSIWYG editor in Confluence (version 2) is very, very nice, and seems to work without a hitch within Internet Exporer (a browser we can't get away from until Firefox becomes more Intranet file link friendly).

Some issues with TWiki's WYSIWYG editor and Internet Explorer have been noted by the users evaluating it here.

Unlike Amanda, if I lean towards TWiki, I'll get company buy-in with no hesitation. To get buy-in for Confluence will actually be harder because of the price tag. Still, Confuence is looking slick so far - perhaps more information about TWiki and mod_perl can be made available (or someone in the know can steer us there, please?).

-- JohnWright - 01 May 2006

Hi John, I run a company called Blended Perspectives (http://www.blendedperspectives.com) - we too are based in Ontario (and provide wiki consulting, including Confluence).

For TWiki we recognise that you need to use an accelerator of some sort. My preference is PersistentPerl.

Feel free to contact me - I'm on 416 786 6752.

Regards, M.

-- MartinCleaver - 01 May 2006

Thanks for alerting me to the existence of PersistentPerl Martin. I have everything in our Twiki installation's /bin directory pointing to a PersistentPerl executable now (perperl instead of perl) and do find that the speed of TWiki has become less of an issue. Would building Apache to use PersistentPerl afford even more speed? If so, Confluence's edge in that department will no longer be a factor...

-- JohnWright - 01 May 2006

It may be slightly premature to use PersistentPerl or other similar solutions, as there currently appears to be a memory leak. Hopefully this will be fixed shortly.

-- MeredithLesly - 02 May 2006

I'm working for IBM now and they use Confluence a lot. There are heaps of Confluence installations around IBM. My team has it's own confluence wiki (actually just a space or web how we call it in twiki) so I will report more about it once I worked with it a bit more...

What I can say already is that thier screen is way better than the standard twiki edit screen.

-- CarloSchulz - 05 Mar 2008

How is it better? Can you provide an analysis?

-- ArthurClemens - 05 Mar 2008

I will... by now this statement is just a first impression based on the things I noticed by just editing one topic.

  • easy to spot and fast switch between rich text (wysiwyg) and wiki mark up
  • page title can be changed in edit (form field like)
  • add tags during edit (form field like)
  • while editing you can still see navigation (it does not look like a complete different screen)

I will provide a more detailed usability analysis of confluence compared to TWiki once I worked more with it

-- CarloSchulz - 05 Mar 2008

Note that there is no miracle anyways on the WYSIWYG editor (also based on tinyMCE). See: http://forums.atlassian.com/thread.jspa?threadID=19644&start=30&tstart=0

Confluence is also used at ILOG in some projects. People wanted it both because of its integration with Atlassian other tools (JIRA), and because it makes more obvious the different features. For instance when I asked the guy who pushed confluence the advantages he saw of confluence over TWiki, he say "You can add comments to any pages". This means that this non-developer had been using TWiki for years and never realised that the comment plugin existed, although he definitely used pages with it before. Maybe because when editing with Confluence, there is a "in your face" "allow comments to this page" option?

-- ColasNahaboo - 06 Mar 2008

How small things can have a big impact...

-- ArthurClemens - 06 Mar 2008

Most users only see the visible.

-- MartinCleaver - 06 Mar 2008

It is more that just "add comments to any page": Comments are out of the way from the content. In TWiki, you need to actually spend energy to have a set up that does more or less the same that Confluence does out of the box.

Curiously, I always saw the CommentPlugin as a way to quickly input data into a topic in a very flexible way, not a way to put "comments" on a topic. Even now, as I'm typing this, I see this smalll text area as a way to add content to this discussion.

-- RafaelAlvarez - 07 Mar 2008

I actually consider the way we use the comment plugin on twiki.org one of the reasons Codev is so hopelessly cluttered with irrelevant content. If comments were on a secondary tab or page, at least not on the front, people who have said something of relevance and who would like it to have any impact would refactor the front page the topic content instead of adding yet another comment sippet quickly. We have much to many content additions instead of content refactoring or structuring here on twiki.org. Actually, we use TWiki more as a forum than a real wiki.

-- MichaelDaum - 08 Mar 2008

Exactly, I had the same thoughts regarding refactoring and comments on a seperate page. Maybe we need to start thinking about SeperateCommentsFromTopics?

-- CarloSchulz - 09 Mar 2008

Would be great if SeparateCommentsFromTopics can be (easily) bundled as a TWikiApplication.

-- KwangErnLiew - 09 Mar 2008

SeperateCommentsFromTopics is something that has been built several times - see the Blog web for just one example. Should be pretty trivial for anyone to make it into an App smile

-- SvenDowideit - 10 Mar 2008

Maybe the fact that it has been built several times should be interpreted as 'it has never worked so far', and the opinion that it should be pretty trivial should be considered with suspicion. Wrong focus? Analysis failure? Obviously this very topic developed as a ThreadMode, as very often. Where is the sedimented information? I would suggest that the problem is a lack of 'Software Configuration Management', (please: no premature shoulder shrugging!). SCM should allow to manage information before it has converged to a globally consistent state. Sedimenting information is a long-time task, not only a one-time merge issue, 'in the end'--which typically never comes.

-- MarcGirod - 10 Mar 2008

That is not the conclusion I would draw. There are different usages for comments inside and outside the topic. To stay on topic: Confluence does not have an advantage over TWiki because it has a well defined SCM. But the concept of "real content plus additional discussion" may fit better in certain areas. Harder is to make the disctinction between discussion and real content. If this separation had been made here on Codev, who would have created the real content? I am afraid that lots of "real content" would have remained empty, and discussion topics as full as we have them.

Of course it would be neat if a TWiki adminstrator is be able to make the choice.

-- ArthurClemens - 10 Mar 2008

Have a look at wikipedia, they have a clear separation between real content and additional discussions. They make a clean cut between these two use cases of a wiki. Admitted, TWiki.org is no wikipedia. We use wiki to discuss most of the time, not to capture knowledge. Still, the knowledge that arises from discussions is "managed" in a way that it is mixed up with all the other noise, unfortunately.

-- MichaelDaum - 10 Mar 2008

Wikipedia is an example of what to avoid, IMHO. It is based on a metaphysics of universality, an ultimate /main/LATEST (NPOV). They exclude needing any SCM by professing that there exists a neutral point of view. The separation between contents and discussion there is naive and fails completely.

-- MarcGirod - 11 Mar 2008

When does a separation between contents and discussion fail and when not? Do you have a positive example?

-- MichaelDaum - 11 Mar 2008

The discussions are ignored, are mostly garbage (circular cause / consequence). One structural reason to produce garbage in the discussion is ThreadMode. People will move contents away from the contents page to the discussion one, and forget about it. The problem is that this distinction is naive: it assumes that control may simplify the reality so as to make management unnecessary.

-- MarcGirod - 13 Mar 2008

Yes, most discussions are garbage. But that's a load you have to carry in the end. Some insights and gems may show up in the end.

Actually the point is to hide garbage effectively while concentrating on the gems ... or whatever every reader thinks the gems are! But if a discussion, how ramified it may have become, wants to contribute back to the main issue, it should be feasible and carried out as a conscious step. I don't agree ThreadMode is that bad and would not condemn it as a basic principle. Discussions do unfold in different directions. Different readers might to focus on each aspect as they see subthreads to be more interesting than the main issue. Ideally , discussions should concentrate on the issue and don't get lost in side tracks. Reality is, that things are not linear. I know that a good meeting facilitator would always try to keep participants on track. But that's different here! Take IRC for example. People have a hard time to cope with its linearity when different discussions are merged, producing a lot of discontinuity. I think ThreadMode might be very appreciated in some places, as long as it does not disturb the visual appearance of the forum too much. Most forum software allows to display one and the same thread in different modes. Not that I have seen one forum software that I like in that respect. Most have vast usability issues, and ThreadMode does make it worse in a lot of cases. That's no surprise anyway...

-- MichaelDaum - 13 Mar 2008

We do not have to carry loads: we have to fix them. There is no end: this is both a curse and a blessing, only there is naivete in refusing to acknowledge it.

-- MarcGirod - 13 Mar 2008

Topic attachments
I Attachment History Action Size Date Who Comment
Microsoft Excel Spreadsheetxls Confluence_TWiki_Comparison.xls r1 manage 30.0 K 2005-11-16 - 02:46 UnknownUser Compare TWiki with Confluence
Edit | Attach | Watch | Print version | History: r30 < r29 < r28 < r27 < r26 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r30 - 2008-03-13 - MarcGirod
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.