Best open source Web design software

The open source software movement is something that many people outside the tech industry struggle to understand. Why would you give up your free time to work on something you’re not getting paid for?. I’ve heard this question many times when speaking with friends and colleagues from outside the industry. To them it seems counter-intuitive to work on something for free. So if you’re not getting paid for this work, why should you do it?

Note: Some people do get paid to work on open source projects. For example, Google engineers get paid to work on as it’s their full-time job.

There are many benefits to working on an open source project. For me personally, the biggest thing has been having the opportunity to work with some really great people. Open source allows you to make connections far outside your normal circle of friends and co-workers. Casting out into such a wide pool of talent can be daunting at first. You might have to deal with issues you haven’t encountered before, like language barriers or working with people in different timezones. All of this is good experience though, which leads me into my next point.

Working on an open source project allows you to develop your skills, learn new things, and gain valuable experience working on a collaborative software project. I can’t stress enough how important this is, especially if you’re a student or just starting out in the industry. The experience that you’ll gain through working on an open source project is invaluable. This isn’t just limited to developing technical skills. Being able to function as part of a team is also really important, and something that companies look for in job applicants.

Finding a Project

Hopefully by now you’re sold on the idea of working on an open source project and eager to get started. But how do you find a project to work on?

The first thing you should do is to look at the software you use every day. Are any of those products open source? If so, those projects are the ones you should check out first.

The chances are you’re going to do much better work if you join a project that builds something you use regularly. You’re more likely to notice little bugs and things that could be changed to make the product easier to use. This concept is generally referred to as dog fooding.

If you’re still stuck for a project to work on take a look at or and browse the projects until you find something you’re interested in.

There are exceptions to the ‘dog fooding’ rule. You might find a product that you won’t use every day, but if it’s having a real impact on the world, that might be enough to keep you motivated. The project would be a good example.

Contributing to a Project

Now that you’ve found a project to work on, where do you start? The first thing you should do is check out the project documentation. Many projects have a wiki page that outlines how to get involved. This will usually explain the project’s mission and the process for making your contributions. It’s also worth looking out for a coding style guide that defines how your code needs to be formatted for it to be accepted into the codebase. Some projects will do things differently to others so it’s important to read through this information if it’s available. Again I’m falling back to my experience as a developer here, but you may find guidelines for designers, copywriters, or translators too.

The next place you should look is the project’s issue tracker. Browse through the list of issues and try to identify something you’d like to work on. Some projects (especially larger ones) maintain a list of issues that are ideal for newcomers to the project.

Many projects have forums or chat rooms where members hang out and chat about the project (as well as other things). Don’t be afraid to jump in and introduce yourself to the community. These people are there for the same reason you are. They just want to build something meaningful and have fun along the way.

You Are Not Your Code

Okay so now you’ve joined a project, submitted your first pull-request, and are waiting anxiously for someone to review your code. Then an email drops into your inbox. You open it and find that your pull-request was rejected, or someone is questioning a design decision you made. It’s natural to feel a little disheartened at this point, especially if you’ve worked really hard on your contribution. The key here is to not get too defensive or start an argument. I’ve seen this happen many times and it almost always ends with someone leaving the project.

Just remember, you are not your code.

The objective of code review is to make sure that a project’s codebase remains high quality and sticks to a consistent style. It would actually be worrying if every patch or pull-request got accepted without any discussion. This would probably mean one of two things. Either your contribution just got blindly accepted, or you’re a (hint: click the link, it’s a great talk).

That said, you can reduce the chances that your contribution will be held back by ensuring that you follow the guidelines in the project documentation. If you’re making any big changes it’s a good idea to discuss your design decisions with the community before you write any code.

Final Thoughts

The best thing about working on an open source project is that you have control over what you work on. Contributing to open source projects is fun, that’s why people do it. If you’re not having fun, you’re free to go work on something else.

If you’ve never contributed to an open source project before I strongly recommend that you give it a go. You’ll gain some great experience and meet some fantastic people along the way. You never quite know where the journey will take you.