Slashdot Mirror
The Scalability of Linus
Hugh Pickens writes "Katherine Noyes writes at LinuxInsider that it may be time for Linus Torvalds to share more of the responsibility for Linux that he's been shouldering. 'If Linux wants to keep up with the competition there is much work to do, more than even a man of Linus's skill [can] accomplish,' argues one user. The 'scalability of Linus' is the subject of a post by Jonathan Corbet wondering if there might there be a Linus scalability crunch point coming. 'The Linux kernel development process stands out in a number of ways; one of those is the fact that there is exactly one person who can commit code to the "official" repository,' Corbet writes. A problem with that scenario is the potential for repeats of what Corbet calls 'the famous "Linus burnout" episode of 1998' when everything stopped for a while until Linus rested a bit, came back, and started merging patches again. 'If Linus is to retain his central position in Linux kernel development, the community as a whole needs to ensure that the process scales and does not overwhelm him,' Corbet adds. But many don't agree. 'Don't be fooled that Linus has to scale — he has to work hard, but he is the team captain and doorman. He has thousands doing most of the work for him. He just has to open the door at the appropriate moment,' writes Robert Pogson, adding that Linus 'has had lots of practice and still has fire in his belly.'"
A good new fork will only be needed if and when Linus stops scaling. Until then, the reason that a fork has never really come together is because Linus' Linux is the best all round solution.
Given that, in practice, virtually every distro maintains its own kernel, or set of patches, to suit their needs, I don't really see the big deal.
As long as Linus is performing his role of keeping the "official" repository basically the easiest and most standard starting point, all the peripheral kernel tweaks maintained by other entities will cluster more or less closely around it for cost reasons.
If he starts to slip, the center of gravity will shift toward one of the distro kernel repositories, or whatever other third party is doing the best job of filling the role, and the "official" repository will fade in prominence a bit.
Because of how kernel code is licensed, the "official" repository could either come back quickly(if Linus or his chosen successor get back on the ball, they could update from the prior leader, and start taking the comit lead again), or it could just fade away, mostly, and development could center around the RedHat tweak of the kernel, or the Debian one, or whatever...
More dangerous are situations(like the X11/X.org one) where there is a major licensing split that actually requires a decisive move one way or the other. Linux graphics are certainly not its strongest suit; but, had the defection to X.org not been so complete, things there could have been a lot uglier today.
The Linux kernel is not a company. Free software projects are a new kind of entity.
The debate is still open about whether it is correct to level "They should..." instructions at this kind of entity.
Possibly "I should..." statements are more appropriate.
-paul
The problem is not if it will die. Linux itself will likely live on. The question lies in what will ultimately happen to it. There needs to be a succession path, even if it's just that Linus keeps 100% of the control while he's on work, and passes it off only when he gets burnt out or worse.
Supposing he does get hit by a bus, there will be months of infighting as big egos clash trying to decide who gets control of the kernel. There'll be those who think the official repository should be managed by committee, those saying the single person structure maintained. The subsequent fight will blow out of proportion which will generate many forks and ultimately and dangerously you will end up with uncertainty.
The best outcome is that there's a plan in place for exactly this kind of situation. That way Linux can remain what Linus wants it's to be in case of his demise rather than to throw it to the dogs and then see what's left over after the frenzy dies.
Which sounds exactly like a scalability problem.
The Tao of math: The numbers you can count are not the real numbers.