Lessons learned as the Debian Project Leader

What is it like to be a Debian Project Leader (DPL), or a former one? According to Andreas Tille, who stepped down this year after two consecutive terms as DPL, you'd have to be one to know. At the recent MiniDebConf in Winterthur, Switzerland, Tille spoke about what he learned while serving as DPL, some of the initiatives he led, mistakes that he made, and his thoughts on the general resolution (GR) on large language model (LLM) usage in Debian.

I did not have the opportunity to attend the MiniDebConf in person, but I watched the video of the session shortly afterward. The slides are also available, as are the slides and videos for many of Tille's talks back to 2001.

A short changelog

Tille said he was often asked what it feels like to be a former DPL. The only way to find out is to do it—and he hoped that a future DPL was sitting in the audience. "I can recommend it. It was less demanding than expected. So just try it, and then you will know." His wife had told him that he had also developed as a person while being DPL, "and I take this as a compliment".

He wanted to start with "a short changelog" of some of the projects he had worked on during his tenure. One of the things he wanted to do as DPL was to attract newcomers to become Debian contributors. He began a Bug of the Day program to train new people to triage and fix bugs, with a web page that lists one or more bugs that might be good candidates for inexperienced people looking to become contributors.

It was an interesting project, Tille said, that helped him learn a lot about Debian, such as the need to address social and cultural issues as well as technical ones. "I felt like a janitor taking a torchlight in the cellar and looking for things that needed clean up [...] and I learned way more than expected myself. And what I learned is that doing something and talking to people is essential for the process". The need for the DPL to spend a lot of time talking to people was a recurring theme in the talk.

Archive and DFSG teams

Tille said that he had spent "a lot of time in video conferences" talking to contributors about the ftpmaster team, which was responsible for two distinct tasks. The team was responsible for both the technical work of caring for the servers and software used in the process of bringing packages into Debian's archive, as well as the non-technical work of ensuring that packages entering Debian's new queue met packaging requirements, including the Debian Free Software Guidelines (DFSG).

"We called it the new queue, but actually it was a new heap", he said. Debian developers had complained for many years about long wait times for packages in the new queue to be reviewed and approved. Tille said that there was "a hint that was born inside the team to just split the distinct tasks", which is what happened.

"Splitting up a core team right before a stable release is not a good idea", Tille said. He waited until a few months after Debian 13 ("trixie") was released to split the ftpmaster team into two new teams. He created the Archive Operations Team for the technical job of managing the infrastructure, and the DFSG, Licensing, & New Packages Team (DFSG team) to do the non-technical job of reviewing packages entering the new queue. He said that the separation of teams has led to faster processing of the new queue and a more transparent system. LWN covered Andrew McMillan's report on the DFSG team's progress in July.

How to step back

Something unusual happened during Tille's term that he wanted to highlight: all three members of Debian's Data Protection Team said that they no longer wished to do the work and quit, which led to an urgent call for new members. The interesting thing about this was that they actually said that they no longer wanted to do the job. "I think the very good thing, and not so typical thing, was that the data protection team told the world that they will not do their job anymore."

Debian is a volunteer organization, and people step up to do a task but then their circumstances change. People have valid reasons for stepping back, but then fail to tell their teammates that they are no longer available. By announcing they wanted to quit, the team enabled a smooth handover to a new team that is now doing the work.

That led Tille to thinking about how delegations are handled within Debian. Typically, a delegation to a team has no time limit attached—it is valid until the DPL revokes it or a person announces that they are stepping down. But, he said, people are reluctant to tell their friends that they are unable to do a task any longer. Stepping down from a position, "is an active process from a person who is burnt out" or otherwise in need of a break.

Tille thought that it might be better to ask delegates if they are still interested in remaining on a team. It would be easier for them to say "no" when asked, rather than proactively stepping down. He raised the idea of time-limited delegations in February 2026 in one of his regular "Bits from the DPL" emails.

In some internal discussion people have raised the question of how Debian should deal with delegates becoming inactive, and how to do so in a way that is both effective and non-confrontational. I have read multiple thoughtful suggestions that converge on a common theme: we should normalize renewal and rotation, rather than treating changes as exceptional or adversarial events.

Tille said that he did not receive any responses about the idea, so he thought there was consensus that it was a good one. Tille asked incoming DPL Sruthi Chandran if it was acceptable to make all delegations in Debian time-limited, to end in October this year unless she renewed them, and she said that was fine. But when the change was announced, it was more controversial than he expected.

Some of the delegates, "stood up and said, 'You should have asked us'", even though Tille had publicly announced the idea. They were offended by the change in delegation procedure because "they felt some kind of distrust". Tille said that the process would have gone better if there was more communication with the delegates. "This is a problem in Debian in general, that we don't find so much time to talk to each other [...] I learned that governance is hard, but we have to do it somehow, and silence is hard to parse". Tille said that there was some clean-up to do after the announcement, but thought that things were fine in the end. "I made failures in my DPL term, yes", he said, but hoped that he admitted to them all openly.

Collaborative maintenance

When Tille began his term as DPL, there were more than 4,000 packages that were not hosted on Debian's GitLab-based collaborative-development platform, Salsa; one of his goals was to reduce that to number to 2,000 or fewer packages. He said that, at the time of his talk, there were only about 1,700 packages not on Salsa "which means no version-control system, or GitHub, or whatever". (The Debian Trends web site tracks the VCS hosting field for packages in the archive.) Even though Debian is a volunteer organization, he believes that it is good to have a shared collaboration platform. "I think this kind of professionalism is what makes volunteer projects scale".

Debian also has strict maintainer ownership of packages. "So if your name is in the maintainer field of the package, it's your package." Historically that was sensible, he said, "because we had experts for, say, 500 or 1,000 packages, and these were really the experts who know what this package is doing". Now Debian has more than 41,000 packages, "and the maintainer field is not always filled with a person who is really competent". He felt he could say that because he knows that he is maintaining packages where he is not an expert, and needs help from other colleagues to ensure he's on the right track. He works on Debian Med packages related to medicine and bioinformatics, while he is a physicist by profession.

But, Tille said, "my name is not on any maintainer field of any Debian packages". Instead, the packages he works on are always maintained by a team of packagers rather than a single packager. He is an uploader for packages, which means that he can make and push changes to the archive, but others can as well. He believes that is the best way to go for the future of packages in Debian.

"This historical strict maintainership is an increasing source of friction in Debian, because its hard to know whether a package is orphaned or just needs no work". Some packages may not be touched for years, but there is no indication why that may be. Silence, he noted again, is hard to interpret, "and also hard to accept for me, because there are maintainers who simply don't answer". The maintainer may be uploading from time to time, but "if you send them an email, they are not answering". He stressed that silence was not the rule, but an exception. "But it's a consequence of the fact that we have this strict maintainership that we can't touch these packages."

Tille had a goal of loosening the strict ownership of packages during his terms as DPL, but he failed to do so. "Debian is a great community, but we are a community of individuals. We have a lot of good teams, but we also have individuals who do not interact." That is fine, he said, but he thought that the project would benefit from stronger collaboration.

He mentioned some of the attempts to improve collaboration on packages and loosen ownership over the years, such as the introduction of non-maintainer uploads (NMUs), the Missing In Action team that checks to ensure maintainers are still active, and the package-salvaging process (more frequently referred to as "intent to salvage" or ITS) for packages that have not been officially orphaned but may be poorly maintained or completely unmaintained.

In late 2024, Tille suggested flipping the default assumption of package ownership to an open maintainership model by introducing a Debian control file file for packages, perhaps called "debian/dont_touch_my_package". A maintainer could indicate that they wanted to discourage others from making changes to a package by documenting their reasons. "This file could include a timestamp, and we could establish an agreed-upon timeframe for refreshing the statement to ensure its continued validity." If the file is not present, then it would be assumed that the package was open for maintenance by other Debian contributors.

That idea has not caught on, at least not yet, but Tille said that he would try to pick it up later. "You don't need to be the DPL to change anything in Debian. It's absolutely not necessary."

Responsible use of LLMs

LLMs and other generative-AI tools were just starting to make their presence felt in open-source communities when Tille began his first term as DPL in 2024. By the time he finished his second term, they had become an important and divisive topic within Debian. Not surprisingly, Tille had some thoughts about Debian's LLM usage GR, its vote to allow "responsible use of generative AI", and his own relationship with LLM tools.

Tille is German, and English is not his first language; thus, he is forced to communicate in a foreign language as part of participating in Debian. "And it's not only the language; you have also a foreign culture because Germans are quite straight. You usually tell what you think, and it's not very well perceived in other cultures." That led him to explore the use of LLMs to try to communicate more effectively as DPL.

He said, in what may have been the least-surprising disclosure in his talk, "you don't always get friendly emails as a response" when serving as DPL. That could lead to an angry response in return, but Tille opted to use LLMs as a buffer to prevent him from "responding quite emotionally", and instead try to discover the underlying problem and if the person had a point. He added that, separate from LLM usage, his advice was to avoid answering on the same day. "Draft your answer, sleep on it, send it the next day, or even better: delete it the next day." LLMs, Tille said, can help to focus on a topic, find new interpretations of an ambiguous response, and so forth.

So for me, LLMs are a legitimate tool; a tool for just clarity, not a ghostwriter. I never say to an LLM, "Please draft an email for me". No. It's kind of a depersonalization, but if you are in a responsibility situation like the DPL is, it makes sense to think wider than, or think beyond your own personality.

I own the intent of what I'm writing, and the LLM helps me with the right expression. So what I always can recommend: LLMs can be kind of an editor. Use this [as an] editor, but not as the author of your words.

He stressed that he drafted his own responses, reviewed all changes, and thought that he owned the final results. "There are people who might disagree, but this is my view on how to use [LLMs] responsibly."

Tille said that his view on the GR was that he perfectly understood the people who wanted to restrict LLM usage. "I know all of the drawbacks of LLMs. I think I'm aware of them". He thought it would have been better for those who wanted to restrict LLM usage to discuss possible restrictions, for those who wanted to enable LLM usage to propose their ideas and to find common sense ways to propose restrictions properly. Instead, there was a "heap" of proposals that "nearly made our software for voting [explode] because we have so many, admittedly interesting, proposals".

In the end, the "Responsible Use of Generative AI" option won, which he interpreted as Debian's voters saying "'we want to stand [by] the existing standards for quality, correctness, and maintainability', which is the core of Debian, in my opinion". He believed that it is not well-perceived within Debian if "someone is telling you, 'you are not permitted to do that'". That is why the non-permissive suggestions failed to even meet the majority requirements to pass, as well as failing to beat the permissive options. "I understand the reasons why the people wanted to have some restrictions, but this is not the way how you can push this on the Debian maintainers".

Lessons learned

Tille said he would cover some of the lessons he learned as DPL, starting with focusing on specific and reachable goals. This meant listening carefully to the community, and trying to find the input that indicates a support for change. He thought he could reach more of his goals, but learned that he had to concentrate on what was really important and leave other things to future DPLs.

"You also need the courage to make hard decisions." He said that he had to make the hardest decision of his life during the DPL term, though he did not specify what that decision was. "My specific goal required decisions which I'm absolutely not happy about, but they were necessary anyway". He added that a DPL should not fear pushback, but it will come.

Tille said that he had also learned that it was important to ensure cooperation from volunteers who will back up a decision. He again stressed the importance of talking to people in the community to find out their opinions and whether the "silent majority" agrees. A lot of people, he said, may be "on your side, but they are too busy to pronounce it on the mailing list".

It is not normal to acknowledge mistakes openly in "normal politics", Tille said, but that is wrong. "I think it was a good idea that I acknowledged my mistakes openly."

His favorite lesson, he said, was that the Debian Med team was able to function without him. In his 2024 DPL platform, Tille had talked about starting and leading the team, which had been "a significant part of half of my life". Being DPL was not as time-consuming as he was afraid it would be, but he had stepped back from his work with the Debian Med team while serving as DPL. "The good news is, the team kept on working." It made him happy to learn that the team could survive "at least for a couple of years" without his involvement. That was not, he noted, always the case for Debian teams when a main contributor steps back for some reason. It is harder, he had learned, for a contributor to step back gracefully than it is to find contributors to step up in the first place.

He had three "final" lessons. The first was that the opinions of Debian contributors are more diverse and divergent than he expected. The second was that—no matter what he said—the interpretation was "it's the DPL speaking". He wanted to "keep on being Andreas Tille talking to his friends", but he had to deal with treating him as the DPL anyway.

The third final lesson was that he couldn't do what he wanted to do in one term. It took him a year to understand the job before he could make the changes he wanted to make. He thought that it was a good thing that the DPL term was only for one year, because if he had known in advance that it would take two "maybe I would not have stepped up for the position. So do it one year and see what happens".

He finished his talk with his favorite quotation, which he credited to Giuseppe Tomasi di Lampedusa: "Everything must change so that everything can stay the same". Tille said that he liked that a lot, and it was fitting for Debian.

Questions

Marc Haber asked the first two questions. He wanted to know Tille's opinion about redefining "or putting some more definition" on the duties of package maintainers. The second question was what could a DPL do to bring more technical leadership into Debian.

Tille responded that the first question related to his own opinion that the historical model of package ownership is "not really meeting the current standards we need". He said that Debian needed to talk about it and that there was a lot of agreement that it needed to change, but "if you propose something, people stand up and say, 'No, I think it's good and we should keep on doing this'". The problem is that they may not represent the "about 1,000 Debian developers, who are all very busy doing their own stuff and don't have time to read long threads and mailing lists". He felt that the LLM GR illustrated this; the people who take part in discussions may not represent the majority view.

As to Haber's second question, Tille said that Debian did have technical leadership in some fields, but not all. The way to attract more was by "doing a good job, being open, being friendly, and inviting for them. But I also have no short and clear path to do this".

Another audience member said that Tille had talked about his Bug of the Day initiative, but he had not talked about whether it had succeeded. Did it bring in more people? Was it successful? Tille said that there were three people who are now Debian maintainers who were not before the program started, but overall "I was not able to break this barrier" of getting people who are "too shy" to participate and ask questions in order to become contributors. He admitted he also had no idea how to solve that problem.