Platform for Anthony Towns

Intro

Hello! Here's my platform!

My notes tell me I should keep this simple, so I'm going to just list a few general themes for the next year and the specific things I've been thinking of doing to work on them over the coming year. I've also included a summary of things that happened during my term as DPL this past year.

Outside of Debian, I'm pretty involved in Linux Australia stuff, and this year I'm also involved with the planning for the 2007 Open Source Developers Conference. I've generally found this to be more symbiotic with my involvement in Debian than competing for time, but along with my plans to seriously investigate free accounting software over the next year, I expect I'll need to be more careful in rationing my time than I have been this past year.

To that end, if re-elected, I'll be extending the 2IC concept into having a handful of assisting leaders who each have their own projects and the authority to implement them, and can respond to interview requests and the like, to otherwise share the load. I'm hoping some of the other candidates will be willing to consider that role if I get re-elected, and likewise I'm happy to volunteer for a role like that if I'm not DPL. Ideally, I'd hope that some of the other candidates could get some of their projects done equally well in that sort of role, and at the same time have a more gentle introduction to being DPL than we usually have. Ideally, I'd like to run again next year against three or four co-DPLs who I'd worked with this coming year, lose to one of them, and have whoever that is invite us all back to work together in 2008, under their direction.

I have a blog, and my platforms from 2005 and 2006 are also available.

DPL Review - April 2006 to February 2007

My goals for last year were Vitality, Recruiting and Direction. As far as vitality goes, I think the last year's gone fairly well. There's been lots of interesting things going on, and by and large even the major arguments we've had have at least been about new things, rather than another repeat of the same old debates.

Our recruiting hasn't been as successful as I would have liked -- it's still a major process to add a new developer, and there's still not enough room for people who want to contribute but can't make the commitment to become a full developer. We've had some success at working with other organisations, both through SPI and directly, but I think we could be doing a lot better on those too.

We've had a bit of success at thinking about Debian's direction outside of just DPL elections -- though given some of the evidence of that is a DPL recall vote, maybe that's not a success I should brag about... :)

Anyway here's a a rough idea of what's occupied my Debian attention over the past year, for what it's worth:

That's not remotely complete, and many of those items weren't limited to just one month, but it's probably useful as an idea of what's been going on. Obviously there's been plenty of stuff happening that hasn't involved me in any way too!

Anyway, on to this year's themes.

Technology

The most important thing about Debian is its technology -- the clever ideas we've come up with to make things work better. Whether that be software we've written to make our packages work better, our packaging system ourself, our and others' licensing hacks to encourage a positive feedback loop of improvements, the procedures and policy documents we've come up with to make maintaining high quality software easier, or the organisational structures we've invented to let us operate as a distributed global organisation in a world that expects us to be centralised and insular.

Of course, most of the technology improvements for Debian don't (and shouldn't) involve the project leader. There is a role the DPL can play though -- and that's in setting an example of constantly working on their own technical improvements, and in so doing encouraging others to do the same.

I did a lot of technical things in 2005 -- including working on pdiffs for apt, cross-arch debootstrapping, a whole bunch of debbugs hacking including usertags, usercategories and pretty CSS, some neat memory improvements to britney, support for the testing security team to use security.debian.org without needing vendor-sec priveleges, some work on getting the archive able to accept amd64 and a few other things.

Since getting elected, I haven't done much coding-level stuff at all; there's been some follow-on stuff for keeping amd64 in shape and helping the release team out, there's been moving ftp-master to its new host, and a few more updates for the testing security support as it began to get some use. I do think some of the stuff I've been doing instead is technical in a meaningful sense, including working with SPI to make it more effective, getting Debian involved in Google's Summer of Code, working on trademark licenses, and helping people form organisations and run events in Debian's name; but ultimately Debian's a free software organisation, and we ought to be more visible for our software than the stuff around it.

So personally, the technical stuff I'm planning on working on over the next few months are Joey Hess's new jetring keyring management tool; dak (the Debian Archive Kit), for which I'm hoping we can get some neat improvements underway during debcamp/debconf; and the still pending review of dunc-tank's release management stuff.

Beyond that, I'm hoping that we'll be able to emphasise our technical work better during the coming year due to a bunch of things, including the release of etch, policy development for lenny, improved QA tests and integration, and other neat work that gets done.

Community

Community is probably the primary buzzword for Linux Australia -- we try to keep our activities focussed on community activities, whether that be the user community or the developer community or something else. That's been a really effective focus for us, in making sure we welcome new members, that we keep giving feedback to our members, that we're accessible to everyone involved in the Australian Linux community whether they're members or not, that our activities are focussed on benefiting the community, rather than particular important projects, and so on.

I've tended to avoid putting the same emphasis on community within Debian, because I suspect a lot of people will just think of it as nothing more than a buzzword or a marketing ploy or an attempt to silence anyone who doesn't agree with me as not a part of the community. But there's no point avoiding it: Debian does have a huge and vibrant community, and even if there are major disagreements going on throughout that community, it's still the community -- of developers, users, advocates, businesses, upstreams, derivatives, competitors and ultimately everyone working on Linux and free software -- that makes Debian thrive. Ultimately that's something that deserves to be recognised, because software, like freedom, can't exist without people to create it and maintain it.

I'd thus intend to stay involved with Software in the Public Interest and helping it work with other organisations such as OFTC, PostgreSQL and FreeDesktop.org to help build and maintain ties with those organisations. SPI have done an excellent job of getting their house in order lately, and in my view, should become a truly excellent resource for free software groups, given some more support from its existing member projects, including Debian.

One person can only do so much, though, so based on some recent comments from Martin Michlmayr, I think it's also worthwhile to nominate some developers as Debian Ambassadors. The idea would be that they'd be people who regulary promote Debian at conferences and tradeshows, or participate in industry groups or attend development summits as Debian's representative, and Debian would support that by helping with travel costs or helping make sure they've got CDs and such to give away. I'd expect that to include the DPL and other members of the leadership team, and as such would expect to authorise flight reimbursements -- which is something I've not been willing to do for myself this past year.

As I wrote about last year, I think we need to expand our development community to allow maintainers that are currently sponsored to participate more directly. I'm hopeful that jetring will turn out to be the major missing piece in that proposal, but we'll see what happens.

Beyond that, I think it's important to keep supporting other community based activities, such as local or regional Debian conferences, work meetings, the unofficial Debian user forums, or new initiatives like Holger Levsen's proposed Debian-Community.org.

Just Do It

Over the past year, and to a lesser extent for a fair while before then, I've spent a fair amount of time trying to explain to folks who complain about the way Debian works what (in my experience) are the most effective ways to actually achieve the changes you want to see, and to discourage them from trying to communicate their desires in ways that (in my opinion) cause more harm than good.

As far as I've seen, that's had no productive effect -- ultimately developers' attention is a limited and valuable resource and it's better to spend it on creating good things and working with people who are productive and helpful than repeating the same arguments with the same people.

Personally, there are plenty of things I can see in Debian that need improving, and I think it'll be better all round if I spend my time working on them, than trying to get everyone to understand my priorities. YMMV, and I might not have explained that very well -- but, well, that's kinda the point. :)

Rebuttal

Communication

More communication is frequently proposed as the solution to most of our problems, and has been a major issue in a number of past DPL elections -- with Martin criticising Bdale for a lack of communication in 2003, and making that a major point of his re-election platform in 2004. Likewise, Branden made communication and transparency one of the major planks of his platform in 2003, 2004 and 2005. This year it's a part of Raphael, Steve, Wouter, Sam, and Gustavo's respective platforms.

The problem with this is communication is a lot harder than it seems -- both in working out what it's worth talking about, how to describe it in a way that people can understand, where and how to say it, how to deal with people misunderstanding, misinterpreting or just disagreeing with what you've said, and just getting past the nervousness that's natural when talking to any sort of audience, let alone a large and often critical one. You can find a lot of examples of this being hard -- whether you look at the perfomance of DPLs over the past few years in keeping everyone up to date with what's going on, people promising to update their blogs more regularly, or random people's fear of public speaking.

There's simply no easy solution to getting good communication happening; it's a problem where you need to keep making lots of small efforts and building on incremental improvements.

One area in which the project hasn't been doing that well is acknowledging the efforts that are being made, and making sure that criticism is focussed on the areas most deserving of it.

For example, over the past year there have been eight reasonably major announcements regarding DSA matters, from Joey (new packages.d.o and backup.d.o), from James (downtime and compromise), Ryan (db.debian.org and wiki.debian.org), Joerg (db.debian.org followup) and myself (DSA delegation stuff). Beyond that, they're in the process of addressing the concerns they have with using the BTS for tracking issues by creating an rt instance (which as of the time of writing is still held up pending spohr.debian.org's availability), which should provide uniquely effective monitoring of that team's progress, both publically for most issues, and internally and by the DPL for non-public issues.

That doesn't mean there aren't still improvements to be made, or that there aren't other people who end up wasting time because they aren't able to find out what's going on. What it does show is that there are real actions being taken by people who are routinely criticised for not being communicative, and if we truly want to improve communication and transparency, the first thing we need to do is make a habit of acknowledging, appreciating and ultimately encouraging the communication we already have.

Getting Along

As a large project, an important aspect of our success is whether by working together we each achieve more than we could alone, or whether we get in each other's way so much that we get less done together than we could have alone.

That's a challenge at many levels -- but there's two I'd like to mention in particular.

Leadership teams

First is in a leadership team: there are a heap of ways to put together a team that doesn't work, whether that be a committee lost in debate, a bureaucracy lost in procedure, or a hierarchy where only yes-men get heard, or whatever else. We've had a few practical examples of that not working perfectly in Debian too -- whether you consider the effectiveness of the technical committee or the SPI board some years, or the ability of the DPL team in 2005 to work together, or the disagreements between Andreas and Jeroen during the 2006 DPL campaign, or between Andreas and Raphael in 2006 or Raphael and Sam this year. None of those are necessarily show-stoppers, but making a team work is as much a matter of finding ways to avoid that sort of tension and make sure your time spent together is useful and enjoyable as it is of finding some things to do and actually doing them.

There's absolutely nothing easy about that, and it's certainly not something I'm going to claim to have an answer for. The only way to deal with it that I know of is to recognise it's a problem and be prepared to work around it if you find a team doesn't end up working well together. That Steve and I managed to pull in pretty much the same direction for most of the year was not only a matter of a fair amount of effort and cooperation between us over the course of the year, but also a fair amount of luck that we often happened to agree both on the way things should go. And if things had turned out differently and we couldn't work together, for whatever reason, then dropping the whole 2IC concept was always on the table: if working together didn't turn out to be fun, we both knew how to go back to working separately. I'm not sure Raphael has a similar backup plan prepared should his DPL team not work together the way he hopes, and given our experience so far, I don't think the difficulty of getting a good team together should be underestimated.

Friends and influence

Getting individuals to work together is one challenge; another is getting groups to work well together. In some ways that's always been a part of Debian -- our social contract indicates we'll work with both upstreams and other free software groups, eg. In other ways, it's always been something we've found difficult: whether by not cooperating with derivatives very well, or getting in arguments with upstreams or other free software groups, or not finding ways of working with companies that use Debian.

That's something I've tried to do over the past year, whether by working with Sun on their non-free Java packages, or having Debian participate in the Google Summer of Code, or helping derivatives get more involved in Debian, or working with SPI, or generally promoting the idea that other projects can and should work with Debian.

I guess there are two reasons I raise this. The first is the comment in Sam's platform that Ubuntu is "not-evil" only in a Google kind of way. Both Google and Ubuntu have a lot that they can contribute to Debian, and more than that, already contribute a lot to Debian. While it's certainly fair to disagree with the way they do things -- both have significant webapps for which they don't release the source, eg! -- it's valuable to keep those disagreements respectful, so that we can continue to cooperate in areas where we actually agree. Implying, even casually or in jest, that another group isn't true to their principles is an excellent way to stop any potential contributions from them ever eventuating for no gain to our users or free software as a whole.

The second aspect grows from that: I doubt there'll ever be a time when no one in Debian will say something like that, whether as a joke or in complete seriousness, and for people who aren't heavily involved in Debian, telling the difference between some random person on a list displaying their ability to present their opinion in the shortest possible way, and the official voice of Established Debian Consensus can be pretty difficult. And Debian lists and politics can be difficult enough and confusing enough that rather than question that, or investigate more, or even argue back, that will often be the end of the discussion, and we'll have just lost another potential contributor and collaborator.

In the end, I think that's where Wouter's concept of not seeking controversy has its biggest problem -- if we want to be actively involved with as much of the free software community as possible, I suspect it's necessary for someone to seek out those disagreements and step in as an advocate for the outsider's case, simply because they're not familiar enough with Debian to argue it on their own terms, and your ideas shouldn't be dismissed just because they seem to contradict Debian's conventional wisdom. I think having the DPL be that someone, at least some of the time, is a useful way for the project to show its appreciation for new ideas and new contributors.

Anti-Rebuttal

I decided it was too long, so posted it to debian-vote instead.

Thanks for reading!