The Linux kernel development and support system is not as perfect as we would like. Why not improve the current system, using as an experiment the successful experience of other projects? This proposal was made by the developer Daniel Vetter (Daniel Vetter). He prepared a report on this topic for the LCA 2017 conference ( slides ), and also published a more detailed text on the blog.

Daniel Vetter has been working with Intel drm / i915 graphics driver for the past few years, he works at the Intel Open Source Technology Center. The drm / i915 driver is supported by two maintainers, and about 19 developers have the right to commit patches to the main branch right away. "This is a completely normal situation for the open source community, but a completely unthinkable thing for the Linux kernel," says Daniel. He believes that such an organization of work on the driver has quite successfully manifested itself and it can be used in other places. For example, in the Linux kernel, where the maintainers now have too much load.

Here are the main points of the report.
')

The cult of employment and burnout

Vetter writes that when discussing the topic of the maintainers, the topic of permanent employment and lack of time is always raised first. In the west, this is a real cult - the developer must be overloaded with work, work overtime, he must always be busy, in which case he is considered a hero. If you have free time, you are some kind of a slacker and, probably, you take time off from work.

The cult of employment leads to burnout - an increasing emotional exhaustion, which can lead to personal changes in the field of communication with people (up to the development of deep cognitive distortions). According to the clinic , emotional burnout is manifested by increasing indifference to their duties and what is happening at work, dehumanization in the form of negativity towards their colleagues and users, as well as negative self-perception in professional terms, dissatisfaction with their work.

In other words, with emotional exhaustion, developers quarrel with each other, and also feel as if they lack professional skills.

Emotional burnout often begins when the person’s pay is not high enough and / or the psychological encouragement of his work is not high enough. In this case, there is a feeling that his work has no value. Sometimes hard work in the period of emotional burnout is accompanied by alcohol abuse.

Daniel Wetter believes that emotional burnout is the main threat to a developer who works in an open source project: “Personally, I went through several difficult steps before I realized my limits and began to comply with them,” he writes. The cult of employment and burnout of the maintainers is understandable. You start working with two or three developers, and after a few years their number increases to several dozen. Naturally, there is not enough time for everything. Jacob Kaplan-Moss , one of the main developers of Django, who is also a former Maintainer, spoke well about this process and his own burnout.

Every year at the kernel development conference a topic is discussed whether Linus is happy .

The problem of burnout in no case can not be ignored, so you should clearly make sure not to work too much.

Linux kernel maintainers

According to the author, the current Linux kernel maintainers work too much, and this is an unhealthy situation. Approximately 80% of all patches are maintained by maintainers on behalf of other authors. Typically, changes are dropped to the mailing list, they are discussed here, and then the maintainer adds the patch to his git thread. Then each maintainer sends a request to incorporate the changes made, often directly to Linus. For some large subsystems (network stack, graphics, ARM-SoC) there is a second or third level of maintainers. Only 20% of patches in the kernel come directly from the authors.

Most of the maintainers are really heavily loaded with work. One person looks after several kernel areas with corresponding different git branches and repositories.

Daniel Vetter says that in their project drm / i915 about a year ago they introduced a radically different system, when all developers were given equal rights to add patches to the drm-intel repository. Now 19 people have such rights. According to the results of the first year of work, the experiment looks quite successful. Now about 70% of commits to the repository come directly from the authors.

The author also refers to the experience of the Rust community (a report from last year’s LCA conference), in which such a system works very well.

Daniel Vetter worked for many years on the traditional model with mainteners, now he has gained new experience and says with confidence that the current model of the Linux kernel meiner simply does not scale. This is not about the fact that the hierarchical model is technically incapable of increasing the number of developers. Not at all. This git model has proven its success. We are talking about the efficiency with which patches are reviewed and entered into the core. Here this efficiency decreases.

In the community, it is customary that a maintainer is appointed almost for life. He pulls this strap at the expense of social and personal life. The Linux kernel developer community does not provide a formal social management structure that comes into play when the project is scaled up.

“If the goal of the project is world domination or at least the creation of something long-term, then it is better to have a reliable organization that copes with the work force,” Vetter writes. Instead, the maintainers generate new levels of hierarchy, which only exacerbate the situation. So, in the graphics subsystem for a simple driver, patches in five different branches are sometimes required. The probability is almost 100% that at least one of the maintainers will not be immediately available, and the process will take a long time.

Another problem is that under the current hierarchical system, most of the maintainers themselves do not consider and analyze most of the patches of the maintainers themselves. It already looks like a dictatorship. A “flat” system with equal rights is free from such a flaw.

Not surprisingly, even in the Debian community, the transition to a model without maintenders is now being discussed.

Instead of the current hierarchical structure, Daniel Vetter proposes to consider something like a mesh network where developers have equal rights to commits. He believes that the maintainers who complain about the lack of time and at the same time say that they can not trust anyone, in fact, poorly doing their job.

You need to trust people more, but be ready to do git revert . Maintainer must remember that he serves developers, and they do not serve him.