What do you do with bugs?

Software bugs are an everyday fact of life, and the sad truth is we’re never going to be free of them. What causes them, and what we can do when we encounter them is what we’ll explore here.

Anyone who develops software starts on their own computer. They have a specific make and model of machine, with all the hardware that manufacturer decided to incorporate in building it. The programmer is using whatever disto they prefer, with that distro’s choices of lower level software (kernel, modules, libraries), and that distro’s spin on their desktop environment of choice. The programmer is also using the support libraries for whatever environment they’re programming for (GTK+, KDE, etc.). When they’re at a certain point where everything they’re trying to accomplish with their application works, it’s usually pushed out for some process of review, where they hope to catch any glaring bugs and fix them before release.

Think about all the variables involved in that process. Start with the programmer’s computer. How many different makes and models of computers are there? All computer manufacturers have one thing in common, they’re trying to make money while at the same time keeping costs low. They mix and match pieces, change hardware configurations, use differing makes and models of peripherals, not to mention core components like the motherboard, chips, bus types, etc. The sheer number of possible hardware variations is staggering.

Next think about the programmer’s distro of choice to work in. Every distro does something different with their core components to try and stand out, be what they feel is better than the others. They can and do change how they compile their kernels, modules, libraries, as well as how they interact with each other. Source code versions can be different, compile time flags are changed, init systems, what’s started, how and when, can all be modified. Another mind-numbing amount of variations is possible.

Then there’s the toolkit the programmer is using. Most will work with whatever is current and supported by the environment they’re targeting, and make any support libraries their application needs “requirements” for packaging. Unfortunately, it’s the distro we choose to use that has to compile and package those requirements, and they might do something different from what the programmer desired or used themselves.

The plain fact is, there are so many variables involved in computers and computer software, a programmer or team of developers can’t possibly foresee or account for them all. The very best developers can’t program for, nor anticipate, all the possible environmental and hardware variations their software is going to encounter in the wild. Many larger projects have Q&A teams or similar, where they try to “torture test” software to find and fix bugs before it’s released. While it certainly helps a lot – much is caught and fixed in the testing – it’s still impossible to account for every variation. We as users are going to find bugs sooner or later.

So before you go on a tirade in social media or other public venue about “buggy crap” software (you can insert your own vile and demeaning adjectives here), think about what the developers are up against. Think about what you are doing. In the FOSS ecosystem you’re railing against people who gave their time to create something good and useful, then gave it freely to the world. Often at some personal and/or economic costs to themselves. In essence, you’re dragging over the coals someone who is trying to help you!

Consider this: Apple controls both hardware and software creation on their platform. They build the hardware, so they know exactly what is in it. They create the software to work with that hardware. They control the toolkits, libraries, kernel, modules, init, everything. They have an extensive and thorough Q&A that all software has to pass. And they STILL have bugs!

As I said when I started, bugs are a computing fact of life. There will always be bugs, the sheer number of variables in modern computing makes that inevitable. However, we in the FOSS world have an advantage. We can do something about the bugs we encounter. We can be proactive, and we don’t need to be a programmer to do it. Almost all software projects have bug trackers, systems where users can report bugs and help find a solution for them. Those that don’t will at least have an email address or IRC channel, some form of contacting the developers. All that’s required is a little patience and a willingness to spend some time helping find a solution. Time and patience, these two things are vital to squashing bugs. If we take a few minutes to just browse through a bug tracking system, we’d see hundreds (if not more) cases of someone reporting a bug with little to no information useful to the developers, and never following up. Or worse, ranting about a bug without even trying to be helpful in squashing it.

The only way a developer can kill a bug is if they understand exactly what’s causing it. The only route to understanding is if the user supplies all the information necessary, and follows up with whatever further tests or information the developer needs. It requires time and patience. It also helps to have a positive attitude and be polite. In the course of trying to kill the bug, the developer may ask you to do or try something you don’t understand. If and when that happens, tell them you don’t understand and ask for guidance. Remember, you’re both asking for help with a problem. They need your help to fix the problem, so don’t be shy in asking for their help in return. Most importantly, stick with it. There IS a solution, it just might take some time to find it. Chances are it’s working properly on their system, so they need to diagnose what is different between your system and theirs, and then figure out what to do about it.

Not all users can be bug chasers. Many of us just don’t have the time or patience for it. That’s okay, because we can still be helpful. How? By NOT trashing the software or developers because we have a bug. Put yourself in the developer’s shoes. You’re trying to create something useful and giving it freely to the world, and someone is publicly flaying you for it? How would you feel? Don’t be a troll. If you don’t have the time or patience to help with a bug, that’s fine. But don’t be a troll instead.

For those of us who do have the time and patience, chip in! It’s the beauty of FOSS, even those of us who aren’t programmers can still be actively involved in software development. Report the bug. If it’s already been reported, add your information. Most bug trackers have a guide for how to submit information, follow it and include yours, don’t just add a “Yeah, I have that bug too.” The more information the developers have on how a bug is affecting users, the more likely they are to find a solution. Then take the time to follow up on it to its resolution. By staying actively involved until it’s fixed, you’ll be able to honestly say “Yep, I helped in the development of that.” You’ll have changed from a being a “user” to being a “contributor”. Then the real reward happens, you get to soak up the feel-good that comes along with the knowledge you’ve helped on something the whole world can use.

Rob Boudreau

Rob started with Linux in 1996, and has been using it exclusively since '97. A strong advocate of free and open source software (FOSS), he's never been a programmer, his views are always from the perspective of a user. He actively supports FOSS financially, by contributing documentation, and by helping other users where and when he can.