Want to contribute to your favorite Linux distro, but not sure where to start? Don’t worry. It’s easier than it looks, and you’ll find plenty of help.
Not a developer? That’s not a problem. There’s enormous demand for Linux distro writers, artists, translators, advocates to work events, educators to introduce Linux to their students, students and parents to push Linux in schools, etc. If your only skill is interpretive dance, you might have a problem finding a place to contribute, but other than that you can find some way to help. Developers, of course, are very welcome too!
Graduating from User to Contributor
According to Canonical, Ubuntu has more than 12 million users. Fedora and openSUSE’s stats show that they also have millions of users. So does Debian, etc. The problem is that out of those millions of users, only a very small group takes the time to contribute to the projects that they use. To be sustainable, these Linux distros need more contributors to participate and help with everything from advocacy to translations. There’s much work to be done, and too few hands to do it.
This isn’t to say there’s anything inherently wrong in being a user without making a direct contribution. Using Linux also helps in the long run. The greater the market share, the more seriously that vendors will take Linux and open source. The easier it will be to convince vendors and service providers that they need to support Linux as a platform and make contributions. Look at the success Firefox has had in convincing providers that they need to stop developing only for Internet Explorer.
Users are important for so many reasons. There’s no doubt. But, if you’re using and enjoying Linux, consider ways to give back and help ensure that other folks can enjoy the same benefits and that your favorite project remains healthy. You really can make a difference. Maybe your contribution is not huge in and of itself, but every bug report, every edit in the wiki, every word translated, and every hour spent handing out DVDs at events is valuable. Conversely, every opportunity to contribute that’s passed up means that one person may not get their question answered or might not have their first experience with Linux, or might not be able to use Linux because the translations didn’t pass the threshold for release.
Also consider that contributions are the new resume. If you’re looking to build a reputation in the community and want to have something to show potential employers, there’s no better way than getting involved with a project and demonstrating your know-how.
The Big Picture: How Distributions Come Together
The problem for many contributors is not a desire to contribute, but the first step. It’s not always easy to find information on how to contribute. The first steps to contributing seem time-consuming. Everything is done online, which can be off-putting for people who are used to working with people face to face. In short, the first step is a doozy and can be intimidating for many people. If you’re one of those people, read on. It’s not as scary as you think and it’s much more rewarding than you imagine.
Most projects these days are on a time-based release cycle. Ubuntu and Fedora release every six months, openSUSE every eight months, Debian releases when it’s ready regardless of the time between releases. A release consists of packaging thousands of upstream projects and packages and testing them, ensuring that all of the translations are complete, documentation is written, marketing materials are written, and all the other work that goes into a release. In general, the best time to get involved is at the beginning of a release cycle. If you’re not starting at the very beginning, no worries. However, the weeks before a release are hectic. Don’t be surprised, or offended, if you don’t get a lot of feedback as a newcomer if you start trying to contribute while everyone is in headless chicken mode.
The work is done by different teams inside of the project. The teams may be slightly different across distributions, but you should be able to find teams for quality assurance, translation, marketing, documentation, infrastructure, and packaging among others. Each team is going to have its own style and a group of contributors who are already helping.
Take Fedora, for example. If you look on the Fedora Project site, you’ll find a page on how to join Fedora. It’s broken up by skills. If you go to OS Developer you’ll find a list of teams that work on the distribution development. You’ll find similar pages for Ubuntu, openSUSE, and most other projects.
Once you’ve decided which team(s) you’d like to work with, make sure you’re subscribed to that team’s mailing list. Also, be sure to join the main project mailing list (if there is one) and the general announcement list. Fire up your favorite IRC client and jump into that team’s IRC channel, if any.
Watch the conversation for a bit. Read the mail archives. Get a sense of the community you’re trying to join. Most teams will appreciate it if you introduce yourself, and say how you’d like to contribute. After you have a feel for the community, it’s time to take the plunge.
Just Jump In
Here’s one of the hardest parts for most new contributors: Submitting that first contribution. It’s a bit odd for many people to work out in the open and to submit work for everyone to look over, critique, and possibly reject. Most of us are also used to being assigned tasks. Some projects do have wish lists or obvious starting points for newcomers, but with some other projects it’s not obvious where to begin. No problem. Find something that needs to be done, and do it.
If you need access to do whatever, ask. If it’s something that could result in duplicated effort, speak up on the mailing list and let people know you’re about to start. But don’t wait for an invitation.
Embrace Criticism, Reject Abuse
Most projects will appreciate any attempts to help and will work with contributors to guide them into becoming more effective contributors. That doesn’t mean that you won’t get any pushback or criticism of contributions, though.
It’s entirely normal to get some course corrections the first couple of times you submit a contribution of any kind. Translation teams may want you to use different words to describe computing concepts in order to be in concert with existing documentation. A documentation team may have a house style that you should use. The art team may push back the first draft because it’s not what they’re looking for or needs to be adjusted to meet style guidelines.
The bottom line: Expect high standards. As a contributor, it may be tempting to feel that anything is Good Enough when you’re doing it in your spare time. But the open source ethos isn’t about “good enough;” it’s about an open process that produces excellent work.
Some criticism may not be as diplomatic as it could or should be. You might need to develop a thicker skin to get used to seeing your contributions critiqued on an open list. Don’t take it personally, though. Remember that everyone in the project wants to do good work, and criticism is just seen as a tool to achieve that.
There is a line between critique and non-constructive criticism. If you’re not getting the respect you deserve as a contributor, move along to the next project.
Resist the temptation to have something “perfect” before submitting it. Submit the first draft of some documentation. Upload a package when it’s built. Announce your plan to work as an ambassador at a local event, or throw a launch party even if you’ve never done it before. Submit a theme or wallpaper, or a marketing proposal for the first time. Do something, even if it’s wrong. It’s better than sitting on your thumbs and just thinking about how you could have contributed.
You’ll often find that the input you get will improve your work and make it more valuable. In other words, don’t be afraid of getting it wrong. One of the important parts of the open source ethos is to release early, and release often. This includes personal contributions as well as software releases.
Keep Promises
Here’s a hard part once you start contributing. Learn to say no, or not to raise your hand all of the time. Delegate tasks, and don’t take on too much.
As I said at the beginning, most projects have too few hands for too much work. Once you know the ropes, it may seem tempting to jump in whenever there’s work to be done, no matter how much you’re already doing. It’s an admirable impulse, but ultimately a bad idea. Break off a chunk of work that lets you make a meaningful contribution, but leaves others room to contribute and gives you plenty of time for life outside open source.
When you do commit to something, make every effort to get it done. But a big part of that is learning early when to say no. It’s not easy, but it might be one of the most valuable skills you bring.
Ready, Set, Contribute!
Each community has its own flavor and it’s hard to give concrete guidelines on how to contribute to all projects. The best way to contribute is to just start. Like anything else, you’ll improve with time. Contributing will seem a little awkward at first, but with each contribution it will be easier and it will be more fun.
