6 ms·

The problem here is that the "Collaborating" sector is the wrong goal for the Linux kernel. Linus Torvalds is uniquely qualified to be concerned about matters c

The problem here is that the "Collaborating" sector is the wrong goal for the Linux kernel. Linus Torvalds is uniquely qualified to be concerned about matters concerning the kernel; if his interlocutors "win" too much on their side of the "win/win", every user loses. The public embarrassment of lazy and dishonest actors, especially those who are paid to collaborate, is an effective tool for maintaining order and standards on behalf of the quality of the product, and provided nobody gets hurt permanently at the end of the day, it is easily justified.

crunchlibrarian 8y ago
This mindset is a bit too fascist for the modern workplace. I still see this attitude a lot, so I think it's good to recognize and call it out for what it is.
- dang 8y ago
  Please let's not bring the f-word into this. That's a move to an inner circle of hell.
skywhopper 8y ago
This has absolutely nothing to do with Linus winning or losing. Only with how he goes about winning. If he wins an argument in ways that alienate contributors, then he’s ultimately losing. There’s no reason he can’t be assertive without being toxic. I for one give him more credit than that. Calling people names is he laziest and least productive way to argue your point.
JoshTriplett 8y ago
> if his interlocutors "win" too much on their side of the "win/win", every user loses. You seem to be trying to find a way to turn this back into "win/lose". Try another interpretation. For instance, a patch might call attention to a problem, but it takes the wrong approach to solve it. Could we find a better solution to the problem? Nobody is suggesting giving bad code or bad ideas a pass. Are you under the impression that it's impossible to reject a patch or give technical feedback without being brutal or toxic?
- wdewind 8y ago
  I think generally you're right, but the comment you're replying to has something to it as well. If two parties are not "equals" in the arena they are in, things get Complicated. I'm not sure true collaboration is possible in situations where parties are on such uneven footing (and I mean this in the abstract sense as well: I don't think the model you've presented is complete as is does not give you a productive way to structure this kind of relationship). In the situation where Linus is far more qualified, and obviously so, and someone is trying to get him to "approve" a patch, there's no way it's ever really going to be a truly collaborative dynamic. This doesn't mean Linus has to be a dick about it, but it's definitely not collaboration between equals.
  - ece 8y ago
    If you read what Linus said, nowhere did he conflate technical merit with social merit. Your comment very much does this. He specifically said there haven't been pain points around technical issues, but around process issues, which is what he's personally trying to fix. Open source is about the community, and I think Linus figured this out later than most. Sure, you can dump some code out there and maybe even get users, but you won't have built a community that improves software until you've shown people can file bugs reports and patches or otherwise be a part of the community without being personally insulted. This is a pretty low bar tbh.
- hueving 8y ago
  A large chunk of frequent contributors are paid by companies to heave features/drivers at the kernel with no regard to doing it the right way. To them it's about landing code ASAP. Linus is already working in the win/win quadrant by default by merging these things all in the name of making the kernel better. Occasionally a frequent contributor who has gained trust will start to merge trash in the name of meeting deadlines. This is usually when linus loses his shit at the people responsible. This has nothing to do with a silly quadrant of being competitive/neutral/anything towards the collaboration itself. Linus is still looking for a win/win, but he's requiring people to fix their shit. That quadrant is irrelevant about Linus's behavior because he's always collaborating. What you need is a quadrant describing how feedback is delivered to subordinates.
irundebian 8y ago
> The public embarrassment of lazy and dishonest actors, especially those who are paid to collaborate, is an effective tool for maintaining order and standards on behalf of the quality of the product, and provided nobody gets hurt permanently at the end of the day, it is easily justified. It may be effective, but aren't there other equally effective alternatives? How are hard situations handled by maintainers of other operating systems/kernels like FreeBSD? Do they also need public embarrassment?
moosingin3space 8y ago
> Linus Torvalds is uniquely qualified Gotta stop you right there. Hero worship should not be considered a good thing in our industry. The kernel subsystem maintainers, who actually review the code prior to getting it merged, are the ones with the real power and the necessary knowledge, and I'd argue they are more qualified to oversee the project's future than Torvalds.
- tomnipotent 8y ago
  Yeah, just like regular employees are better qualified to run a company than the CEO. No one is more qualified than Linus to run this project and he's done a damn good job so far. Has he made mistakes? Sure. He's human.
  - moosingin3space 8y ago
    I think that when a company reaches a certain size and stability level, as long as the CEO is competent and understands how to balance external and internal issues, the particular CEO doesn't matter that much. The real power over product direction comes from the PMs, VPs, etc. That's my argument -- Linus isn't uniquely qualified to run the Linux kernel project, since he's barely even involved in the direction of the project.
    - tomnipotent 8y ago
      > the particular CEO doesn't matter that much Business history & Jack Welch disagree with you. Individual project success is incredibly nuanced and individuals - even in 10k+ orgs - can have massive impacts. Trying to pretend that outliers don't massively influence company success is naive, and MBA programs study these individuals because they are the exception and not the rule. There's a reason we have Madison Square Garden, Rockefeller Center and Carnegie Mellon. It's not hero worship to acknowledge the contributions of individuals - recognizing a great general doesn't diminish the accomplishments of his army.
      - emodendroket 8y ago
farazbabar 8y ago
I think this can be further generalized, that there is a tier of talent that we must excuse from having to filter themselves and that this may serve humanity even if it rubs some the wrong way.
JohnBooty 8y ago
The public embarrassment of lazy and dishonest actors, especially those who are paid to collaborate, is an effective tool for maintaining order and standards on behalf of the quality of the product, and provided nobody gets hurt permanently at the end of the day, it is easily justified. Can you explain why you feel rants and insults are necessary to maintain high technical standards? Literally nobody is asking Linus to relax his standards for what makes it into the kernel.
- microcolonel 8y ago
  > Can you explain why you feel rants and insults are necessary to maintain high technical standards? It is possible that they are not truly "necessary", but they are one often-effective way to discourage disruptive/unproductive behaviour. Linus ultimately should not be asked to review changesets he will be far from willing to merge; and for him there are only so many hours in the day. It is, as a practical matter, necessary to communicate that there is a cost to wasting his time with work that somebody should have known was substandard, and it is important that that cost is borne primarily by the originator of that substandard work (i.e. it needs to suck more for the committer to waste Linus' time than it sucks for Linus to spend time responding). It is a high-risk, unappealing technique, but we should be careful not to impose alternatives which fail to meet the same criteria at least to some extent.
  - JohnBooty 8y ago
    there are only so many hours [for Linus] in the day. It is, as a practical matter, necessary to communicate that there is a cost to wasting his time with work that somebody should have known was substandard This is a really a restatement of the old (yet still relevant) "Linus doesn't scale" issue, right? It's true: Linus' time is a valuable resource and shouldn't be wasted. This is of course true of any project maintainer, or any person at all really -- it's just that the stakes are a higher in the case of the Linux kernel because of the scope and impact of the project. it is important that that cost is borne primarily by the originator of that substandard work (i.e. it needs to suck more for the committer to waste Linus' time than it sucks for Linus to spend time responding) This is a nearly universal problem. Imagine suggesting "hurl insults at the perpetrators until they learn" as a solution in any other field. Ridiculous! The answer of course is to proactively reduce the number of time-wasting things that are raised to Linus' attention, not to reactively be meaner when those sorts of things do happen. Typically you'd do this in Linux or any software project by: (a) making sure that the other kernel maintainers are trusted and skilled (b) making sure that everybody has a solid understanding of what is and isn't a good contribution (c) discussing contributions ahead of time so that there are fewer surprises at review/merge time (d) solve the "Linus doesn't scale" issue by delegating more of his responsibility elsewhere, cloning him, etc. I should note that I have no idea about how the kernel maintainers function on a daily basis. Maybe they're already doing a really great job of those things, and it's only 0.001% of merge requests that result in spectacular Linus rants and therefore show up on HN or whatever. Since it seems like kernel development is humming along pretty well for the mooooooost part I'd put my money on that, but who knows.
emodendroket 8y ago
Really? If they're so "lazy and dishonest," maybe they just shouldn't be involved in the project, instead of being allowed but also publicly berated.
ece 8y ago
You're an idiot if you think insulting someone is effective shaming or the only way to do so. As the CoC points out, you can reprimand a community member in any number of ways and keep track of it.

crunchlibrarian 8y ago

This mindset is a bit too fascist for the modern workplace. I still see this attitude a lot, so I think it's good to recognize and call it out for what it is.

dang 8y ago
Please let's not bring the f-word into this. That's a move to an inner circle of hell.

skywhopper 8y ago

This has absolutely nothing to do with Linus winning or losing. Only with how he goes about winning. If he wins an argument in ways that alienate contributors, then he’s ultimately losing. There’s no reason he can’t be assertive without being toxic. I for one give him more credit than that. Calling people names is he laziest and least productive way to argue your point.

JoshTriplett 8y ago

> if his interlocutors "win" too much on their side of the "win/win", every user loses. You seem to be trying to find a way to turn this back into "win/lose". Try another interpretation. For instance, a patch might call attention to a problem, but it takes the wrong approach to solve it. Could we find a better solution to the problem? Nobody is suggesting giving bad code or bad ideas a pass. Are you under the impression that it's impossible to reject a patch or give technical feedback without being brutal or toxic?

wdewind 8y ago
I think generally you're right, but the comment you're replying to has something to it as well. If two parties are not "equals" in the arena they are in, things get Complicated. I'm not sure true collaboration is possible in situations where parties are on such uneven footing (and I mean this in the abstract sense as well: I don't think the model you've presented is complete as is does not give you a productive way to structure this kind of relationship). In the situation where Linus is far more qualified, and obviously so, and someone is trying to get him to "approve" a patch, there's no way it's ever really going to be a truly collaborative dynamic. This doesn't mean Linus has to be a dick about it, but it's definitely not collaboration between equals.
- ece 8y ago
  If you read what Linus said, nowhere did he conflate technical merit with social merit. Your comment very much does this. He specifically said there haven't been pain points around technical issues, but around process issues, which is what he's personally trying to fix. Open source is about the community, and I think Linus figured this out later than most. Sure, you can dump some code out there and maybe even get users, but you won't have built a community that improves software until you've shown people can file bugs reports and patches or otherwise be a part of the community without being personally insulted. This is a pretty low bar tbh.
hueving 8y ago
A large chunk of frequent contributors are paid by companies to heave features/drivers at the kernel with no regard to doing it the right way. To them it's about landing code ASAP. Linus is already working in the win/win quadrant by default by merging these things all in the name of making the kernel better. Occasionally a frequent contributor who has gained trust will start to merge trash in the name of meeting deadlines. This is usually when linus loses his shit at the people responsible. This has nothing to do with a silly quadrant of being competitive/neutral/anything towards the collaboration itself. Linus is still looking for a win/win, but he's requiring people to fix their shit. That quadrant is irrelevant about Linus's behavior because he's always collaborating. What you need is a quadrant describing how feedback is delivered to subordinates.

irundebian 8y ago

> The public embarrassment of lazy and dishonest actors, especially those who are paid to collaborate, is an effective tool for maintaining order and standards on behalf of the quality of the product, and provided nobody gets hurt permanently at the end of the day, it is easily justified. It may be effective, but aren't there other equally effective alternatives? How are hard situations handled by maintainers of other operating systems/kernels like FreeBSD? Do they also need public embarrassment?

moosingin3space 8y ago

> Linus Torvalds is uniquely qualified Gotta stop you right there. Hero worship should not be considered a good thing in our industry. The kernel subsystem maintainers, who actually review the code prior to getting it merged, are the ones with the real power and the necessary knowledge, and I'd argue they are more qualified to oversee the project's future than Torvalds.

tomnipotent 8y ago
Yeah, just like regular employees are better qualified to run a company than the CEO. No one is more qualified than Linus to run this project and he's done a damn good job so far. Has he made mistakes? Sure. He's human.
- moosingin3space 8y ago
  I think that when a company reaches a certain size and stability level, as long as the CEO is competent and understands how to balance external and internal issues, the particular CEO doesn't matter that much. The real power over product direction comes from the PMs, VPs, etc. That's my argument -- Linus isn't uniquely qualified to run the Linux kernel project, since he's barely even involved in the direction of the project.
  - tomnipotent 8y ago
    > the particular CEO doesn't matter that much Business history & Jack Welch disagree with you. Individual project success is incredibly nuanced and individuals - even in 10k+ orgs - can have massive impacts. Trying to pretend that outliers don't massively influence company success is naive, and MBA programs study these individuals because they are the exception and not the rule. There's a reason we have Madison Square Garden, Rockefeller Center and Carnegie Mellon. It's not hero worship to acknowledge the contributions of individuals - recognizing a great general doesn't diminish the accomplishments of his army.
    - emodendroket 8y ago

farazbabar 8y ago

I think this can be further generalized, that there is a tier of talent that we must excuse from having to filter themselves and that this may serve humanity even if it rubs some the wrong way.

JohnBooty 8y ago

The public embarrassment of lazy and dishonest actors, especially those who are paid to collaborate, is an effective tool for maintaining order and standards on behalf of the quality of the product, and provided nobody gets hurt permanently at the end of the day, it is easily justified. Can you explain why you feel rants and insults are necessary to maintain high technical standards? Literally nobody is asking Linus to relax his standards for what makes it into the kernel.

microcolonel 8y ago
> Can you explain why you feel rants and insults are necessary to maintain high technical standards? It is possible that they are not truly "necessary", but they are one often-effective way to discourage disruptive/unproductive behaviour. Linus ultimately should not be asked to review changesets he will be far from willing to merge; and for him there are only so many hours in the day. It is, as a practical matter, necessary to communicate that there is a cost to wasting his time with work that somebody should have known was substandard, and it is important that that cost is borne primarily by the originator of that substandard work (i.e. it needs to suck more for the committer to waste Linus' time than it sucks for Linus to spend time responding). It is a high-risk, unappealing technique, but we should be careful not to impose alternatives which fail to meet the same criteria at least to some extent.
- JohnBooty 8y ago
  there are only so many hours [for Linus] in the day. It is, as a practical matter, necessary to communicate that there is a cost to wasting his time with work that somebody should have known was substandard This is a really a restatement of the old (yet still relevant) "Linus doesn't scale" issue, right? It's true: Linus' time is a valuable resource and shouldn't be wasted. This is of course true of any project maintainer, or any person at all really -- it's just that the stakes are a higher in the case of the Linux kernel because of the scope and impact of the project. it is important that that cost is borne primarily by the originator of that substandard work (i.e. it needs to suck more for the committer to waste Linus' time than it sucks for Linus to spend time responding) This is a nearly universal problem. Imagine suggesting "hurl insults at the perpetrators until they learn" as a solution in any other field. Ridiculous! The answer of course is to proactively reduce the number of time-wasting things that are raised to Linus' attention, not to reactively be meaner when those sorts of things do happen. Typically you'd do this in Linux or any software project by: (a) making sure that the other kernel maintainers are trusted and skilled (b) making sure that everybody has a solid understanding of what is and isn't a good contribution (c) discussing contributions ahead of time so that there are fewer surprises at review/merge time (d) solve the "Linus doesn't scale" issue by delegating more of his responsibility elsewhere, cloning him, etc. I should note that I have no idea about how the kernel maintainers function on a daily basis. Maybe they're already doing a really great job of those things, and it's only 0.001% of merge requests that result in spectacular Linus rants and therefore show up on HN or whatever. Since it seems like kernel development is humming along pretty well for the mooooooost part I'd put my money on that, but who knows.

emodendroket 8y ago

Really? If they're so "lazy and dishonest," maybe they just shouldn't be involved in the project, instead of being allowed but also publicly berated.

ece 8y ago

You're an idiot if you think insulting someone is effective shaming or the only way to do so. As the CoC points out, you can reprimand a community member in any number of ways and keep track of it.