We live in a golden age of open source, and it can sometimes be easy to forget the privileges that this affords us. I’m writing this article with vim, in a terminal emulator called urxvt, listening to music with mpv, in a Sway desktop session, on the Linux kernel. Supporting this are libraries like glibc or musl, harfbuzz, and mesa. I also have the support of the AMDGPU video driver, libinput and udev, alsa and pulseaudio.
All of this is open source. I can be reading the code for any of these tools within 30 seconds, and for many of these tools I already have their code checked out somewhere on my filesystem. It gets even better, though: these projects don’t just make their code available - they accept patches, too! Why wouldn’t we take advantage of this tremendous opportunity?
I often meet people who are willing to contribute to one project, but not another. Some people will shut down when they’re faced with a problem that requires them to dig into territory that they’re unfamiliar with. In Sway, for example, it’s often places like libinput or mesa. These tools might seem foreign and scary - but to these people, at some point, so did Sway. In reality these codebases are quite accessible.
Getting around in an unfamiliar repository can be a little intimidating, but do
it enough times and it’ll become second nature. The same tools like gdb work
just as well on them. If you have a stacktrace for a segfault originating in
libinput, compile libinput with symbols and gdb will show you the file name and
line number of the problem. Go there and read the code! Learn how to use tools
git grep to find stuff. Run
git blame to see who wrote a confusing line
of code, and send them an email! When you find the problem, don’t be afraid to
send a patch over instead of working around it in your own code. This is
something every programmer should be comfortable doing often.
Even when the leads you’re chasing down are written in unfamiliar programming languages or utilize even more unfamiliar libraries, don’t despair. All programming languages have a lot in common and huge numbers of resources are available online. Learning just enough to understand (and fix!) a particular problem is very possible, and something I find myself doing it all the time. You don’t have to be an expert in a particular programming language to invoke trial & error.
If you’re similarly worried about the time investment, don’t be. You already set aside time to work your problem, and this is just part of that process. Yes, you’ll probably be spending your time differently from your expectations - more reading code than writing code. But how is that any less productive? The biggest time sink in this process is all the time you spend worrying about how much time it’s going to take, or telling me in IRC you can’t solve your problem because you’re not good enough to understand mesa or the kernel or whatever.
An important pastime of the effective programmer is reading and understanding the tools you use. You should at least have a basic idea of how everything on your system works, and in the places your knowledge is lacking you should make it your business to study up. The more you do this, the less scary foreign code will become, and the more productive you will be. No longer will you be stuck in your tracks because your problem leads you away from the beaten path!
Are you a free software maintainer who is struggling with stress, demanding users, overwork, or any other social problems in the course of your work? Please email me — I know how you feel, and I can lend a sympathetic ear and share some veteran advice.
Articles from blogs I follow around the net
This post gives an overview of the recent updates to the Writing an OS in Rust blog and the corresponding libraries and tools. I focused my time this month on finishing the long-planned post about Async/Await. In addition to that, there were a few updates …via Writing an OS in Rust April 1, 2020
Clipboard and drag & drop are arguably one of the most complicated parts of the core Wayland protocol. They involve a lot of back-and-forth communication between three processes: the application where some content has been copied, the compositor, and …via emersion March 26, 2020
Go always comes second to more basic concerns like personal and family health and safety. Around the world, the past couple months have been terrible, and we are still at the start of this awful pandemic. There are days when it seems like wo…via The Go Programming Language Blog March 25, 2020
Generated by openring