In OSS communities, participants can both launch their own projects as repository founders and make voluntary (helping) contributions to the repositories of others (code patches, improvement suggestions, feedback and comments). Interestingly, these activities often tend to be filled out by different individuals and lead to some role specialization. Why exactly such a structure would emerge and persist is not trivial, though. Researchers have drawn on a diverse set of theoretical lenses in the past, however, two perspectives have featured most prominently in the explanations: (1) OSS as reciprocal networks of helping behaviors and (2) OSS as goal-directed agent-based systems. In this project, we aim at reconciling the two prospects by asking the following question: if we better capture the heterogeneity in the contributions peers can make to help each other, will we observe a form of reciprocity that could explain observable patterns in their division of labor?

To this end, we introduce the idea of indirect reciprocity with non-equivalence. Equivalent reciprocity refers to situations wherein A does X for B, and B does X for C, whereas non-equivalent reciprocity occurs when A does X for B, and B does Y for C. The literature on exchange relations has been concerned about the volumes, rather than types, of resources transferred between actors in developing reciprocal relations. With this conceptualization, we argue that the principle of network evolutions in OSS communities is non-equivalent reciprocity, and that non-equivalent reciprocity among OSS contributors can lead to division of labor, particularly when accounting for heterogeneity in types of contributions community participants make on the one hand and receive on the other.

We develop founder-level predictions to test our idea of non-equivalent reciprocity as a driver of OSS repository growth. From the founders’ standpoint, their code repositories grow when receiving more contributions from other participants. Equivalent reciprocity would suggest that they should receive more inputs the more they also contribute to other founders’ projects themselves. On the contrary, non-equivalent reciprocity would suggest that the founders can pay their dues to others in a different way as well; notably, rather than reciprocating by providing code to other projects, they could be seen as giving back to the community by paying close attention to the contributions they received themselves and maintaining their repository in the interest of many.