You can leave comments on my posts by following
the relevant link associated to each post. You can also mail me comments; note that unless
otherwise requested, I will add mailed comments in the comment
feeds.

Shuttleworth Foundation Flash Grant

Flash grants are an interesting funding model, which I've just
learned about. You don't need to apply for them. Rather, you get
nominated by current fellows, and
then selected and approached by the foundation for funding. The
grant amount is smaller than actual fellowships,
but it comes with very few strings attached: furthering open
knowledge (which is the foundation's core mission)
and being transparent about how you use the money.

I'm lucky enough to already have a full-time job to pay my
bills, and I do my Free Software activism mostly in my spare time.
So I plan to use the money not to pay my bills, but rather to boost
the parts of my Free Software activities that could benefit from
some funding. I don't have a fully detailed budget yet but,
tentatively: some money will go to fund Debsources development (by others),
some into promoting my
thoughts on the dark ages of Free Software, and maybe some into
helping the upcoming release of Debian.
I'll provide a public report at the end of the funding period (~6
months from now).

I'd like to thank the Shuttleworth Foundation for the grant and
foundation's fellow Jonas
Öberg for making this possible.

Apparently, enough fellow developers have been foolish enough to
nominate me as a prospective member of the Debian Technical
Committee (CTTE), that I've been approached to formally
accept/decline the nomination. (Accepted nominees would then
go through a selection process and possibly proposed to the DPL for
nomination.)

I'm honored by the nominations and I thank the fellow developers
that have thrown my name in the hat. But I've respectfully declined
the nomination. Given my current involvement in an ongoing attempt
to introduce a maximum term limit for CTTE membership, it would
have been highly inappropriate for me to accept the nomination at
this time.

I have no doubt that the current CTTE and the DPL will fill the
empty seats with worthy project members.

on perceived hysteria and silent sanity

Init system coupling GR: results (arrow from A to B means
that voters preferred A to B by that margin)

Some random thoughts about them:

The turnout has been the highest
since 2010 DPL elections and the 2nd highest among all GRs (!= DPL
elections) ever. The highest among all GRs dates back to 2004 and
was about dropping
non-free. In absolute terms this vote scores even
better: it is the GR with the highest number of voters ever.

Clearly there was a lot of interest within the
project about this vote. The results appear to be as representative
of the views of project members as we have been able to get in the
second half of Debian history.

There is a total ordering of options (which is not always the
case with our voting
system). Starting with the winning option, each option in the
results beats every subsequent option. The winning option ("General
resolution is not required") beats the runner-up ("Support for
other init systems is recommended, i.e., "you SHOULD NOT require a
specific init") by a large margin: 100 votes,
~20.7% of the voters. The winning options wins over further options
by increasingly large margins: 173 votes (~35.8%) against "Packages
may require specific init systems if maintainers decide" (the MAY
option); 176 (~36.4%) against "Packages may not require a specific
init system" (the MUST NOT option); 263 (~54.5%) against "Further
discussion" (the "let's keep on flaming" option).

While judging from Debian mailing lists and news sites you might
have gotten the impression that the project was evenly split on
init system matters, at least w.r.t. the matter on the ballot that
doesn't seem to be the case.

The winning option is not as crazy as its label
might imply (voting to declare that the vote was not required?
WTH?). What the winning option actually says is more articulated
than that; quoting from the ballot
(highlight mine):

Regarding the subject of this ballot, the Project affirms
that the procedures for decision making and conflict
resolution are working adequately and thus a General
Resolution is not required.

With this GR the Debian Project affirms that the procedures we
have used to decide the default init system for Jessie and to
arbitrate the ensuing conflicts are just fine. People
might flame and troll debian-devel as much as they
want (actually, I'm pretty sure we would all like them to stop, but
that matter wasn't on the ballot so you'll have to take my word for
it). People might write blog posts and make headlines corroborating
the impression that Debian is still being torn apart by ongoing
init system battles. But this vote says instead that the large
majority of project members thinks our decision making and
conflict-arbitration procedures, which most prominently include the
Debian Technical Committee, have served use
"adequately" well over the past troubled months.

That of course doesn't mean that everyone in Debian is happy
about every single recent decision, otherwise we wouldn't have had
this GR in the first place. But it does mean that we consider our
procedures good enough to (a) avoid getting in their way with a
project-wide vote, and (b) keep on trusting them for the
foreseeable future.

[ It is not the main focus of this post, but if you care
specifically about the implications of this GR on
systemd adoption in Debian, I recommend reading
this
excellent GR commentary by Russ Allbery. ]

My take home message is that we are experiencing a huge gap
between the public perception of the state of
Debian (both from within and from without the project) and the
actual beliefs of the silent majority of people
that make Debian with their work, day after day.

In part this is old news. The most "senior" members of the
project will remember that the topic of "vocal minorities vs silent
majority" was a recurrent one in Debian 10+ years ago, when flames
were periodically ravaging the project. Since then Debian has grown
a lot though, and we are now part of a much larger and varied
ecosystem. We are now at a scale at which there are plenty of FOSS
"mass-media" covering daily what happens in Debian, inducing
feedback loops with our own perception of ourselves which we do not
fully grok yet. This is a new factor in the perception gap. This
situation is not intrinsically bad, nor there is blame to assign
here: after all influential bloggers, news sites, etc., just do
their job. And their attention also testifies of the huge interest
that there is around Debian and our choices.

But we still need to adapt and learn to take perceived hysteria
with a pinch (or two) of salt. It might just be time for our
decennial check-up. Time to remind ourselves that our ways of doing
things might in fact still be much more sane than sometimes we tend
to believe.

We went on 10+ years ago, after monumental flames. It looks like
we are now ready to move on again, putting The Era of the Great
systemd Histeria™ behind
us.

I've just added sophiejjj's blog to Planet
Debian, so you will soon hear about her work in the Debian
blogosphere.

I've been impressed by the interest that the
Debsources proposal in this round of OPW has spawned. Together
with Matthieu I have interacted with more than a dozen OPW
applicants. Many of them have contributed useful patches during the
application period, and those patches have been in production at
http://sources.debian.net
since quite a while now (see the commit log for details). A special
mention goes to Akshita Jha, who has shown a lot of determination
in tackling both simple and complex issues affecting Debsources. I
hope there will be other chances to work with her in the
future.

OPW internship will begin December 9th, fasten your seat belts
for a boost in Debsources development!

Debian participation in Italy's CAD68 committee

(The initial policy change discussed in this document is
a couple of years old now, but it took about the same time to be
fully implemented, and AFAIK the role Debian played in it has not
been documented yet.)

In October 2012 the Italian government, led at the time by
Mario
Monti, did something rather innovative, at least for a country
that is not usually ahead of its time in the area of information
technology legislation. They decided to change the
main law (the "CAD", for Codice dell'Amministrazione
Digitale) that regulates the acquisition of software at all
levels of the public administration (PA), giving an
explicit preference to the acquisition of Free
Software.

The new formulation of
article 68 of the CAD first lists some macro criteria (e.g.,
TCO,
adherence to open standards, security support, etc.) that public
administrations in Italy shall use as ranking criteria in
software-related calls for tenders. Then, and this is the most
important part, the article affirms that the acquisition of
proprietary software solutions is permitted only
if it is impossible to choose Free Software solutions
instead; or, alternatively, to choose software solutions that have
already being acquired (and paid for) by the PA in the past,
reusing preexisting software. The combined effect of these two
provisions is that all new software acquisitions by PAs in
Italy will be Free Software, unless it is motivated—in writing,
challengable by a judge—that it was impossible to do otherwise.
Isn't it great?

It is, except that such a law is not necessarily easy to adhere
to in practice, especially for small public administrations (e.g.,
municipalities of a few hundred people, not uncommon in Italy)
which might have very little clue about software in general, and
even less so about Free Software. This is why the government also
tasked the relevant Italian
agency to provide guidelines on how to choose software in a way
that conforms with the new formulation of article 68. The agency
decided to form a committee to work on the guidelines (because you
always need a committee, right? ).

To my surprise, the call for participation to be part of the
committee explicitly listed representatives of Free Software
communities as privileged software stakeholders that they wanted to
have on the committee—kudos to the agency for that. (The
Italian wording on the call was: Costituirà titolo di preferenza
rivestire un ruolo di […] referenti di community del software a
codice sorgente aperto.) Therefore, after various prods
by fellow European Free Software activists that were aware of the
ongoing change in legislation, I applied to be a volunteer CAD68
committee member, got selected, and ended up working over a period
of about 6 months (March-September 2013) to help the agency writing
the new software acquisition guidelines.

Logistically, it hasn't been entirely trivial, as the default
meeting place was in Rome, I live in Paris, and the agency didn't
really have a travel budget for committee members. That's why I've
sought sponsorship from Debian, offering to represent Debian views
within the committee; Lucas kindly
agreed to my request. So what did I do on behalf of Debian as a
committee member during those months?

Most of my job has been some sort of consulting on how
community-driven Free Software projects—like Debian—work, on how
the software they produce can be relied upon and contributed to,
and more generally on how the PA can productively interact with
such projects. In particular, I've been happy to work on the
related work section of the guidelines, ensuring they point to
relevant documents such as the French government guidelines on how
to adopt Free Software (AKA
circulaire Ayrault). I've also drafted the guidelines
section on Free Software directories, ensuring that important
resources such as FSF's Free Software
Directory are listed as starting points for PAs that
looking for software solutions for specific needs.

Another part of my job has been ensuring that the guidelines do
not end up betraying the principle of Free Software preference that
is embodied in article 68. A majority of committee members came
from a Free Software background, so that might not seem a difficult
goal to accomplish. But it is important to notice that: (a) the
final editor of the guidelines is the agency itself, not the
committee, so having a "pro-Free Software" majority within the
committee doesn't mean much per se; and (b) lobbying from the
"pro-proprietary software" camp did happen, as it is entirely
natural in these cases. In this respect I'm happy with the result:
I do believe that the software selection process recommended by the
guidelines, finally
published in January 2014, upholds the Free Software
preference principle of article 68. I credit both the
agency and the non-ambiguity of the law (on this specific point)
for that result.

All in all, this has been a positive experience for me. It has
reaffirmed my belief that Debian is a respected, non-partisan
political actor of the wider software/ICT ecosystem. This
experience has also given me a chance to be part of country-level
policy-making, which has been very instructive on how and why good
ideas might take a while to come into effect and influence citizen
lives. Speaking of which, I'm now looking forward to the first
alleged violations of article 68 in Italy, and how they
will be dealt with.

Abundant popcorn will certainly be needed.

Links & press

If you want to know more about this topic, I've collected below
links to resources that have documented, in various languages, the
publication of the CAD68 guidelines.

je.code(); — promoting programming (in French)

jecode.org is
a nice initiative by, among others, my fellow Debian developer and
university professor Martin Quinson. The goal of jecode.org is to
raise awareness about the importance of learning the basics
of programming, for everyone in modern societies.
jecode.org targets specifically francophone children (hence the
name, for "I code").

I've been happy to contribute to the initiative with my thoughts on
why learning to program is so important today, joining the happy
bunch of "codeurs" on the
web site. If you read French, you can find them reposted below. If
you also write French, you might want to contribute
your thoughts on the matter. How? By forking the project of
course!

debsources debbugs oh

I've migrated bug reports from the previous
ad-hoc text file in the Git repo to the Debian BTS, under the umbrella of the
qa.debian.org pseudo-package.
From now on this is the recommended (and documented) way of reporting
bugs against http://sources.debian.net.

While at it, I've also properly tagged the current easy hacks on Debsources using the gift tag. There
are definitely opportunities for new contributors there, and there
might be more if you submit your own Debsources' pet peeves to the
BTS.

my setup, take #1

Among the various things I've catched up with during the summer,
I've finally managed to set aside some time to answer a pending
interview request for The [GNU/]Linux Setup: a blog
run by Steven Ovadia that collects interviews about how people use
GNU/Linux-based desktops.

In the interview I discuss my day to day work-flow, from GNOME
Shell to Mutt, from Emacs to Notmuch, and the various glue code
tools I've written for integrating them.