Platform for Andreas Schuldei


I am 34 years old, am married and we have one child. I have been a Debian Developer since 2000 and have worked professionally with Linux (and later Debian) since 1996. Presently I am paid to work on Debian-Edu. I would continue to enjoy the support of my employer, if elected, as he believes the role of DPL is crucial to Debian - this would also allow me to work on DPL issues during work hours. Many of you might also know me from the Debian conferences that I've helped organize.

I would like to run for the office of Debian Project Leader because:

I also started some time ago to work on some of the problems that we have today, namely the FTP-master confusion1 and the release delay2.

What I want to achieve

The overall goal is to make Debian a fun and rewarding context to work and spend time in. So much so, that one misses and longs for it when one can't be or work in it.

Part of this goal would be:

These steps would make Debian a more enjoyable place and at the same time address scalability issues4 that Debian suffers from.

Implementing those changes as a one-shot measure is sure to fail and will do harm: social change needs to be implemented gradually and gently. Nonetheless it is important to start as soon as possible, and even though we won't see instant results, it is important to continue steadily and patiently.

It is not necessary to have perfect leaders, prospering small teams, and a friendly and helpful working climate, all within one month. But we will soon start seeing noticeable changes for the better if we manage to perform many small improvements, one step at a time.

How I want to achieve it: a DPL team

I believe that the DPL has become a harder job throughout the years, with more and more time consuming tasks. I also believe that Debian could do here and there with some serious attention which should not be limited by the resources of a single person. In order to be better able to achieve my goals, I have solicited the help of a small team of Debian Developers. At present this team consists of (in alphabetical order) Andreas Schuldei, Bdale Garbee, Branden Robinson, Enrico Zini, Jeroen van Wolffelaar and Steve Langasek.

Having a DPL team will allow us to:

Implementation details:

We strive for transparency and are open for more people, but we don't intent to grow too much (say, above ~7 people) to keep group-work efficient. Low fluctuation/turn-over and steadiness is desired, however, there is no expectation for team members to stay on longer than they're able to.


Good Leadership exists in the free software world, Debian included, and happens mostly without anyone noticing, not even the person who took the lead. Good examples in Debian are Steve Langasek in the release team, Petter Reinholdtsen in Debian-Edu or Joey Hess in Debian-Installer.

Leadership in voluntary organisations like Debian lacks the instruments of power that are used in business environments and give leadership its bad taste. That does not keep some people from trying to apply them anyway: usually this results in people leaving or frustration in general. The answer to fear of bad leadership is not to have no leadership at all, but to seek good leaders. Great leaders do not just appear out of nowhere, but they need to grow. Small teams are good environments for them to develop their skills and learn from others.

The "Herding of Cats" failed. The problem is in the word "herding" which implies "keeping people in the place where they are". People are more inclined to pursue some fascinating goal. Debian's goal is to produce an excellent free operating system and have fun doing so. The leader's task is to keep that vision alive and vivid and to encourage people to want to go there.

Make Life better!

What leaders in voluntary projects can do and must do is to:

It will take time to gently introduce this in Debian.

Small Teams

Small teams are probably the single most important characteristic that a group like Debian needs to have to be able to grow in a healthy way. If done right they can solve many problems.

What small teams could do

What small teams need to be like

For a team to be able to fully serve those functions it needs to have a couple of necessary features:

Introducing such a small team organization into Debian takes time and is a gradual process. While group maintenance of packages is no novelty and normal teamwork does happen, this concept is more.

If you elect me to be your DPL, I will be in a much more effective position to advocate and implement such teams within the Debian project.

Working Climate

The attractiveness of a group depends significantly on the feeling of how welcomed, respected, and appreciated their members feel. Even though the word is incredibly hackneyed and frequently abused, I still want to describe the relationships we need as "loving" since it communicates the concept best. The quality of communication in groups is strongly correlated to this key characteristic.


The tone of conduct in Debian is a good indication of how "loving" the people are towards each other. Is the atmosphere friendly and constructive, or caustic and corrosive? Humor, laughter and fun are the positive components which make a group a pleasant environment to be in. Random acts of kindness are possible in virtual communities as well and can even extend into Real Life.

Where it works better

Sub-projects which are smaller, more personal and where people meet regularly achieve a much better signal/noise ratio in communication and feel warmer than the big busy mailing lists and IRC channels Debian has.

Change is possible

It is possible to purposefully change relationships and the tone of conduct in Debian. We can inform people about basic group dynamics and help them to find better forms to express themselves. Everyone should learn when a mail or remark is not worth sending, for example.


What I propose in this platform is at the same time "radical" and "just common sense": most of it is about making Debian less stressful and more fun. The only changes that will ever be accepted are those that people want, in Debian as in other places where people are free.

I believe that these changes are so obviously good ideas that we want them, regardless of who will be elected as a DPL. Electing me is a way of showing that you agree, and to get started.

[1] The FTP-Master confusion

For some time there has been some irritation, general flaming or even open hostility between FTP-masters and some other Debian developers regarding the job of FTP-masters and the way they think it is supposed to work. This is an example of negative working climate in Debian.

The situation has reached a dead-lock where one side demands transparency and accountability and the other refuses to comply as long as the climate remains hostile.

The multi-stage solution to the problem takes some time and will provide a long term scalable solution. I discussed it with some FTP-masters and individuals who could do the work. As an additional bonus it fits well with the "Small Teams" approach I will push elsewhere and resembles the release master/assistant and the AM/Frontdesk/DAM model that works satisfactorily already.

This is just one example of what I would do if I was elected DPL. While I can de-escalate and mediate already today, having the authority that comes from being the chosen leader of all developers is a help for leading this project to successful resolution of internal conflicts.

[2] Release Delays

Debian needs more frequent, regular releases. The present delays cause frustration and a decline in morale in Debian country. To pave the way for a smoother development cycle and release process I took the initiative, acquired sponsorship (from NUUGF) and organized a meeting of the release team and FTP-masters taking place soon.

[3] Real-Life Meetings

Besides being fun, meetings serve a few vital functions, especially for virtual communities as Debian:

So while meetings themselves are not a goal per se, their results definitely are and have proven to be of high value to Debian.

[4] Managing Growing Needs

Capacity planning is frequently a challenge for large organizations, and once you fall behind, it's even more difficult to catch up. A lot of Debian's hottest issues over the past few years have been capacity issues: making sure the autobuilder network scales to handle our package count; making sure the NM process scales to meet the number of incoming applicants; making sure the security team scales to handle the architecture count; etc. While many of these issues are largely technical in nature, the task of identifying and resolving choke points before they become a problem is one that requires managerial attention, and the DPL is best suited to provide this oversight.


What has characterized this years platforms and campaigning seems to be that most candidates (Branden, Anthony, Matthew and also Angus) recognized the shortcomings on some social level within the Debian Project. The most obvious symptom they identified is the limited efficiency of communication on some of the projects mailing lists.

I take that as an indication that my approach to try to influence the social characteristics of the project actually is the right way to go.

What is different in my approach compared to theirs is that it will not only address one symptom of the problem by adding additional rules for communication within the project, but change the bigger context. By introducing conscious and empowering leadership, strengthening and expanding small teams, working on loving relationships and increasing frequency and quality of real life meetings, real change for the better can be achieved. In this context I would like to point to the very helpful question by Henning "[...] how will your being DPL make a difference [...]?" and my passionate answer to that.

All other candidates (besides Branden) seem to either underestimate the workload which the office of Debian Project Leader brought in recent years or will need to work on it full time. Our current Leader, Martin, is both highly intelligent and organized and still carried heavily on the workload, partly even neglecting his research.

The great option to rely on the DPL team would help Branden or me to both accomplish our respective goals and still stay sane in the process.

Branden and I were unable to identify areas where we are in profound disagreement. This is a good thing, since we intent to work on the same team. But we do have different priorities. While i intent to use the available powers of the DPL proactively to address everyday problems, I also strive for informal changes enabling the project to take charge of core social challenges while Branden proposes improvements based on greater process formalism.

Another way in which I differentiate myself from Branden is in how I engaged in active community building by my involvement in DebConfs and numerous other gatherings and development meetings.