How to Start Your Own FOSS Project

Get Involved

Article from Issue 200/2017

Don't just consume Free Software – contribute to it! We share the tips and tricks required to start a successful FOSS project.

There are many ways you can give something back to the free and open source software (FOSS) community. You can help new users come to grips with Linux or write documentation for your favorite app. If you have coding or graphic design skills, you can help in those areas as well. But, what if you're really itching to contribute to a FOSS project and can't find one that really appeals to you? The answer, of course, is to start your own!

Now, obviously, you'll need some prerequisite skills for this. You'll need to be pretty adept at the programming language you're going to use. But don't let that put you off – if all goes well, you'll spend more time implementing patches from other users rather than writing new code by yourself. I can attest to this: When I started the MikeOS project [1], I wasn't especially knowledgeable about x86 assembly language. But I learned the basics – enough to judge the quality of the patches that then started trickling in.

Creating a whole new FOSS project may seem like a daunting task, but if you break it down into steps, it becomes a lot easier. We've watched many FOSS projects come and go over the years – and have our own experiences starting and contributing to them – so this month, we'll share what we've learned to help you successfully kickstart your project.

Step 1: Set the Goal (and Name)

What sort of software are you going to create? Whether it's a desktop app, a programming tool, or a game – or anything else – make sure it has a reason to exist. For example, if you want to make an email client just because you're curious about how they work, that's fine – good luck! But it's not really worth creating yet another SourceForge or GitHub page for it. If you define a clear goal for your app, however, you'll stand a much better chance of attracting new contributors.

This goal is up to you: Maybe you want to make the world's fastest email client or a text editor geared toward a specific programming language. Perhaps you want to create the world's most awesome Tetris variant or a DHCP server that only needs 2K or RAM to operate (e.g., for embedded devices). Whatever the case, have something you can shout about on your web page – something that makes potential contributors think: "Cool, I've not seen something like that before!"

Then you have to come up with a name. This is one of the trickiest aspects of launching a new FOSS project, because it's difficult to change it further down the road. You can modify your goals, your branding, and even the structure of your community, but you won't be able to change your project's name without major headaches.

Take Gimp as an example – great piece of software but absolutely ridiculous name (Figure 1). If you've been using the application for a long time, you might not think about how bad it is – but have you ever tried explaining or advocating Gimp to a Windows or Mac OS user? Just think of the images that people get in their heads when they hear the word gimp.

Figure 1: Gimp has a pretty good mascot (Wilber), but the application's name has all manner of problems.

Over the years, there have been many discussions about changing Gimp's name. But it's such a mature and well-established piece of software, that it'd be an enormous job. There's so much Gimp-related information and material on the Internet that, even if the team decided on a name change, all that other content would refer to Gimp for years to come.

Some people argue that your project's name should say exactly what it does, but I don't think that's important. Firefox doesn't set fire to foxes, but it's short, snappy, quirky, and makes for a great logo. Think of Google, Flickr, Twitter, and many other strong web brands – the names have little relation to what the services provide, but everyone knows them.

So keep the name short (two to four syllables), make sure it's easy to pronounce (think of all the different ways people can say Mageia), and check that it won't offend anyone in the world's major languages. Also consider how people can search for information about it. Gnome's web browser is called Web, for example, so if a new user needs some help, he or she will search the web for, er, Web. That makes it much harder to get targeted results.

Step 2: Build a Brand

Once you have a name and some goals for your project, it's time to start coding. You should really do this before even creating a website or asking for potential contributors. The web is laden with of 0.0.1 proof-of-concept FOSS projects that never went anywhere – projects where the original creators had grand ambitions, put loads of work into fancy websites and logos, but didn't even provide a working version of the software for people to try.

So, get cracking with the code. Even if you only get to version 0.1, missing some key features, if you have something that people can actually compile and use (or play in the case of a game), it'll be much easier to bring new contributors on board. Not only will you have something to build on, but you also prove to your fledgling community that you are capable of writing code and doing the grunt work to keep things moving.

Then think about branding. A logo or mascot isn't essential, but it adds some personality to your project. It's a good idea to start with something very simple, because over time you can then make variants on the original logo with more detail. Consider the LibreOffice document logo (Figure 2): It's basically two shapes, in black and white, but the individual modules of the suite (Writer, Calc, Impress, etc.) all have their own variants of the logo with more details inside the document shape.

Figure 2: Notice how the main LibreOffice logo at the top is very simple, and variants on it are used for the components of the suite.

Logos can be very simple yet extremely memorable. Think of IBM's logo – just those three letters, but drawn like a grid. Or Nintendo, which is just that word in a particular font with an oval around it. For my project, MikeOS, a contributor sent in a logo design (Figure 3), which we still use. The green triangle going through the letter "O" doesn't mean anything, but it's simple, unique, and easy to reproduce in different sizes.

Figure 3: The MikeOS logo was created by someone who just happened to randomly come across the project, but it has survived the test of time.

Next up, you'll want some kind of web host for your project. There are many of these – e.g., GitHub and SourceForge – all with their own features and restrictions, so you should investigate a few and find one that's best for you.

When creating a web page for your app, there are some things you absolutely should do. First, somewhere near the top of the page, state what your project does. This simple description is often buried under news updates or other content – or isn't even there. When compiling the FOSS Picks section of this magazine, we come across many projects for which there's no actual short and obvious description of what they do. So we just skip over them. They may be great, but the websites aren't doing their job.

It's a good idea to have some news updates on the front page as well – for new major/minor releases or new contributors to the project. This gives visitors an immediate indication of how active (or not) your project is.

Step 3: Develop Your Community

So you've got a working alpha version of your app or game. You've given it a snappy name, come up with a clear and striking logo, and your website has all the essentials, neatly structured to welcome potential new contributors. Where do you go from here?

Well, you need to get the word out. Reddit is a great site for this – go to the open source [2] or Linux [3] subreddits and write a post explaining who you are, what you're doing, and how people can get involved. Remember that SourceForge and GitHub are littered with abandoned FOSS projects, so you really need to sound active and positive. Make it really easy for potential contributors to try your app (e.g., with prebuilt RPMs, .debs, Snaps, Flatpaks, Docker images, etc.) Maybe create a few easy hacks – coding or design jobs that don't require much time but will help people join your community. Set up a mailing list and encourage people to voice their opinions.

Another site where you can post your announcement is Hacker News [4]. Note that it's a very busy site, so unless you're very lucky, your post will fall off the front page within 20 minutes. But it's still worth a try. Also try talking to Linux journalists – like us – so that we can learn about your project and consider featuring it in the magazine.

In the early days, you may have new contributors trying to one-up each other to establish control in the project. There's nothing wrong with making clear from the start that you're the "benevolent dictator" – after all, someone has to make decisions, and endless arguing at the start typically kills projects in their infancy. Don't be afraid to be the main decision maker, but also encourage your contributors to set up their own subprojects (e.g., documentation, design) and teams, so that they also feel like they have an element of control. (See the "Art of Bikeshedding" box for more details.)

The Art of Bikeshedding

Parkinson's law of triviality, commonly known in FOSS circles as "bikeshedding," states that "members of an organization give disproportionate weight to trivial issues." In other words, people spend huge amounts of time bickering about petty stuff – like the color of a bike shed before it's even built. It's a common problem in FOSS projects: You may want some important feedback about a major new feature you're adding, but everyone starts arguing about comparatively trivial things like the design of an icon, or whether it's better to use tabs or spaces in code.

Still, bikeshedding can actually be useful in some cases. If your project has been rather quiet for a while, or a particular mailing list or forum appears to be dead, you can inject some life into it by posing a trivial question – but one for which everyone has an opinion. For example, you could say that you're going to rearrange some of the menus in your app, or tweak some colors, or modify some command-line options.

Even if you have no serious intention to do any of these, you'll still get plenty of opinions on the forum or mailing list. Ideally, this will generate other discussions and activity in your project – and, of course, it makes bystanders and lurkers in the project feel more involved. For more on bikeshedding, check out a fascinating insight from the FreeBSD camp [5].

And from there onwards, it's up to you. Most FOSS projects take years to reach maturity and develop bustling communities, but with the approach we've outlined here, you have a decent chance of success. There will be problems down the line (see the "Dealing with Trolls" box), and your project may even get forked a few times. But that's often healthy when developers simply have fundamental disagreements and can even bring competition back to stagnant projects.

Dealing with Trolls

"Hurr durr, your app sucks and you suck, and you are obviously paid for by Microsoft AND Apple and you are literally Hitler and I'm going to tell everyone not to use your software because it's rubbish." See that? It's a typical comment on the Internet. If you've ever spent any time on YouTube, you'll know that 99.98% of all comments are dribbling nonsense in that vein (but usually much, much worse). Trolls are everywhere – they're part and parcel of the Internet – and in many cases, they're just causing irritation and chaos for their own entertainment.

Anyway, your open source project isn't likely to be swamped by trolls, but a few may rear their heads, especially if your software starts to gain popularity or is perceived as a challenger to an established app. The best thing to do is simply ignore them. Delete their posts, ban their accounts, but don't give them any attention whatsoever. Don't respond at all. Most trolls don't mean any serious harm and when they realize they can't get you in a fluster, they head elsewhere for their "lulz" (Figure 4).

Figure 4: Don't let trolls get to you – they thrive off angry responses. Don't even let them think they're having any effect.

Above all, make sure you're having fun. If you're not being paid to work on FOSS, you should make sure you're getting something valuable out of it for yourself. We often like to think we contribute to FOSS for altruistic reasons – but it's also a way to gain valuable experience (in terms of coding and project management) as well. Don't get burned out; put a deputy project leader in place if you need time off, and above all, enjoy.

Real abuse (threats, harassment, posting personal info, etc.) is much more serious than trolling, and while rare, it can happen. Consider setting a Code of Conduct [6] for your project to establish the behavior you expect from the start. And, if someone violates the guidelines, take the discussion off-list immediately. Talk to the offender personally and try to understand why he/she is acting in that way before taking further steps. Chances are you'll have to ban them from the project – but make sure you hear all sides of an argument first.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95