Platform for Anthony Towns
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.
DPL Review - April 2006 to February 2007
My goals for last year were Vitality, Recruiting and Direction. As far
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.
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
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:
- introduced Debian Maintainers concept (taken up by Marc Brockschmidt and Christoph Berg, there was a talk at DebConf 6, but it didn't make it past that to an implementation)
- appointed Steve McIntyre as 2IC
- Debian accepted as a mentor organisation for the Google Summer of Code
- interviews on linux.com and zdnet.com.au
- DebConf 7 selection process
- interview on pro-linux.de
- visit to Australian Attorney-General's dept with Rusty Russell
- freedesktop.org joins SPI
- apparently DFSG-free creative commons license draft appears
- Linspire launches community based derivative, Freespire
- HP announce official support for Debian on server class machines
- Kalle Kivimaa appointed as Debian auditor
- interview on OSOTA podcast
- firmware resolutions
- recall vote
- visited Google in Mountain View for the Summer of Code Summit and did a techtalk on britney
- new policy team
- announcement that Sun Java will be GPLed
- SPI resolves conflict with OSI over opensource.org
- ftp-master moves to ries, twice daily dinstall
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.
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 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. :)
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.
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.
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
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
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.
I decided it was too long, so posted it to debian-vote instead.
Thanks for reading!