Introduction
My boss informed me a few days ago that wiki is an old-school, outdated, low-tech term. She suggested that, when I go about convincing organizations that they need one, I use a more current term, such as Collaboration Platform.
However, the word wiki, in my mind, describes a tool quite precisely, narrowing the intent and capabilities of the tool to a good approximation of the functionality that I seek. For that reason, and given that I'm not using this post to sell such a tool to anyone, I'm going to use the term wiki.
Here's a simple definition for the term: a website that allows collaborative editing of its content and structure by its users.
In principle, there are may ways of interpreting that definition. For example, you might say that it's an excellent way for a group of people to share information. Or, you might think of a wiki as a knowledge base. But the capabilities of a wiki allow for a huge range of functionality: planning, scheduling, documenting, blogging, consolidating information, posting resumes, sharing pictures, creating how-to's, and so on.
Today I found myself needing a wiki to keep notes about various projects, to share information with others involved in those projects, to record (mostly for myself, but also for the world) solutions to problems that I'm encountering these days, to post my resume and contact information, and to have a platform to share interesting discoveries.
I've used wikis in the past, at every job since about the year 2000, and I've even introduced a wiki into several of the companies that employed me. You could say I have experience with a wide variety of wikis. Nevertheless, most of the wikis I set up or used were in a private network, behind a firewall, or accessible to my peers only. Therefore, security happened outside of the wiki. No one from the Internet was able to access the wiki. Wikipedia, for example, is different, allowing basically anyone at all to contribute by adding or editing articles, or joining discussions.
When I realized that I needed a wiki, a whole bunch of requirements just popped into my head. Here's a partial list:
Requirements
- Open source and free
- Markdown or some such text-based syntax, not WYSIWYG
- Granular user-level, group-level, page-level, and area-level permissions
- Responsive
- Modern look and feel
- Large user base
- Downloadable and able to run in my server
- Gentle learning curve
The Search
My extreme laziness came into play when pondering how to start the search. I settled on Wikipedia for the starting list of wiki candidates. I copied all the tables from the article Comparison of Wiki Software into a Google Sheets spreadsheet. Then, I sorted the tables according to my requirements and used some Emacs code to cross reference the results and eliminate candidates according to the criteria I listed earlier. I was able to narrow the selection to the following wiki software (sorted alphabetically):
- Finalists
- BlueSpice MediaWiki
- CLiki2
- DokuWiki
- Foswiki
- Ikiwiki
- PmWiki
- TWiki
- Tiki Wiki CMS Groupware
- Wiki.js
- WikiWikiWeb
- XWiki
Interestingly, MediaWiki, which powers Wikipedia, is not in the list because of permission issues. It's too open. I understand that this is the true spirit of a wiki, but I need to be able to lock down some areas of the wiki because I have to work with other humans who don't understand.
Foswiki and TWiki are quite similar in many ways, and derived from a common ancestor. Together with PmWiki, these solutions are written in Perl. I have used these in the past. I've also used DokuWiki. To choose a wiki from among the finalists, I had to try out each of the other finalists.
Evaluation Approach
To evaluate the wikis, I found a docker-compose.yml for each of these finalists, then simply put each wiki's docker-compose.yml file in a directory (with anything else they needed to run), ran docker-compose up in that directory, then tested the operational wiki at the localhost port indicated in the docker-compose.yml file.
Here's an example of the kind of docker-compose.yml file I'm talking about:
- docker-compose.yml
version: "3"
services:
db:
image: postgres:9-alpine
environment:
POSTGRES_DB: pgdb-name
POSTGRES_PASSWORD: some-db-password
POSTGRES_USER: some-db-username
logging:
driver: "none"
volumes:
- data:/var/lib/postgresql/data
networks:
- wikinet
wiki:
image: requarks/wiki:beta
depends_on:
- db
environment:
DB_TYPE: postgres
DB_HOST: db
DB_PORT: 5432
DB_USER: some-db-username
DB_PASS: some-db-password
DB_NAME: pgdb-name
volumes:
- ./files:/files
networks:
- wikinet
ports:
- "8081:3000"
volumes:
data:
networks:
wikinet:
Evaluating the operational wiki consisted of creating a fixed set up pages, groups, and users, then assigning users and permissions to the groups. I was trying to determine how easy it was to create and edit pages, to create a user, to restrict a user to a subset of pages, to include images in a post, and to navigate the wiki. Beyond functionality, I considered ease of installation, learning curve, and the effectiveness of the UI for me as a user and an administrator.
Final Selection
My final selection for wiki software should come as no surprise. You're reading this post on that selection. It's Wiki.js. This software came the closest to meeting all my criteria in the approximately 4 hours that I spent on this exercise. If you know something I don't, please put it in the comments or send me an email.