Developer skills and code modularity: Does one trump the other?

I came across an interesting paper [PDF] today on the intersection between modularity and developer skill in open source projects. I’m often a cheerleader for greater modularity in software, open or closed, but this research (from Giuri Paola, Matteo Ploner, Francesco Rullani, and Salvatore Torrisi, entitled “Skills, Division of Labor and Performance in Collective Inventions. Evidence from the Open Source Software”) suggests that modularity and division of labor works best when done by a cohesive team of skilled developers:

Our results indicate that projects with a large number of modules and homogeneous skill sets (as well as projects with few modules and heterogeneous skills) outperform highly modularized projects with heterogeneous skill sets. Why do projects that have adopted a more decentralized design approach, signalled by a large number of presumably independent subprojects, benefit from limited skill differences among participants?

To answer this question we should remind that OSS is a collective invention based on modular product architectures. However, there are differences among projects in terms of product complexity (i.e., the strength of interdependencies among modules) or the design strategy pursued by project leaders. The division of the collective invention labour is then affected by product complexity. A higher level of complexity reduces the possibility to divide the work into separate tasks (subprojects) and leads to a more centralized division of labour. In a centralized setting coordination costs among different interconnected tasks and contributors are quite limited. The benefits arising from differences in skill experience among participants (e.g., mutual learning and creativity) then can be easily translated into higher levels of productivity with limited effects on coordination costs and the control of system interdependencies (among tasks and modules). The productivity gains of this division of collective labour then draws on the benefits typical of a workshop-like knowledge production system. The flexibility of the system does not rely much on organizational modularity but depends on skill diversity, imitation and knowledge transfer among participants.

Projects with a large division of problem-solving labour among subprojects probably focus on less complex product architectures, i.e., a high level of modularity and finer problem decomposition. In this organizational setting, corresponding to a ‘factory-like’ production approach, problem solving is more decentralized and knowledge is highly partitioned. This can bring about higher level of skill diversity among participants. Marked differences among participants (e.g., in skill experience) imply mutual learning, creativity and many potential inputs. However, the variance in the quality of inputs tends to increase with the level of heterogeneity of contributors and this imposes high monitoring costs on project core developers. Our results suggest that the monitoring costs associated with high skill variety tend to overcome the benefits when problem solving is decentralized (i.e., modularity is high)….

We argue that these two models of OSS organization highlight a classical trade-off between ‘creativity’ and ‘control’. High levels of skill diversification are good for ‘creativity’ but impose substantial management costs. A high level of skill diversity yields greater variance in the quality of contributions and calls for more control and coordination efforts. When the number of subprojects increases the costs of skill diversity tend to overcome the benefits arising from creativity. (30-31, 38-39)

On its face, this may seem obvious: you want everyone to be of equal, superior talent. But it’s not necessarily congruent with what we often hear in the open source world. We tend to promote the idea of a global pool of developers with little concern for the relative quality of their contributions. But it seems intuitive that the worse the quality of contributions, the higher the code management costs.

Maybe this means that it’s better to have less, but better community? Thoughts?