Wikis

Today a wiki has come to be known as “a knowledge base website” where “users … modify content directly from the web browser.” (Wikipedia)

However, both the conventional wiki software and overall wiki philosophy have some pretty major disadvantages and you should think carefully before investing time in one.

These disadvantages are the major motivation for my work on the S²OIL README World Knowledge Exchange and README WorldPress Personal Publishing Platform.

Problems with Conventional Wiki Software

Conventional wiki software served a purpose for its time and many legacy wikis are engrained into the modern Web but this conventional, legacy wiki software has largely been superseded by better approaches and tools for most documentation needs, notably static site generators with content written in Markdown, hosted on a git provider, and delivered over a content delivery network such as Netlify. This modern approach fulfills the same needs as conventional wiki software:

However, conventional wiki software comes with the following heavy disadvantages:

In short, avoid the use of conventional wiki software and fulfill the same needs with a JAMStack approach based on Pandoc Markdown instead.

Challenges to Wiki Philosophy

Crowdsourcing knowledge initially seems like a great idea. Everyone contributes. No one is excluded. Opinions are discouraged. The best, balanced knowledge wins. But these advantages comes with several strong disadvantages that are often overlooked.

Falsification and Trust

This is the #1 biggest disadvantage cited by most educators about why they penalize students for even considering wiki information. While it is likely an over zealous response, the fact remains people do regularly lie, troll, and falsify content on Wikipedia and presumably others.

The problem exists because there is no relationship of trust between any of the authors as well as none between the reader and collective authors. Without trust you can never provide quality content, period.

This is why the free README WorldPress Personal Publishing Platform allows all content to be easily GPG signed to ensure the identity of the author (or trusted group of authors).

Content is Inconsistent

I realized this after having several members become confused by almost contradictory and inconsistent writing in several substantial wiki pages. It was clear one person had changed one area but (for whatever reason) decided not to change the other related information.

Opinions are Silenced

I rediscovered the strong advantage a good book has over any wiki covering the same material: you can strong, well-researched opinions from the author. Opinions are the basis of innovation and fundamentally not something the crowd will generally agree upon — especially ground-breaking ideas. Imagine what a group of “collaborative authors” would say about connecting two computers together in the 80s, or saying "fat is good for you, or saying “the world is actually round” (Okay that’s a rough one.) Point is well-researched* opinions are not only essential to good content, they are the very basis of scientific discovery.

No Voice or Audience

Ever notice some Wikipedia pages will have all sorts of words a 12-year-old would have to look up? Others are so simply written anyone could understand. This is because Wikipedia is the functional equivalent of the Borg trying to write something for everyone. Collective authoring is always devoid of voice, style, and (in that case) a target audience with a specific target vocabulary. Now consider all the things that are taught at a good, novice writers’ seminars:

The result is something no one really enjoys reading. If they read it it’s likely because they have no other choice. This is the polar opposite of the very successful and proven Head First approach.

Just Too Many Authors

In software development this disadvantage can be compared to having several developers all working on a project using different style conventions. The comparison holds for the number of people working on the project. Throwing more people at a software project often results in missed deadlines and reduction of quality because the effort to manage all the participants detracts from the core development goals.

Instead, having a core team (or a core team of committers) meets the demand for consistency in the code base. This same approach can (and should) be applied to collaborative knowledge content development.

I actually applied this truth to this very page when someone anonymously suggested I widen my definition of wiki to be more than what they considered I was describing as “conventional wiki software”. I took the feedback, considered it, and essentially merged the change request. This is common for software development, why not for content development?