Create Your Own Free Software Project

Got a great idea for an application or game? Not sure how to get started and attract other developers? Mike Saunders is your guide.

Free software is tremendously democratic. Anyone with a computer and an internet connection can get involved – there are no barriers of wealth or social status. Being educated
in computer science helps, but there are plenty of people working on free software at Red Hat, Canonical and Intel who’ve never been to university, and who acquired their positions simply by writing great code.

So anyone can contribute to free software, and anyone can start a new project as well. But how do you turn that great idea in your head into a real-life success? The likes of SourceForge and GitHub are littered with now-abandoned projects with barely 50 lines of code, which initially started as grand ideas to create the next killer music player, email client or game. Yes, free software is awesome, but 95% of projects never get off the ground or are abandoned after a few weeks.

Over the next few pages we’ll show you how to avoid this, and make sure your project has a proper chance of being a success. We’ll show you how to plan ahead, market your software, pull in new developers and get into the major distros. We’re basing this on experience too: this author runs a small operating system project (http://mikeos.sf.net) that has had over 60,000 downloads and contributions from 20+ developers around the globe. Lots has been learnt since the project started in 2006, and we’ll share these experiences here.

GitHub is one of the most popular project hosts, and includes an issue tracker for users to report bugs.

Naming, hosting, and choosing a licence

It’s crucially important to choose a good name from the start. You might be tempted to use a temporary name or some clever geek pun, but if you have to change it later, you’ll probably have to use new URLs for your project page and then lose a bunch of hits from web searches. Your name should also be appropriate for the 1.0 release as well. Consider Minetest, an open source Minecraft clone: it wasn’t such a bad name at version 0.0.1 when it was literally just a quick test to see if the developer could hack together a Minecraft-like engine, but now the game is much more complete and the name belies the extent of its features.

Also, avoid using special characters that cause problems with URLs or search engines. At FOSDEM we came across the OP^2 project to build an open source VoIP phone – but just try Googling that name. You’ll have absolutely no luck, and if people can’t even find your project on the world’s biggest search engine, your name means nothing. (We’ve seen even more horrific examples over the years, including project names containing asterisks and pipes. No, no, no!)

Try to come up with a catchy name, and note that it doesn’t have to be directly related to the type of software you’re writing. Firefox has nothing to do with fire or foxes, but it’s a short, unique and slightly odd name that everyone remembers. And again, think of Googlability: don’t go too generic. The Gnome 3 team decided to rename its Epiphany web browser to simply Web, but imagine what that’s like for people searching for solutions on Google. “Epiphany page load crash” is going to get you much better results than “Web page load crash” – so we don’t think that was the smartest move by our friends at Gnome.

Finding the right host

Next, you’ll need some kind of web presence for your software. The sheer variety of options on offer can be overwhelming, but there are a handful of websites that we recommend. GitHub (https://github.com) is the most popular right now, and lets you create a source code repository that anyone can clone via Git and then work on their own branch. GitHub is great for fast-moving projects with lots of contributors, although the services on offer are rather limited – you can’t use it to create forums or mailing lists.

SourceForge (www.sourceforge.net), meanwhile, is one of the oldest FOSS project hosts and includes the aforementioned forum and mailing list facilities. You can even administer the website of your project over SSH. SourceForge is a giant site, though, and it can be fiddly to use; we’ve also seen it become inaccessible for periods of time. SourceForge got some flak recently for modifying installers of FOSS Windows programs to include (optional) adware, but this hasn’t affected Linux users.

If you’re passionate about free software principles, want to use the GPL for your licence and plan to avoid all non-free file formats (such as Flash) on your web pages, you could try Savannah (http://savannah.gnu.org). Another alternative, especially for those creating software that’s tied in with Ubuntu, is Launchpad at www.launchpad.net. Then there’s Google Code (http://code.google.com) which is fairly limited but very reliable thanks to Google’s mighty data centres.

A few notes on creating your web presence: always, always say what your program does right at the top of the page. So many projects have awesome-looking websites that don’t actually reveal a single thing about the software in question. Additionally, make sure to include a news section (with dates) on the front page – again, ideally near the top. This way visitors will see that your project is alive and being updated. Try to summarise what’s great about your program in a few bullet points, and include screenshots. If you can’t make pretty images (eg it’s a command line program), try installing a screen recording tool from your distro’s repositories such as RecordItNow or SimpleScreenRecorder, and make a few videos showing off the features.

Choosing a licence

Before you write a single line of code, it’s important to settle on a licence for your project. You can’t just say that your program is open source or free software – it needs to have some kind of licence attached to it, so that contributors know what they can do with the code. By far the most popular licence in the Linux world is the GNU General Public Licence (GPL), which says that the source code is free for anyone to read, modify and share. But the GPL is more complicated than “just do what you want”; it also enforces these freedoms on others. So you can’t take a GPLed program and make something proprietary out of it – you have to share your modifications under the same terms.

Most of us love this licence, and it has stopped companies from taking the Linux kernel, the GCC compiler, the essential GNU C library (Glibc) and other valuable projects and using them in proprietary operating systems. But the GPL isn’t everyone’s cup of tea: some developers regard it as too restrictive, and prefer the BSD licence. This essentially has the same freedoms to share and modify, but permits code to be used in proprietary software. FreeBSD, for instance, is a BSD-licensed operating system that anyone can download and modify, but there’s also a closed-source version included in the firmware of the PlayStation 4.

To use the GNU GPL, see www.gnu.org/licenses/gpl-howto.html. The BSD licence is available at http://opensource.org/licenses/BSD-2-Clause, and includes clauses to stop you from being sued if your program doesn’t work properly – so if someone uses your code to run a nuclear power station and a catastrophic meltdown occurs, it’s not your fault. The BSD licence also ensures that you get credit for your work when it’s used in other projects.

If you’re not interested in any restrictions and don’t care about being credited as the original author, you can release your code as public domain
(www.unlicense.org). Alternatively, you could try the Beerware licence (http://en.wikipedia.org/wiki/Beerware) which says: do what you want with the code, but if you find it useful and happen meet me one day, buy me a beer.

Even if you don’t care about the licence now, bear in mind your future contributors. Many people are passionate about the GPL and its enforced sharing mechanisms, so it’s the best licence to choose if you want to attract the widest pool of developer talent.

The GPL is a good default choice of licence, but see www.choosealicense.com if you want to explore some alternatives.

Writing the code, and bringing people on board

So many developers make a crucial mistake in the first stages of a project: they start asking around for contributors. This sounds like a great thing to do, and is very tempting – after all, if you tell the world about your awesome idea, you’ll soon have a team of 20 hacking away on code, graphics and documentation, won’t you?

Well, no. Until you have anything to show, even a 0.1 version, many potential contributors are going to ignore your calls for help. That’s not an insult – it’s just that there are tens of thousands of projects out there with good intentions, but not a single line of code. If you want people to help you out, you need to show that you’re serious about the project, and that you have the knowledge and commitment to do the bulk of the work early on.

Similarly, another problem that can arise in these very early stages is developer spats. If you don’t have a basic codebase and roadmap, you could end up with new contributors trying to take the project in many different directions, causing arguments, resignations and (potentially) forks. All this before you’ve even gotten 0.1 out of the door! It’s happened before, and it will happen again…

So it’s vitally important to have something to show the world – even if it’s a very primitive version of the app. Try to get to version 0.1 or 0.2 on your own. If you have some fantastic ideas for a music player, for instance, but you’ll need extra help implementing the advanced features, you should at least get the basics done yourself. Write a simple music player and add menu items or toolbar buttons for the features you plan to add later. This shows potential contributors that you have the knowledge and capability to write
an application.

Once you’ve made a start, try to define a roadmap, at least for the next two or three releases, but ideally up to version 1.0. This helps developers to see your goals more clearly, and prevents your project from languishing in 0.XX versions for many years (like Inkscape – a stable, brilliantly useful vector graphics app that’s used by professionals, but somehow is still stuck at version number 0.48.2). If some of your feature ideas are awesome but very difficult to implement, don’t be afraid to push them to version 2.0 on the roadmap, and focus on getting a simpler 1.0 release out of the door.

Finding contributors

Once you have a 0.1 release prepared, you need to tell the world about it somehow. A good start is to visit http://freshcode.club, a regularly updated feed of free software project releases. Click on the Submit button in the bar towards the top, then enter your project’s name, website and a short description. You can also add tags to your project to help users when they search on the site. Once you’ve filled out the form, click Submit at the bottom and your entry will be added to the page.

Freshcode’s feed is picked up by many other websites, so this is a good first step for spreading awareness about your project. If you’re working on a game, you could also submit it to the Linux Game Database at www.lgdb.org – make sure you have some pretty screenshots to get plenty of attention! If your first release is already close to being feature-complete, you could also submit a link on www.reddit.com/r/linux, but note that this subreddit is very busy and your post could get lost unless your program will be of interest to many people.

After this, you can do some more targeted advertising of your project. Try posting an announcement about the first release on a
popular forum, such as www.linuxquestions.org/questions – the “General” subforum is the best choice in this case. Make it clear that your program is open source so that your post doesn’t accidentally get marked as spam, and use this as an opportunity to recruit new developers.

It’s important to be specific about what you want. Don’t just say “please come and write code for my app!” Instead, state which features or parts of the codebase need work, and point people to specific files and line numbers where appropriate. Nobody wants to spend days poring through your code to find the relevant place; they want to get hacking straight away! Other forums to post on include www.ubuntuforums.org and, of course, our very own at http://forums.linuxvoice.com.

If your project needs some artwork and you’re not a dab hand with Inkscape or Krita, you can request help at www.opengameart.org/forums/resource-requests. Post a message explaining what you’re working on, including a link to your web page, and describe what you need. See some of the previous posts for examples. You might not get an immediate response, but give it a few days and hopefully someone will be in touch.

Finally, contact Linux journalists! Our Ben Everard (ben@linuxvoice.com) writes the FOSSpicks section of this magazine, which is a great opportunity to showcase new projects. Send him a link and if your program is already usable and potentially of interest to Linux Voice readers, he’ll consider it for inclusion.

Once you’ve made your first release, submit it to http://freshcode.club for all the world to see.

And that’s all the weather

If you bear in mind everything we’ve discussed here, your project will get off to a healthy start and it won’t be long before you end up getting contributions from around the world. As your project grows, you can even add a ‘donate’ button to your web page – there’s nothing better than sipping on a particularly nice coffee/beer/wine that one of your users has paid for.

And above all: good luck, and thank you for contributing to the world of free software! Even if it takes time to build up your project, so much in FOSS started as a hobby project coded in someone’s bedroom. From tiny acorns, and all that…