Is Linux Too Much for One Mere Mortal to Handle?
Jul 22, 2010 5:00 AM PT
Well it may be a wild ride these days for those on Apple's side of the fence -- gotta love those bumpers! -- but for those of us here in the Linux blogosphere, things have been remarkably calm, cool and collected.
Much, in fact, like the Father of Linux himself, one might say.
It should come as no great surprise, then, that the very same man -- Linus Torvalds -- was the subject of some considerable -- albeit well-mannered -- debate.
'The Linus Burnout Episode'
The "scalability of Linus," in fact, was the subject of a post by Jonathan Corbet earlier this month on LWN, and it's sparked quite a discussion.
"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 begins.
A problem with that scenario, he notes, is the potential for repeats of what calls "the famous 'Linus burnout' episode of 1998."
As a result, "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. "As with the code itself, it makes sense to think about the next level of scalability issues in the development process before they strike."
'It Adds Too Much Pressure for One Person'
Bloggers jumped on the topic with gusto.
"Linux project definitely needs a failover guy (and it has many), primarily because it adds too much pressure for one person to shoulder all the way," wrote rilder in the LWN comments, for example.
"Imagine what an indefinite period of serious in-hospital Linus illness (starting...now) would do to the project," PO8 chimed in. "In a way it would be worse than if he (God forbid) was hit by a bus -- in that case presumably someone would step in and try to take over his role, for better or worse."
Still, for now "Linus' scalability when operating properly is the least of my worries," PO8 added.
'No Single Choke Point'
"If Linus went away, at least all the distributors would immediately start merging from the respective subsystem maintainers themselves -- and over time, a new gold standard is likely to emerge, either from them or the community," lmb asserted.
"Linux has a very distributed development model with no single choke point in it; the centralization is merely convenient for all, not required," lmb added.
Then again: "It might be time for Linus to start thinking about this and maybe train a (few) possible successor(s)," superstoned suggested. "It can take years before one has the experience to do what he is doing, so he should start doing that sooner rather than later..."
Now, Linux Girl has been lucky enough to interview Mr. Torvalds on more than one occasion, and she is surely one of his biggest fans.
Nonetheless, personal considerations aside, the question has merit: Is Linux too much for one man?
'Another Big Problem'
The current situation "is a problem if he gets hit by a bus," Hyperlogos blogger Martin Espinoza told Linux Girl. "I suspect enforcing some stability on the kernel is a good idea."
Indeed, "people always whine about Linus, but the most important thing he does is enforce good taste and timelines on the kernel," Montreal consultant and Slashdot blogger Gerhard Mack opined. "Without his constant merge deadlines, Linux would revert back to a multiyear development branch lifecycle, and that would be a disaster."
On the other hand, "I think this is another big problem FLOSS has," Slashdot blogger hairyfeet opined.
'He Is Only Human, After All'
"A good example is Con Kolivas, who came up with a kernel patch that would give the end users a better multimedia experience," hairyfeet explained. "Since it would decrease performance for servers -- which is ultimately who pays Linus's bills -- it was rejected and he ended up quitting in disgust.
"In the end I'd say that was too much pressure and too much responsibility for even Linus to handle," hairyfeet said. "He is only human, after all."
The process could be split into three camps: desktop, server and embedded, hairyfeet suggested. "They really need to be separate anyway, as what is good for a desktop experience might not be great for server throughput, and embedded is a different beast entirely."
Linus, then, "should keep server, and let someone dedicated to the desktop, like Con, take the desktop kernel role, then have the head of one of the longtime embedded projects take the helm for embedded kernel development," he said. "I know that with the source code one can DIY, but if Linux wants to keep up with the competition there is much work to do, more than even a man of Linus's skill to accomplish."
'Linus Still Has Fire in His Belly'
Not everyone, however, saw it that way.
"The commit process has evolved over time, and will continue to develop, same as the kernel itself," noted Barbara Hudson, a blogger on Slashdot who goes by "Tom" on the site.
"In a worst-case scenario, Linus takes some time to write another tool, like he did with git," she added.
Similarly, "don't be fooled that Linus has to scale -- he has to work hard, but he is the team captain and doorman," blogger Robert Pogson said. "He has thousands doing most of the work for him. He just has to open the door at the appropriate moment."
Linus "has had lots of practice and still has fire in his belly," Pogson added. "He can go on for the rest of his career with accomplishment recognized by the world and satisfaction in a job well done in his heart."
'What Would Linus Do?'
If Torvalds "ever burns out or retires, we may have some worry," Pogson admitted. "I am sure there are several reasonable candidates for a replacement. If they get into a jam they can always phone up Linus or think, 'What would Linus do?' and they would not go far wrong.
"Besides," Pogson added, "if a replacement made a mistake, the developers would let him know... ;-)"
Pogson's overall conclusion?
"Thank you, Linus, for a job well done," he said. "May your next 20 years be as successful."
"Amen," Linux Girl would add. We can all drink to that. ;-)