> The curse: coordinating efforts across a volunteer community was challenging…
> …Since Thunderbird was being contributed to by many volunteer contributors with varying tastes, it resulted in an Inconsistent user interface without a coherent user experience.
Brooks' "The Mythical Man-Month" really never stops giving.
You don't actually get more efficient by moving to a giant decentralized volunteer engineering workforce -- someone has to coordinate all that, or else what you're going to get is a mess, both under the hood and in what is visible. And coordinating all that is hard and resource-intensive, the more so the _more_ developers involved.
Some open source projects manage to do that coordination with a decentralized volunteer coordinating staff (although in many cases, it's not truly "volunteer", it's people being paid by various employers collaborating across organizations/employers -- this was in fact most of original open source success stories). But it's not easy. And requires stability and tenure in that decentralized coordinating staff, to hold the vision, and to have the relationships to work together in a unified way. (A "benevolent dictator" is another way to do it).
The hardest part of developing software that is too much for one person to do by themselves (and that one person never leaves), is always the inter-personal communication, coordination, and shared-mental-model-making-and-sharing, not the coding.
So anyway, without being involved in Thunderbird at all, I totally believe this story, and that bringing it back into an organization of paid employees as a core was necessary to prevent complete disintegration (I mean, other organizational solutions are possible too, but they are all even more challenging, this is the simplest), because... that's how it works.
One entity (person/group) with a strong product vision + a giant decentralized workforce is pretty much how everything gets built. The actual people putting hands to keyboard have the mythical man month thing going for them.
The part of mythical man month I was thinking of, which I consider the most famous/useful take-away, is how adding people to a project will not necessarily make it go faster, because the more people, the more coordination work -- and Brooks paid a lot of attention to the fact that the "coordination work" isn't just, like, issuing orders and monitoring people, but involves building and sharing and maintaining "mental models", a vision for how it all goes together in a consistent and coherent way.
i don't think that vision can be developed and maintained succesfully only by people who never get their hands dirty, it needs to be iteratively developed with constant feedback from the work itself and it's reception, if it is to be successful.
> it needs to be iteratively developed with constant feedback from the work itself and it's reception, if it is to be successful.
There's a danger here too in that you can iterate on a design in a "monolithic" way where you iterate over a brittle design that's still hard to work with years later because you need to reload the entire system into your brain to make sense of it again.
Looking at Unix as an open source design success story, it was designed in relatively well-defined "layers". So for example it can get away with making literally everything a "file" with a common file interface, even if you're actually working with a physical peripheral or a "black hole" like /dev/null. And on these layers you can build all kinds of different implementations.
I try to push for a similar approach even on proprietary projects because if we can compartmentalize what we need to know to work with the pieces of our systems, they'll be easier to understand with less effort than if we need to understand everything about them before iterating on them.
And this can be passively "encouraged" by how the work is divided across teams/workgroups to leverage Conway's Law (which can also just as easily lead to software components that don't make any engineering sense if people aren't conscious of the effect their organization has on their software's organization).
> …Since Thunderbird was being contributed to by many volunteer contributors with varying tastes, it resulted in an Inconsistent user interface without a coherent user experience.
Brooks' "The Mythical Man-Month" really never stops giving.
You don't actually get more efficient by moving to a giant decentralized volunteer engineering workforce -- someone has to coordinate all that, or else what you're going to get is a mess, both under the hood and in what is visible. And coordinating all that is hard and resource-intensive, the more so the _more_ developers involved.
Some open source projects manage to do that coordination with a decentralized volunteer coordinating staff (although in many cases, it's not truly "volunteer", it's people being paid by various employers collaborating across organizations/employers -- this was in fact most of original open source success stories). But it's not easy. And requires stability and tenure in that decentralized coordinating staff, to hold the vision, and to have the relationships to work together in a unified way. (A "benevolent dictator" is another way to do it).
The hardest part of developing software that is too much for one person to do by themselves (and that one person never leaves), is always the inter-personal communication, coordination, and shared-mental-model-making-and-sharing, not the coding.
So anyway, without being involved in Thunderbird at all, I totally believe this story, and that bringing it back into an organization of paid employees as a core was necessary to prevent complete disintegration (I mean, other organizational solutions are possible too, but they are all even more challenging, this is the simplest), because... that's how it works.