If thriving is a metric (is it measurable? too subjective?) of success then the 3 characteristics it must have are:

• modularity: divisible into components
• granularity: fine-grained modularity
• integrability: low-cost integration of contributions

I don't dispute that these characteristics are needed, but they are too general to be helpful, so I propose that we look at these three characteristics through the lens of the type of contributor we are seeking to motivate.

How do these characteristics inform what we should focus on to remove barriers to collaboration for each of these contributor-types?

Below I've made up a rough list of lenses. Maybe you have links or references that have already made these classifications better than I have... if so, share them!

Roughly here are the classifications of the types of relationships to open source projects that I commonly see:

• core developers: either hired by a company, foundation, or some entity to work on the project. These people care most about integrability.

• ecosystem contributors: someone either self-motivated or who receives a reward via some mechanism outside the institution that funds the core developers (e.g. reputation, portfolio for future job prospects, tools and platforms that support a consulting business, etc). These people care most about modularity.

• feature-driven contributors: The project is useful out-of-the-box for these people and rather than build their own tool from scratch they see that it is possible for the tool to work they way they want by merely contributing code or at least a feature-request based on their idea. These people care most about granularity.

The above lenses fit the characteristics outlined in the article, but below are other contributor-types that don't directly care about these characteristics.

• the funder: a company, foundation, crowd, or some other funding body that directly funds the core developers to work on the project for hire.

• consumer contributors: This class of people might not even be aware that they are contributors, but simply using the project returns direct benefits through logs and other instrumented uses of the tool to generate data that can be used to improve the project.

• knowledge-driven contributors: These contributors are most likely closest to the ecosystem contributors, maybe even a sub-species of those, that contribute to documentation and learning the system; they may be less-skilled at coding, but still serve a valuable part of the community even if they are not committing to the core code base.

• failure-driven contributors: A primary source of bug reports and may also be any one of the other lenses.

What other lenses might be useful to look through? What characteristics are we missing? How can we reduce barriers to contribution for each of these contributor types?

I feel that there are plenty of motivations... but what barriers exist and what motivations are sufficient for enough people to be willing to surmount those barriers? I think it may be easier to focus on the barriers to make contributing less painful for the already-convinced, than to think about the motivators for those needing to be convinced-- I think the consumer contributors are some of the very best suited to convince the unconvinced; our job should be to remove the barriers for people at each stage of community we are trying to build.

A note to the awesome folks at Hypothes.is who are reading our consumer contributions... given the current state of the hypothes.is project, what class of contributors are you most in need of?

The first analytic move.

Towards the end of our last conversation the text following "common appropriation" seemed an interesting place to dive into further for our future discussions.

I have tagged this annotation with "meta" because it is a comment about our discussion and where to continue it rather than an annotation focused on the content itself.

In the future I would be interested in exploring the idea of "annotation types" that can be selectively turned on and off, but for now will handle that with ad hoc tags like "meta".

The second analytic move.