Who am I?

I am 28 years old (I will turn 29 in may), and live in Belgium; I grew up in the town of Ekeren, which since the early 1980's is part of the city of Antwerp. I hold a degree of Graduaat Business Information Technology which I earned in 2001 at the Karel de Grote-hogeschool of Antwerp; a Graduaat is similar to a Bachelor's degree (which, indeed, is what it's been replaced with by now). Today I'm self-employed, and single.

My first contact with Debian happened in the summer of 2000, when I was setting out to use Linux From Scratch, then still a HOWTO, to build my own system; and rather than using RedHat—which I had been using for three years prior to 2000—as a base system to compile software on, I downloaded an ISO image of Potato Test Cycle III which I then installed. I guess it's a compliment to the technical quality and impressiveness of Debian that my LFS project never got finished; and that by February of the next year, I had reformatted the partition that I had set aside for it and become a Debian Developer. Yes, it was possible to make it through NM so fast in those days.

A few months later, I received an old mac from a friend. Interested in trying out Debian on another architecture than just i386, I set out to install Debian on this machine. A few weeks later, I had become part of the Debian/m68k porting team, of which I am still a member to this day. As it turned out, the original mac that I had received couldn't even be used to run Debian/m68k, because it had a broken 68LC040 processor.

Those interested in knowing more can have a look at a list of things I've done for Debian that I've been (somewhat) maintaining on my website since a few years.

Ironically, I joined the Debian project as a means to temporarily satisfy my desire to join some Open Source effort, until I could find and join some real project that involved real coding. It didn't take me a long time to realize that Debian, in some ways, is much more real about these matters than some other projects I have come into contact with over the years.

One word about my name: I was born and raised in an area where Dutch is the language of choice, and so many people who do not speak the language have problems pronouncing my given name at first. It's not very hard, however: my name rhymes with one particular pronunciation of the word router. It does not, however, rhyme with scooter. If you want to be absolutely perfect and pronounce it like a native Dutch speaker would, then you'd need to use a hard t in the middle of the word (i.e., not softening it to a d), and use a rolling r at the end. But those are details. My family name is pronounced pretty similar to how someone familiar with the english language would assume it is.

Background

I believe Debian is about two things: people, and (Free) technology. While it is possible to put emphasis more on one of those two, it is important to realize that neither of them can exist without the other. We need people to create the technology of which we're all very proud; and we need technology to keep us geeks busy, happy, and proud to be part of Debian. Take away the technology and Debian degrades to a lousy debate club which I'll give, at most, a year before it perishes; take away the people and everything else will vanish, because technology doesn't create itself. Well—at least not until we invent AI powerful enough to do so.

Unfortunately, I feel that Debian, as it exists today, has overemphasised the technical side of the project too much, and has in some cases done this at the expense of the people who make up the project. I don't want to provide an example here and start pointing fingers, but suffice to say I feel this is not an unnatural phenomenon: being good in technical matters is a prerequisite for joining the project, while being good in interpersonal matters is not; it's therefore only expected that technical matters get more attention.

In addition, the fact that we communicate mainly over the Internet does not help things. ASCII is very good at conveying words in the English language; it is not very good at conveying emotions. It is often said that in face-to-face communication, 90% of what you say is conveyed by body language. If this is true, then email, IRC and weblogs are a very poor means of communication; and it is a fact that these are the main media with which we communicate with eachother.

On top of that, they are slow. A heated discussion in Debian can easily take a few weeks or even more than a month; and as I've been able to experience first-hand in the past, such a long discussion can easily drown out and demotivate a person quite a bit if they have a stake in the argument, to the point where they'll consider to give it all up.

Socially, there is a culture on Debian's mailinglists which, as many have pointed out, is not always optimal. In some settings, flaming is commonplace; and at the very least, mouthing off against eachother will go unpunished.

I believe this makes Debian less of a fun place to be than is necessary, and that it's long overdue to do something about that. Josip Rodin recently suggested to form a Social Committee, to make decisions in social matters, much like the Technical Committee has authority over technical matters today; and while I think that such a dispute resolution system is a good idea in itself, I also feel that avoiding disputes altogether, where possible, would be even better.

On a more practical and immediately useful level, there are a number of things I feel are wrong with the organization of the Debian Project as it exists today:

First, the position of DPL is perceived by some to be a position of technical leadership or, at least, to have the ability to appoint and dismiss those in a position of technical leadership.

I believe this is wrong. In a Free Software project such as Debian, the ability to lead on a technical level very much depends on past and current accomplishments of the technical leader him- or herself. As Eric Raymond puts it: authority follows responsibilty; in other words, you need to have worked on something before you can become its leader. Obviously a DPL is a Debian Developer and therefore has worked on Debian; but the DPL does not necessarily have the experience and history that is found in most Benevolent Dictators that lead other projects.

Of course, when I say the DPL has a lack of some practical leadership abilities, that does not mean I think the DPL is totally powerless, and/or that we would be better off without a DPL at all; if that were the case, I would be very silly indeed by running for DPL. However, I do think the DPL could benefit from better outlining what his or her responsabilities and abilities really are.

Second, the Debian Constitution contains a whole section on Delegates to the Project Leader which, by the way it is worded, gives me the impression that it was meant to be used for people in role positions: ftpmasters, system administrators, and similar. However, many of these people in role positions are not delegates; when I once asked, I was told that this is on purpose. I'll let the non-delegates in role positions do their own explanation, but the gist of the explanation as I remember it was that they want to be sure the integrity of their work and, indirectly, the whole Debian project, is not compromised by a DPL who does not fully understand their motives for doing things in a particular way.

While I can understand this as a motivation for not wanting to be a delegate, I think it does pose a problem. I have no doubt that people in role positions are very much aware of the importance of the work they do, and that they aim to do it to the best of their abilities with Debian's best interests in mind; however, it should be a known fact to anyone who's been involved in the project for a while that some of these teams have been the cause of frustration with other developers on numerous occasions in the past, which is not beneficial to the project. Moreover, if the delegate position is not used by those for whom it would seem to have been made in the first place, we might just as well not have it at all.

Some have suggested that non-delegates in role positions should be replaced for that reason. Personally, I do not believe that this would solve many things, while it would create a number of additional and unnecessary problems.

What do I propose to change the situation?

Well, I don't know that yet.

Of course I do have some general ideas as to what I could do to improve Debian; the careful reader may be able to distill some of them from the Background section above. However, I feel that more than anything, it is important that before even attempting to implement these ideas I should discuss them with the people directly involved. It may very well be the case that after this discussion my ideas turn out to be not very good at all; that something entirely different would be needed to improve the situation. Therefore, I felt it better to outline what I think the current problems in Debian are, rather than explaining what I'll do about them.

My lack of detail should not be mistaken for a lack of determinism, however.

That being said, there is one thing which I do not think needs much discussion, and which I therefore can easily make promises about already:

I will do my best to more promote the organization of meetings, of all types and sizes. Anthony Towns, our current DPL, has recently proposed to allow disbursment of Debian funds for holding meetings. I already had, and continue to have, similar plans, and think this is a great idea. As explained above in the background section, I believe that communicating via the Internet is problematic, at best. There is no better way to have two people reach a certain level of understanding than to put them together in a bar and to let them have a good face-to-face chat over a beverage of their choosing, or to put them in the same room and allow them to work together on things that they care about. This is what you will see in many large corporations with teams working together in branch offices spanning the globe: occasionally, they will meet up in some location somewhere (often an exotic one), to work together at some important project in a face-to-face setting; but such meetings also tend to involve other less work-related things, euphemistically called team-building.

There is no reason why Debian couldn't do the same. And in fact, this is already happening to some degree: we have DebConf, where many people meet up, hold talks, and share ideas; we have meetings sponsored by parties like the Junta de Extramadura, and others. We have developers meet up at local events, such as FOSDEM, linux.conf.au, LWE, and others. We've also had occasional small meetings that were fully organized by Debian people, sometime with and sometimes without external help, such as the QA meeting in Darmstadt and the Vancouver meeting a few years back.

As DPL, I will consider it my duty and do my utter best to make sure as many as possible of such meetings can be held. I will do this by encouraging people to go to events when they can; by encouraging developers who have personal disagreements or seem to hold grudges or vendettas to talk to eachother when they have a chance to see eachother in person; by encouraging companies and governments that use Debian or otherwise have a stake in the future of Debian to help hold such meetings; but also, more directly, by allowing the disbursement of Debian funds to allow Developers to hold a meeting of some kind that is directly related to Debian.

Obviously, such disbursements will have to be regulated to some degree, because we don't want to be without money at the end of this term. The guidelines which Anthony set forward would seem to be more or less okay, even if they're quite new and might perhaps need some filing off of rough edges in a few months or so; but we'll see whether this is true at that time. Also, it should be clear that third parties, such as companies, governments, or others who want to sponsor people to go to such meetings can (but absolutely do not have to) follow the same priorities which the Debian project will follow.

Who should not vote for me

There are a number of reasons why people sometimes vote for DPLs; and in an effort to avoid having to answer such questions during campaigning, I thought it might be nice if I answer them beforehand.

You should not vote for me if you want a DPL who will...

Finally,

I'd like to thank you for staying with me for this long. I hope you agree with me that the problems I've outlined are in much need of change. If you do, I urge you to vote for me on the upcoming DPL elections, and I will thank you for your confidence

In closing, allow me dig up a quote by Colin Walters in <1055185240.13855.18.camel@columbia>, which has been a source of motivation and inspiration to me on many occiasions in the past:

I don't deny the benefits. I do think that in the current implementation, the drawbacks outweigh those benefits. That's not to say it couldn't be done. But if it is done, we should do it *right*. We're Debian. That's what we do.

Rebuttals

All this is IMHO, and of course YMMV. I'm usually not the type of guy who will publically tell people what I think of their ideas in this type of confrontational way; rather, I prefer to try and understand their point of view, so that I can provide suggestions that follow from my point of view in order to find out what the best possible way to go forward is. I find this usually works, depending on the personality and willingness to compromise of the other party. However, since this is how the election process works, here we go.

Aigars Mahinovs

Aigars' platform basically outlines five things. I feel I can only agree with the first. On the others:

  1. Make Debian a trunk: I think getting all Debian packages in a version control system, as Aigars is suggesting, will be very hard to do, if is at all possible; at the very least, I predict many flamewars about what will be our version control system of choice. Next, it would require a complete change of our procedures—I wouldn't want to be responsible for ftpmastery while such a change is being implemented.
  2. Organise home folders and configuration files: Debian isn't the right place to do that. It would require every maintainer to start adding sometimes horrible patches to their packages, which will introduce Debian-specific bugs, render a lot of beginner-style documentation useless, and will cause other people to think of us as crazy fanatics. For once, they'd be right. Mind you, organizing home directories is a great idea, and a battle that I wish Aigars the best of luck with; but it has to be fought upstream, not here.
  3. Recheck our skills from time to time: that would be a waste of time. Long-time developers are usually either valuable contributors (in which case a check of skills is unnecessary), or are inactive (in which case we need to figure that out, either through MIA or through WaT). I think it's totally impossible for incompetent people to stay active in Debian for the better part of a decade and remain unnoticed.
  4. Drop the trademarks: I would truly love a world in which there would be no people who want to abuse our name in a way that would be detrimental for the project. Unfortunately, we do not live in such a world. In the real world, people will abuse our name. They will not spare us because we are a volunteer project, as the case around the Linux trademark in the US has shown. The only way to avoid this from happening to Debian is to have a trademark.

Not having a release this year does sound like a worthy goal to me. However, I'd like to point out that setting the target release date is something which I'd consider the responsibility of the Release Managers.

In short, while I have met Aigars in Helsinki at Debconf5 and think he has a pretty clear understanding of many free foftware-related things, I do not think his platform outlines what is needed to keep Debian going forward.

Gustavo Franco

Gustavo has a lot of separate plans. I hope he realizes that implementing them all would be a lot of work; I do not think he can do them all in one term. YMMV, of course. Rather than making this text long enough to be unreadable by replying to each and every one of them, I will limit myself to the ones that I think are the most interesting ones:

I like Gustavo's idea about release goals. It sounds like a reasonable thing to do.
Promoting more group work, be that through groups, subprojects or supergroups, also sounds like a worthy goal to me.
I think his idea to promote local Debian meetings and to improve the Debsphere, as he calls it, is definately a worthy goal; I have a similar promise in my platform.
Getting more Debian ports official, and getting Debian to be officially supported on desktop systems sounds like a goal that would push Debian further. While I'm not sure it's critical, it would certainly be a good thing if it could be accomplished.
Adding information about whether people are interested in non-maintainer upload to a source package could in some cases help during bug squashing parties and similar things. It sounds like a good idea, though I'd like to point out that all what's needed to implement this idea today is to propose an amendment to Debian's Policy document.

His ideas about the BTS, the New Maintainer system, and the NEW queue seem to have been prepared without discussing them with the people involved; in fact, he even admits this in one case. I do not think it is very wise to do that.

The Technical Committee is a body that, by the text of the constitution, can only act as last resort, when efforts to resolve it via consensus have been tried and failed, or when it was asked to make a decision by the person or body who would normally be responsible for it (§6.3.6 of the constitution). In other words, if it is mostly inactive, that means it is working as designed. Getting it more active therefore sounds like a strange goal.

I do not like his idea about adding new packages to stable. I once said this in <[email protected]> (which got me in the infodrom fortune file):
In my opinion, the conservative rules for updates to stable are a feature, one that should not be touched, ever.
and I stand by that today.

What I do miss in Gustavo's platform is focus. It seems as if he wants to do everything at once. I don't think that's possible.

Sven Luther

I have some sympathy for the things Sven has gone through in the project, although I cannot deprive myself of the idea that there are a number of things he could have done to at least ameliorate, if not avoid, many of the things that have happened. However, running for DPL in an effort to get broader attention for his problems in the community does not sound like a good approach to me.

Sam Hocevar

I have found in Sam's platform what I miss in Gustavo's. If he is able to accomplish what he outlines in his platform (and I have no doubt that this is the case), then he is a very strong candidate indeed.

I do not share all his ideas, however. For instance, I do not think that shortening our release cycles is the ideal thing to do. I think the steady pace at which Debian is going has its advantages (even if I'll agree that it has its problems, too). There is no reason why we should try to be everything for everyone, and being a steady rock that people can build on—a new distribution, or a desktop system, or a business—should not be something we should be ashamed about.

Steve McIntyre

I don't have much to say about Steve's platform. This is not because I think it makes no sense; on the contrary. I do have some different priorities, but I generally agree with what he has to say.

Raphaël Hertzog

This is a difficult one.

Raphaël wants to promote a DPL Board. I have similar issues with a theoretical DPL board as I had with what has become known as Project Scud (although I did not properly explain it in that mail): it sounds like introducing anonther level of red tape, of which I think there is already too much in Debian and which, if not done properly, may create more problems than it attempts to solve.

Having said that, the attentive reader will notice that I am on Raphaël's shortlist of people whom he would like to have a seat in the board. A short explanation of why this is true can be found in Raphaël's platform. The slightly longer version sounds approximately like this: I may be of the opinion that another level of red tape will not help the project, but ultimately this has to be the project's decision; and if the project, through a DPL GR, indeed chooses that this will help, then who am I to say it's silly?

Therefore, if Raphaël does indeed win the election and my own result is good enough to assume that I have a level of support which I deem necessary to serve on such a board, I will probably do so; but I won't set up a similar board if I get elected.

Anthony Towns

The most obvious difference between Anthony's platform and mine is what he declares as the most important point. Where I clearly state that technology matters, but that I want to focus on the people who make out the project this year, Anthony clearly focuses more on the technology. Both of us acknowledge the other position, but we have different priorities.

While there's certainly nothing wrong with that if you think people matter less than technology, this just is not how I think about the project.

Moreover, Anthony also is our current DPL, and he's made some fairly controversial decisions over the last year, including the decision to go with dunc-tank over the objection of a number of developers. Some of these were very valuable contributors, and some of them have left the project as a result. While I did not and still do not have any problem with paying developers to do Debian work in principle, I think this kind of I know it all best is precisely what §5.1.9 of the constitution is trying to prevent.

It could be argued that my second point is a direct result of the first.

Simon Richter

Simon was rather late in submitting a somewhat short platform. This gives me the impression that he either made a very last-minute decision to run without thinking very much about the ramifications, or that he lacks some motivation. The fact that he was the last person to become a DPL candidate, very late into the nomination period, would seem to support the former. In any case, neither of these two possibilities are qualities which I would like to see in a DPL.

The platform itself also fails to convince me, mainly due to what I perceive as lack of content: he mentions two examples of past problems, but does not mention whether he thinks these are still relevant, or whether something similar will occur in the future; and by not giving many arguments, he does not convince me that the problems he mentions have anything to do with what he apparently considers to be the root cause of all other problems in Debian—personally, I think it's much more complex than just the forming of subgroups, although this may certainly be related.