DPL Campaign Questions 005
Do you see the diminishing care for our Core infrastructure as a problem? Do you have any idea how do sensibilize our new blood for the fact that "new packages" doesn't help Debian if our Core stuff is diminishing? I know that this is not exactly within the power of the DPL, but do you think that you, as DPL, can help speeding up Core development again?
Note: "core infrastructure" here refers to dpkg and apt.
I am seeing numerous projects across the free software world struggle with a lack of contributors, and wonder why they cannot get anyone to help them. In most cases, I think there are hints about why people might feel disenfranchised by a particular development process, and in most cases, I think the people in charge are mostly unwilling to change the way that they have been doing things for years and years just to accommodate potential contributors. I think this is particularly true of projects where there is a dictatorship or a single gatekeeper for all VCS repository commits.
Frequently these things seem to work themselves out after a long time. Old people leave, new people come in. Sometimes it is peaceful, sometimes it is violent. Rarely does it result in structural improvements.
I do not know why there is lack of manpower on dpkg and apt right now. I know I tried to make a change to dpkg a few months ago and was unable to do so, partly due to the codebase and partly due to important information existing only in Guillem's mind. In the end, I had to just wait for Guillem to do it, which he helpfully did, and now we have libdpkg-dev in experimental, with one reverse build-dep.
Had I been able to make the change myself, it is unclear whether I would have made any other contributions; that was the only itch I needed scratched, and I have plenty of other things to work on. So even though I found it near-impossible to contribute to dpkg in this way, I don't think that I'm excluded.
So as DPL I would first try to determine why there might not be enough contributors to dpkg and apt, or why the existing contributors are not performing up to your standards. This could be an instance where I would solicit private communication from people who might have potentially-valuable information that they do not wish to communicate in public for fear of hurting someone's feelings. This does not mean that I would try to resolve these issues behind the scenes, because I consider that to be a dangerous and potentially-harmful tactic.
Given a reasonable theory about why the problem exists, I would then proceed to encourage the resolution of that problem.
I also think that some package maintenance teams may share some issues with some core teams and even the project at large, and addressing the more general problems could lead to relief in many areas. Specifically I would name problems related to ego and teamwork, which is a theme on which I plan to elaborate later.