Monday, May 6, 2013

Getting Into Open Source as an Inexperienced Self-Taught Programmer

I often see questions from newer programmers like myself asking how they can start getting involved in open source projects. On Reddit's learnprogramming subreddit, it is #9 on the FAQ list.

I want to share my own experience.

After about a year and half of teaching myself programming, I had dabbled in a variety of languages and a few different programming environments.  I had a little experience in a large range of fields: Android development, Python desktop applications, network servers and clients in C and Go, and various toy game projects in a variety of frameworks.  While this provided me with a lot of useful learning opportunities, it never left me feeling skilled enough in any one area to meaningfully contribute to an open source project.

Some time in 2012, I heard about Glances, a curses based system monitor program written in Python.  I thought it was a nice program, downloaded it, and used it from time to time.


Eventually, in February of this year (2013), I came across Glances again when I was looking for open source projects to contribute to.

Python was the language I first started to learn programming with, and it is probably still the language I feel most comfortable in, so the project was a good fit for me.

The most difficult part of getting involved in a new project is understanding the project structure and the code base.  Fortunately for me, it wasn't necessary to understand the entire code base before I started making some changes.  By starting with a very small change, you can hopefully avoid affecting other parts of the code.  If you want to continue contributing to the project, it will eventually be essential to understand how everything works together, but changing some string formatting here and there, or adding a new data piece to an object might not be that big a deal.  You should still do your best to tread carefully.  The best case scenario is your pull request gets reject with some nice comments asking for changes.  The worst case scenario is you introduce bugs into the project that go undiscovered until it's too late.

I began to contribute to the project by adding small, easy to implement features.  Specifically, I added options for displaying network traffic data.  I think this is an excellent way for newer programmers to start contributing, but it is important to keep in mind that the maintainers of the project may not necessarily be interested in adding these features, depending on their vision for the project.  Communication is important if you don't want to risk wasting your time.  It doesn't hurt to first send an email laying out your plans, and asking for opinions, or even just asking for help.

Next, after doing more work on small features and various bug fixes, I implemented a feature that allowed Glances to run without collecting processes data, which was the vast majority of CPU overhead.  This allowed Glances to run on my Raspberry Pi, using only 2-4% of CPU, instead of 20% (!).  Of course, it meant sacrificing data for individual processes, but a system monitor app that takes 20% CPU is of questionable usefulness anyways.

This, is in turn, gave me an idea for how I could further contribute.  Glances can run in server mode, and using an XML/RPC api, it can deliver its data in json format.  I run my Raspberry Pi headless, so this seemed like it could be really useful when ssh is not an option.

As I mentioned above, I had some experience with Android, so I spent a month or so implementing the Glances API in Java, which is technically the first open source project of any usefulness that I have created.

The next step after that was to create the Android app. It uses the Java Glances API to collect the data and display it to user:


The final product can be downloaded here

Or you can view the Github repo

Interestingly, shortly after the creation of the repo, a contributor helped out by adding a French localization (Glances is popular in France, the home of its creator) and also the cpu and memory utilization bars seen in the above screenshot.

I  think the key to getting involved in your first open source project is to aim small, be polite, and don't be afraid to ask questions.  Things can really ramp up from there.

No comments:

Post a Comment