Debian – Page 81

Open money and Debian

May 17, 2010 by Raphaël Hertzog

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

January 9, 2010 by Raphaël Hertzog

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

January 5, 2010 by Raphaël Hertzog

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!

New source formats allowed in testing/unstable

November 2, 2009 by Raphaël Hertzog

The ftpmasters merged my dak branch last week during their meeting and have enabled the support of new source formats “3.0 (quilt)” and “3.0 (native)” in testing, unstable and testing-proposed-updates. I have uploaded 3 packages using the new formats already: logidee-tools using “3.0 (native)”, quilt and ftplib using “3.0 (quilt)”. The latter is arch any and has been successfully built on all architectures even those that still use an old version of sbuild (it looks like the fears that the old version would not cope with the new format were unfounded). For logidee-tools I built it with “-Zbzip2” in order to use bzip2 compression on the native tarball.

I have updated the wiki page and the release goal page with latest information. Feel free to convert some of your packages to give it a try. For ftplib, it led me to discover a Debian specific patch that I completely missed when I took the package over. This is precisely the kind of benefit that I expect from generalizing this format, it will encourage us to have separate documented patches instead of keeping everything hidden inside the usual .diff.gz. Combined with DEP-3 (patch tagging guidelines), we have a better infrastructure to share our patches with the rest of the free software community.

The next step is to fix all bugs listed here and make dpkg-source use the new source formats by default (#553928). Feel free to help by preparing patches (and offering NMUs), it’s a release goal to have all packages buildable with new source formats.

Tags

Recent Posts