OStatic

Wikifying Your Free Software Project

Guest Post By Kord Campbell

I'm a software evangelist for an IT search engine startup in San Francisco, doing a guest post here on OStatic. We just released a new version of our software which provides REST-based APIs for developers to extend and enhance the basic functionality of their products, beyond what we originally designed. Much like Sleepycat did with Berkeley DB, or Flickr does with their APIs, we encourage an open system for accessing the data that the proprietary product stores.

Now that we have an API available for developers, my task is to grow a development community around it through various software projects addressing specific and specialized needs, using the product as a base. Ideally these projects will be based on a free software model, where we, in conjunction with developers, contribute how-tos, examples, SDKs, and more to the community.

Creating a new, viable, and open software project isn't as easy as it looks. One would assume making a project's source code available would be an immediate guarantee for widespread use and collaborative development, but it's not. Usability, design and layout, interestingness, quality of code, extensibility, documentation, possibility of fame and glory, and personalities all play a part in the success or failure of free software project.

Basically, you need developers to get interested in writing software for the users, and a large user base wanting to use the software and drive features. There are dozens of project hosting services like SourceForge and Google Code geared toward developers and their projects. These services provide good features for encouraging collaborative development including a basic home page, code repository, download service, bug tracking, and usage stats reporting. What they don't provide are features necessary for a more user-centric experience such as a custom layout, blog for promotion, forum for discussion, and a wiki for docs and development notes.

Because of this, many projects have resorted to rolling their own sites to provide the necessary requirements for satisfying both developers and these end-users. If you look at the popular open source project Adium, you'll see several standard technologies at play including a blog (Blogger), forum (phpBB), bug tracking system and wiki (Trac), mailing list (Mailman), and code repository (SVN). Providing all of these features can become a challenge when integrating various software packages into a coherent, unified website.

Authentication, for one, raises its ugly head, where users need a single sign-on for logging into the site, posting to the blog, and adding content to the wiki. These solutions usually end up being solved by a one-off solution, are prone to breakage when doing upgrades to other packages, and ironically, are rarely shared with other users or developers.

Because of the versatility of wiki software, many wiki projects have started adding features to help ease the pain of integrations with other software packages. The developers for the MediaWiki project have written a wide range of useful extensions for displaying SVN diffs, integrated authentication for forums, showing bugs from a Bugzilla install, and dealing with large amounts of documentation.

Facebook launched their MediaWiki powered developers wiki last year which allows users to log into their Facebook account and contribute how-tos and reference material for other developers. For now, I'm using Google Code for our development wiki. In the next few weeks I'm planning on moving it over to a MediaWiki install and getting it integrated into our existing authentications and website chrome.

Within a few days of installing MediaWiki for testing, I had the folks from documentation come and ask me about the possibilities of moving the online documentation over as well. When I showed them the tons of features available via MediaWiki's extensions, they said "how fast can you do this?". Heh.

Granted, some development projects don't need a unified solution for developers and users, but when they rely on tight developer-to-user communications, a wiki hosted on your own site might just do the trick.

Do you have your own ways of solving the problems I've described?

• wikis
• Wikipedia
• Sleepycat
• Google Code

by Kurt Blane on Mar. 06, 2008

Kord, great post. Here's my 2 cents:

I don't see why Sourceforge doesn't add wikis, blogs and couple of the other features mentioned to their offering.

Sourceforge is great and I use it all the time but they do tend to move slowly. I don't their marketplace has really taken off like they expected and they don't do a great job of monetizing their properties (given the large amount of traffic they receive). They should focus on providing tools to the OSS projects to improve collaboration (wikis, better bug tracking, feature voting, etc.) instead of trying to expand into other areas and new businesses.

0 Votes

by on Mar. 06, 2008

Well, for smaller projects, Google Sites seems to work pretty well too. Media Wiki, at first glance, seemed cumbersome to install and set up without having to spend a lot of time tweaking it. Tried TikiWiki too, and the software had a learning curve for what we really wanted to do - share specs and roadmaps with a small team.

For that, I've poked around with Google Code a bit and found that to be fairly usable and interesting. Granted, our project code is not deployed over the web to 100s of devs - we just needed an info resource for a small crew.

0 Votes

by Sam Dean on Mar. 06, 2008

Google Sites looks like the way to go. It's the product of their JotSpot wiki acquisition and is very easy to use.

0 Votes

by on Mar. 06, 2008

Yup. Plus, it's easy and intuitive to use. You don't have to learn to speak 'wiki' to get things going. I bet that is the way Media Wiki and the other wiki sites will go too... They have to. HTML pre-(gasp!) frontpage days is where the wiki language seems to be...

0 Votes

Share Your Comments