How to manage an open source project

The do's and don'ts of handling projects

MikeOS

At this point, you might've rediscovered an old, wonderful idea for an application that you had one day, and now be eager to make it and change the world. That's cool, but it pays to think practically.

Many developers would rush headlong into setting up a SourceForge project at this stage, writing grandiose descriptions of what the program will achieve, and perhaps even adding mock-up screenshots. I've seen countless SourceForge project pages drenched in big claims, hope and ambition - and yet when you click the download link, you discover that the developers had never uploaded anything.

So focus first on making something usable. It doesn't need to be feature-complete or ultra reliable, but it needs to convey some of the vision. You want users to think 'This is cool! OK, it needs much more work, but I can already see what it's going to be like'.

Not only does this provide an entry point for other developers to get involved, but it also means that people will take you seriously, and recognise you're capable of delivering the goods as time goes on.

Setting milestones is important, such as having feature X planned for 0.4 and Y planned for 0.5, but don't stick to them too strictly. You might reach a point where Y is almost finished but there are problems with X, and end up preventing users and developers from enjoying both features.

So be flexible with your schedule; think about where approximately you'd like to be in a few months' time, but don't be afraid to change feature plans if something nasty crops up.

One of the most famous mantras in the free software world is "release early, release often". There's sense in this, but don't go mad with it - your releases need to have impact to get noticed.

If you make a new release every few days with just a handful of bugfixes and perhaps one or two new features, and post these updates on Freecode, outsiders will just see it as an endless drip-feed of information about your project (One project doing this, the Rho text editor, is making new releases and announcements every day with minuscule changes. It might be a great app, but I'm totally sick of seeing it).

Really, it's better to wait until you've got several awesome new things to demonstrate, with screenshots if possible, and stir up some excitement.

Version control comes into this too. It's largely a technical choice, and we won't delve into it here, but be careful how you use it. Telling people via your website to just "grab the latest source from SVN" isn't very exciting - what's new about it? What milestones has it reached? For some users: how do I use SVN in the first place?

Even when development in your project is moving at breakneck pace, it's still worth having defined, versioned, guaranteed-to-build tarball releases on your website.

Image matters!

It really does. I don't mean this in terms of prettifying your website, but in thinking carefully about how it will be perceived.

One of the most common flaws I found in 40 issues of writing HotPicks is this: many free software project websites don't even tell you what they do. You go to the site, and see a list of news updates, links to Twitter feeds, downloads and information about the developers, but nothing describing the application. Sometimes this'll be tucked away in an About page, but it's massively off-putting.

Users could try to decipher the program's purpose from a news item, then form a misconception and leave. So it's vital to have a clear description of the project at the top of the page. Think of it like this article: you have a headline to grab attention, and then a strapline providing a brief summary of what's to come.

On your website's main page, it's also worth following this up with a few bullet points describing the key features of your program, and then some news updates. If you'd rather have news on a separate page, include a message saying when the site was last updated so visitors know there's real activity in your project.

Screenshots are good, even if your program is command-line based. Show it in action, show its manual page, show it doing something cool. Whatever the program, screenshots give potential users an insight into how it feels to use it.

Keep screenshots up-to-date. I've seen far too many game websites where the game is at an advanced stage and looking fantastic, but the screenshots depict version 0.2, where everything looked pants.

Have a logo, but don't spend forever on it. Use simple shapes and colours - things that can be reproduced easily. Use the same logo everywhere to give your app an identity, and be consistent with its naming.

Look at KRename for example: on its website the description text calls it KRename with a capital R, but in the logo and page title it's lowercase (Krename). This might seem trivial, but focusing on consistency shows that you really care.

Dealing with lunatics

Here's to the crazy ones, eh? There are some pretty wacky people on the internet. Most of the time this is a good thing, as it means they spend hours every day making YouTube videos of cats being superimposed onto video games - ie entertainment for the rest of us - but occasionally it can go wrong.

When someone with a screw loose decides to focus all of his or her attention on your project, you're in trouble. And when they have several hours a day to devote to their cause, and you might have only 30 minutes, dealing with them can become a nightmare.

At the end of 2010, someone joined the MikeOS mailing list claiming that the project had been taken over by his company. His use of English was atrocious - so bad that I don't want to quote it verbatim here, as it'd be a crime against magazines.

I asked him to take his nonsense elsewhere, and his response was to personally email me a huge barrage of abuse, saying he was going to "tell Steve Jobs" on me, that I was violating his company's policy, and going to be punished, and MikeOS was doomed anyway because he'd made a Linux respin in SUSE Studio, which he was going to sell to Canonical. As the icing on the cake, with full cruise-control caps lock enabled, he told me five times "YOU'RE FIRED!!!".

But this clearly didn't satiate his loony rage, as a few days later he was back again, posting insulting comments on YouTube about me and claiming to be a police officer.

At this point, I decided to take it remotely seriously, so I did some investigation and discovered he was a 14-year-old boy with behavioural problems, and belonged to an internet gang of similar attention-seeking children who thought they were going to defeat Microsoft.

With this in mind, I emailed him saying I was contacting his parents about the abuse, and received a torrent of apologies from the boy, saying he'd make me a director of his company and other such twaddle. He claimed he was going to write programs for MikeOS, and made huge progress by… sending me ASCII art pictures to put on the disk. I ignored him and he disappeared, but I suspect he's haranguing some other hobbyist OS project now.

Handling hyperactivity

More recently, some disturbed individual joined the MikeOS list and claimed that he'd added "four APIs" to MikeOS. When I asked him what that meant, he posted some irrelevant code from another OS. I told him to be sensible or leave, and that instigated two months of daily nonsense to my inbox, completely indecipherable messages and bits of code that made no sense.

His crowning achievement was to send me some C code from a random Unix-like OS, and tell me to put it on the MikeOS disk in the "boot" folder - it would magically add networking support. (Even if MikeOS had a C compiler, it'd never work). Normally, I'd laugh these sort of antics off, but he seemed so determined to get my attention, even with such ridiculous contributions, that I found him pretty disturbing.

Eventually, I told him that I was contacting his ISP for harassment, and that sent him packing. His email address seemed to be linked to an XBox Live account, and while I know adults can enjoy consoles too (I do!), I suspect it was another hyperactive kid with too much time on his hands.

Some people are simply on another planet, and can't be reasoned out of their position. It's best to ignore them for as long as possible, and if you suspect that the offender is pretty young, tell them you're going to take action with their service provider. Almost certainly, the sprog's parents will be paying for their internet access, so the prospect of mummy and daddy getting affected by these shenanigans is usually enough to shut them up.