Reinventing the (Wiki) wheel

I have been mulling for some time the idea of creating yet another Wiki engine/application. But before I started building it, I wanted to iron out the reasons why I want to do it. Some reasons seem childish when looked at objectively and others seem frivolous. But when I probe deeper into them, I find myself motivated to at least give it an honest chance.

So far I have asked myself some questions on why not to go ahead with this project. Is there really a need for another Wiki application when a plethora of choices are already available? Isn’t it better to work on a project which doesn’t have as many choices and people working on it? What is it that I can provide in your Wiki application that others haven’t already provided or considered but rejected? Who do I want to target as my audience; individuals, developers, small teams, large teams, etc.? Do I have the time, drive, and commitment to not only start this project but continue to maintain if it is ever finished? In short, I have tried to ask myself questions that would discourage me from going ahead because there’s a side of me that really believes that yet another Wiki engine will not benefit a lot of people. I could rather work on making, for example, a Session Border Controller solution using OpenSIPS and FreeSWITCH, you know, something that a lot more people could find useful.

But there’s another side that really wants to undertake this project for a few reasons. I tried MoinMoin (in fact, still using it) and the biggest problem for me (and I could be wrong here) was that to make changes to config, I have to change Python code. I am certainly capable of understanding Python code and trying to modify it to suit my purpose but the biggest obstacle is to first learn how and where to make the changes. This requires excellent documentation, something not easily done when users may be required to do some short programming stuff. I started with MoinMoin precisely because I feel very comfortable with Python and knew that I could adapt it if required. I love that MoinMoin stores content in flat files, which I can backup using rsync from my server to my notebook. But I don’t get that ‘Oh, I get it!’ feeling when trying to change the way MoinMoin works by default. I could try some other Wiki that does these things but not many are built using Python.

These, and many other, reasons prompted this prospect of re-inventing a Wiki application. Some of the goals, inspirations, and design choices are below.

• I want to learn how to create a Wiki.
• Always use the test tool for the job.
• Leverage already-existing tools rather than re-creating them for no reason.
• Focus primarily on making a Wiki.
• First have a functioning Wiki and then think about performance, scalability, serving as true collaboration platform, plug-in support, etc.
• The same Wiki should serve multiple groups and users with smart and secure permissions.
• Security features, such as IP whitelist, IP blacklist, account lock on multiple login failures, etc. should be easy to manage.
• Allow multiple Wikis to be hosted from the same server using either the same database (shared credentials among the farm) or different databases.
• Wikis are mostly read-only with a small portion of it being edited at any given time. So use flat files for content and attachments. File systems were designed to handle files well so let them do their job.
• Databases are great for structured data so use them configuration, settings, rules, etc. This deals with the issues of changing code to maintain policy.
• Differentiate between Wiki Management System (WMS) and content. WMS are all the bits and pieces that make a Wiki function: user management, parsers, etc. Content is what the users most focus on because the Wiki exists to gather and serve content.
• Advanced, fine-grained user profile and access control management, auditing, and logging.
• Use Django because that’s what I know best. An additional advantage of using Django is that the project can then be modified by people who know it or it can be integrated/enhanced into a much bigger Django project.
• Python and Django make it easy to create a multi-platform application but focus primarily on Linux.
• Keep the project free, open source, and freely available.

Some wishlist items are also included.

• Add some elements of blogs, such as tags, time-sensitivity of content, discussions, etc.
• RSS feeds.
• Simultaneous editing for a true multi-user Wiki.
• Integration with different authentication/authorization methods, such as RADIUS, LDAP, etc.
• Use YUI Library to create user-friendly and pretty templates, etc.

Now the question I ask myself is this: how much time and effort will be required to get this project started and rolling. This is a huge list of goals for a single developer (who is a developer-for-fun in the first place). Am I capable of managing this project? Only time will tell. But the last question I ask myself before I start: is it worth it to reinvent the wheel when others have already done pioneering work before you?