How to manage an open source project

Running a project
Is this the year of MikeOS on the desktop? Probably not, but we're looking forward to another busy 12 months for the project

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. 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 Freecode (formerly freshmeat) 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.