The end of the year is a period of time during which many people
sit down and decide to donate some money to initiatives that pursue
the public good.
I have that habit myself. At the end of 2011 I've decided to
donate to Wikipedia, as I
consider Wikipedia to be one of the greatest achievements of
humanity and I see a lot of value in keeping it running on a purely
non-profit basis.
(Not to mention that it's already quite
annoying to see Jimbo's banners one month per year, go figure what
would happen if those banners would suddenly turn into
permanent advertisement banners!)
You may wonder why I haven't donated to Debian, given my
involvement in the project. In fact, that involvement is precisely
why I didn't donate to Debian: there is some sort of sanity in
keeping a distinction between causes to which I donate my spare
time (the case of Debian) and those to which I donate money (the
case of Wikipedia), and I like to keep that distinction.
As DPL, I've the luxury of being cc:-ed on Debian donation
notifications that flow through
SPI, and I can also check the flow of
donations to other
Debian trusted
organizations. This year, I've been particularly impressed by
the high flow of
Debian
donations during the end of the year. Thank
you, donors, it is thanks to your generosity that we keep
many Debian activities going. Using the money people like you
regularly donate to Debian we:
- buy hardware and hardware-related services that keep the Debian
infrastructure running
- sponsor sprints
and other events that allow volunteer developers to get together
and work on Debian in fun and productive contexts
- support travel expenses of Debian developers that attend
conferences or meetings as representatives of the Debian
Project
On a more political note, I'm happy to observe that Debian
incomes come almost entirely from private citizens. We do have big
corporate sponsors, but their contributions tend to be concentrated
as specifically earmarked donations for
our annual conference. This is good
for them, because they get the fancy banners on the DebConf website
and at the conference. But it is also good for Debian, because a
donation-based economy (as Debian's, with DebConf exception) is
less likely to be influenced by the whims of a few big donors.
But with (great) donations comes (great) responsibility. In
particular, it comes the need of budget
transparency. You can't go out soliciting donations and
simply say "thanks, your contribution is appreciated". You need to
show donors how their money are used, so that they can judge
whether they made the right choice in donating to you or not.
Whether they will donate again in the future or not granting long
term sustainability to your project usually depends on that.
So, if you have donated to Debian or are considering doing so in
the future, here are a few of places where you can check
what we have been doing with donated money:
- Minutes
of SPI monthly meetings, that come with monthly reports of incomes
and expenses of all affiliated projects
- the list of
sprints, past and forthcoming
- "Bits from the DPL" mails (indexed on the DPL "team" page), that often
come with a "money" section highligthing significant expenses for
the reporting period
- the DebConf reports,
that come with detailed "budgeting" sections of each DebConf
edition
Albeit quite detailed, the above is not enough: we should do
better on the transparency of Debian budget. For one thing, the
above is too scattered: budget transparency should not depend on
(potential) donors mixing and matching too many sources of
information. Further more, the above is not even complete: SPI is
not the only Debian trusted organization, and the accessibility of
information about Debian budgets hosted at other organizations
varies quite a bit.
We've been working on improving this for the past year or so:
we're not there yet, but I'm positive we can have detailed and
comprehensive budgets encompassing all Debian trusted
organizations published in the
coming months .
Why has it taken so long and what could possibly be so difficult
about it?
I think the cause of the delay is twofold:
-
The disperse nature of Debian adds some difficulties to regular
accounting challenges. Contrary to other FOSS projects I'm aware
of, we've many different trusted organizations, each one with its
own different way of reporting things. The advantage of
such a setup is that we can often avoid the costs of money
transfers around the world, costs in which we'd incur had we a
single organization holding our assets, say, in the US. Still,
having too many organizations is counterproductive. This
is why for the past 1.5 years I've been working on consolidating
our money assets into as few budgets as possible (avoiding, for
instance, to use more than one organization per currency).
-
We tend to be good at recruiting packaging geeks, but not so
good at recruiting other kinds of geeks: budget geeks, artwork
geeks, journalist geeks, management geeks, etc. But it is upon
those other kinds of "geekness" that many activities of "standard"
Debian geeks depend. For example: if you want to have a steady flow
of new project members, you need to communicate effectively Debian
values and make some buzz around them, so that you could hope they
get to the right ears. If you want to organize sprints for
maintainers to work together you need money donations, and to
solicit donations you need a transparent budget. Etc. In the
specific case of accounting, we're now lucky enough to have found
"standard" Debian geeks who also have a passion for accounting and
auditing; but that appaears to be, essentially, a coincidence. If
we don't fix the more general problem, I believe our difficulties
in recruiting "non-standard" Debian geeks might hurt us quite a bit
in the long run.
I ve just uploaded new version of sshfs package.
Here goes changelog:
sshfs-fuse (2.3-1) unstable; urgency=low
* New upstream version. (Closes: #636357)
...
[0] There is perfectly valid reason for doing that.
I might get back to that in a later post.
[1] One in unstable, testing, testing-proposed-updates and proposed-updates. The latter may seem a bit weird, but [0]
[2] This is the rule that prune relations like the one in the dpkg Breaks-field.
Edit: 2011-01/09, clarified that we have at most 4 versions per architecture.
Having designed the 3D model for a Pinard Horn (Foetoscope) last night, I 
Recently I've been wanting to replace my old point and shoot camera, a 
