How to manage an open source project

10th Mar 2012 | 12:00

How to manage an open source project

The do's and don'ts of handling projects

Manage open source projects: how to be different

Put yourself in their shoes - that's the most important thing to remember as the boss of a free software project.

Whether you're handling a code patch from an argumentative contributor or trying to attract users via a release announcement, it's vital to think carefully about how other people will see it.

You, as the leader of the project, might have all the insight and ambition in the world, but you've got to think constantly of how others perceive you.

For six years, I've been working on an x86 assembly language operating system called MikeOS at While it's still in the hobbyist sector of the OS market, it has been a decent success, with coverage on OSNews, thousands of downloads, hundreds of patches and countless emails from users.

There have been ups, downs and mistakes, so I'm going to share the knowledge I've picked up - and it's real knowledge, not buzzword-ridden project management strategies designed to make 'consultants' money.

Be different

Browse (formerly for half an hour and you'll probably come to this conclusion: the world doesn't need another GTK-based lightweight MP3 player. There are already hundreds - some good, some rubbish - and that market is totally saturated.

Of course, there are reasons why so many people write MP3 players: we all listen to music, they're pretty easy to code, and you have great libraries and sound frameworks available to assist in the development. It can be a great learning experience.

But that doesn't make it a great free software project, or something in which other hackers will want to get involved. So you've got to produce something unique. You need a selling point that differentiates it from everything else.

This doesn't mean you should shy away from established genres - perhaps you've got an idea for an MP3 player with built-in speech recognition for transcribing interviews, for instance. That's novel, a cool idea that hasn't been done to death, and when you add your project to Freecode, it'll really stand out from the crowd.

Ultimately, you want people to see your work and think "Wow, I didn't know that was possible," or "Finally, someone has done it". Whether or not you get other developers involved, this is good self-encouragement too, helping you to believe that you're genuinely making a difference to the computing landscape.

If you're working on a project that feels a bit bland and samey, but you want to release the code anyway, spend a few weeks browsing around, getting feature ideas and thinking of how you can make your application different from the rest.

"Now Mike," you say sternly, "that's all good and well, but what about MikeOS? Isn't there already a pile of real-mode assembly language operating systems out there?"

Yes, that's true. And when I first released MikeOS, I made the mistake above - it didn't do anything special. I was proud of it, and wanted to keep developing it, but nobody was paying attention.

So I decided to give it a unique selling point: I didn't have time to transform it into a Linux-like super OS, but I know how to write about things. So I set MikeOS's goal as being the best-documented hobbyist OS around, where everything is explained, commented and understandable.

I wrote three meticulously-checked handbooks for running the OS, developing applications and customising the system, and I went through the code and commented as much as I could. It's not perfect, and there are still gaps, but I've yet to see a similar learning-focused assembly language project documented in such detail.

Manage open source projects: something usable


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.

tutorial Linux open source
Share this Article

Most Popular

Edition: UK
TopView classic version