Are you shopping for a wiki: Look at Foswiki!
January 1st, 2010
I just read a list of good arguments from Colas Nahaboo for Foswiki on the Foswiki mailing list and wanted to post them here quickly:
Our Foswiki at work (ILOG, then IBM) is in place since 2001, and has
now 60,000 pages. In my view, the main strengths of Foswiki wrt
mediawiki are:
* Utter reliability: it can run unattended for months without a worry,
it relies only on the filesystem. And if the filesystem is on a
NAS…. automatic continous backup for free!
* Resilience: it survives problems such as no more disk space, power
outages, hard disk failures with no damage nor curruptions
* Integration: you can use Foswiki pages as front-end applications to
services, or as display of programs results, as the engine just handle
text files that are easy to handle or generate by any scripting
language you like. For instance we use a separate search engine (now a
Google appliance) to provide full text searching.
* Power: If you are used to the unix way of thinking (data is defined
as simple text in files, and you use shell/perl/python/ruby/C/…
scripts to manage them) then any kind of feature can be added to
Foswiki as the engine is geared to having its data files changed by
other processes too, thanks to its dynamic nature. The great feature
of Foswiki is that users can code a feature via Foswiki Macros, and
other users can copy/paste this code which is not hidden like the php
of Mediawiki extensions.
On the performance problems, the main drawback of this dynamicity is
that a lot of things are recomputed on each requests, e.g. some
“macros” in Foswiki that search in pages can be slow. But things can
be optimised quite a bit by separating the contents into different
directories, and coding special scripts or plugins to optimize the
bottlenecks. Flat files are not slow per se (a grep in our 60,000
pages takes 10 seconds), it is just that we lack now the equivalent of
“indexes” you have with a database. But the community is working on
this.
I would add that wheter you choose Mediawiki or Foswiki, your
technical team is expected to learn to invest some time to unerstand
how the system works. I guess in the end the decisive factor is
whether your people are more at ease with php+mysql or with
traditional Unix scripting.
Colas.
Our Foswiki at work (ILOG, then IBM) is in place since 2001, and has now 60,000 pages. In my view, the main strengths of Foswiki wrt mediawiki are:
- Utter reliability: it can run unattended for months without a worry, it relies only on the filesystem. And if the filesystem is on a NAS…. automatic continous backup for free!
- Resilience: it survived problems such as no more disk space, power outages, hard disk failures with no damage nor corruptions
- Integration: you can use Foswiki pages as front-end applications to services, or as display of programs results, as the engine just handle text files that are easy to handle or generate by any scripting language you like. For instance we use a separate search engine (now a Google appliance) to provide full text searching.
- Power: If you are used to the unix way of thinking (data is defined as simple text in files, and you use shell/perl/python/ruby/C/… scripts to manage them) then any kind of feature can be added to Foswiki as the engine is geared to having its data files changed by other processes too, thanks to its dynamic nature. The great feature of Foswiki is that users can code a feature via Foswiki Macros, and other users can copy/paste/enhance this code which is not hidden like the php of Mediawiki extensions.
- On the performance problems, the main drawback of this dynamicity is that a lot of things are recomputed on each requests, e.g. some ”macros” in Foswiki that search in pages can be slow. But things can be optimised quite a bit by separating the contents into different directories, and coding special scripts or plugins to optimize the bottlenecks. Flat files are not slow per se (a grep in our 60,000 pages takes 10 seconds), it is just that we lack now the equivalent of ”indexes” you have with a database. But the community is working on this.
I would add that whether you choose Mediawiki or Foswiki, your technical team is expected to invest some time to understand how the system works. I guess in the end the decisive factor is whether your people are more at ease with php+mysql or with traditional Unix scripting.
Colas
Read the whole mail-conversation including a happy ending here on our Nabble-documentation online.
I would be an instant convert to Foswiki if Foswiki were to enter into an agreement with a hosting company like Godaddy that had an instant unzipping installation. Once up and running, further tweaking and customization is straightforward, but getting Foswiki (or TWik) installed on a shared host is very, very difficult if one has no experience in that regard, and even more so if one doesn't have some of the write permissions needed. TWiki has an instant installation that works on Godaddy, for example. I'd much rather be running a Foswiki platform and I'd be prepared to move my website and wiki to a new host if I knew I could get a functional wiki installed.
You might also want to try to use the Foswiki JumpBox? – http://www.jumpbox.com/app/foswiki #noinstallationreequired
I bet you could enable this type of easy installation if Foswiki were to use local-lib, a perl module that allows you to install perl modules where users have write permission.
I agree with the discussion, but I have a bit of an ethical problem with the post itself : a "FosWiki" in place since 2001 ??? Wow, that was years before the fork happened.
So I have two messages fo whoever may feel concerned :
1. even if sour things happened, everything before the fork was Twiki, wasnt it ? Then it should be stated correctly.
2. One of the advantages of having someone paid for support is to avoid that clicking on "reasons to look at FosWiki" gets you on a blog (not FosWiki-powered, but Wordpress), without much potential for discussion or enhancements …
Right you are. Foswiki did not exist before Octobre 2009. It was TWiki before.
We had intensive discussion about whether to use Foswiki oder WordPress for this weblog. I still think it is right to use WordPress for the web and Foswiki for internal blogging.