The diversity measures used in this study are a fascinating window into some unusually measurable communities. The count of contributors and volume of their con

The diversity measures used in this study are a fascinating window into some unusually measurable communities. The count of contributors and volume of their contributions are proxies to many things, including project popularity, ease of contribution, number of approachable fixes (tantamount to how many simple/low-hanging bugs there are), and diversity of use cases exposing the product to new situations (i.e. potential growth of project scope). These things need to align for diversity of contributors' motivations to arise and contributors to approach the project initially, but different things need to arise to sustain involvement: introduction of new bugs, need for completely new features (i.e. a growing project scope), continuing need for refinement of otherwise battle-tested code (i.e. performance gains remaining on the table), and continued relevance as other alternative packages and paradigms rise and fall. I can't wait to read their future work, and I hope it includes measures of project maturity (in the senses of feature-completeness/code quality as well as whether functional scope is growing or not). Surely there are projects that lack contributors for the simple reason that the projects are "done", and surely there are projects where engagement looks like disproportionately many shallow contributions due to immaturity of the product, and surely there are projects that have wider or shallower pools of scope to draw from (as well as management ethoses that readily take on new scope or are avoidant of the same). Some opposing examples are the Linux kernel (eternally growing scope, with huge motivation by many user communities) and libpng (which is relatively fixed in scope, with desirements like security increasing the bar for contributions to an already mature and popular product).