I wrote down a hazy line one evening in notepad and then saved it. It says: “open source contribution if you are not a programmer?”. I think I’ve pontificated on this issue in the past as well, but let’s see what thoughts I have on it now.

I’ve done very minor contributions, because I’m not a programmer. More on this later. What I’ve done includes mostly submitting bug-reports, the odd translation effort here and there, and some documentation (mostly the latter). I’ve always like documenting stuff, because I know how much it can suck to use a program that has little to no documentation. I’ve worked in customer service, and in the help desk, so I think I have some kind of idea of what the end user wants to read in regards to documentation. Of course, this isn’t based on decades of working with people, but some years.

This question gets tossed around a lot. “How can I help? I couldn’t program my way out of a paper bag!”. I’ve taken a few programming courses in my life, trust me. From basic, perl and php to c++ and assembly. But I don’t like it. I’m not good at it, which is probably a product of the former statement. If you don’t like something, it’s generally very hard to get a grasp of the subject. The closest thing I’ll do to programming is writing shell scripts, or modifying some existing perl or python script to suit my needs. I can read source and kind of understand what is happening. Kind of like how i know Spanish. I can get the topic of the conversation or the sentence, but god help me if I have to produce anything more than “Una cerveza, por favor”. As a kid, I remember me and a friend worked on a role playing game in BASIC. It worked pretty well and we had implemented buying and selling items, gambling and even combat. But then my friend, who later went on to become a whiz kid of mathematics or whatever, suggested we take up a more advanced language and port the game over to that. At this point my interest dwindled and the thing kind of died out.

But I digress. Back to the question: How can I help? The four main answers that usually get spit out are:

  • Help new users by tutoring them
  • Document something that needs it
  • Translate a program
  • Report bugs whenever you see them

Helping new users should be second nature to all geeks. We all start out somewhere. B used to say, “Senior guys don’t fuck with you, they teach you”. Paraphrased. Your mileage will vary, as most people are not so friendly towards the budding geek. Some are outright hostile, telling people with seemingly stupid or simple questions to piss off. This is a major problem in free software and open source in my opinion. Personally, I love explaining how something works, as soon as I understand it myself. It’s a few minutes out of your life (as long as you remember your “No, I won’t fix your computer” t-shirt), and can set someone off on a lifelong hobby or career.

Documentation. Now this usually splits people down the middle. Sometimes literally. From my experiences, most people hate it. It’s that arduous task that someone has to do after a project is completed, because no one thought of doing it as they went along. Documentation, I am afraid to say, is usually of utter shit quality; hard to read, badly structured and written for someone like the writer (as opposed to a new user). Gurus will rarely look at documentation anyway, except when smoke starts rising, so why not gear it toward the new user instead?

Translation. This I’ve personally found out is pretty fun. If you’re adept at a language, and most of us have at least one primary language that they actually know, why not share it? Some projects make translation easier than others. They give you a file or files and you translate the different bits that are designated, like pieces of the UI, menus etc. Though, not everyone has a knack for language, and the result ends up as a horrible mess. But at least it’s a start. Usually better than google translate, anyway.

Reporting bugs. This is a mixed bag. Some programs make it very easy to report bugs. This is key. If reporting bugs is a fucking hassle, nobody will ever bother, except for the developers, and they rarely see all of the weird issues that the actual users do. If you’ve ever done help desk duties or tech support, you know that sometimes the end users can create such a mess inside a program, I doubt any automated testing or developers poking around would have found. They should be the ones doing testing. But since they are not as savy as you, the developer, you need to meet them in the middle. If a crash happens, and it’s fairly controlled, give the user an option to automagically collect relevant data about the software, the plaform it’s running on etc, and then send it off, along with a brief description of what you were doing. Some are really good at this, like Firefox. Some are notoriously bad.

Also, a bane in any bug reporting system is usually duplicates. New users have no idea that there could possibly be someone else with the same issue, and the end result is 50 reports on the same issue. And then you have devs and community managers running round telling people to “search first and then report”. If this isn’t easy, nobody will bother. Granted, usually someone will either point the user in the right direction, or even merge the issues. Sometimes, all they get are some hasty quips and a closed bug report. Improving these systems, in my opinion, should be a priority. Make the system look up key words from already posted bugs, and then try to match those up with what the user is writing. If we find similarities, suggest courses of action, or give clear, simple instructions on how to proceed with uncertainties.

Users also neglect to report key issues, and instead the reports are usually “I was typing and all of a sudden everything went black, please fix it!!!!11”. The solution might be user education, but also, automated data gathering, and clearer instructions on what to include and in what kind of format.

Of course, none of these issues will fix people that simply neglect every bit of documentation, information and guidelines. But it’s a start.

In closing, not everyone is a programmer. I remember back in college, a lot of courses centered on programming. And I felt desperate. Is this all IT is? Programming in different languages? The school seemed to think so. Some pushed through. Most didn’t. I think out of some 40 odd students in my class, less than 10 graduated.

And eventually, I found what i was looking for: A job in IT that isn’t programming. And here I am, installing server clusters for programmers to use as platforms. Who’da thunk it? It isn’t all just programming!


Leave a Reply

Your email address will not be published. Required fields are marked *