Author: lola Planned by: h4cd
In 1996, Bruce Perens took over the baton from Debian founder Ian Murdock and became the second head of the Debian community in history. In the same year, Joey Hess, who was under 20 years old, became a member of Debian in order to satisfy his hobby of packaging games.
One day, in the sunshine in California, somewhere in the San Francisco Bay Area (where Silicon Valley is located), Bruce Perens knocked on the door of Joey, a young man who had just come to work here.
“I’m going to take you on a tour of the Bay Area. ”
They drive around the Bay Area casually and chat as they pass by major tech companies. This ride was Joey's first time with the community, which opened Joey's door to this new world, and the visit of Bruce Perens, a big man, also made Joey feel very incredible.
Young Joey Hess in a Debian t-shirt
It is a pity that in December 1997, Bruce Perens stepped down from the position of Debian, and founded OSI (Open Source Initiative) together with another famous person Eric Raymond, and became the pioneer of open source.
At the time, there were some controversial voices in the Debian community that Bruce Perens was a dictator who had everything in his hands. Therefore, after Bruce Perens left, Debian began to develop the Debian Constitution (Debian Constitution) to restrict the power of leaders.
In 2014, Joey left Debian, which he had contributed to for 18 years, after a protracted and heated quarrel within Debian over whether to adopt the init process of systemd.
If I have one regret for my 18 years in Debian, it's that when the Debian constitution was originally proposed, despite seeming dubious, I had neglected to speak out. It's clear to me now that it's a toxic document that has slowly but surely led Debian in very unhealthy directions.
If there's one regret in my 18 years at Debian, it's that when the Debian charter was first formulated, I didn't speak up, despite feeling inappropriate. I am well aware that this poisonous charter is slowly but surely leading Debian to a pathological state.
In an interview in November 2021 , Joey bluntly stated that "the Debian charter is poisonous" . Joey is nervous within the framework of the Debian charters, which are delaying all decisions.
Also in 2014, also because of this protracted syetemd debate, Debian technical committee members Colin Watson and Russ Allbery announced their resignations on the Debian mailing list . In Russ Allbery's resignation letter , he mentioned Joey:
Finally, I've been thinking hard about Debian project governance in the light of Joey's resignation, as I'm sure many of us have been.
Joey's departure made me wonder what went wrong with Debian management, and I'm sure many of us did too.
At the time, Russ had been on the Debian technical committee for six years, but he couldn't survive the 2014 debate. He said that the committee was under enormous pressure for almost every decision, and he felt that he had no energy to deal with these things, and he also felt that his work on the technical committee was not helpful for the whole project.
In 2019, Debian developer Michael Stapelberg left a long article when he left Debian , which detailed various problems within Debian, which caused heated discussions.
A few weeks before writing this article, Michael met some old friends he hadn't seen in years at the Zurich Debian meetup, and in this conversation, they touched on a topic - Debian's democracy and their work in theory and practice on the failure .
As one of the oldest Linux distributions, the Debian system occupies almost half of the Linux system family; as a veteran open source community, Debian has been running for nearly 30 years and is still incense; however, as a society that coordinates the collaboration of hundreds of developers Organization, why did Debian let these people down?
01 Unpopular DPL
After Bruce Perens left, the term DPL (Debian Project Leader) was defined by the Debian Charter . The DPL is elected by the Debian community and is held once a year. Every spring, a Debian developer successfully runs to receive the "crown" of the organization.
In the spring of 2019, this election for Debian was "bye" . On March 11, an open letter titled " Leaderless Debian " appeared on the Debian mailing list. The article stated that March 3-10 of this year was the nomination stage for candidates. Eligible Debian developers submit applications.
The previous Debian leader, Chris Lamb, has been highly expected. He has been re-elected for two years, but this year he has publicly stated that he will not run for some Debian-related and some personal reasons . As a result, Debian has to extend the nomination period according to the bylaws until someone submits an application.
Of course, in the end, someone jumped out and ran for election. It should be pointed out here that this embarrassing incident very intuitively reflects the fact that DPL is not popular .
To be precise, under the constraints of the Debian charter, the DPL is a virtual seat without absolute rights.
First, the DPL is not in touch with a specific business, he can appoint someone to perform a dedicated task, and these representatives have the power to make what they think is the best decision taking into account technical standards and consensus.
As for the project level of the Debian community, the DPL has no right to intervene. The developers of each project have 100% decision-making power over the project. For example, individual developers have almost complete control over the packages they maintain; technical disagreements between developers are dealt with by the project's technical committee when there are significant technical differences; release managers and FTP masters have the final say on what the project actually releases, and When will it be released; the project secretary is responsible for ensuring that the necessary procedures are followed; the policy team handles most of the overall design of the project.
Secondly, DPL can be changed at any time, because there is a channel such as General Resolution, developers can re-elect another DPL, revoke DPL or representative decisions, modify basic documents and make other binding decisions Decide. (As shown below)
So, what exactly does DPL do? It is mainly divided into two aspects:
In its external function, the DPL represents the Debian Project by giving presentations and presentations about Debian, attending trade shows, building good relationships with other organizations and companies, and dealing with legal issues. That is, he is an image representative and official spokesperson .
Internally, the DPL should talk to other Debian developers, especially representatives, to see how they can assist the developers in their work. Then there are the financial matters of approving the budget. That is, some administrative matters.
In most companies or organizations, external branding and administration are not core business departments and are very marginal. These functions often face the dilemma of no sense of value and tedious chores. At the same time, DPL spends a lot of time and energy without any salary in return.
It is not difficult to understand why some DPLs are unwilling to be re-elected. For example, Sam Hartman, who took over in the bye event in 2019, said in the 2020 campaign season that he would no longer run .
02 The "common will" of developers
So, who is the authority in Debian?
There are only two official roles in the Debian community : Debian Developer (DD) and Debian Maintainer (DM). DD is defined by the Debian Charter , and the Debian maintainers only did it in the 2007 General Resolution.
Among them, DM is a role that does not have many permissions, they can only for those packages that contain their name in the Maintainer or Uploaders field, and have been specified by DD with the DM-Upload-Allowed: yes flag (meaning allowing DM to upload) They have no other rights beyond that to perform uploads, and they have very limited access to Debian resources.
As defined by the Debian Charter, the main function of a Debian Developer (DD) is to submit code and maintain packages for which they are responsible. They have access to the Debian server and can participate in community votes (such as annual elections, etc.).
On the one hand, DDs are in complete control of their work and can make any technical and non-technical decisions with almost no restrictions. That is, there is no leadership in the Debian community.
On the other hand, these DDs with voting rights have become the main body of power in the Debian community through the General Resolution process. They can appoint or remove the DPL; they can overturn any decision made by the DPL or its representatives if they are unhappy; they can change the Debian Bylaws by a 3:1 majority; they can dispose of Debian's trust property, and so on.
In addition to this, in order to ensure that all developer voices are respected, the Debian Bylaws go out of their way to make " None Of The Above " (none of the above) the default option. That is to say, when you feel that you do not want to vote for any of the above options, you can open a separate column, write your options, and participate in the voting.
At the same time, Debian adopts the Condorcet method (aka Condorcet standard) for voting, which requires a "two-by-two" to choose the party that wins the majority of the votes, rather than voting among many candidates at once, Then pick the one with the most votes.
In general, it is a politically correct thing to give individual developers the greatest degree of authority to seek the "common will" of the group to the greatest extent. But does the greatest degree of "consent" really exist? Joey Hess said it doesn't exist and there will always be people unhappy.
In addition, while Debian maximizes individual freedom, it also makes individuals appear full of individuality and difficult to compromise; once there is no strong cohesive force to bring them together, there will be a "split" situation.
"If someone insists on refusing to cooperate, it's very easy for your changes to be delayed. I'll give a typical example: rsync, whose maintainer refuses to use debhelper for my patch package purely out of personal preference. Granted The great freedom of the individual maintainer prevents us from working on projects that raise the level of abstraction for building Debian packages, which in turn makes the tooling more difficult." Michael Stapelberg discusses too much personal freedom in Debian in his own article.
"I think there's a big problem with the governance of the Debian community -- the community is deeply divided into many different camps by certain issues," Russ Allbery once said.
Perhaps, this has also made Debian today's "children and grandchildren" - a lot of software is derived from Debian. Take the systemd incident in 2014, for example, where the controversy led to a split in the Debian camp - opponents created a fork called Devuan that didn't use systemd . In addition, there are many derivatives based on Debian, such as Ubuntu, Deepin, Kali Linux, MX Linux, etc.
03 Technology in power, lack of management
In addition to the "extraordinary" individual freedom, Debian also has a "technical inclination" in its bones.
At the beginning, Ian Murdock, the founder of Debian, started to make a new version of Linux because he was very dissatisfied with SLS (Softlanding Linux System, known as the oldest Linux distribution), so he improved SLS, and as a result, he improved too many things. Enough to release a new version.
The starting point is very geeky - use technology to create what you want. So, while there's a lot of squabbling within Debian over systemd, most of the debate revolves around the technology itself.
Genetically, the Debian community is basically a space for technology construction , and the moral contract about technology is the core force that unites Debian, and this also makes the internal balance of Debian very difficult. This overwhelmed the Debian Technical Committee.
The Debian Charter states that the Technical Committee (TC) is the authority to decide all technical matters, including any matters that developers are uncertain about going to the Technical Committee. For example: disputes between developers about the ownership of directive names, disagreements between conflicting packages, which package should be responsible for existing bugs, etc.
At the same time, the technical committee also needs to make a formal statement on controversial matters within the community. For example, in the systemd battle in 2014, the Debian technical committee stood up and said: accept systemd (but there are still many people who do not buy it).
In addition, the Debian charter also writes such an item in the responsibilities of the technical committee: Make a decision when asked to do so The technical committee seeks advice.
In Russ Allbery's 2014 resignation letter, he said a lot of "tired and unloved" things:
Technical committee work and related topics have become the vast majority of my work at Debian. It's not fun. I underestimate the emotion and attention that this job requires, which is worse than the time investment.
Almost every decision of the technical committee is full of unpleasantness. Under the existing framework, every decision made by the technical committee requires more skills, care, attention and carefulness, which makes me psychologically stressed.
At the same time, he also believes that management is necessary, and he believes that more management is needed in the mechanism of a large group, so that the organization will not be paralyzed by differences.
The main problem with Debian now is the lack of management . At the beginning, the Debian developers evaded the role of DPL to the greatest extent through the charter, but the need for management was still there, so the technical committee had to play a certain management role.
Thus, the uneven division of functional roles, combined with the excessive freedom of individual roles, has turned the Debian Bylaws into what Joey calls a "toxic document."
I think some things in agile philosophy are right: find ways to reduce the cost of change, to empower some individual decision-making rights, to act, instead of being afraid of failure in advance and timid. Lately, I've been increasingly skeptical that Debian's current decision-making mechanisms (especially technical committees) are really appropriate.
A few years after typing these words, Russ Allbery is once again a member of the Debian Technical Committee. This time, instead of sitting still, he presented a draft of fundamental reforms. For details, please click: " Debian to the left: or will usher in a fundamental reform "