DebConf 7 positions Debian for the future

At last week’s DebConf 7 Debian Conference in Edinburgh, Scotland, nearly 400 attendees had a chance to meet and socialise after years of working together online. They attended more than 100 talks and events, ranging from an update by the current and former Debian Project Leaders to a group trip to the Isle of Bute, off the opposite coast of the country.

Throughout the conference, socialising Debian developers could be heard discussing the finer points of programs they maintain and use and ways things could be improved. Sometimes a laptop would open and something would get fixed on the spot.

The conference itself was held at the Teviot Row House in Edinburgh, just a few minutes south of the downtown core of the historic city. The venue had several presentation and discussion rooms, and all rooms were equipped with video cameras for recording the proceedings.

The conference opened with a welcome from the organising team and an update from the former and current Debian Project Leaders (DPL).

Former DPL Anthony Towns of Australia opened with a recollection of his term as DPL. Towns noted that the first month of a DPL’s term is taken up with media interviews asking questions like “what’s it like to be DPL?” before he has the answers. After that, the DPL’s role is mainly dispute resolution and money allocation.

Towns introduced Sam Hocevar of France, the new DPL, who has been in the role only a couple of months. Hocevar got into what it is he wants to see for the future of Debian, saying that he would like to see a sexier more efficient distribution that integrates all the desktop components.

Debian’s quality assurance team should focus not only on license compliance, Hocevar continued, but on the quality of software. Every package, for example, should have proper man pages. And Debian should be aiming for faster release cycles.

On the topic of efficiency he referred to his DPL election platform. Don’t rely on Debian’s teams to do what you can do yourself, he asked. Citing Wikipedia’s policy, he said “be bold.” If something needs doing, just do it.

He also asked that each developer set up his work within Debian so that if he gets hit by a comet or gets married his work can go on. Even a relatively short period of inactivity when the goal is a faster release cycle can have a big impact, he warned.

Hocevar asked developers to take back some of Ubuntu and other distributions’ work. Don’t ignore their work just because you think Debian is better, he said.

We need better communication, he went on. Use debian-devel-announce mailing list for things you do. Put everything you do in a public place for future use and reference. Look at patches implemented in other distributions and use them where applicable, improving Debian and Free Software at large together.

In the Q&A session that followed, Hocevar noted that technical expertise in package maintenance should not be the primary requirement for becoming a Debian developer, citing translators as an import development role in which package maintenance itself is not the critical aspect.

Near the end of the lengthly Q&A session he was asked what he thought about governance reforms in Debian. Noting that he has not felt overwhelmed as the DPL, he indicated that he did not see a need for such things as a DPL team but reserved the right to change his mind in the future.

Evolving Debian’s Governance

The topic of governance, governing committees, and conformance with Debian’s constitution came up several times over the course of the conference. The next talk on the topic was by Andi Barth, entitled “Evolving Debian’s Governance.”

Barth started out by noting that while Debian’s constitution should be central, it is not, yet the system does actually work. Any improvements made then need to be done cautiously to ensure they actually improve things.

He summarised a bit how the governing structure of Debian currently works, describing Debian’s famous flame wars as a form of governance. General Resolutions — where all Debian Developers are invited to vote on a particular issue — are long and painful and not often used. There is a Technical Committee responsible for technical policy and technical decisions where two developers overlap. The DPL has the power to delegate power, and the Quality Assurance team has the power to forcefully upload packages.

So what improvements are needed, he asked. Does Debian need a DPL team? A Social Committee, which would itself become the topic of its own talk some days later in the conference, or perhaps a reform of the DPL delegates system?

In the discussion that ensued it was suggested that Debian should not fire developers over technical violations of the constitution where good work is still being done.

Another commenter stated unequivocally that the problem with Debian is that some infrastructure teams cannot be overridden. They are not elected or accountable and can make final decisions to which Barth responded that on the other hand the people doing their kind of work should not be arbitrarily overridden. The constitution exists for that reason, to not give the DPL the ability to fire people over the colour of their hair.

Sam Hocevar, the DPL, chimed in that there is no sense in risking the participation of important contributors to the Debian project at large by firing them from a specific role.

Another participant noted that when people are causing trouble only due to lack of time to contribute, they should be eased out and replaced rather than engaged in a flame war by others. It would be helpful, said the same commenter, if Debian experimented with telling people they have been “hit by a bus” to see how the project can cope without specific people.

The DPL noted that in person meetings tend to be beneficial and suggested that if Debian Developers need to get together to resolve something that they should contact him. Debian has the money should developers need to meet.

Still on the topic of governance, Andreas Tille hosted a discussion session during the conference entitled “Leading a Free Software project” in which he sought to answer three basic questions: What to lead? Who to lead? How to lead?

At the core, he asked, what is the motivation to work on Free Software? Getting something to work for yourself, he answered himself. There is no ready solution to work on a certain task, so you start coding. If you release the code as Free Software you can pick up some colleagues who have the same or similar needs, and then you start splitting the work and improving the code. Releasing Free Software, he said, is a clever thing to do. Releasing code is a way to make friends.

His example for Free Software project leadership is the Debian-Med distribution, a Debian-based distribution for the bio-medical community. He became leader, he said, by issuing an announcement of the project. If you want to avoid becoming a project leader, he cautioned, don’t be the one to announce the project.

If you take care of the infrastructure for the project like the Web page and the mailing list you are continuing on the path to becoming the project leader by default, he cautioned; you have done some work, so now you are the leader. If you try to do reasonable things to bring the project forward, people tend to draw you into a leadership position. He called this type of leadership a “Do-ocracy” — he who does, rules.

Who to lead? Free Software developers — individualists, he said. They just behave differently from normal computer users. They want to dive deeper into the project and not necessarily accept what others present. Developers, he warned, often refuse to accept leadership; just look at their T-shirts. They do, however, accept leadership from people they respect and who they would normally otherwise agree with. To that end, if you do not have a technical background, you will simply not be accepted as a Free Software leader, he warned.

On effecting decisions, Tille noted that you have no handle to force your developers. If you force people they will simply go away. There is no other motivation than working on their own project. If people are forced to do things they do not want to do, they will simply leave the project. The relationship is different from the employer-employee relationship.

There is also the risk of projects forking, he commented, which is not normally a good course of action. Differences between developers and the project leadership is generally the source of forks.

Tille’s talk finished with an extension discussion on how leaders may or may not have control over project developers. Tille summarised it nicely by saying, “You have to be clever to be a leader.”

A mission statement for the project and period reports, good communication, including in person or by telephone as needed, is important for the good functioning of a project, participants agreed.

Be nice to your people, Tille advised. Sometimes people in a position of leadership tend to become harsh toward others. If someone does a good job, say so. Positive reinforcement works. Don’t reject things out of hand and be an example to follow. It’s about taking a leading role, not about being a strong leader, he said.

Organizing events

Thursday, Alex “Tolimar” Schmehl hosted a discussion group entitled “Debian Events Howto,” with an eye toward helping Debian Developers organise booths at conferences when invited.

The problem, Schmehl said, is that Debian is invited to participate at conferences and trade shows around the world, and currently is not able to keep up with the demand. The organization declined at least 15 invitations last year due to a shortage of volunteers — an unfortunate situation, he said.

Schmehl said he learned how to organise a booth the hard way when organising one for LinuxWorld in Frankfurt some years ago. In spite of his lack of experience, he said, it went well. Organising a booth, he assured his discussion group’s participants, is easy.

Start by brainstorming about what is needed. The short list is, in order determined by the room: T-shirts and merchandising goods, name tags to help gain the trust of people coming to talk to the booth attendants, something to look at other than the volunteers themselves, such as a demonstration computer, and a code of conduct for participants that includes a reminder that they are not there to hack in the corner.

DVDs and CDs are, of course, critical. People come to the booth for Debian, after all. Burned DVDs or CDs are fine, Schmehl said, and can even be burned while people wait, giving them more of a chance to talk about Debian and learn more about it while they wait.

Critically, have a place for technical support at the location. People often show up with laptops or full desktop systems seeking help with Debian, and a place in the booth that is relatively out of the way to help these people is important, he advised.

Someone asked how you could expect volunteers to attend with a code of conduct. Schmehl pointed out that developers already contend with a code of conduct to make Debian packages. The same idea applies to volunteering in a booth. There need to be some minimum criteria for being a booth volunteer, he said.

Another person suggested charging a nominal fee for CDs so that they last beyond the first hour of the show. Schmehl suggested making CDs for a minimum donation of zero cents.

Posters and flyers are important and help visitors remember Debian, Schmehl noted. Participants suggested that there should be a set of slides running in a loop.

If at all possible, keep at least one Debian Developer around at the booth, even if they step away for a few minutes. Some people, Schmehl said, come in from far away to see the Debian booth specifically in order to get their GPG key signed and get into the Debian keyring. Finally, Schmehl said, keep pens and papers around to write notes out for visitors.

Schmehl posted three photos of booths from different conferences. The first showed a group of people crowded around a laptop with a scantily clad woman as the background and he asked the audience to spot the problems with this booth. Being a geek crowd, the first problem noted was not the background but the fact that the people were facing away from the conference aisle. Among other problems was the lack of posters or other identifying marks around the booth.

Among the things he warned about was ensuring that everyone present at the booth have the passwords needed to use any demonstration computers to avoid the embarrassment of a visitor coming to the booth and wanting a demonstration, but no one present being able to actually give them one.

It is important for there to be more than one attendee so that people are able to take breaks from booth duty. Taking care of the volunteers with snacks and breaks, Schmehl pointed out, is important, lest the volunteers become unpleasant or aggressive over the course of the day. Also, Schmehl suggested ensuring that the volunteers be dressed appropriately for the type of conference or trade show. A businessperson-oriented conference requires better dress than a developers’ conference, for example. Find a place to keep volunteers’ personal belongings out of sight. Figure out what people will want to know in advance, too, he advised. Check Schmehl’s event howto and the Debian booth information page for more information about booth FAQs and both information.

Critically, a member of the group concluded, if you accept an invitation, show up.

In times to come

DebConf 8 will take place in Argentina, and DebConf 9 will most likely be in the region of Extremadura, Spain, which is the only bidder for the 2009 conference to have put on a strong bid for the event.