Mark: I'm happy to read publicly that there will be a team working on upstream at Canonical. That's awesome news, and I'm certainly eagerly waiting to see the first patches flow in. However, when I read your blog post, I couldn't avoid an unpleasant feeling. Let me try to explain by commenting a few quotes from your post.

Increasingly, though, Canonical is in a position to drive real change in the software that is part of Ubuntu.

While it sounds cool, I would have appreciated a more modest statement. Something like Canonical is in a position to help drive real change certainly sounds better to me: let's give credits to the whole community (people from various companies, and above all, a huge number of volunteers) for driving the change.

If we just showed up with pictures and prototypes and asked people to shape their projects differently, I can’t imagine that being well received!

Heh. I see the point here, and there's definitely some truth behind it: people certainly don't like seeing pictures and then being told to implement this. It's been tried in the past and sure, it doesn't work. However, all of us do like to see pictures to discuss ideas. If we love the pictures and we're told that those are being prototyped, we'll even be ecstatic. Okay, not everybody will be ecstatic :-) But most will feel that you're simply doing the right thing and participating to the community.

Of course, there’s a risk to participation, because you can’t easily participate without expressing opinions, visions, desires, goals, and those can clash with other participants. It’s hard to drive change, even when people agree that change is needed. I hope we can find ways to explore and experiment with new ideas without blocking on consensus across diverse and distributed teams.

Well, you can't participate at all without expressing opinions, visions, desires or goals! I would certainly agree here, but how is it a risk? The risk is really in not participating, because your visions will likely not be reached. Blocking on consensus is indeed one of the biggest issue, especially in projects with a high number of contributors, each one having a subtly different goal. But most free software project have dealt with this quite a few times already and, well, they're still here :-)

All of this has me tapdancing to work in the mornings, because we’re sketching out really interesting ideas for user interaction in Launchpad and in the desktop. The team has come together very nicely, and I’m thoroughly enjoying the processes, brainstorming and prototyping. I can’t wait to see those ideas landing in production!

This is probably what worries me most. Do the work upstream. Even prototyping. Publish early results and screenshots and everything else. Give other people a chance to contribute and emit opinions. If you don't do so, we'll end up with something that might be cool, but where upstream and your team won't completely agree. And this is bad because this might lead to upstream not adopting some good stuff -- solution where we all lose. There's a downside to this way, though: it will slow development down; but it's worth it.

I could continue a bit, with other things, but I don't want to sound too negative and lose my message :-) I do welcome this change, and I hope this will make us all progress. However, I'd love Canonical to try harder to think as upstream, and to participate there as early as possible. Or if I try to explain this with a metaphor (and it's quite possible that it's not what you wanted to express): reading your post made me feel like you want to do some work and then send it in a big packet to upstream, as a gift. I, as upstream, very much prefer many small gifts since the very beginning (that accumulate in a huge gift) to a big gift that I can't handle.

Lu dans cet article du Monde, sur les machines à voter qui commencent à apparaitre en France et les soupçons qu'elles inspirent (emphase ajoutée par moi-même) :

A l'automne 2006, un groupe d'informaticiens néerlandais a fait l'acquisition de machines Nedap pour en évaluer l'intégrité. "Ces informaticiens ont démonté une machine, ont constaté qu'ils pouvaient en changer le logiciel et l'ont reprogrammée pour jouer aux échecs", explique M. Di Cosmo. Surtout, ils affirment être parvenus à capter les radiofréquences émises par la machine à une distance de 25 mètres environ et être ainsi à même de savoir si le nom affiché sur l'écran à cristaux liquides de l'appareil - le nom du candidat pour lequel le vote a été enregistré - comporte ou non des caractères accentués. "Ce qu'ils ont fait, c'est simplement de vérifier que la machine fait bien ce qu'on lui demande", tempère M. Palisson. Quant à la possibilité de surveiller à distance le fonctionnement de la machine, "l'expérience a été faite sur un ancien modèle qui n'est plus en service et, de toute façon, il serait possible de mettre en oeuvre le même type de surveillance avec le vote classique, au moyen de caméras installées dans les isoloirs", réplique le directeur de France-Election, qui fait valoir qu'aucun dysfonctionnement des appareils Nedap n'a été rapporté.

Passons outre le fait que les caméras installées dans les isoloirs seraient probablement moins efficaces et plus difficiles à mettre en œuvre que la faille que M. Palisson tente de balayer. L'argument mis en emphase ne sert malheureusement pas les intérêts de M. Palisson : il revient à dire qu'une faille dans un système n'est pas importante car elle peut exister dans un autre système utilisé. C'est faux. Une faille est une faille, et tenter de la minimiser de la sorte est irresponsable.

Difficile d'être mis en confiance avec ces propos.