Librement: a new way to help people who want to contribute to free software

Find your way in the free software worldI have this project in my head, I want to work on it but I always lack the time. In order to go forward, I thought I could write about it, at least it would let me clarify my ideas and the core goals. So here I am, I will present you Librement (I have registered the alioth project but it’s empty).

The core goal is to make it easy for every user to contribute to free software in some way. I will now present the main features that I envision.

Defining skills and interests

In order to propose tasks that the user can do, we must have an idea of his skills. So on the first run (and later through a preferences menu) the user will be invited to define his skills:

  • his native languages (multiple allowed)
  • other languages he can understand
  • programming languages he knows
  • version control systems he can use
  • markup language he knows (HTML, DocBook, Wiki-like formats, etc.)
  • etc.

Maybe we can also ask which skills he would like to learn. Because contributing to free software is a nice opportunity to learn new skills!

We should also find out what the user is interested in. What are his favorite free software projects? What kind of contributions would he like to do (documentation, translation, coding, bug fixing, bug triaging, creating artwork, donations, etc.)?

Choose activities and pick concrete tasks

Based on the user’s skills and his interests, the software shows a list of possible activities. The user can then sort that list, from the most interesting one to those that he doesn’t want to do.

Each activity can generate concrete tasks. For example, the activity “Do translation for Debian” could generate a task “Translate strings in debconf/fr.po” or “Review translations in partman/fr.po”.

Work on tasks

When the user decides to work on a task, a step-by-step assistant helps him/her. It can automate some steps and provide explanations for the remaining ones, for example in the case of a translation for Debian:

  • grab the PO file (from a VCS, from an HTTP URL, from a translation server, etc.);
  • select and install a software to work with PO file (if not already done);
  • edit the PO file with the preferred program;
  • check the PO file (is it complete? is there no mistakes like missing substitutions?);
  • send back the completed PO file in a mail to the Debian bugtracking system.

If the tasks is not completed in one go, the user can resume it the next time.

Each free software project must provide some meta-information describing the various workflows involved for contributing to the different parts of the project. If necessary the project can also provide new plugins to support new operations that are not available in the default library.

Setting goals

In order to keep the user motivated, the software could track how much time he spent contributing to free software and it could verify if the user reached the goals he picked up for himself. Maybe it can also hook into the OMG Trophy Awarding System.

The sky is the limit

I hope that you now have a clearer idea of what this desktop application is supposed to be. There are literally hundreds of ways to contribute to free software and I like the idea that we can streamline the process for most users.

All the plugins implementing activities can use local information (list of packages installed with their versions, configuration settings, etc.) to propose tasks targetted to the user and highly beneficial for the corresponding free software projects. For example, a bug tagged unreproducible might benefit from a few more users trying to reproduce it. The software could direct the user to this bug report if it detects that he/she runs the same version on the same architecture and that this software is regularly run on the system.

Many projects have created “operations” or “events” to encourage people to contribute, they could all be implemented as dedicated activities in Librement. I’m thinking of stuff like Gnome Love, Ubuntu’s 5-a-day, Ubuntu’s 100 papercuts, etc.

Even for people who have no time to contribute, the application can still be useful by referencing the various ways to donate money (or material) to projects that they are using.

Feedback welcome

I’m excited by the potential of such an application, but it’s normal since it’s my idea. Do you believe it can be useful and popular? Do you have ideas of exciting activities that such a framework can offer?

PS: If you wonder how I came up with the name “Librement”, here’s the explanation. It’s a French word which means “freely”. And users who want to give back are trying to live up to the principles of free software, which I sum up by “they are trying to live freely”.

Follow me on Identi.ca, Twitter and Facebook. Or subscribe to this blog by RSS or by email.

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.

Interdependence in Debian, how to suffer less from it

Listening to Martin Krafft’s talk at Debconf (related to his PhD) shed some new light on the idea that I expressed last year — I wanted that each maintainer regularly answers a questionnaire so that he has to ask himself whether he does a good enough job with his packages.

When thinking of this idea, I only saw the QA side of ensuring good maintenance on all packages, however I believe that the root problem lies further and this project would not be enough: we are interdependent but we are not equipped to deal with this reality. Martin’s only merit has been to mention that we are interdependent, but it’s worth analyzing a bit.

Our organization is centered around individuals acting as package maintainers, and in theory each package maintainer can work on his corner and all goes well. We know that this model doesn’t hold any more: transitions to testing require coordination of uploads and timely fixes of RC bugs, keeping up with the work frequently requires several volunteers that have to coordinate, etc. More and more of the work requires a level of availability that a single individual can’t offer, yet in our day-to-day work we mainly interact with individuals. Wouldn’t it be better if we could immediately know what we can expect from any Debian developer:

  • mean time to reply to Debian mail (reading every day or once a week is not the same);
  • amount/periods of time spent on Debian (knowing that they spend up to 4 hours mainly on Saturday can be useful);
  • current availability for Debian (if they are currently busy with life, we should be able to know it, if they know when it will end, it would also be good to share);
  • best way to get in touch for issues (they might have preference between IRC or mail);
  • kind of relationship they have with packages where they are listed in Maintainer/Uploaders (an active maintainer that uses the software daily is not the same than a passive maintainer that only packaged the software because it was a build-dependency for some other software that they care about);
  • any other information that the maintainer wants to share (about his habits/constraints/values/goals/whatever).

All this information should be shared by all Debian maintainers (some of it is already available but either not publicly or not in any machine-parseable way) and we should actively use it. Here are some examples of use: for each RC bug report, you could look up if at least one maintainer is available and you could ping him explicitly if needed. When you plan an NMU, you could look up if the maintainer is likely to respond in the next day or not, and possibly adjust the number of days spent in the DELAYED queue. When organizing a large-scale transition, you could extract a list of packages whose maintainers are not available and arrange immediate NMUs.

Furthermore there are many cases where the project’s usual expectation exceed what the maintainer is ready to do. Documenting what part of the job is done (or not) by the maintainer makes it clear for volunteers whether their help is needed and whether they could/would be a better maintainer for a given package.

Designing solutions to all these problems is going to be the scope of the DEP2 that I reserved some time ago. It’s likely to be some sort of dedicated web interface. I would welcome supplementary drivers for this DEP, so if you’re interested, get in touch with me.

Debian membership reform

Following Ganneff’s post to debian-devel-announce, several discussions have again started on the topic of Debian’s membership and several proposals have been made. Unfortunately none of these proposals try to resolve the underlying trust problem that has been growing over the years. Despite the NM process (or maybe due to it), we managed to give DD status to people who are motivated but whose technical skills are doubtful (at that point people ask for an example, and as much as I hate fingerpointing, here’s an example with #499201. The same maintainer created troubles with libpng during the etch release cycle and tried to take over a base package like mawk recently).

With our current model, all DD can sponsor, NMU, introduce/adopt/hijack packages without review. This is fine as long as we trust the body of DD to contain only skilled and reasonable people. I believe that premise to be somewhat broken since Debian has become too big for people to know everybody and since the NM process had no way to grant partial rights to volunteers who were motivated but that clearly had not shown their ability to handle more complex stuff than what they had packaged during their NM period (like some trivial perl modules for example).

Thus I strongly believe that any membership reform must provide a convincing answer to that trust problem before being implemented. I took several hours to draft a proposal last Friday and I’ve been somewhat disappointed that nobody commented on it. I hope to draw some attention on it with this blog post.

The proposal builds on the idea that we should not have “classes” of contributors but simply two: a short-term contributor and a long-term contributor (those are called Debian Developers and have the right to vote). But all contributors can be granted “privileges” as they need them for their work and each privilege requires the contributor to fulfill some conditions. The set of privileges and the conditions associated all need discussions (but I have personal opinions here, see below). There’s however one privilege that is somewhat particular: it’s the right to grant privileges to other contributors. Handling it as a privilege like another is on purpose: it makes it clear that anyone can try to get that privilege and the procedure is clear. In practice, imagine that set of people as a big team encompassing the responsibilities split over DAM/AM/FD/DM-team and where all members can do all the steps required to grant/retire a privilege provided that 2 or 3 members agrees and that nobody opposes (in case of opposition a specific procedure is probably needed). I called that set of people the Debian Community Managers. It should contain only skilled and dedicated developers.

One of their main duties would be to retain the trust that the project as a whole must have in all its members. They would have the powers to retire privileges if they discover someone that has not acted according to the (high) expectations of the project.

Among the privileges would be “limited upload rights” (like DM have currently), “full upload rights” (like DD have currently although it might be that we want to split that privilege further in right to sponsor, right to package new software, right to maintain a package of priority > standard, etc.) and “developer status” (email + right to vote, once you can prove 6 months of contribution).

There’s lots of stuff to discuss in such a proposal (like how to decide who gets what privileges among existing DD) but I think it’s a good basis and need some serious consideration by all the project members. The NM process is there only so that we can collectively trust that new members are as good as we expect them to be and trust can only be built over time so it’s good that we can grant privileges progressively.

Some people believe that I’m reinventing a new NM process that will end up to be very similar to the current one. My answer is that the conditions associated to each privilege should be based on the work done by the contributor and the advocations that he managed to collect. It should not be a questionnaire like “Task and Skills”. This, together with the distribution of the power/work on many people, would render this system very different from today’s NM process.

Some people believe that I’m copying Ubuntu when designing this since it’s somewhat similar to the process to become MOTU and/or get upload right to Ubuntu’s main component. Let me say that I’m not copying deliberately at least, I simply took the problem from the most important side. But remember that many aspects of Ubuntu have been designed by Debian developers that tried to avoid known pitfalls of Debian, and maybe they got some things right (or better at least) while doing this.

Planet Debian for users ?

A few days ago I created a planet for French Debian users, and the interest is slowly growing. In fact, I just received a request to add an English-speaking blog!

So the question is: why not creating (and hosting) an English-speaking planet for Debian users that would allow only Debian-related articles. Developers are also users and if they have a feed dedicated to their Debian posts, they could add it of course. It would be handled like the current planet and a few volunteers could collect and process the requests to add new feeds for non-developers.

This would provide the much-requested alternative of filtering planet Debian… and also encourage some of our users to blog about Debian and how they use it.

What do you think of this idea?

Revisiting the DPL team concept

I have not been very much involved in this year DPL campaigning, but I’m part of two DPL teams, thus I feel the need to give my point of view on the subject.

I’m not really satisfied by how the current DPL team worked out, and being on the DPL candidate team of both Jeroen and Andreas gave me the opportunity to gather information on what really happened. Also I’ve met Bdale yesterday and he gave me his opinion as well (and I really enjoyed that dinner. Thanks bdale!).

Just for the record, I’ll try to sum up what really happened: Branden had agreed to be a participant of the DPL team concept, but wasn’t a major proponent of the idea. This, combined with his personal problems, explains why he didn’t make use of the full potential of a DPL team.

Does it invalidate the DPL team concept? No, I don’t think so because the concept will evolve this year. Let’s see how it can change.

Both DPL teams would this year receive all the mails sent to leader@debian.org. This means that the members are involved from the beginning and not only on request of the leader, which means that they can pro-actively take over if they see that the DPL doesn’t manage to follow up up to its expectations (which hopefully won’t be needed this year). Furthermore I expect that the team would be informed of what the DPL does, so that the team can give its opinion on everything done, and prevent big errors (nobody is perfect, errors do happen).

But the most important thing is that the team should not stand behind the DPL, but next to him taking initiatives, and I expect the DPL to work with the team members for the best of Debian. As such I expect the DPL to accept most of the proposals of his team if there’s a consensus on it, even if he doesn’t personnaly think that’s it’s a priority for his DPL mandate.

If I am part of an elected DPL team, I will work on that basis. I do have many ideas to try, and will make proposals. I ran once for the DPL election, and if you check my platform, you can see that I always had ideas for Debian and you can see that I worked on several of them which are nowadays very common (such as the PTS, alioth, collaborative maintenance). I won’t miss an opportunity to get the project moving forward.

How to handle unmaintained packages with few users

Last week I had an interesting discussion with Benjamin Bayart about unmaintained packages which have very few users. Once the initial maintainer disappear, we usually don’t find another one having both Debian skills and a good knowledge of the package. So the software just stay there until it becomes so outdated that it doesn’t work anymore… and then it gets removed blindly. Most of those packages have a low “popcon” rating so they get removed without care.

Read the whole problematic described by Benjamin, and then see my initial mail with a suggestion on how to do better in that area.

The discussion has seen interesting developments even if there’s no consensus (yet). But it’s an important topic concerning QA, so I hope that something useful will come out of it… I’d like to have more time to implement something but I’m already overloaded… I really should have proposed projects for Google’s summer of code. :-)

Keeping mailing lists sane with social pressure

Today I was reading my backlog of debian-devel and noticed the big thread about the trademark issue with Firefox. It was a pain to read it because as usual some people got so involved that they felt the need to reply to all mails rehashing again and again the same point.

This is not acceptable for a civilized project like Debian. So I complained by private mail to the person who misbehaved according to my own criteria. This time it was “Humberto Massa Guimarães”. I have been polite and expressed clearly what was not acceptable in his behaviour:

  • he has posted 20 times the same argument
  • he’s no more expressing his point of view but trying to impose it to other by repeating it over and over

I didn’t mention the fact that I disagree with his point of view because I’m not complaining about his opinions, only about his way of behaving on the lists.

Do you want to know the result ? Humberto replied to me :

Your point was taken and I will try to behave better.

What does it mean ? That social pressure works … and that all other readers of debian-devel should do the same. When someone clearly goes too far, we should politely invite him by private mail to calm down. When someone receives 10 similar requests I’m sure he will quickly understand that his behaviour is not well accepted.

Going further in that direction we could have a system where all those complaints can be publicly archived. We would CC or BCC complaints@debian.org and the system would generate statistics : who has been the biggest cause of complaints and so on. :-)
(This last paragraph is only semi-serious)