Linux follows an inverse form of Conway's Law

Conway's Law absolutely applies to Linux. The trick is to remember that the communication patterns that Linux is optimized to reflect is "git tree pulls". Over time, things have been factored to minimize the amount of cross-tree merge conflicts. That way we can decentralize the development effort, and worry much less about conflicts when Linus has to pull from a hundred-odd git trees (many of which have sub-trees that were merged together by the subsystem maintainers before Linus then pulled them into his tree). But that is the primary communication pattern which is critical, and we have absolutely optimized how the code has been laid out to minimize communication difficulties --- when defined in terms of merge conflicts.

I don't think the author makes a very convincing point here; Linux is frequently cited as a prime example of Conway's Law in practice for a reason.

The reason the driver subsystem is architected as pluggable modules ("drivers") is to support the extremely wide array of organizations that have to build into it.

The reason why Linux is broken down into subsystems is to support the "specialists" who work in only on system at a time.

The reason Linux is a monolithic kernel that has a large degree of complication internally (vs. a microkernel) is because Linus is strong enough to make it happen.

I mean, the logical error is right in the title. The author inverted cause and effect.

Misleading y-axis strikes again: https://cdn-images-1.medium.com/max/800/1*MiF0VmKW19IC3OlVDI...

What the article is suggesting is that the Linux architecture wasn't affected by organisational pressures that closed-source systems face.

That is to say that subsytems were defined solely based on technical considerations, which is how it should be if the goal is sound engineering.

Not sure what to make of the ratio between "specialists" and "generalists". A comparison to ratios from other projects would provide some helpful context.

The article makes a good point but I wonder if it is an incomplete explanation. What would happen if Linus Torvalds walked away and there was no single leader to guide (or "dictate", depending on your point of view) its development? Would it begin to fragment and exhibit signs of Conway's Law?

I believe the answer is, yes, it would. While Linus is a stubborn and opinionated leader ("Benevolent Dictator For Life") it is those qualities, coupled with his extremely high standards, that have preserved the coherence of Linux's system architecture all this time.

I've elsewhere seen described the "Inverse Conway Manoeuvre": make the org fit the emerging architecture.

We do this at work. It mostly works, modulo "Distributed Systems Are Hard".

There is an unsubstantiated ocean between the "Therefore" beginning the last paragraph and the paragraphs before it. If anything, the author's data points lead me to draw the opposite conclusion.

The statistics seem to be obviously incorrect, there is no discount for the distribution of the number of files that a contributor might author/have a significant effect on. Since most contributors will have made a small number of contributions, this is a large bias.

The graph that would ultimately support the point of the article would have the difference between a simulation of a uniform distribution of contributions by the authors, and have a full 0-100% axis for scale, as opposed to the 35-65% presented in this article.

> the Degree-of-Authorship (DOA) measure to define the authors of each file in a system

But in source control, author is typically defined as the first contributor to a file, which doesn't always reflect the person who contributed the most content to the file.

In my experience, while the statistics that the article quotes are obviously correct, the reasons have very little to do with the architecture, and they very much mimic the way that the "community" works. Linux' architecture has very little to do with why communication (and contributions) are the way they are. In fact, the architecture is largely designed precisely so that it can withstand the sort of organizational pressure that the Linux kernel faces. See, for example, the recent(-ish) rejection of AMD's drivers: they got rejected because they included a HAL, which -- based on previous exeperience -- is usually a bad idea in an open system, as it tends to depend on highly organization-specific knowledge, and the volume and difficulty of maintenance work makes it difficult to manage by a non-committed community once the main owner drops it for greener pa$ture$.

The very separation that the article draws "core" vs "drivers" is actually highly representative of how the Linux community is structured. Most of the core work (including the driver subsystem's backbone) is done by long-term contributors who actually work on the Linux kernel full time. Most drivers actually come from occasional contributors.

Driver contributions are "specialized" for the same reasons why they're specialized on pretty much any non-hobby operating system, namely:

1. The expertise required to write complex drivers mainly exists within the organization that sells the hardware. Needless to say, these people are largely paid -- by the hardware manufacturers! -- to pay drivers, not contribute to what the article calls core subsystems. There are exceptions ("trivial" devices, such as simple EEPROMs in drivers/misc, are written by people outside the organizations that sold them), but otherwise drivers are mostly one-organization shows. In fact, for some hardware devices, "generalists" don't even have access to the sort of documentation required to write the drivers in the first place. (sauce: wrote Linux drivers for devices that you and me can't get datasheets for. $manufacturer doesn't even bother to talk to you if you aren't Really Big (TM))

2. Furthermore, there really are subsystems in the kernel that are largely a one-company show and are very obvious examples of Conway's law. IIO drivers, for instance, while started by Jonathan Cameron who, IIRC, is really an independent developer, are largely Intel' and Analog Devices' -- to such a degree that, even though they follow the same coding conventions, if you've worked there enough, you can tell who wrote a given snippet. Same goes for most of the graphics drivers. Most of Infiniband used to be IBM, I think. If you dig down in the drivers subsystems, you'll see even funnier examples (my favourite example are ChipIdea USB controllers; a few years ago, support for USB slave mode on some Broadcom SoCs broke down because Freescale pretty much took over de facto ownership of the drivers, and some of their changesets worked fine on their ARM cores, but broke on Broadcom's funky MIPS-based cores)

Also, this is very weird to me:

> Adherence to Conway's Lay (sic!) is often mentioned as one of the benefits of microservices architecture.

Back in My Day (TM), adherence to Conway's Law was usually considered a negative trait, summarized by the mantra that, in the absence of proper technical leadership, an organization of N teams tasked with writing a compiler is going to produce an N-pass compiler.

Of course, this is a most negative example, but are we really, seriously considering that adherence to Conway's law is a positive thing today? That it's actually a good idea for the architecture of a software system to reflect the "architecture" of the team that created it, rather than, you know, the architecture that's actually best for what it's meant to do?

Could this be related to the fact that all communication between Linux devs is done by email?