TWikiOffice

I've been mulling over this proposal for a while now and, with all the Usability and User Experience energy flowing through the community at the moment, this seems as good a time as any to propose it.

TWiki's tagline is (or was) "the Enterprise wiki" but, on the merits of the default distribution alone, that is perhaps not evident beyond the tagline. It's certainly not a personal wiki (there are much simpler and more straightforward alternatives out there) and even Carlo has stated himself that it took him a couple of years before he began to appreciate the power of TWiki. So, what does that mean? Do Sys Admins and their companies choose TWiki because it is "the Enterprise wiki" and obstinately stick it out until they realise that "hey, we did make the right choice after all," or worst-case, give in to user pressure and jump to a slicker competitor: I've had my fair share of defending TWiki against the likes of Plone and MediaWiki.

What I have in mind is a TWiki distro fully loaded with all the plugins/addons/applications/contribs that fulfil the TWikiOfficeVision and turned into a single, coherent enterprise product: customisations made on the interface and extensions to merge their features, all buggy features either fixed or disabled, all js packed into a single file, all css minified into a single file, (is it possible to speed up the handling of plugins if they are treated as part of the core code and not as plugins?,) new releases no more than 2 months after the release of a new TWiki, patches to handle security and extension updates, etc. Think of the various satellite linux distros built on top of the foundation distros (e.g. Mint->Ubuntu->Debian) but I'm certainly not proposing a fork or a new project with its own website etc., rather another option on the TWiki download page.

Nor do I want to split the small team of core developers we depend on. This would be a project for all the sys admins and user experts out there who have daily contact with users and want to contribute to the TWiki project. Any bug fixes or improvements made could be fed back to the individual extensions or even the core code. This way, we can perhaps encourage contributions that may otherwise not have happened.

As a starting point I have a VMware virtual machine running Ubuntu JEOS 7.10, TWiki 4.2.2 and in the region of 80 extensions (plugins/contribs/addon/skins) installed and, in some cases, customised.

There are 2 reasons why I have held back on this proposal rather than simply posting it:

• First, I don't want to upset any of the community members who might say, "Hey, this is what I do for a living!" My hope is that this would be a positive contribution to the TWiki project overall and, more than anything, a very effective advert for a great open-source product which would raise the demand for TWiki knowledgeable consultants.
• Second, I don't want to be seen as a freeloader trying to get something for free that my organisation would otherwise have to pay for. The fact of the matter is, I am not a sys admin, I'm an engineer in a small section of a very big organisation who once had the idea to use a wiki to maintain a living document he had written the first version of. A couple of years down the line and I'm administering and developing a growing TWiki instance on our intranet without a dedicated work package. I tinker around with Plugins that aren't working, change them to suit our needs, write applications and swim around the top levels of the core code (the deeper I go the less I understand of the Perl). I have also spent a lot of personal time working with TWiki and I want to contribute to its success. I have ideas for plugins but (I think) I have better ideas for how they could all work together. I'll be doing this work anyway but through TWikiOffice I could share the results.

Depending on the feedback I'll either start writing the TWikiOfficeVision and solicit for contributions (what TWikiOffice should actually offer and which extensions are needed for this), or just let things be.

-- Contributors: DavidPatterson - 11 Sep 2008

Discussion

David - yes please do - don't worry about competing with anyone, what it actually does is reduce the list of things other people need (but didn't find the time) to do.

If you use the debian repository at fosiki you will be able to auto upgrade the plugins (and twiki) using apt-get - thus making a Vm that will last forever

If you also set up the same things the were done for the DebianVM - Samba, etc, then you'll have done a job i've been meaning to do for years, but never found time for.

The debian packages that I publish at fosiki (i the experimental repository) are updated automatically by a nightly build script I set up, so basically should be pretty close to instantly uptodate. The only thing is that it relies on dependancy information provided by BuildContrib packaging - which is why your Skin isn't in there. The other thing is of course that this system encourages you to commit your changes back to svn and twiki.org - as it only builds from the packages that are publically available.

-- SvenDowideit - 11 Sep 2008

Great idea David, just go for it!

-- FranzJosefGigler - 11 Sep 2008

Nice, I had almost the same idea. But no time to work on it. Please, go for it.

-- CarloSchulz - 11 Sep 2008

This idea excites me a lot. I, too, am not a real system admin and certainly not a programmer. I've fallen into TWiki much the same way as DavidPatterson. Though our TWiki is pretty new (around a year), it is growing quickly and I've spent way more time than I probably should have trying to fumble my way around plugin installs and troubleshooting.

The only thing I would suggest for consideration is the idea of a VM or other OS-specific setup. Some of us still prefer to have dedicated servers. At my company, we try to leverage the learning curve by maintaining only one server OS. We would steer away from VM packages that would require us to learn another OS. Not that we're afraid of learning at all. It's just that our company is a learning-related company--not an IT company. It's not intuitive for us to poke around much at command prompts. So, we like to try to keep building on what we learn instead of having to learn something different for every server.

-- DavidWolfe - 11 Sep 2008

It's about time someone did this. If the result is a no-brains install that hits the major platforms, even better. Go for it!

-- CrawfordCurrie - 11 Sep 2008

Hey, I was thinking about it since last week!

Actually I've been thinking about use HTTP Engine with TWikiOnMemoryStick for personal use. Then I could add some plugins and pre-configure it, so one can use it on any computer that have a Perl environment.

After that I thought about creating pre-configured packages focusing on speed, for example (and maybe cookbooks about).

-- GilmarSantosJr - 11 Sep 2008

hmm... a TWiki distro... I like the idea

-- RafaelAlvarez - 11 Sep 2008

Currently I too use Ubuntu Jeos in VMWare but then I remembered ubuntu-vm-builder. Actually the Jeos cd images will be gone from next version and the vm-builder is the way, with a new web-gui to build from.

Even if we have a distro with TWikiStandAlone many TWiki administrators/customers could benefit from quickly set up a new twiki-server the ubuntu-vm way, because then they have a minimal and specialist installation that requires less updates than a standard Ubuntu server and it is optimized for their virtual enironment (vmware, xen, kvm, vbox, qemu). With apt-proxy installed you install a fresh server in about three minutes.

I think of it like OpenFiler and other appliance-distro's, many have some Linux OS but I dont care too much as long as it updates very easy and the focus is on the features. Don't necessarily need to learn CentOS or Debian or whatever distro.

-- LarsEik - 11 Sep 2008

If you use the 230+ package twiki debian repository I mentioned above, then updates are trivial. These packages have dependancies built from the DEPENDANCIES file, so installing ImgPlugin will automatically install ImageMagick, installing the NatSkin package will automatically install all the prerequisite plugins, and so on.

-- SvenDowideit - 12 Sep 2008

Hi David. Great idea. I tried to do the same thing long ago with the KoalaSkin : a distribution of [1] a clean and usable skin (well, for 2002 [2] faster (precompile as much as possible) [3] automated upgrades [4] including useful plugin and patches. But it is a lot of work.

So I would advise you to just at first use Sven's debian repository to "get the feeling" of a proper packaging system, (and reduce your daily maintainance work). Afterwards you may want to contribute to the debian effort, or start your own.

I do not think that the TWikiStandAlone way is worth it however: you would be reinventing the wheel of the hosters providing you with ready-to-use Debians in VMs, such as http://linode.com, http://slicehost.com, http://www.gandi.net/hosting/, or ... your local IT (most Entreprise IT are deploying internal VM services)

But, like the others, I'd say go! TWiki is currently too customizable for its own good. Wordpress is simple to install/upgrade because all the directory names are fixed for instance. being able to put all the TWiki dirs all other the place is perhaps an intellectually satisfying feature, but one of the many things that make simple install/upgrade harder than the other wikis (and hinders performance) for no real gain (hey, this is what symbolic links are made for). Or windows compatibility: why try to provide it now that Virtual Machines such as DebianVM exist? So go, and simplify at will.

-- ColasNahaboo - 13 Sep 2008

Thanks, everyone, for the feedback and words of encouragement. I'll continue with TWikiOfficeVision in the next few days and then make available the vm I've got for anyone who might find it useful or wants to join in with the development. Inline with this, I'll create a scratch-branch on the svn server. I imagine the first release will be a vmware vm only (the simplest all-platform solution), with a twikioffice debian package available by the time of the second release.

To DavidWolfe, I understand what you're saying but, for now, the easiest way (that I can see) to package a TWiki distro with all the required external dependencies (CPAN modules, htmldoc, abiword etc.) is in a vm. If you want to stick with a physical server and leverage the learning curve you could do a check-out from svn (when it's available) and then install all the external modules that twiki core plus the extensions require (I haven't put that list together yet but it must be pretty big =8-O ). The idea, however, is to pre-configure/simplify things so much that we can provide, as part of the documentation, a (short) list of all the ubuntu commands that might ever be needed.

Colas, thanks for the warning Once the first version is out I intend to stick to a relaxed release cycle: as the target is the company intranet, the focus will be on stability and usability rather than riding on the leading wave of innovation (not that I wouldn't respond to a new plugin with a killer application). I am intrigued by the pre-compiling of the templates. Did that really make a performance difference? Would it still be worth doing on the latest release?

-- DavidPatterson - 16 Sep 2008

I made a small thing with a few pages that is a web interface for ubuntu-vm-builder. It generates the script needed to build a machine and you name your machine and select the other options that are selectable. Each machine then get a topic with history and attachcontent plugin writes the script to a text file also. I have not put in the list of all Ubuntu/Debian packages but I have a editable list with the packages I use for testing and making TWiki installations. It's not perfected yet. Is that of any interest?

I also intent to find out if Buildcontrib can build a dummy package with a DEPENDENCIES file that contains a selection of plugins needed. I also intend to have a web interface for this, like with the TWiki Ubuntu vm builder, and the MANIFEST will also be created from selecting files in the TWiki web gui. If it is only interesting for me I will create another topic. I really like Ubuntu This will be a very good disaster recovery solution also.

Actually one "profile" of the TWiki Ubuntu builder will perhaps be to create a developer station, ready with a fresh svn checkout.

These build scripts could also be available as images for download if there are demand from others who just want to download a ready to fire up machine. Btw I think ubuntu-vm-builder can create images with the standard server kernel also, even though the kernel optimized for virtual machine is default.

-- LarsEik - 19 Sep 2008

Nice, Lars, very nice. Without question, people are going to be interested in this.

-- DavidPatterson - 19 Sep 2008

Ah, I forgot. You may want to look at what I am using to install and upgrade in a fully automated way my various TWikis at home/work/hosters on debian/ubuntu/centos at TWikiDevEnvColasNahaboo. Basically you maintain copies of a full TWiki distrib, a local SVN checkout of TWiki, and you just define the plugins you want to use, and your local overrides and patches. Running the script thus install or upgrade in one operation.

-- ColasNahaboo - 20 Sep 2008

Nice Dev Env, Colas. I missed that before. Reminds me of the goals TWikiReleaseTrackerPlugin that I once wrote - with this an admin could determine all the changes they had made from the package files that came in the distro and create zips of the bundles.

Something like Colas' DevEnv or/and my plugin would benefit the main distro, methinks, and would be a key enable TWikiOffice contributions to flow back sanely.

-- MartinCleaver - 20 Sep 2008