|
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? |