I recently watched FFmpeg: The Incredible Technology Behind Video on the Internet | Lex Fridman Podcast, and it has only strengthened my love and fascination for the field of software. There is so much amazing technology being described by the two interviewees (Jean-Baptiste Kempf, Kieran Kunhya), yet this is something that almost all of us take for granted. Even after watching the entire podcast, I realise that I still have not yet grasped the true intensity of work that went on behind the scenes to give us the amazing software of FFmpeg and VLC media player that we have today. Yet, I’m already in awe just hearing heavily abstracted versions of history.

What really first gave me this feeling was when Kieran said (heavily paraphrased, emphasis mine) “every part of the video compression and decompression process is someone’s lifetime’s work. There are books about every part, with thousands of people working on each, so the complexity is inordinate.” I found this crazy to take in. These folks are taking advanced research and converting it into the most performant code in the world, all so that people can endlessly doomscroll TikTok videos on their phones. (I jest, as there are many other much healthier and more useful applications of video.)

Then there is the regularly reposted meme on Reddit that JB (short for Jean-Baptiste) repeatedly refused millions of dollars to keep VLC media player ads-free at a time when many other software were injecting spyware and adware into their applications. Why? It’s not because he doesn’t like money; it’s simply because he wants to earn money ethically and to do what he thinks is right so that he can go to bed at night being happy about what he did.

It made me question my own motivations for working on software. I initially jumped into this field three years ago because I found it fun to create software with the code I write. Now, I’m most fascinated by how all the underlying abstractions work — from compilers to garbage collectors, from operating systems to the hardware-software interface. However, is learning for my own enjoyment all there is to it? Is there a bigger purpose that I can contribute to?

The immediate answer seems to be to contribute to an open source project. What I’m learning about the beauty of open source is that people together are able to push software far beyond what any single person or entity is able to do. Yes, burnout is an actively discussed issue, but it doesn’t take away from the fact that many of the best software is created in open source. Examples I can think of include Linux, FFmpeg (of course), and Git. There are definitely many many others. Ultimately, it comes down to the many humans working together to create technical excellence for the progress of humanity.

I realise I want to contribute to a greater good as well. In the words of JB, I want to go to bed at night being happy about what I did. If I can improve even a small part of an open source project, such as documentation, that goes a long way towards improving the overall quality of the project. As I recall, Alice Ryhl (core maintainer of Tokio) said that she first started contributing to the Tokio project by improving the docs too.

The question is then what project do I want to commit time and effort to?

For FFmpeg, many contributors came to the project because they loved watching anime but couldn’t obtain commercial sources, so they first had to rip the video from discs, then add subtitles. But many of the existing video codecs back then didn’t support anime well, so they contributed to improving the codecs so that they could watch their anime with better quality. The lesson here is that finding a project that lines up with what you love can go a long way towards sustainable long-term contribution.

Right now, there is one area of software that I’m drawn to for reasons that are not very clear to me as of yet: compilers. I simply find them very fascinating. At a high-level, compilers convert one form of binary to another, typically a programming language to machine code. I find the simple conversion process already very intriguing and fascinating, yet there is so much more to it! Type-checking and optimisation are just two other things that can be done during the compilation process that I’m aware of, but there is so much more. It feels like a rabbit hole that once entered, expands into an entire cave system with multiple huge caverns, each possibly entailing a lifetime’s work to fully explore and deeply understand. There is much that I do not know yet, but that could be a strength as well when contributing, in particular to documentation. I do not know where this journey will bring me, but it feels nice knowing that my efforts to improve a significant software project might help someone else too.

Open source is a community of people coming together to work on a project as a labour of love. There is no technical excellence without people; there is no amazing software without people. Someone somewhere contributed that piece of software, and someone somewhere today is maintaining that piece of software. This explains why open source maintainers can be more skeptical, harsher, or unkind to new contributors. A working patch with crap code is code that has to be maintained by maintainers, so if it doesn’t meet their standards, they have every right to reject contributions. Most new contributors are drive-by, meaning they don’t stick around, so whatever goes into the codebase ends up being maintained by the existing community. That’s why they must be strict about code quality.1

“If we have to compromise our software, we will shut it down. That is clear.” - Jean-Baptiste Kempf

Another point I took away from the podcast was that it’s important to be aware of the scale of usage of a piece of software. At FFmpeg’s scale, where it’s being used literally everywhere there is video, technical excellence is paramount. Every instruction saved during the decoding process of a video makes a difference to global energy consumption levels. At a personal level, it affects the battery life of our devices. Some napkin math: If we one instruction per second of video, for a one hour long video, that is 3600 instructions. Say a billion other people in the world also watch only a single one hour video each day. That would already amount to 3.6 trillion instructions. That is already a couple of minutes of processing time on a modern computer that could be saved. Imagine waiting an extra couple of minutes for your program to load. And we’re using small numbers here. Modern computers process billions of instructions per second, so one instruction saved per second is extremely little (less than 0.000000001%). A billion people viewing videos a day is little, as is watching only an hour of videos a day. Every CPU instruction saved literally saves energy for the world!

At the end of the day, software is but a tool to solve problems. However, creating software is very much a craft and a hobby too. Much of the great software that we have in the world today started not because some big corporation decided they needed that piece of software, but because an individual thought the problem was interesting enough for them to pursue for fun.

“Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.” - Linus Torvalds


  1. I don’t think this applies for every project, especially with the prevalence of LLM-generated code. For me, I will be looking at the AI policies of projects, and only work on those that places humans first as I believe that open source is a community-driven and highly collaborative endeavour. ↩︎