Moray Allan


Who am I?

What have I done in Debian?

Here are some of the things I have done in Debian over the years:

Since the DebConf team should be a black box to most of you, but has taken a lot of my time in the last few years, I'll comment a bit further on what I've done there. I have worked there in different roles over the years, which have brought me into contact with many aspects of Debian:


Debian is now in its twentieth year. Looking back at the project's development, the first years showed the rapid development of early childhood, open to try anything. In the following years it started to be more careful, and its permanent character emerged in our Social Contract and the Debian Free Software Guidelines. As Debian became a teenager, it showed typical stubbornness even in minor squabbles, and had a tendency to fight with its friends. Debian's calmer atmosphere and greater predictability in the last few years may be signs of adulthood, but we need to hang on to the project's feeling of fun even if that means occasionally being childish, and to hang on to a child's sense of surprise and excitement.

To me it is indeed surprising that Debian has lasted, and prospered, this long. I'm very happy that it has, but we should remember the level of success (and perhaps also some luck) involved in that. In particular it's surprising to me that despite the many arguments over the years we never had a permanent schism in the project and a fork into separate groups working independently. Of course we now have many derivatives, each with a different character, but each of those makes Debian a more important part of the free software community. We have many users who take Debian for granted, including many who don't even know they are using Debian's work – we should be pleased about this as a sign of how mature and stable a project Debian is seen to be. Recent W3Techs surveys show Debian as the most popular choice for Linux webservers, with a market share of over 30%.

Debian is also surprising for working very well as a flat organisation. Much work on Debian is done by people working independently or in loose, unstructured teams. Most teams in Debian were not created top-down but bottom-up by people doing a specific type of work. This looseness and lack of lines of hierarchy can occasionally lead to conflict about specific decisions, or prevent any definite decision from being made in a reasonable time, and the DPL can help in such cases by mediating between different groups. I would also like us to take a more pre-emptive approach to such issues by encouraging more turnover of members between different teams so that teams share experience, and by encouraging more organised discussions between teams about their plans and requirements, including where appropriate at face-to-face inter-team sprints.

Below I comment on a few aspects of how I would work in the DPL role if elected. While we only elect one DPL, I am sure that my fellow candidates will present good ideas which would benefit the project. If I am elected, I would also work with them to make sure that those ideas are implemented.

I have grouped topics below going in order from the general to the more specific. Although I can say clearer things about my own specific ideas than about, for example, coordination which where the DPL needs to react to problems that aren't known in advance, if I am elected I would treat the more general points of delegation, coordination and communication as higher priority than pushing my own specific ideas.

Delegations and teams

I believe that as well as experience and skill in the relevant area, Debian teams need:

If elected, I would lead a discussion to establish some guidelines on good practice for Debian teams including these aspects. When making delegations, I would ask teams to define their points of contact and specify how they will communicate their results.

Where I saw a lack of transparency, communication and openness in an existing team, I would work with the existing team members to address this problem. I don't believe that any Debian team wants to be opaque, uncommunicative or closed, and I think that our teams generally have high standards in these respects, but we know from past problems that maintaining those high standards can be hard when there are more immediate pressures on teams to get work done.

I would encourage teams to plan ahead how they will enable a turnover of people in delegated roles. This could mean, for example, that a team defines in advance a rotation schedule that commits it to recruiting new members. It isn't healthy for team membership to stay static until too many members get bored or burn out. Our ideal should be for people to retire from roles while they are still performing them well, and then transfer their experience to other areas of the project.

I would continue the intention of previous DPLs to ensure that all delegations are clearly listed on the Debian organisation webpage. I would ask delegated teams to see if the scope of their delegations should be expanded or otherwise updated.

I would also intend to record publicly formal delegations for specific one-off tasks, not only ongoing teams, more often than has happened recently, to increase transparency.


Much of the time the DPL's role is coordination and mediation, working by encouragement and influence rather than through power. This is quite similar to the coordination role I have played in DebConf organisation. Already within DebConf I have also been ready to set aside my own preferences when neutral mediation is required between different positions.

I also think that many others in Debian can help with coordination and mediation. I would continue the recently formed DPL helpers initiative as a point of contact for people interested in this kind of activity to hold discussions, share out tasks, and work together.

However, I believe that Debian is at its best when it is a flat organisation where different groups and individual contributors work together directly as needed, including of course groups that themselves have a coordinating purpose, like the Release Team. In my view, coordination and mediation from the DPL or helpers should only interfere where it looks like something is going wrong or being forgotten, and an important part of their goal in interfering should be to restore things so that less interference is needed in future.

Internal communications

Internally, I would continue Stefano's attempt to make as much of the DPL's activities as possible public at least to project members, including an activity log. The DPL and helpers have a responsibility to provide a good example of the criteria of transparency, communication and openness that I defined above.

Where possible, I would push DPL-related discussions from private venues to public ones. For example, many DPL-related topics should be discussed on the debian-project mailing list where others can follow what is happening and provide feedback and new ideas.

More importantly, I would encourage all Debian teams to be transparent and communicative, and to have clearly defined points of contact.

External communications

Externally, I would try to help the press and publicity teams find more volunteers so that they can build more active relationships, for example with sympathetic journalists, company representatives or government officials, rather than only pushing out announcements and hoping that they are picked up. (I am currently part of both teams.)

Building relationships with company representatives and government officials also goes beyond the responsibilities of the press or publicity teams alone. These teams currently cover one aspect, of pushing information to them. A second aspect could be fundraising, as I discuss below. But a third aspect would be to listen to what these organisations, as major users, would like to see from Debian, and to motivate them to fund contributions to Debian in ways that will make it more useful for them. Some work in this direction, limited to companies that already contribute to Debian, was started in the debian-companies initiative that launched last year.

I would be willing, and available, to attend events and to give talks on behalf of Debian. But I don't think that this kind of role of representing Debian should be limited to the DPL, or to people in high-profile technical roles. Where Debian money is used to fund travel purely to give talks, the priority should be to send a good speaker who will present Debian well, taking into account travel costs for possible candidates. Where good speakers feel that they lack an appropriate Debian position from which to represent Debian and gain speaker slots at conferences (including because they previously held such a position but have retired), I would be happy to give them some appropriate title by a delegation.

Local communications

In my experience, although most Debian communication happens online, it is much easier for us to recruit new volunteers where there is some existing personal contact.

I would like to encourage more local meetings of Debian contributors, as a way for us to reach out to potential new contributors. I don't mean by this that I want us to try to split up existing local groups that are wider than Debian, but while many locations have regular Linux User Group meetings, most of these are very different in participants and intentions to a Free Software Developer meeting. In addition, it would be good to have more immediate ways to answer the frequent queries for who to contact about Debian in a given region, through a database of local groups and of Debian people who have agreed to be regional contacts.

As a more immediate goal, I would like Debian's 20th birthday this August to be celebrated by many Debian Day local celebrations round the world, not just at DebConf for those of us present there. Where possible, these events could be used to inaugurate ongoing regular local meetings.

Fundraising and spending

Now that we have greater clarity about what assets Debian holds, and how funds have been spent in the past, due to the great work of the Debian Auditors, I would like us to more actively plan both how best to spend the funds available to us, in a transparent way. Our constitution already demands that major expenditure should be debated in advance, not merely authorised by a DPL edict.

I certainly don't want us to start scattering nagging advertisements across users' desktops, but we already seek significant levels of donations, most significantly for DebConf and individual team sprints and for hardware replacement, and I would like to see people working on this coordinate their work through a shared fundraising team. The work of raising this money needs some central coordination, even if only because having multiple fundraising teams saying different things to the same organisations could be dangerous. I am pleased that Brian Gupta, from the DebConf fundraising team, has recently taken up this topic, and as DPL I would seek to push this forward.

I would seek suggestions on how we could try to advance Debian's goals by spending money in ways we're not currently doing. While I think we should be careful with money, I would be willing to authorise spending to try out new ideas from others, where goals can be defined and the success of an initiative can be judged.

Merging from the DebConf branch

In the last few years I've been pushing for some aspects of DebConf to be merged back with their main Debian equivalents, where some branching had happened, or to be made more general where they only existed formally within DebConf. The next steps of this would be easier to push by having a DPL focus on them than from within the DebConf team.

I would like to note here that while I would have rather less time for day-to-day DebConf work as DPL, I am confident that the other DebConf Chairs and the rest of the DebConf Team would continue very well even if I disappeared utterly from doing work there tomorrow.

Specific ideas

Most of what I have said above is intentionally general. If elected DPL, I would not see pushing my own specific views as primary – our Constitution in fact requires that when leading discussions the DPL should not use the Leadership position to promote their own personal views. But since you're reading this, I'll take the opportunity to advertise a few specific ideas I'd like to see taken up or, better, improved on:

What would I intend to do differently from Stefano?

I have been asked what I would intend to do differently from Stefano if I became DPL. I have mentioned some points under the topic headings above. Here are a few more comments:

How would I have time to be DPL?

Comments on the other candidates' platforms (Rebuttal)

I'm grateful to the other candidates for standing, for taking the time to write thought-provoking platforms, and for participating in the debian-vote discussion, where we have touched on many Debian topics that don't normally get much attention.

For better or worse, my platform is the most dependent on holding the DPL role, since it grew out of my experience doing coordination work in Debian and is directly related to coordination-level changes that I would have no mandate or authority to push through unless I am elected. In contrast, I think that Gergely and Lucas could implement the major ideas from their platforms without needing to be DPL, and if I am elected I will encourage them to do so.

Gergely Nagy

It seems that I'm more positive about the current state of Debian than Gergely, but I share some of his concerns about communication, including the idea that we should encourage more local communication and events, and about the need to more actively encourage people into Debian contribution. I'm glad that the DPL campaign period has been an opportunity to raise these topics. If I am elected, I especially hope that Gergely will help coordinate work on local Debian groups and events, and on finding other ways to reach out to new contributors.

I'm also generally grateful to Gergely for his perseverance in standing once again and for making the election discussions more interesting.

Lucas Nussbaum

For me, the most important points in Lucas's platform are his suggestions on documentation, development practices, and sponsorship infrastructure. I would like us to take a more active approach than he suggests to reaching out to new contributors (as well as to the media, companies and governmental organisations), but these points of his are complementary to the more coordination-level ideas I want to push. If I am elected, I will strongly encourage Lucas to continue his work on these topics. I especially look forward to us having concise documentation to bring old contributors up to date with current best practices. I am interested by Lucas's suggestions about a project observatory, and encourage him to apply his technical skills to improve our tools in this area too.

As Lucas has noted on debian-vote, most of the things he mentions in his platform don't require special powers, but if I am elected, I would be happy to give his work on these topics formal support by a delegation.