Stop using MySQL in 2026, it is not true open source
If you care about supporting open source software, and still use MySQL in 2026, you should switch to MariaDB like so many others have already done.

If you care about supporting open source software, and still use MySQL in 2026, you should switch to MariaDB like so many others have already done.

I am a huge fan of Git, as I have witnessed how it has made software development so much more productive compared to the pre-2010s era. I wish all Debian source code were in Git to reap the full benefits.

The discovery of a backdoor in XZ Utils in the spring of 2024 shocked the open source community, raising critical questions about software supply chain security. This post explores whether better Debian packaging practices could have detected this threat, offering a guide to auditing packages and suggesting future improvements.

Historically the primary way to contribute to Debian has been to email the Debian bug tracker with a code patch. Now that 92% of all Debian source packages are hosted at salsa.debian.org — the GitLab instance of Debian — more and more developers are using Merge Requests, but not necessarily in the optimal way. In this post, I share what I’ve found the best practice to be, presented in the natural workflow from forking to merging.

Debian packaging is notoriously hard. Far too many new contributors give up while trying, and many long-time contributors leave due to burnout from having to do too many thankless maintenance tasks. Some just skip testing their changes properly because it feels like too much toil. Debcraft is my attempt to solve this by automating all the boring stuff, making it easier to learn the correct practices, and helping new and old packagers better track changes in both source code and build artifacts.

This post is based on a presentation given at the Validos annual members’ meeting on June 25th, 2025.

In this post, I demonstrate the optimal workflow for creating new Debian packages in 2025, preserving the upstream Git history. The motivation for this is to lower the barrier for sharing improvements to and from upstream, and to improve software provenance and supply-chain security by making it easy to inspect every change at any level using standard Git tooling. Key elements of this workflow include: Using a Git fork/clone of the upstream repository as the starting point for creating Debian packaging repositories. Consistent use of the same git-buildpackage commands, with all package-specific options in gbp.conf. DEP-14 tag and branch names for an optimal Git packaging repository structure. Pristine-tar and upstream signatures for supply-chain security. Use of Files-Excluded in the debian/copyright file to filter out unwanted files in Debian. Patch queues to easily rebase and cherry-pick changes across Debian and upstream branches. Efficient use of Salsa, Debian’s GitLab instance, for both automated feedback from CI systems and human feedback from peer reviews. To make the instructions so concrete that anyone can repeat all the steps themselves on a real package, I demonstrate the steps by packaging the command-line tool Entr. It is written in C, has very few dependencies, and its final Debian source package structure is simple, yet exemplifies all the important parts that go into a complete Debian package:

After careful consideration, I’ve decided to embark on a new chapter in my professional journey. I’ve left my position at AWS to dedicate at least the next six months to developing open source software and strengthening digital ecosystems. My focus will be on contributing to Linux distributions (primarily Debian) and other critical infrastructure components that our modern society depends on, but which may not receive adequate attention or resources.

Are you a student aspiring to participate in the Google Summer of Code 2025? Would you like to improve the continuous integration pipeline used at salsa.debian.org, the Debian GitLab instance, to help improve the quality of tens of thousands of software packages in Debian?

Becoming a Debian maintainer is a journey that combines technical expertise, community collaboration, and continuous learning. In this post, I’ll share 10 key habits that will both help you navigate the complexities of Debian packaging without getting lost and enable you to contribute more effectively to one of the world’s largest open source projects.

In software engineering, most ideas can be implemented without writing any design document at all. This is particularly prominent in open source communities. For example, the Linux kernel has 35 million lines of code that have been written and rewritten many times over alongside 30 years of mailing list discussions. Linux wasn’t created as a result of a grandiose design document by Linus Torvalds, but it evolved organically in small increments of actual running code.

The XZ Utils backdoor, discovered last week, and the Heartbleed security vulnerability ten years ago, share the same ultimate root cause. Both of them, and in fact all critical infrastructure open source projects, should be fixed with the same solution: ensure baseline funding for proper open source maintenance.
