Ask HN: Difference in management styles of Ulrich Drepper and Linus Torvalds
Linus Torvalds stewardship is often cited as critical factor in thriving linux kernel development
Ulrich Drepper is often cited for preventing widespread community contribution to glibc and causing forks such as eglibc.
For casual observer like me it appears both are technically brilliant individuals who have strong opinions and dont suffer fools lightly. What caused linux to thrive ? Was it the organizational heirarchy of having individual maintainers for different components in the linux kernel ?
22 comments
Linus accepts patches for just about anything, only discriminating based on patch quality and general development direction of the kernel, without discriminating against the specific thing someone wanted to add. Ulrich went on record several times as not caring about most architecture ports or various other areas, and he rejected patches in those areas, forcing them to live in add-on areas like the "ports" repository. Distributions had to maintain a large number of patches.
Linus cares deeply about the quality of the kernel, but leaves it to developers to determine its direction. Ulrich had very specific thoughts on the direction of glibc, and screw you if you cared about anything else.
Linus has a large number of trusted submaintainers, and delegated a large amount of trust and judgement over patches to them; Ulrich took everything on himself, and simply rejected patches in areas he didn't care about.
Linus has been known to change his mind, graciously, in the face of convincing argument; he also readily admits being wrong. Ulrich, not so much; if he didn't like your patch, you might as well give up.
While Linus can be unnecessarily awful to people he thinks he can expect better from, there's an undercurrent of doing it to defend kernel quality, and he usually has a point underneath the invective; I also don't think I've ever seen Linus go off on a new developer who's still learning and making reasonable mistakes. Ulrich was awful to everyone, with or without reason, and he was wrong far too often to get away with it.
Finally, for every discussion in which Linus ranted at someone, I've seen several dozen where he gets involved in a complicated technical problem and helps find the solution, or works with someone else to do so; the balance is overwhelmingly positive.
Don't look at either of their abrasive communication styles as worthy of emulation; do better than that. Linus successfully manages Linux despite being occasionally abrasive. Ulrich's abrasiveness just added to his mismanagement, rather than being the sole source of it.
Linus cares deeply about the quality of the kernel, but leaves it to developers to determine its direction. Ulrich had very specific thoughts on the direction of glibc, and screw you if you cared about anything else.
Linus has a large number of trusted submaintainers, and delegated a large amount of trust and judgement over patches to them; Ulrich took everything on himself, and simply rejected patches in areas he didn't care about.
Linus has been known to change his mind, graciously, in the face of convincing argument; he also readily admits being wrong. Ulrich, not so much; if he didn't like your patch, you might as well give up.
While Linus can be unnecessarily awful to people he thinks he can expect better from, there's an undercurrent of doing it to defend kernel quality, and he usually has a point underneath the invective; I also don't think I've ever seen Linus go off on a new developer who's still learning and making reasonable mistakes. Ulrich was awful to everyone, with or without reason, and he was wrong far too often to get away with it.
Finally, for every discussion in which Linus ranted at someone, I've seen several dozen where he gets involved in a complicated technical problem and helps find the solution, or works with someone else to do so; the balance is overwhelmingly positive.
Don't look at either of their abrasive communication styles as worthy of emulation; do better than that. Linus successfully manages Linux despite being occasionally abrasive. Ulrich's abrasiveness just added to his mismanagement, rather than being the sole source of it.
When Torvalds hurls invective at some idea and at anyone who would support it, it's clear that he read it, understands it, and is speaking directly to it. Drepper would just swear at people and call them stupid.
The way to figure out the difference between the two is to strip out the choice of language and focus on the content of their responses. Drepper, if you strip out the invective, rarely has any content at all. Torvalds' sweary hateposts are often some of his most profound, detailed, and quotable.
The way to figure out the difference between the two is to strip out the choice of language and focus on the content of their responses. Drepper, if you strip out the invective, rarely has any content at all. Torvalds' sweary hateposts are often some of his most profound, detailed, and quotable.
If I remember correctly, the main problem with Mr. Drepper was that he was resistant to accepting changes to glibc... even (subjectively) good ones.
Torvalds, like Drepper, is often criticized for a less-than-friendly attitude, but it is generally acknowledged that he lets the Linux kernel progress.
Torvalds, like Drepper, is often criticized for a less-than-friendly attitude, but it is generally acknowledged that he lets the Linux kernel progress.
To add to this: Torvalds has definitely let changes into the kernel which he was initially against (particularly when changes moved away from the "UNIX way" of doing things to more complex, but more efficient, solutions). However he can be talked into things with reason (and data!), he can snap at people, but then the conversation continues and progress is made.
Actually, Torvalds can be quite friendly and nice.
Bashing Ulrich Drepper has now taken on the flavor of bashing Nickelback, it's a fun and socially safe outlet for hate. The guy hasn't even been a thorn in anyone's side for years now, it's time to let it go.
Like all software projects, glibc and the kernel are resistant to change. The kernel not (often) unreasonably so. Drepper was notorious for being unreasonable.
Gregkh gives talks about kernel maintenance, here's an excerpt:
Simply, Drepper's excuses sucked, he was the problem.
For casual observer like me it appears both are technically brilliant individuals who have strong opinions and dont suffer fools lightly.
Also, perception of Linus' attitude is more smoke than fire. He does suffer fools lightly, it's the people he expects better of or explicitly provoke him that get the angry responses that make LKML show up on social media.
Gregkh gives talks about kernel maintenance, here's an excerpt:
It is in my self-interest to ignore your patch [...]
So your goal is, when sending a patch, is to give me NO excuse to not
accept it. To make it such that if I ignore it, or reject it, I am the one
that is the problem here, not you.
Simply, Drepper's excuses sucked, he was the problem.
For casual observer like me it appears both are technically brilliant individuals who have strong opinions and dont suffer fools lightly.
Also, perception of Linus' attitude is more smoke than fire. He does suffer fools lightly, it's the people he expects better of or explicitly provoke him that get the angry responses that make LKML show up on social media.
The assholeness of Torvalds is oversold. Imagine that every conversation you had at work, and a good deal of your conversations with your friends off work, were publicly available on the internet and routinely scrutinized by journalists and bloggers, and any time they criticized you it was newsworthy enough to make it to all the big social news aggregators. Now imagine that you worked a retail job, and not only dealt with professionals with a sense of propriety, but randoms with varying degrees of anger, malice, and incompetence.
I cannot say I have studied either in sufficient detail but I will say there is a huge body of academic and less-academic work on the effectiveness of leaders and leadership style in commercial and corporate markets - and none of it is conclusive in anyway.
However, in these cases there is a vast corpus of emails and comma - it's as if we had a stenographer following Lou Gerstner and Steve Jobs around, so I would be surprised that now you have mentioned it, there is not some academic attempt to quantify answers.
Hell, if anyone fancies a middle aged student for a research thesis I would happily take a run at this :-)
However, in these cases there is a vast corpus of emails and comma - it's as if we had a stenographer following Lou Gerstner and Steve Jobs around, so I would be surprised that now you have mentioned it, there is not some academic attempt to quantify answers.
Hell, if anyone fancies a middle aged student for a research thesis I would happily take a run at this :-)
There really is not much similarity between Linus and Ulrich. Linus relies on his "lieutenants" to do most of the work in Linux... not only the code, but also reviewing the patches of others. Ulrich was a one-man show who would often rewrite patches rather than accept the work of someone else.
Anyway, Ulrich was just wrong about a lot of things. I remember one bug that affected ARM that he tried to close because "ARM is not a real arch." He made a lot of very questionable decisions, like leaving out strlcpy and strlcat. To be fair, there is valuable stuff he did behind the scenes (like ELF TLS support and some of the dynamic linking documentation). But people (reasonably) focus on the negative things, because a negative maintainer can cause huge problems for downstream projects...
Anyway, Ulrich was just wrong about a lot of things. I remember one bug that affected ARM that he tried to close because "ARM is not a real arch." He made a lot of very questionable decisions, like leaving out strlcpy and strlcat. To be fair, there is valuable stuff he did behind the scenes (like ELF TLS support and some of the dynamic linking documentation). But people (reasonably) focus on the negative things, because a negative maintainer can cause huge problems for downstream projects...
Let me see: I came across a bug in adobe flash (I know, evil) on linux one day where it came down to a change in memcpy in glibc.
https://bugzilla.redhat.com/show_bug.cgi?id=638477
comment 129 https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129
---
Quite frankly, I find your attitude to be annoying and downright stupid.
How hard can it be to understand the following simple sentence:
Also, the fact is, that from a Q&A standpoint, a memcpy() that "just does the right thing" is simply _better_. Quoting standards is just stupid, when there's two simple choices: "it works" or "it doesn't work because bugs happen".
Standards are paper. I use paper to wipe my butt every day. That's how much that paper is worth.
Reality is what matters. When glibc changed memcpy, it created problems. Saying "not my problem" is irresponsible when it hurts users.
And pointing fingers at Adobe and blaming them for creating bad software is _doubly_ irresponsible if you are then not willing to set a higher standard for your own project. And "not my problem" is not a higher standard.
So please just fix it.
The easy and technically nice solution is to just say "we'll alias memcpy to memmove - good software should never notice, and it helps bad software and a known problem".
---
This is why Linus is widely considered a good steward, and Ulrich had to be removed from glibc.
Yes, they both had abrasive mannerisms, yes they sometimes said things that wouldn't pass fortune 500 HR policy.
The difference is: Ulrich seemed to care more about some kind of technical "correct-ness", and anything that didn't fit in his mental model was considered wrong, and nothing else mattered.
Linus deeply cares about the user experience. the kernel has a strict no-regressions policy for this reason. If it used to work before and now it doesn't, this needs to be fixed in the kernel
Like this case, most of the cases where Linus uses salty language comes down to various kernel developers not following this policy, then complaining when their patch doesn't get accepted.
Edited for formatting
https://bugzilla.redhat.com/show_bug.cgi?id=638477
comment 129 https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129
---
Quite frankly, I find your attitude to be annoying and downright stupid.
How hard can it be to understand the following simple sentence:
THE USER DOESN'T CARE.
Also, the fact is, that from a Q&A standpoint, a memcpy() that "just does the right thing" is simply _better_. Quoting standards is just stupid, when there's two simple choices: "it works" or "it doesn't work because bugs happen".
Standards are paper. I use paper to wipe my butt every day. That's how much that paper is worth.
Reality is what matters. When glibc changed memcpy, it created problems. Saying "not my problem" is irresponsible when it hurts users.
And pointing fingers at Adobe and blaming them for creating bad software is _doubly_ irresponsible if you are then not willing to set a higher standard for your own project. And "not my problem" is not a higher standard.
So please just fix it.
The easy and technically nice solution is to just say "we'll alias memcpy to memmove - good software should never notice, and it helps bad software and a known problem".
---
This is why Linus is widely considered a good steward, and Ulrich had to be removed from glibc.
Yes, they both had abrasive mannerisms, yes they sometimes said things that wouldn't pass fortune 500 HR policy.
The difference is: Ulrich seemed to care more about some kind of technical "correct-ness", and anything that didn't fit in his mental model was considered wrong, and nothing else mattered.
Linus deeply cares about the user experience. the kernel has a strict no-regressions policy for this reason. If it used to work before and now it doesn't, this needs to be fixed in the kernel
Like this case, most of the cases where Linus uses salty language comes down to various kernel developers not following this policy, then complaining when their patch doesn't get accepted.
Edited for formatting
I suggest watching Torvalds' take on his honesty:
http://youtu.be/-ZRvHbHxr-k
http://youtu.be/-ZRvHbHxr-k
Well, we can conclude that being an asshole is irrelevant or not enough for running a successful project.
I remember at the peak of the Steve Jobs dynasty, I noticed several classmates who would try and act just like him while speaking in front of people (black sweaters and all), and they started being complete jerks to people who didn't have the same perceived creativity or vision that they had. They thought if they acted in the ways Jobs was famour for, maybe they'd inherit his brilliance...
Sounds like a cargo cult (https://en.wikipedia.org/wiki/Cargo_cult).
Exactly this. I had a boss who read "Steve Jobs" and took away from it that treating employees like lazy, passive aggressive assholes was a good recipe for motivating them to make great things. Within a space of a particular month, the entire engineering team quit.
The real lesson should've been that Jobs was brilliant to the point that people bought into his vision enough to put up with his bullshit. He succeeded in spite of his attitude, not because of it.
The real lesson should've been that Jobs was brilliant to the point that people bought into his vision enough to put up with his bullshit. He succeeded in spite of his attitude, not because of it.
In my job, I could successfully be an asshole. But my assholishness wouldn't be irrelevant. If it's a weakness, then I had other advantages to make up for it. If it's a strength, then I applied certain things to make it work.
It also depends on the culture. Some cultures make assholishness less viable. For instance, conferences with a decent code of conduct make physical harassment less viable.
It also depends on the culture. Some cultures make assholishness less viable. For instance, conferences with a decent code of conduct make physical harassment less viable.
People want to work under linus.
Nobody wants to work under Ulrich.
Case closed?
Case closed?