I am David Tadokoro, a Computer Science PhD student at the University of São Paulo who is passionate about Free Software and GNU/Linux. For the last 3 years, I have continuously contributed to and maintained Free Software projects. I am the maintainer of two projects called kworkflow (https://kworkflow.org) and patch-hub (https://github.com/kworkflow/patch-hub), which are closely tied to the Linux project as, collectively, they aim to streamline the tasks that kernel developers (contributors and maintainers alike) have to do in their daily lives.

My doctorate research revolves around understanding the workflows that govern the Linux kernel development model, what processes and practices create bottlenecks that risk the project's long-term sustainability, and how we can use this knowledge to make informed decisions when developing tools that support the GNU/Linux ecosystem.

Personally, I align entirely with the Debian philosophy - especially the "standing on the shoulders of giants" aspect - and genuinely believe that Free Software is the way to go for a better society. When I am not collaborating with other developers, advancing my research, or tinkering with my setups, I like to spend time with my loyal companion, my dog Alfredo.

Accepted Talks:

Mitigating kernel development bottlenecks and supporting the GNU/Linux ecosystem with kworkflow

The Linux kernel project sits at the base of a gigantic and complex Free Software ecosystem. As a two-way road, downstream projects - the most prominent, Debian - feed off the kernel development while returning contributions to the upstream and giving it importance. Be it downstream or upstream development, if you work with the Linux kernel source code, chances are that you probably had to do one (if not all) of the following: set up a testing environment for custom kernels; fetching, optimizing, and managing several .config files; building a kernel from source; deploying a custom kernel to a testing environment. Before doing these tasks, some questions must be answered: Do I use physical machines or VMs as testing environments? What will the distro(s) of the target machine(s) be? Where do I get a base .config for a specific distro and architecture? What optimizations to do for building? How do I deploy the custom kernel to a particular testing environment?

For each combination of answers to these questions, surely, there will be a different sequence of commands, processes, paths to consider, and so on. After a few runs, you will probably be tired of manually doing all this work and will create scripts to automate your workflow. The problem is, if your workflow mutates a little or has slight variations, or your scripts have bugs, you will need to waste your precious development time maintaining these scripts that were not your objective in the first place! This is where kworkflow (kw), a Developer Automation Workflow System (DAWS), enters the scene. With a unified interface to many commands, kw abstracts many of these details, streamlines and automates time-consuming workflows, and enforces good practices so kernel developers can focus on the code they are writing, not on whether the make command was typed correctly.

  • Want to up a VM? Run kw vm --up;
  • Want to fetch a .config from within a machine in the network? Run kw kernel-config-manager --fetch;
  • How about compiling with optimizations and cross-compilation? Do some simple configuration with kw config, then just fire kw build;
  • I doubt installing custom kernels and modules is as simple as running one command, right? Wrong, you just need kw deploy.

In reality, kw does much more than this. For example, there is a Terminal User Interface (TUI) feature to consult and manipulate patches sent to the mailing lists, resulting from a PhD applied research. This talk will introduce the key features of kw and show how it can be used to improve your kernel development workflows.

Even though kernel development has worked well for more than 30 years, we understand bottlenecks in developers’ workflows are risking the long-term sustainability of the whole ecosystem, and projects like kw are vital to avoid this scenario beyond just automating tasks. At the end of the talk, we will want to collect feedback from the best community in the GNU/Linux distro world, the Debian community, about what kw is doing right and wrong and how the community experience and knowledge can help us have a more comprehensive view of the GNU/Linux ecosystem.

Training Students in Free Software Development through GNU/Linux ecosystem contributions

This talk will showcase how the Free Software Development course at the University of São Paulo (IME-USP) trains students to become active contributors to the GNU/Linux ecosystem with a focus on the Linux kernel and Debian. We want to share how to bridge academia and real-world collaboration with educators, community maintainers, and free software advocates. Attendees will understand how our students progress from philosophical foundations (licenses, community norms) to hands-on contributions, such as submitting kernel patches, engaging with the Debian packaging system, and navigating distributed workflows.

The audience will leave with actionable strategies to replicate this model, including (1) Scaffolded workshops (e.g., kernel workflow tutorials, Debian packaging labs); (2) How to partner with community members; (3) Feedback of success beyond code (e.g., students publishing diaries of their journey).

In short, our students (part of them from scratch) submitted a kernel Linux patch in two months, and all students left with a solid foundation in Git and understood the Debian packaging mechanism.

Whether you are a teacher seeking curriculum ideas, a maintainer looking to grow your contributor base, or a newcomer curious about academic pathways into Free Software, this talk offers a blueprint for sustainable engagement.

Guidelines for Boosting Long-Lasting FLOSS Contributors

Free Libre and Open Source Software (FLOSS) development is a validated approach to producing cutting-edge software solutions used by governments, companies, and society at large. At the core of all FLOSS software projects are communities composed primarily of developers who evolve and maintain the software while devising rules for the development process. A common problem is the renewal and/or scaling of the workforce, which is not about encouraging waves of new and sporadic contributors but about fostering long-lasting ones that can have a more profound impact on the project. This work presents guidelines for mentoring students to build skills and gain experience essential to becoming valuable assets in most FLOSS ecosystems. Beyond a reasonable software development background, previous experience in FLOSS development is not a requirement. These guidelines are a product of a 15-weeks university course where students had to (1) learn the fundamentals of Linux kernel development and send patches to a subsystem, (2) contribute to supporting tools to the GNU/Linux ecosystem, (3) introduce software packaging in the context of Debian, and finally (4) contribute to a chosen FLOSS project. The method reproduces the natural way a “self-taught” contributor would enter a FLOSS ecosystem (heavily inspired by how Debian does it), though in a more focused and immersive environment. Through in-loco workshops, accessible and knowledgeable mentors, and close and constant monitoring, we simulated a smaller FLOSS community where students (inexperienced contributors) learned from mentors (maintainers); we argue that this simulated community can be more efficient than a real one as feedback is faster and more adapted to each contributor, and concepts can be abstracted and simplified for easier absorption. Our results show that the method fostered (1) developers who are more confident in contributing to any FLOSS project and beyond to the “one-commit contributor” and (2) the enhancement of fundamental hard skills (like Git and Web/email-based contribution models) and soft skills (like communication and feedback assimilation) for any FLOSS project. Even though deep technical knowledge becomes mandatory for every contributor in a specific project, we claim that implementing the proposed guidelines can quickly nurture tens of developers with a solid base for becoming long-lasting contributors to FLOSS.

ArKanjo: a tool for detecting function-level Code Duplication in the Linux Kernel

The Linux kernel’s massive scale (+28 M LoC, +20 K contributors) presents unique maintenance challenges. Surprisingly, Code duplication remains a persistent issue in the kernel’s codebase, which could hinder its evolution and patching. Academic approaches often focus on pairwise comparison of code artifacts, not directly applied for comprehensive codebase analyses. Other existing free software tools explored in practice frequently suffer from limited functionality, such as primitive textual matching, prove too narrow in scope, or fail to deliver effective results on complex, large-scale codebases. Existing solutions generally fail to address the Linux kernel’s specific needs: (1) scalability to handle its size, (2) actionable results for developers, and (3) integration with kernel development workflows. This paper presents ArKanjo, a novel command-line tool for Linux kernel maintenance designed to detect and analyze function-level duplications. Released under the MIT license, ArKanjo employs a two-stage architecture consisting of a Preprocessor and a Query Responder that separates computationally intensive analysis from efficient querying for duplications within large codebases. Pivotal advantages of ArKanjo over existing solutions include: (1) optimization for C codebases with kernel-specific patterns; (2) preprocessing that enables rapid queries without redundant analysis; and (3) prioritization of duplicates that impact maintainability, such as copied buggy logic. We evaluate Arkanjo against real-world duplication cases in recent kernel versions, demonstrating its effectiveness in identifying problematic clones that generic tools often overlook. By identifying well-defined, manageable duplication instances, ArKanjo effectively lowers the barrier for new contributors, a capability evidenced by its role in guiding students to make their first code improvements to the kernel. ArKanjo offers immediate value to kernel maintainers and serves as a replicable model for clone detection in other large-scale free software projects.