About the Debian Community Poll

While I find the idea interesting, several of the questions can’t be correctly answered because the proposed choices are not realistic or too limited.

On the question of the usage of money, I believe we should spend money to fund important projects but I don’t want to fund “people having important positions in Debian and doing important work”. What should I reply? (Granted, there’s the other item but that doesn’t help getting a clear picture of the answers)

On the question “Do you prefer time based releases instead of the «it’s ready when it’s ready» releases?”, it is putting two concepts in opposition when the release managers recently proposed a third way that combines both: “time based freezes and release when it’s ready”. This is what I want and I can’t adequately express it either in the current poll.

Open money and Debian

I recently read an introductory article in an IT magazine on the increased usage of new currencies. It briefly mentioned the work of a researcher called Arthur Brock in using those currencies within open source communities. While I did not find more details on the research, it led me to think again about Debian’s relation with money.

The reason why we have troubles using money to pay the time spent by our developers is that money is scarce and it’s thus next to impossible to be fair in the way money is spent among us. So why not invent a new currency that is not scarce and that would encourage the kind of work that we really value? Apparently there is free software out there to build new currencies: see metacurrency.org or openmoney.org. Let’s call the new currency “swirly/swirlies” for the sake of the examples below.

There are then multiple ways to create a small economy within the community and/or even create bridges with the national currencies:

  • we could have auctions (priced in swirlies) to redistribute goods among us (say I have this unused laptop and I want to give it away to someone who could make use of it within Debian)
  • Debian sponsors/partners could offer discounts codes on their products and Debian would exchange them against the Debian-specific currency (inspired by community way);
  • swirlies could be used to get funding to attend debconf and/or other meetings;
  • we could donate our swirlies as bounties on important projects that we want to see implemented, we could even grant swirlies to release managers to help them drive the project towards a release (they would not end up in their accounts but they could use them to motivate people to work on release blockers);

I’m sure we can come up with many similar ideas. Feel free to share yours in the comments.

Debian related goals for 2010

Here’s stuff that I’d like to do this year, more or less by decreasing order of importance:

  • translate my Debian book into English and get it published;
  • finish the cleanup of the perl API in dpkg-dev in order to create libdpkg-perl;
  • create dpkg-buildflags to export default build flags that packages should use (and get rid of the code setting those environment variables in dpkg-buildpackage), needed to properly fix #489771;
  • ensure the new source formats continue to gain acceptance by improving whatever is needed;
  • design a generic vcs-buildpackage infrastructure to be integrated in dpkg-dev. This design will probably happen through a DEP (Debian Enhancement Proposal) to ensure we have had proper discussion before someone gets to the implementation;
  • continue fixing dpkg bugs faster than they are reported;
  • enhance our infrastructure to ease interaction between contributors and to have a better view of how each package is maintained (see my last blog entry on this topic);
  • update the developers-reference where needed and fix some of the numerous wishlist bugs;
  • rewrite in C the last perl scripts provided by the dpkg binary package (update-alternatives/mksplit mainly, for dpkg-divert there’s a preliminary patch available already) so that it’s easier to build a minimal system without perl-base;
  • integrate the 3-way merge tool for Debian changelogs in dpkg-dev;

All of this probably doesn’t fit in my free time (being a father since last month does not help increasing my free time :-)), so if you’re interested in seeing one or more of those projects completed, and if you know some person/company that could sponsor them, get in touch with me!

5 years of Freexian

5 years ago I founded my own company Freexian SARL with the goal to make a living out of my free software experience. I marketed the company as being specialized on the Debian distribution in the hope to combine my Debian work and my professional work.

Given that Freexian is still alive I think I met the first goal. My free software experience allowed me to complete many projects: a large number of development projects for embedded devices running a custom Linux distribution (usually built with debian udebs), the development of a Debian derivative (SLIS) and some recurring tasks of remote system administration.

However, even if I use Debian daily for all my work, very few of the projects that I complete for customers have direct results in terms of improvements for Debian (except some bugreports and some related fixes). And even when I’m able to contribute something back to Debian, it’s usually not in areas that I care about.

My focus within Debian is on the technical and organizational infrastructure of the project: as a dpkg/dpkg-dev maintainer I try to improve the packaging infrastructure, as a QA member I maintain the Package Tracking System to ease collaboration, as an Alioth admin I ensure all DD can host VCS repositories for their Debian related projects, as a developers-reference co-maintainer I try to share good packaging practices, etc. Given this bias, it’s difficult to find customer projects that would let me contribute in those areas. Thus I think I need to try another approach: the simplest solution would be to find sponsors for some of my own Debian-related projects (if you have something else to suggest, please leave a comment — either in the blog or by mail).

That said finding sponsors looks like a difficult task in itself. While I can imagine (for example) a company using Debian on embedded devices that would like to sponsor the rewrite of update-alternatives in C in order to get rid of the perl dependency in the dpkg package (if you know such a company, get in touch with me!), I don’t see who would have an interest in sponsoring the time that I need to contribute new sections to the developers-reference manual. But who knows… maybe I should just try and publicly solicit sponsorship for some of the projects that I care about. In any case, suggestions and comments are welcome!