openSUSE readies for community contributions

In the past, only Novell employees could contribute code to Factory, the development version of openSUSE. However, this policy has started to change in the last few weeks, ever since openSUSE board member Henne Vogelsang announced sweeping changes to how Factory operates. These changes include a reorganization of Factory into specialized teams, and permitting community members to contribute code directly — a move that has the distribution rethinking its security measures as well.

The opening of the distribution to community contributions is only one of the changes to the distribution in recent years to make it more open (and, perhaps, to silence accusations that openSUSE is controlled entirely by Novell). These changes have included the appointment of a community manager, the transition to an elected board, and increasing access to the project through such features as openFATE, the feature-tracking service, and the openSUSE Build Service.

Joe "Zonker" Brockmeier, openSUSE community manager, explained that the changes were made "to continue enabling the contributor community outside of Novell and make it easier for people who are doing work on openSUSE to participate directly. We want to enable and encourage contributions from outside of Novell, and continue to make openSUSE a more independent project."

Similarly, Vogelsang said that most of the requirements for open contribution have been gradually coming into place over the last year or so, but "What we did not have was the possibility to take responsibility. That's why we changed our policies now so people can not only contribute but also take responsibility."

Vogelsang is referring to the division of Factory into working teams for patches and packaging. To a limited extent, this division already exists. Informally, teams for major areas such as GNOME, KDE, and Education already have their own web pages and ways of working, and exist semi-autonomously within openSUSE.

The difference now, as Vogelsang said in his initial announcement is that "What we want now is to use this model for every aspect of the distribution, not only the big parts where this comes naturally."

To this end, Vogelsang and the current package maintainers have developed a preliminary list of over 85 possible teams. These teams are listed as having responsibility for maintaining packages and reviewing contributions for as few as three or four packages, or for dozens, depending on the area that they cover.

In the announcement, Vogelsang wrote that, "As our goal is to make it possible for everybody to work on the distribution, we will simply allow the topic groups to organize themselves. We think that there is not the one and only way such a group of maintainers can work together, but it depends on the involved people and also on the topic . . . . So to transition we will throw together the people that are currently maintainers of packages and help them work out how to best collaborate with each other and [with] new people."

What is not immediately clear (at least, not without a lot of web searches) is which of the proposed teams are active and which are still largely hypothetical. But, for now, the distribution will be working with existing maintainers, and adding Novell employees to fill in where volunteers are lacking.

Policy vs. procedure

A particular area of concern is security, as Marcus Meissner pointed out. As Meissner explained, "Every single package can disturb / destroy the integrity of the whole openSUSE distribution (As in 'install trojans, rootkits, etc.')." Even if a package is not installed by default, Meissner warned, it could still be installed by the automatic resolution of dependencies.

Under these circumstances, Meissner stresses that the role of packagers needs to change along with openSUSE's policies. In particular, packagers will need to review all submissions with extreme caution, checking for malicious code and maintaining a workable set of project and package submission. They will need to decide how much they trust each contributor, and, at the same time, watch for email addresses that spoof those of trusted contributors, or cracked openSUSE accounts.

"Always keep such a thing in the back of your head and watch for behavioural changes", Meissner advised. "Trust your gut feeling and check twice if in doubt!"

Meissner's warning sparked a brief discussion on how the submission process could be made more secure. Karsten König suggested that the use of MD5 of SHA-1 hashes become mandatory in all submitted tarballs and within package scripts, so that reviewing the integrity of submissions would become easier. König also proposed that all hashes for packages be available on a web interface. Such changes in procedure would probably be resisted by some maintainers, but Vincent Untz wrote that they might be accepted more easily if they were made voluntary for one release cycle, then mandatory for the next.

Allowing community changes is a reversal of existing policy that can only add to the credibility of openSUSE as a free software project. However, as the security issue shows, changes in policy can require rethinking of procedures as well. While no final decision has been announced about how to handle the security issues created by the policy change, the need for some guidelines is inevitable. Nor are policies for acceptable structures or standards likely to be far behind, as other community distributions have discovered in the past. The devil, openSUSE is finding out, is not in the policies so much as in thrashing out the details.