For the past few days an ardent discussion on the OSAF design mailing list has revealed there is no consensus about the best way to collaboratively gather and sift design input about Chandler, a task which has become quite important.
I've learned since yesterday about the wiki, the twiki, the zwiki, and the wikipedia, all variants of an open source tool for collaborative editing. Each has its partisans and critics and each is used, in varying ways, by open source projects. We are investigating.
In a conventional corporation, there are a basic set of ground rules about how activity is organized. Corporations are still ultimately hierarchical. Some pyramids of power are steeper, others flatter, but they all point to the top. Anyone who works in the business world absorbs a set of default rules about how workplaces operate, e.g., your boss tells you what to do, but you don't tell your boss what to do.
As an open source project, we are experiment in progress. Like every other project we have to determine how decisions are made and who has what kind of power. Other projects have pioneered various methods of organizing their own activity, i.e., who can submit code for inclusion and who can commit it. There's a lot to learn from them and there is not yet any general consensus.
I had a fascinating conversation yesterday with Mitchell Baker, the general manager of mozilla.org, after which I began to appreciate the scope of process issues we are going to have to deal with. Active and successful community participation will require careful choice and use of the communications vehicles. I've already seen that the openness of mailing lists coupled with relatively wide membership and the willingness of participants to express themselves means that more than one side of most every issue is going to be brought up, no matter how small the issue.
Case in point: I received an email from the design list which I wanted to reply to. I use the reply command of Eudora. The new message is addressed by default to the person who posted the message I'm replying to, not to the list as a whole, which is what I want. I make a note to myself let Morgen, a developer who's currently doubling as system administrator to see whether the Mailman program we use can be reconfigured to fix what I regarded as a problem. Before I got around to sending it, I read perhaps a dozen postings to the list discussing what the correct behavior should be. Surprisingly, there were articulate and strong arguments on both sides. Not only that, but there are already lengthy essays on this posted in various places on the net which were cited.
Looking into it, I discovered there are substantive points about how replies to lists should form the To: address. One the one hand, since the previous message was sent by a poster to the list, a reply to the message ought to be sent by the default to that poster, as a reply is meant to go to the author, not the recipients, of the previous message. If I want to include the recipients, I should use the Reply to All command. On the other hand, what most people probably want to do is to reply to the list (and perhaps copy the author), in which case the "proper" solution doesn't do what is wanted and requires extra work. So why not munge the headers of the posted message such that when I do want to reply, the To: address of the new message is the list. For the rest of the gory details, you could start here
In a world in which all points can be discussed endlessly, it becomes important to have generally agreed-to processes by which decisions can actually be made and respected. Whether munging reply-to headers is really harmful or not isn't the point. It is that it's a Brave New World out there and we better get used to it. What's new here for me is not the endless discussions of mailing lists, but their impact on a project which is trying to work in an open and participatory fashion. And everything I discussed here is just the tip of the iceberg.
Posted by mitch@osafoundation.org at October 30, 2002 04:31 PM
Darn fumble fingers (and Mozilla? -- I had several paragraphs written here and then hit some key combination that closed the Mozilla window) anyway:
I chose to use TWiki for a variety of reasons:
* Content under revision control (RCS) so TWiki never forgets and you can (fairly) easily find changes
* Significant variety of TWiki markup includes headings, automatic TOCs, tables, drawings (sketches) with the TWikiDraw plugin
* An active community of developers
* Written in Perl
* Some support for authorization / authentication -- I want to have all contributors register so that I can identify who added what -- there is (weak) hiding of information.
* Skins in case you don't like the default TWiki look (I don't, and have changed it on my private TWiki, but I can't change it on WikiLearn (AFAICT) while it is hosted on twiki.org
* Other things that don't come to mind at the moment
I have a public TWiki site named WikiLearn (temporarily hosted at twiki.org). You might check out these pages (not for content but for examples of what can be done):
* http://twiki.org/cgi-bin/view/Wikilearn/EmailServerSketches
When I was trying to select a wiki for my own purposes, I went through a review process and tried to record (most of) my findings on Ward's wiki -- see http://www.c2.com/cgi/wiki?WikiEngineReview -- it's embarrassingly messy, but it may help you somewhat (and feel free to add / fix anything as you conduct your own review)
I'll try to write more later.
Posted by: Randy Kramer at November 8, 2002 02:26 PM
Have you taken an indepth look at ZWiki? As a Zope developer, I've used and installed zwiki, and it seems to make a lot more sense than twiki does. Twiki is a wiki which is attempting to become an application server. Zope is already an application server, and zwiki is built-on top of that. This makes for a faster more feature rich wiki. Zwiki has features like a fast search engine (can handle hundreds of thousands of pages), FTP interface so that wiki members can edit wiki nodes using emacs, and it can even be scaled across multiple servers if your traffic gets really high.
ZWiki is also already being used by a large open source company (Zope Corp.) for software development, so it stands a good chance of having features useful for software development being added.
http://dev.zope.org/Wikis/FrontPage
Although there have been indications that Zope Corp may be outgrowing wikis in software development as this recent thread on the dev mailing list indicates:
http://lists.zope.org/pipermail/zope3-dev/2002-October/002960.html
Posted by: Kevin Teague at November 8, 2002 06:52 PM
Prompted by Kevin I should mention that one of the drawbacks of TWiki (IMHO) is the search engine -- it is (to me) on the slow and somewhat primitive side, although sometime in the last six months someone added the ability to do boolean "and" searches using ";" as the "connector". Also, the search uses grep (or a variant) instead of being a true search engine. WikiLearn is indexed by Google and other public search engines which helps overcome these problems, and people have added search engines to their own installations (one that comes almost to mind is a Japanese one with a Japanese sounding name, something like Namazumi (I know that's not right)). (The one thing that needs to be done is more intelligent excluding of TWiki pages from Google searches -- it does exclude the obvious ones (like edit and preview pages) but pages with a dynamic searches (WebChanges, or pages with customized inline searches) add a lot of "false hits" or noise to Google results.
Another wart on TWiki is the need to preview before saving, although one of the popular skins (forget the name) overcomes that, and there is periodic discussion about fixing it more widely.
I considered Zope at least a little (don't recall if I tried to review it on WikiEngineReview) -- the thing that scared me off (without attempting it) was the installation, although maybe it's not as bad as I thought -- it may be that if you install the right Linux distro Zope is pre-installed and getting ZWiki to run is a minor issue.
TWiki is not the easiest thing to install (or was not for me -- partially because I was trying to make a transition from Windows to Linux and TWiki was one of the first things I tried to install in Linux). (TWiki can be installed on Windows or Linux, and there are pages on twiki.org devoted to both.) Since the first install, I (recently) did several more installs on a private LAN and it's not all that bad. I still dread doing it on something like SourceForge because there are some file permission and ownership things that must be handled, and they are a pain if you don't have root access.
I guess I'm trying to point out the warts on TWiki (or anything else I know enough about) -- most people will tell you the good things, to make a good decision I think you need to know about the warts.
Also, which wiki you choose probably depends on your objectives -- my goal for WikiLearn is a collaborative learning environment -- the pages serving as my (or anybody else's) learning notebook, with the opportunity for discussion on any page. I don't know all the implications of the phrase "application server" but I don't think that's what I'm trying to do with TWiki.
I should really review WikiEngineReview again myself. Some of the things that made me not choose other wikis included the possibility of forgetting. (IIRC, even though there are some threads on Ward's Wiki about wiki never forgetting, only the previous copy of a page is recoverable -- if some vandalization or something similar occurs and you need to go back two revisions there is no easy way (IIRC).)
Although TWiki does use RCS I would prefer a better presentation of differences -- the current approach is to use what I'll call (for lack of the correct terminology) "Unix style" diffs that show, for example, two versions of a paragraph even if only one word is different -- I much prefer what I'll call "Word" style diffs where the paragraph is shown once and the one different word is shown with the new word in bold (or underlined) and the deleted word is shown crossed out.
Posted by: Randy Kramer at November 9, 2002 05:51 AM
Here's another page that might be helpful:
http://www.c2.com/cgi/wiki?ChoosingaWiki
Posted by: Randy Kramer at November 9, 2002 06:50 AM
The right linux distro can make most software easy
to install. The right distro being Debian :)
ZWiki installation is as easy as:
apt-get install zope-zwiki
And Debian will fetch zope, and then zwiki and install them and start-up Zope on port 9673. You can also install Twiki quite easily on Debian as well, simply:
apt-get install twiki
The only drawback being that installing Debian itself is not quite as easy as some of the other distros. But once you are up and running, almost
every package is just an apt-get away.
For the phrase "application server" I am referring to an engine that runs as a core suite of tools that are used for building web-based applications (although with a good application server you are not limited to web, and can also serve other forms such as WebDAV, FTP, and XML-RPC). Core tools include things like database connectivity, RAM caching, session tracking, user authentication and authorization, and search.
Building/installing all of your tools on an application server works great for me. I run an intranet at work where I can give each user one username/password, and then allow those users to create documents, images, files, wikis, and even archive public emails. Every piece of content is then available through search.
I think the integration makes a nice selling point for Zwiki, as if at a later point you want to expand beyond your wiki site with other things like documentation tools, slashdot-style news, content management systems, etc, you can do so with the need create additional user accounts for each component in your web site.
There is also a product for Zope that allows you to install a complete content management system, and this lets users create their own complete, seperate Wikis through-the-web:
http://www.plone.org
Posted by: Kevin Teague at November 9, 2002 01:40 PM
Thanks, Kevin, for your additional comments. (Seems like we're having a dialogue here ;-)
Debian is on my list of distros to try (again) -- probably next time by way of Knoppix (if I got that right).
Posted by: Randy Kramer at November 11, 2002 01:21 AM
Great tip on plone Kevin;
Also, someone ought to mention
Mambo, and perhaps the several
good forum apps (phpBB, etc.) Larry C.
Posted by: Larry at November 19, 2002 08:15 AM