Remember wikis?

In their original incarnation, wikis were completely open without any form of access control. Anyone could add and edit pages. Through a process of social darwinism, the content would automagically evolve to increasingly higher quality.

Wonderfully naive, and in hindsight it is easy to understand why this doesn't work. In practice, it requires intensive monitoring to avoid weak content and vandalism. As a result, many wikis have introduced editing policies and some form of access control.

Even with access control, a wiki seemed appealing as a light-weight collaborative CMS. That is the reason why I originally chose to deploy myhdl.org as a wiki, based on the dokuwiki software.

At first, access control on myhdl.org was kept minimal. Anyone could register and start editing pages. The idea was that the site would attract motivated and knowledgeable engineers, that would understand how to improve the site without much guidance.

But again, this doesn't work in real life. A single person with more self-confidence than competence is sufficient to spoil the party. On a site with some popularity, it is only a matter of time before such a person shows up.

That is exactly what happened on myhdl.org. At some point, an individual started to "improve" the content. The only problem was that he didn't have a clue what it was all about. Consequently, his edits were typically completely wrong. Moreover, he started to change pages that were "obviously" frozen.

You can guess the outcome: tighter access controls. Now a would-be contributor had to contact me first, show some credentials, and then I would register him. More overhead and manual work - nothing that I actually wanted to do.

What about the other typical wiki features? The news is not good. Yes, you can edit content in a light-weight markup language. But every wiki system typically grew its own language. They are all similar but different, and none of them is as good as Markdown. Wikis also need a revision control system to track and undo changes. Again, they typically grew their own system which can never be as powerful as widely used systems like git and mercurial.

As you see, I have basically had it with wikis. Moreover, I know what I want instead. For my purposes, a static website that I can develop like a software or a digital hardware project is ideal. Develop locally in a git or mercurial repository. Enter content in Markdown format. Run a tool to generate the website. Commit and push to collaborate with others, possibly on GitHub or Bitbucket. Use hooks for automatic deployment. In terms of overall productivity, nothing beats this workflow, even without the possibility to edit over the web.

At this point, all technologies to enable such a system are in place, and there is actually a wide choice of static website generators. However, I didn't find a tool that satisfied my requirements, because they are typically blog-oriented and lack a focus on good navigation practices. Therefore, I am writing my own. That means work, but I find it quite satisfying and I am pleased with the result so far. Actually, you can view it in action on this very site. I plan to migrate all my websites gradually to the new system.

Pretty soon I plan to open source the initial version of the software. Watch this space!