Sunday, 28 May 2017

My Open Source Journey: Working With Open Source Projects

Hello people. Long time, no see. For those of you kind enough to wonder what I’ve been up to, here we are. I’ve been contributing to open source software or at least trying to, with varying levels of success. Now if you’re asking what open source software is, please read here for the thorough definition that I, in the interest of remaining on topic, cannot give you. For the purpose of this post, I’m assuming that you’ve read this and will keep it in mind as we go along.

So, to return to what I was saying earlier. I’ve been trying to contribute to open source software. I had wanted to for the longest time. Anyone who’s known me long enough, knows that I’m a huge Linux fan. Using Linux isn’t necessary to contribute to open source software especially if your skills are non technical. You can organize events, share the software that you love with friends and family, and even donate to the cause. So I must arrest you with a disclaimer: this particular open source contributor is of a technical bent. Thus this post will be biased towards contributing as a technical person. However if you’re non technical and you’re interested, I think this guide will help. 

Technical and still following along? Thank you for sticking with me. 😎 Now as I was saying using Linux isn’t necessary but it helps. Primarily because if you use Linux long enough, you begin to get into the techie bits. You find yourself asking questions like ‘Why isn’t X working?’, ‘I got this error message, what does it mean?’ You spend time trawling through forums, asking questions on IRC and mailing lists, looking for solutions.

Through this you (hopefully) build up good habits when interacting with other open source software users and developers (the people making and maintaining the software). You learn empathy, respect, how to ask the right questions (a good and humourous guide is here), how to keep track of and find error messages, and in time, what these error messages mean and what they could possibly point to as being the problem. You also learn how to read documentation (RTFM is commonly expanded as Read The Fine Manual, and if you’re being told this, don’t feel too down; it usually means that your problem is fairly simple or the people you're interacting with aren't very pleasant. It does happen, though rarely. The other form of this is ‘Google it’. If you insist, you’ll get a LMGTFY link (LMGTFY = Let Me Google That For You). 

These skills can be learned via using a programming language or through using a particular piece of software, open source or otherwise. Cue personal biases here; I learned this through open source software and mostly through using Linux. Your mileage may very well vary 😉. If pushed to recommend anything, curiosity and a hunger to learn go a very long way. I have had many headaches, and many frustrations in my journey using Linux e.g. at some point I had to simply get used to my computer crashing every now and again. Lesson? Make sure I have a very, very recent backup of my data.

Reasons why I contribute
I love the idea of open source software and I want to help. It’s a mutually beneficial transaction: you develop your coding and/or documentation skills, and the project gets one more contributor. Also, I must confess I’m not very good with doing personal projects. I don’t have very fond memories of having to do them while in uni. 

I think projects are a good idea, since you have something to show on your portfolio, but for me the challenge was that there was a huge disconnect between what I wanted to do, the skills I had and the time available. It wasn’t pleasant for me both psychologically and emotionally. So open source software works for me. It has an existing codebase so I don’t have to think about what to create (I do hope not to remain this way forever obviously, but for now it will do 😉), and it builds on the skills I acquired through using Linux (let’s just say I found sorting out my computer problems very...absorbing 😉)

People have varying and diverse reasons for contributing, from wanting to see a particular feature implemented (yes there are such gutsy people out there and we can be them! 😀) or having a particular bug fixed (ditto). Or they like the software but aren’t too impressed by the state of the documentation and so they set out to right that.

Whatever your reason, I encourage you to do your best, ask for help and/or clarification, and always remember that the people you’re interacting with are humans too. It’s very easy sometimes to become entitled regarding open source software and I would encourage you not to be that person who from the first sentence shows that they are looking for a babysitter and has no plans of doing any real work. Try as hard as you can not to be them. I have asked questions about the obvious, said something that in hindsight was really silly to say, and complained about a problem when the fault lay on my end and not that of the software, so I know you can’t be perfect. Just do your best. 

How do you choose your project

Just to be clear, it isn’t weird if you don’t immediately find a project that works for you. You may have been searching a long time. Have faith, you’ll find one 😊. Just keep your eyes open. If the above story inspires you or makes it look a little less daunting than it did before, here are some tips on picking a project:

1. Choose a project you like.  
Honestly, don’t get into a project because it is cool to do so or whatever. 
Because when you’re in the thick of things, what will sustain you is your liking (eventually and/or hopefully, love) for the project, not the project that is ‘cool’. (though that sometimes helps 😉). 

2. Choose a project that looks interesting to you 
By interesting, I meant that you've used it before and found yourself curious about its inner workings or you like the idea behind the project and want to learn more. Sometimes you like a project but its not for you at that particular moment in time. You may be learning Python and the project you’re curious about uses Ruby. 
If you’re interested in learning Ruby too, it’s great for the future but not right now. If you can, find other ways to contribute to it or keep an eye on it for when you’re ready.

Combining both of these is great because it means that you’ll become a long-term contributor to the project and you’ll be able to really benefit both the project and yourself. Having at least one of these is good because one tends to follow the other i.e. if you’re interested, there’s a chance you’ll end up liking the project and if you like the project, you stand a good chance of staying interested. Make sense? No? Well, you get what I mean. 😀 Seriously, if it keeps you up at night thinking (positively, of course), makes you excited to get up in the morning (or at least very willing 😉) or stays in your head throughout the day, chances are it’s the project for you.

How do you find your project? If you're not already using open source software, try searching GitLab and GitHub for interesting projects. GitHub can sort projects by language and if you wish to see the license, there's a file in the project's repository (where the project stores their source code) or looking at the README file will also work. 
Starting your own project is also another option 😉 

Preparing to Contribute 

Now that I’ve left you feeling inspired and excited to go work on your very own open source project (you can start your own by the way), let me hold you for a moment and talk about laying the foundation. This is as follows: 

  1. Know the project’s Code of Conduct.
  2. Know the project’s aims and goals.
  3. Know how to prepare your computer to contribute.
  4. Know how and where to get help with any issues to do with the project. 
Does that look daunting? No worries. The above basically boil down to first reading the project's documentation before interacting with it. 

Knowing the project’s Code of Conduct 

This essentially means treating others the way you would want to be treated, remembering that the people you’re interacting with are human beings just like you, and never saying something online that you’d never even dream of saying in person.

It means being respectful at all times, when you agree with the person, and when you disagree with someone. It means aiming to be your best self: honest and sincere about both your flaws and shortcomings as well as your talents and gifts, being responsible with them and apologizing for when either of these get in the way of your work or the work of others on the project. It means trying very hard to be objective, even when you’d much rather be biased. A project’s code of conduct also provides ways for you to seek help in the event that you are harmed by a fellow contributor’s behaviour, regardless of who they are in the project.

Knowing the project’s aims and goals 

This is important especially when there are different ways to do the same thing. Sometimes a project elects not to go down a very obvious path and instead chooses a different route e.g. opts not to implement a certain feature. If you’re not very well versed regarding the project’s aims and goals, and you like the feature, it can be very frustrating to see something that you think is good not implemented, even when it seems there are willing contributors who can make it happen. Keeping the project’s aims and goals in mind helps you keep things in perspective and helps you remain on the same page as the developers and the leaders in the community who do the hard work of managing the sometimes not-so-fun activities that affect how a project is run.  

Knowing how to prepare your computer to contribute

This is very necessary to do. If you're planning to work on documentation and/or development of the project, you’ll need to do this. This usually involves making sure you have the right system (development can be resource intensive and/or platform specific, depending on the project), the right configuration and/or tools for what you’re planning to contribute to and how you’ll be using them, knowing where to download the project’s source code, how to compile it, and what to expect while doing this. The more time you invest in doing this, the more difficulties you spare yourself later on when you begin work.


Knowing how and where to get help

If you still remember me randomly throwing the words ‘mailing lists’ ‘forums’ and ‘IRC’ and could not for the life of you figure out what I meant, here’s where I explain.

IRC stands for Internet Relay Chat. You’ve used WhatsApp, right? Or Facebook Messenger? Or Google Hangouts? Well IRC operates on a similar principle but is far, far more basic. The idea is that you connect to a server via an IRC client that is on a particular network. Most open source projects can be found on the Freenode network ( or OFTC ( Other projects may have their own server altogether (like Mozilla which is at or that of GNOME which is at Some networks like OFTC and Freenode have web interfaces (e.g. for Freenode and for OFTC
) that you can log into using just a browser. Here’s a good guide on how to get started with IRC. Good IRC clients to begin with are Pidgin and HexChat, which work on Windows, Linux and OS X. 

After connecting, you join a channel that deals with the project you're interested in e.g. on Freenode, you could join #kde and #kde-devel. Remember to register the name (known as a 'nickname' in IRC terms) as there are quite a few channels that won't allow you to participate if your nickname (nick for short) isn't registered. Like I said, you need not use your real name; any name you feel comfortable using will do.  
Forums are simple. You register with your name, e-mail address and password, confirm your registration (steps are usually sent via e-mail) and then proceed to  login to the forums using the details you provided during registration. Look for the areas in the forum relevant to you and what contributions you want to make to the project.
Now on to mailing lists. Ever seen a site asking you to give them your e-mail address so that you receive updates or a newsletter? Mailing lists are like that. Each project that uses a mailing list has a link directing you to where you can subscribe to them. You choose which mailing lists you wish to receive updates from. If you're planning to contribute, you would subscribe to the users' mailing list, then depending on what area you'll be working with, you'll subscribe to other mailing lists about your area of interest e.g. development, documentation, design and so on.

You can choose between a weekly digest, where you receive all the e-mails of the week or have the latest e-mails of the day sent to you daily. This is where commitment to the project comes in: if you're receiving emails that you're beginning to find a nuisance, there's a good chance that the project is not for you or e-mail is not your thing. Good explanations of mailing lists are here and here.
Whatever the means of interaction, introduce yourself and state what you’d like to do. Endeavour to show that you’ve read the documentation and ask for any other helpful information the community can provide. By the way, this is a good time to mention that you do not have to use your real name except in cases where it is required e.g. becoming a Debian Developer. If you’re a community contributor, then your real name is usually not necessary. So pick a name you like and register with it. But pick a good one, one that you wouldn’t be ashamed of should we somehow get to know your real identity 😉. 



I could go on for pages and pages about this, but there are great resources out there, and I'll try to help you out if you ask nicely in the comments 😊. My next post will be about the projects I'm working on at the moment. Cheers!

1 comment:

  1. Am glad, you are adding value to yourself and other people that either benefit from your contributions or the people you interact with in the I.T Tech forums. Am sure British Airways will keep a watchful eye on you. you go girl