Shortest Path to Wiki
A surprise request arrived from a client yesterday. “We need a wiki, can you help?”
Sure. What they didn’t know was that I had already installed JSPWiki one of their development servers a while ago. Another developer and I used it for simple development notes and maintaining lists of links to other websites. Nothing complex.
At the time I had told a few people in the organisation about the “developer wiki”, but it never got any traction. For others, at the time, it was a solution looking for a problem. This time someone mentioned wikis to a manager who had a business need driven by cost saving. He was looking for a way to replace an externally hosted online help service, and to create document oriented content.
The manager had done his research. The original email request came with a link to WikiMatrix. The requirements included multiple sub-sites, individual user accounts and permission management, visibility of all changes, WYSIWYG editor, etc, and in bold “it must be free and open source”. OK, no problem.
Off to the Web I went looking for the latest open source wiki software that would run on the web application platforms used by this organisation – Windows, SQL Server, Java or .NET. There were not many options that looked like they could meet the client’s requirements. The latest versions of JSPWiki and XWiki seemed like the best candidates.
“What about [insert favourite wiki] that runs on PHP/Python/Perl and MySQL?”, you ask. Yes, WAMP would have provided a lot more options, some of which would have been better candidates. However, this organisation only has one part time network/systems administrator, and relies on contract developers, so my recommendation was to not introduce yet another platform.
I created a list of tasks that I’d have to complete to get the open source wikis to meet the client’s requirements. The list included items like:
- Learn custom JSP/Velocity template system and create site template(s).
- Learn security model and config files, create user accounts, find out how/if that works across multiple sub-sites.
- Set up multiple sub-sites.
- Obtain open source WYSIWYG editor, integrate it and remove unwanted options/tools.
- etc…
A quick look through the documentation of the candidate products revealed that some of this would be easy and some might be difficult. Difficulty/risk was usually proportional to the availability and quality of documentation. Some was good, some was thin, some did not exist.
By the time I finished doing a quick feasibility on both products I was thinking that there might be 3-5 days work involved in getting an open source product to the point where it would meet the client’s requirements. And, there was still some risk that those requirements might not be able to be met.
I presented the client with two options:
- JSPWiki plus 3-5 days of my time (and some risk), or
- Buy a 25 user licence of Confluence.
Confluence is an enterprise wiki with very good documentation.
After a quick discussion with the client about total cost, technical risk, limiting dependency on myself to adminster and maintain the wiki software, and why I had not offered more options (the PHP/Python/Perl issue) I got the go ahead to install a 30 day trial of Confluence. In about 45 minutes Confluence was downloaded, installed on Tomcat (two small config files), licensed, plus I had set up some trial Spaces (sub-sites) and added a few user accounts.
A few more minutes were required to add the organisation logo and change some of the colours to the organisational intranet standard. While I was doing that the manager was already creating test pages. Sweet!
(Note: This post is not a “commercial software is better than open source software” rant. In this case, for this particular client’s requirements, I thought Confluence was the better option.)
Wiki Software Comparisons
Disclosure: I am a customer of Atlassian Software. I own an Jira licence, but other than that I have relationship with the company.
[tags]wiki, confluence, open source[/tags]
Mark — 9 April 2006, 11:35
Quite a bit of time was spent working out how to best implement an open source solution to the client's requirements, and in their technical environment. Having used Confluence before, and knowing the pricing, I thought it was also worth a look.
The client was presented with the estimates of total cost for the open source and commercial options. Based on the estimates of total cost, and the functionality provided by each option, they chose to happily ignore their own directive and pursue the commercial option.
All I did was present a contrasting "have you thought about this?" option. My intent was to help my client get the best value for their money. In this case, the best value wasn't paying for my time to customise an open source solution.
Andrew
Andrew Hallam — 9 April 2006, 17:31