Contributing to Open Source Projects Not Just For the Experts
XDA has long been a proponent of open source development, and we’ve seen it flourish over the years. In fact, it’s one of the main reasons our community has grown as fast as it has over these past 13 years, with Android’s core being the driving force. Many people desire to be part of open source and contribute but often don’t know how they can, whether because they think they lack the skills or they just don’t have the time.
I recently read a good article on RubyGarage which spoke to this, and I thought I would build on it and bring relevance to the XDA community. In the article the author points out that the best way to learn and/or expand your skills is to in fact just start contributing. Now, I hear what you’re thinking:
“That’s great. Wonderful analysis. Much words. That doesn’t help me though. I don’t know why I should or where to begin!”
Never fear, dear reader. I am here to give you some reasons why you should, and then we’ll move to ways you can begin.
Open Source Basics
In a conversation I had recently with my oldest child, we were discussing how cars have changed over the years. I told him that in many ways the idea of the car wasn’t far removed from the horse-drawn carriages of the late 19th / early 20th century. Every car has wheels (usually four), a power source, and a passenger/cargo area. Each manufacturer may dream up, and in some cases implement, new designs, but they haven’t gotten away from the core of what Henry Ford based his original vehicle on.
In many ways, the same goes for software: there’s nothing really new under the sun (no matter how many times Apple labels some new feature innovative that everyone else not inside the reality-distortion-filter of Cupertino has had for years), and all these software packages out there tend to reinterpret what has already been into something different and usable for a new audience. And don’t get me wrong – that’s not a bad thing at all. What it does mean is that you’re building on a foundation which has been laid before you.
Open source arose from the Free Software movement, and at its core is an idea that software should be made so that anyone can make use of it’s functionality and methodology. This means that developers, bound by the terms of whatever open source license the original software is protected by, may a) take the work and use it for their own; b) contribute fixes, features, etc. to existing projects; or c) take the work, improve on it, and contribute their changes back (some licenses REQUIRE this like the GPLv3). You’re standing on the shoulders of the giants who have come before you – so give back just like they did.
Why should I?
I’ll answer this with an answer back – “Why shouldn’t you?” I’m being serious here. If you have the ability to, or the desire to lend your assistance, etc. – why wouldn’t you just do it? Often what I have found as a blocker for entering open source is a disconnect between what contributing actually is.
Being a contributor to an open source project is often identified as someone who commits actual code to solve an issue, add a new feature, or a new project entirely. But what’s frequently forgotten about is that often what a project needs is someone to handle the task of keeping up / translating documentation, reporting bugs, providing user support, etc.
Where do I find a project?
Outside of deciding to start your own project, you can of course help out other projects. With so many to choose from, a good way is to start in the device-specific ROMs, Kernels, Recoveries, & Other Development section on XDA for your device. You can also look for Trending projects on Gitlab or Github or Github’s nice way to explore projects solving different types of problems.
How do I start?
It is not uncommon for someone to start reporting bugs and then decide to figure out how to fix them and then commit the fixes to the project. While not the most interesting, reporting bugs/issues can be one of the most important. When you find a bug you should report it using that project’s chosen bug tracker, i.e. XDA’s DevDB Bug Tracker or the Issues found on Gitlab or Github. Make sure you provide as much information as possible, like the error message, log of the error, steps taken to get to the error, etc. The more information the better.
If you look through the project’s bug tracker and you see something that you know how to fix, whether it be code-related or user error, do not hesitate to jump in and assist. If you have the fix, follow the contributing guidelines for the project and submit the fix via the correct steps.
Projects often find themselves heavy on those who can write code, but light on those who can right good documentation. Let’s face it – developers don’t like writing it, but they sure wish the previous developer did. So if you can document a procedure, modify a current one to make it more “intuitive” (which is a nice way of saying “idiot-proof”), or create or update wiki entries, by all means do it. The project, and its users, will love you.
I hope this has given you some ideas on why and how you can get involved in open source. If you have some experiences with being a contributor, or have a project you would like help on, please let us know in the comments below.
[Featured image courtesy of OpenSource.org]