Introduction

The production of innovation and knowledge increasingly relies on collective efforts. For example, teamwork is crucial in scientific research, where teams have demonstrated their effectiveness in fostering groundbreaking discoveries1,2,3, or in industry, where teamwork is essential for the rapid development of innovative solutions4. The effectiveness of teamwork depends on the continuous integration of specialized knowledge of individuals5,6, and the ability to leverage constructive conflicts to generate novel insights7,8. Extensive research has investigated characteristics of team members that are associated with performance9, from the effect of team size3, the interdependencies among team members10, and their diversity in terms of gender11,12,13,14,15, expertise16, prior experiences2,17, and ethnicity18,19. In this way, the results of such collaborative efforts often go beyond the sum of individual contributions thanks to the emergence of synergies among team members20,21, conditional on the team’s organization.

In a team, not all members are equal22. Successful teamwork often relies on the management of tensions by leaders23,24, who organize work through the division of complex tasks into sub-tasks among different team members25. Even in self-organizing teams, lacking a predefined hierarchical structure, specific team members can emerge as leading figures who carry out a sizeable fraction of the work and are eventually responsible for the project advancement26,27,28. The organizational dynamic and evolving nature of teams impact team structure over time, as roles and responsibilities shift to adapt to new challenges29,30. For instance, adjustments in the distribution of labor, the emergence and shift of leadership, and the turnover of team members all hinder coordination in teams, explaining why social and coordination skills are growing in value as teams get larger and teamwork more prevalent31.

Indeed, various conceptual frameworks have highlighted the need to explicitly consider team dynamics to properly understand how teams function and their success30,32,33. Nevertheless, most of the insights we have consider teams as static entities, with little empirical research accounting for their temporal evolution. This is largely due to difficulties in accessing or collecting temporal data tracking and measuring team activities across time34,35. In science, benefiting from the availability of large-scale curated publication data, a few studies have recently explored the concept of “persistent teams” 36 – researchers who consistently collaborate together over time – showing that “fresh” teams made of new collaborators produce more impactful research37. However, publication data only records the outcome of teamwork, lacking information about the process of the collaborative effort, such as the specific contributions and activities of the authors of each paper. An exception is the analysis of email communications within research teams, which can provide insights into individual contributions and team dynamics38.

In organization theory, team activity is typically tracked through multi-period observations, where team members are surveyed at various intervals. Yet this approach suffers from inherent limitations of low temporal resolution because it would necessitate frequently surveying team members. Such frequent surveys can disrupt teamwork and lead to survey fatigue, eventually compromising data quality and preventing the effective investigation of team dynamics at a microscopic scale34. While fine-grained data about team processes can be collected through other methods like sensors that generate real-time data39 or in controlled laboratory experiments40, these approaches typically cover only a limited number of teams and are difficult to scale.

Open-source software development offers an ideal opportunity to investigate collaborative dynamics at a large scale and with a fine-grained resolution41,42,43,44. In this context, software developers typically track changes to the software codebase using version control systems (e.g., Git) and store their software in online public repositories (e.g., GitHub). For instance, by analyzing the contribution history of a project via its commit log (a record of every edit made to code), it is possible to obtain information about who made which modification to the software and when. The analysis of this source of data has identified patterns where few developers often perform the majority of contributions in a project and most developers make few45,46,47. This tendency towards centralization, widespread across collaborative software development, has been employed to develop heuristics to identify the core members of teams48. Changes in the activity of core developers, as well as changes in its composition, can offer novel insights about how teams function and the relationship to project success49. The dynamics of the main developers may vary significantly across projects. For instance, Linus Torvalds, who created the Linux kernel in 1991, still dominates the development effort of the project50 and defines himself as a “benevolent dictator of Planet Linux” 51. On the other hand, Pandas’ creator Wes McKinney stopped actively working on Pandas after five years52 and other developers have succeeded as the main developers of the project53. While both Linux and the Pandas library are examples of successful projects, their contrasting leadership dynamics highlight a gap in our understanding of the causes and consequences of the emergence of key team members, their potential turnover, and the effect of such changes on project success.

To advance the understanding of team dynamics in open-source software projects, we analyze teams’ activity within three software ecosystems – Rust, JavaScript, and Python – along with their success metrics. First, we examine the distribution of work as reflected by the distribution of commits among team members, study the activity patterns of the lead developers – users responsible for the largest share of commits – and correlate it with project success. Then, we identify repositories where the lead developer changes during the project’s lifespan, identifying profound redistribution of workload and a potential reorganization of the team. Finally, we investigate the association between the change of lead developer and the success growth of the project after the transition by comparing those repositories to similar ones that did not change the lead developer. Our findings, consistent across the three software ecosystems, demonstrate the interplay of team dynamics and performance in open-source software projects, suggesting that changes in team organization have implications for the success of the project.

Results

We leverage three datasets tracking the activity of software developers working on GitHub repositories hosting packages from three popular programming languages: Rust, JavaScript, and Python. For Rust, we rely on a well-curated dataset covering over 40,000 developers working on more than 6000 repositories between 2014 and 2022, including their success time series54,55. The JavaScript and Python datasets are about four and two times bigger, respectively, with activity from 2010 to 201856,57. We supplement these two datasets by collecting success time series data (see Supplementary Section S3 of the Supplementary Material).

In the main text, we present results focusing on the Rust ecosystem because it offers the greatest level of detail and coverage of the three systems. Indeed, as Rust was released in 2015, we have access to comprehensive temporal data on project development and GitHub-specific metrics such as stars. Moreover, the Rust package manager records download data since release. Javascript and Python, on the other hand, were created in the 1990s, well before the creation of GitHub, which limits our ability to collect comprehensive data on these languages. Similarly, data on downloads for Python and Javascript libraries are available only for limited time periods. Despite these limitations, we can still run our analyses in these much larger and longer-running systems and our substantive findings on team dynamics and project success are consistent across all three languages. We provide detailed information for JavaScript and Python in Supplementary Section S3 of the Supplementary Material.

Emergence of a lead developer

Software developers track their changes to the software codebase through commits, whose distribution across team members can measure their work contributions47 and be informative about their roles in a project48. After having verified that most of the commits refer to actual coding activities (see Supplementary Fig. S1)58, we begin by analyzing the distribution of commits among team members to characterize the distribution of work in software development teams. We define a team as the set of developers who make at least one commit to a repository. By ranking the developers of a repository by their total number of commits, we measure the fraction of commits authored by developers as a function of their rank. Figure 1a shows that the most active developer (rank = 1) authors more than half of the total number of commits. In contrast, the second most active developer typically accounts for only around 10-20% of the total, while the rest is done by the other team members. This observation highlights the presence of a “lead developer” who carries the majority of the workload in a repository, alongside other developers contributing to a lesser extent. Those properties are consistent across teams of different sizes as shown in Fig. 1a (see Supplementary Fig. S2a for the distribution of repositories across different team sizes), through the lifetime of repositories (see Supplementary Fig. S6), and cannot be explained by random activity of developers (see Supplementary Fig. S4). This persistent nature of the workload distribution suggests a possible advantage from such a centralization.

Fig. 1: Workload distribution within teams and relationship with success.
figure 1

a Median fraction of commits authored by the r-th most active developer of a repository stratified by team size. The most active developer makes more than half of the total number of commits while other developers contribute substantially less, regardless of the size of the team. Median number of stars (b) and downloads (c) as a function of the relative effective team size stratified by team size. The more heterogeneous the workload distribution in the team, the higher the success. The Spearman’s rank test returns p < 0.001 for all team sizes. The number of stars and downloads are incremented by one unit. Error bars range from the 25th to the 75th percentile of the distributions.

Full size image

One potential aspect where this advantage may manifest is projects’ success. To test for a relationship between heterogeneous workload distribution and success, we first quantify the heterogeneity of the workload distribution using the relative effective team size47. This metric is defined as:

$$\,{{\rm{rel.}}} \, {{\rm{eff.}}} \, {{\rm{team}}} \, {{\rm{size}}}\,={2}^{H}/N$$

where H is the binary entropy of the distribution of commits among team members and N is the size of the team. This measure ranges from 1/N (i.e., one single developer makes all commits) to 1 (i.e., the workload is evenly distributed among all members). Consequently, a smaller relative effective team size indicates a more uneven distribution of commits among team members. Then, we employ the number of stars and downloads as metrics of repositories’ success. Such metrics track two different dimensions of success: stars can be considered as a proxy for repositories’ popularity, similar to likes in social media59, whereas the number of downloads reflects factors such as utility, necessity, and perceived quality. Our analysis reveals an inverse relationship between repositories’ success and their relative effective team size, as displayed in Fig. 1b for the number of stars and Fig. 1c for the number of downloads (see Supplementary Fig. S2b for the distribution of the number of repositories for different relative effective team sizes). The relationship is supported by Spearman’s correlation test, yielding a correlation coefficient of at least ρ = −0.28 for stars and ρ = − 0.11 for downloads across all team sizes (p < 0.001; see Supplementary Table S1 for details). Note that we grouped repositories according to their team size since this is already strongly correlated with success (see Supplementary Fig. S5). To check if the age of repositories affects the results of the correlation, we repeated the analysis considering the relative effective team size and success at different moments of repositories’ lifetime, finding consistent results (see Supplementary Fig. S6 and Supplementary Table S1).

Our observation aligns with prior research on software development teams46, confirming that even in a relatively new programming language such as Rust, the most successful teams of software developers have an uneven workload distribution47. Same findings hold for JavaScript and Python as shown in Supplementary Fig. S18. Furthermore, as already found in45 where three large open-source projects were studied, our results show that the workload distribution becomes heterogeneous already within the first year of activity. Differently from previous studies, in the following we provide a characterization of the behaviors of the lead developers of each repository. Beyond static analyses, we focus in particular on team dynamics, revealing changes in workload distribution and how this impacts a project’s success.

Characterization of lead developers’ activity

Lead developers are not just prolific team members, but they fulfill specific management and coordination roles within their projects. The first aspect that underscores a distinguished role is whether they have direct write privileges, granting them the authority to integrate changes into the repository. We found that all identified lead developers do indeed have this right (see Supplementary Section S1.1 of the Supplementary Material). This privilege extends beyond integrating their own work, but it also confers the authority to review and decide whether others’ contributions are worth being accepted. By searching for commits related to merging pull requests – the principal mechanism of collaboration in GitHub – we revealed that most lead developers are heavily involved in such merging activities (83% of them; see Supplementary Section S1.2 of the Supplementary Material), suggesting that they review and decide which contributions to accept. Finally, coordinating team efforts is critical to managing a project effectively. We therefore assessed lead developers’ roles in coordination by analyzing their centrality in the communication networks built from discussions under issues and pull requests, finding that they frequently occupy the central positions (in 82% of the cases they are among the top-three; see Supplementary Section S1.3 of the Supplementary Material). Taken together, these observations reveal that lead developers fulfill core leadership tasks, from integrating and reviewing external contributions to coordinating team efforts.

We now shift our focus to how the coding activities of leaders differ from those of other developers. We compare the distribution of their inter-commit time, defined as the time elapsed between two consecutive commits authored by the same user (regardless of the repository in which the commit is made). Figure 2a displays the distributions for lead and non-lead developers separately, showing distinct characteristics for those two sets of users. In particular, lead developers exhibit a higher frequency of commits. Indeed, their inter-commit time distribution is left-skewed compared to that of non-lead developers, displaying a prominent peak around 30 minutes (the peak in non-lead developers’ inter-commit time ranges between one day and one week). This difference turns into lead developers being more likely to have longer streaks of consecutive commits, as depicted in the inset of Fig. 2a. The inset shows the probability distribution of making more than E consecutive commits whose inter-commit time is smaller than Δt = 30 min (the observation is robust across other values of Δt as can be seen in Supplementary Fig. S7). Lead developers are indeed three times more likely to make streaks of at least 10 commits (\(P\left(\ge 10\right)=0.0097\)) compared to non-lead developers (\(P\left(\ge 10\right)=0.0030\)).

Fig. 2: Characterization of lead developers’ activity.
figure 2

a Distribution of the inter-commit times and cumulative distribution of the number of commits close in time (inset) for lead and non-lead developers. Lead developers exhibit higher frequency of commits and longer streaks of consecutive commits. b Distribution of the number of repositories in which lead and non-lead developers are active. Lead developers are involved in a larger number of repositories. Box plots indicate median (middle line), 25th, 75th percentile (box) and 5th and 95th percentile (whiskers) as well as outliers (single points). c Distribution of the repository switch time of lead and non-lead developers. Lead developers tend to switch from one project to another on a daily to weekly basis. d Number of downloads across repositories' lifetime stratified by lead developers' experience (median and its 95% confidence interval). Repositories led by experienced developers are downloaded more compared to those led by inexperienced ones. Time is binned into trimesters.

Full size image

Another aspect of the activity pattern of developers is the number of repositories they contribute to. We first show in Fig. 2b the distribution of the number of repositories in which lead and non-lead developers author at least one commit (see Supplementary Fig. S3 for the aggregate distribution). In addition to being the most active developers in their repositories, lead developers contribute to a median of 4 repositories (interquartile range IQR 2–8) while non-lead developers are active in only a median of 1 repository (IQR 1–2). This difference is deemed significant according to the Mann–Whitney U test (U = 96197128, n1 = 3627 and n2 = 32998, p < 0.0001). To gauge insights on the extent to which lead developers work on multiple projects simultaneously, we introduce the repository switch time of developers. This is defined as the time elapsed between a developer’s first commit on a repository and their first commit on a different one, namely the time elapsed between a developer initiating work on one repository and transitioning to another. Figure 2c shows the distribution of repository switch time for lead and non-lead developers separately. The difference with the inter-commit time distribution in Fig. 2a suggests that the trains of consecutive commits shortly separated in time (i.e., inter-commit time of 30 min) are mostly done on the same repository, as lead developers switch from one repository to another on a daily to weekly basis. The rapid decay of the repository switch time after one week, in addition to the number of repositories in which lead developers are active, implies that they work concurrently on multiple projects and focus their efforts within the Rust ecosystem. Non-lead developers rather move between repositories over longer periods. This may be a consequence of non-lead developers being active in fewer projects and possibly being less involved in the Rust ecosystem.

Lead developers often contribute to multiple repositories, and their experience as core members in previous projects might prove beneficial for new endeavours. For this reason, we ask: Does an experienced lead developer impact the success of a repository? We define the lead developer of a repository i as experienced if they have been the lead developer of other repositories before starting to contribute to repository i. We identify 2744 (43%) repositories led by experienced lead developers and show in Fig. 2d the median number of downloads these repositories receive across their lifetime, compared to repositories whose lead developer never led a repository before. We observe that repositories led by developers with previous experience receive more downloads over their lifetime. Since downloads reflect factors such as utility, necessity, and perceived quality, we speculate that developers who led repositories in the past may leverage their previous experience in Rust projects to develop software that is more useful and widely needed. By contrast, it is worth noticing that lead developers’ previous experience does not affect the number of stars, indicating a lack of advantage in terms of popularity (see Supplementary Fig. S8). We verified that the observations are not influenced by the inclusion of repositories with varying ages, as this could introduce bias due to the advantage older repositories may have in accumulating stars and downloads (see Supplementary Fig. S8).

All these observations are mirrored in the other two datasets. Specifically, we show the distribution of inter-commit times in Supplementary Fig. S19a, e, the distribution of the number of repositories where developers are active in Supplementary Fig. S19b, f, the distribution of repository switch time in Supplementary Fig. S19c, g, and the success across time depending on the experience of the lead developer in Supplementary Fig. S19d, h.

Lead developers of repositories can change

Lead developers emerge early in a project and display distinct activity patterns. Does the same individual consistently maintain such a role, or does this figure change in time? To identify such changes, we first aggregate developer activities (i.e., cumulative number of commits) and the success of repositories (i.e., cumulative number of stars and downloads) by trimesters. Then, we consider the lead developer of a repository at trimester t as the one who has made the largest share of commits up to that time (we excluded 206 repositories from the subsequent analyses to ensure the inclusion of repositories displaying meaningful changes; see details in the Methods section). We find that 618 repositories (10%) undergo a change of lead developer, with the majority of such changes occurring between the second and third year of a repository’s lifetime, as shown in Fig. 3a. Most repositories undergoing a change in lead developer experience only one transition (92%). Therefore, we focus our subsequent analyses on the first and second lead developers, hereafter referred to as the old and new lead developers, respectively.

Fig. 3: Lead developers can change across the lifetime of repositories.
figure 3

a Cumulative percentage of repositories undergoing a lead developer change as a function of the number of years since their creation. Around 10% of repositories change their lead developer throughout their lifetime, with the majority occurring within the second and third year of activity. b Fraction of new commits authored by the old and new lead developer before and after the lead developer transition (mean and its 95% confidence interval). After the transition (vertical dashed line), contributions from the old lead developer diminish rapidly. c Percentage of lead-change repositories stratified by the previous experience of the old lead developer. Each point refers to repositories created at a specific year or later. Repositories led by inexperienced lead developers exhibit a significantly higher likelihood to change their lead developer compared to those led by experienced ones, according to Fisher’s exact test. Significance levels are denoted as follows: * for p < 0.05, ** for p < 0.01, and *** for p < 0.001. Error bars refer to 95% confidence intervals of the estimated percentages (Wilson score interval).

Full size image

To further investigate how the transition from the old to the new lead developer occurs, the first aspect we examine is the dynamics of the transition. We show in Fig. 3b the relative number of new commits authored by the old and new lead developer around the time when the transition occurs (i.e., the time when the lead developer changes), averaged across repositories (repositories with no activity in a trimester are omitted). The result indicates a rapid transition with a drop in the activity of the former lead developer. One year before the transition, old and new lead developers make a comparable amount of new contributions on average, i.e., 30% of the total number of new commits. However, while the activity of old lead developers sharply declines, dropping to levels below 10%, the relative contribution of new leads largely increases, ultimately making a heavy portion of new commits (around 65%) in the subsequent year after the change. In particular, in 297 repositories, corresponding to 48% of projects that undergo a change, the old lead developer ceases to contribute entirely through commits. This stop in commit activity does not necessarily indicate a complete departure from the project, as contributors can remain involved in other activities within projects. Indeed, we observe that in 48 of such repositories (16%), old lead developers remain active by engaging in other tasks such as addressing issues and reviewing pull requests. This transition of core team members to administrative roles has been previously observed in open-source software development as a response to an abrupt increase of external attention60, and reflects in new lead developers moving to more central positions in the communication network of the project (see Supplementary Section S1.3 of the Supplementary Material).

Next, we ask if previous experience can explain changes to the role of the lead developer. To account for the temporal dimension, we consider the lead developer of a repository i as experienced if they have been the lead developer of other repositories before becoming the lead developer of repository i. We find that 11% of repositories initiated by inexperienced lead developers undergo a transition of lead developer (388 out of 3519), while this happens to 9% of those initiated by experienced lead developers (230 out of 2646). Although this difference looks small, it corresponds to a 30% increase in the odds of changing the lead developer when the initial lead lacks previous experience and it is deemed significant according to Fisher’s exact test (odds ratio at 1.30, p-value = 0.003). We checked the robustness of the result against the year in which repositories were initiated by conducting additional tests restricted to repositories initiated after specific years. The results, shown in Fig. 3c, confirm that the association remains significant except for the last two years, possibly because of the reduction of the sample size (N = 2339 for 2019 and N = 1027 for 2020). In short, the experience of the initial lead developer is associated with a lower likelihood of change.

Finally, we investigate if lead developers changes may be explained by the success of the project before the change. For instance, existing literature on startups suggests a U-shape relationship between founder departure and growth rate, indicating that founders of startups experiencing either slow or rapid growth are more likely to depart than those of startups with intermediate growth rates61. Interestingly, we find no evidence supporting an association between previous success and the likelihood of changing the lead developer in the future within the Rust ecosystem (see Supplementary Fig. S9 for details).

These results replicate almost entirely in the JavaScript and Python datasets. We provide the cumulative fraction of repositories undergoing a lead developer change in Supplementary Fig. S20a, d, the activity dynamics close to the transition point in Supplementary Fig. S20b, e, and the likelihood of lead developer change depending on the experience of the lead developer in Supplementary Fig. S20c, f. The main difference is the weaker yet significant association between lead developer change and experience in the JavaScript dataset (odds ratio at 1.11, p = 0.02).

Repositories that change the lead developer perform better after the change

With the previous analyses, we have shown that a sizeable fraction of repositories undergo a change of their lead developers, describing the dynamics and factors associated with this turnover. How does such a turnover relate to the repositories’ future success?

To answer this question, we employ a matching approach to compare the success trend of those repositories (named “lead-change repositories”) against the success of similar repositories whose lead developer did not change (named “lead-remain repositories”). Specifically, we design a stringed matching procedure to identify pairs of lead-change and lead-remain repositories that are similar in terms of team composition and success prior to the change of the lead developer (see Methods section for details). To ensure a reasonable fit, we restrict the analysis to a subset of 151 lead-change repositories (24%) displaying meaningful activity and success one year before the change of lead developer (more than 50 commits, 10 stars, and 100 downloads). We then monitor the difference in the success growth at time t (Δt) associated to the lead developer change as

$${\Delta }_{t}={Y}_{t}-\widetilde{{Y}_{t}}$$

where \({Y}_{t}={S}_{t}/{S}_{{t}_{0}}\) is the success of the lead-change repository (i.e., either number of stars or downloads) relative to the last pre-treatment period (t0 = − 1) and \(\widetilde{{Y}_{t}}\) is that of the matched repository. The value of Δt should be close to zero for t ≤ t0, indicating that the lead-change repository and its match exhibit similar success trajectories before the change. After t0, Δt quantifies how the success growth varies in relation to the change of lead developer. We consider Δt for t ranging from \(\left[-4,4\right]\), namely, one year before and after the time in which the change occurs (t = 0).

We find that the change of lead developer is positively related to a stronger growth in success. Figure 4a shows the success difference Δt for stars averaged across the 135 repositories with a suitable match (89% of the lead-change repositories). Notably, the difference in success growth is already positive during the first trimester in which the new lead developer takes over (Δt=0 = 0.05 on average, 95% CI: 0.02–0.09) and keeps increasing during the whole year after the change (one year later, Δt=4 = 0.23 on average, 95% CI: 0.06–0.40). Same results hold for downloads (see Supplementary Fig. S13), thus suggesting that the change of lead developer is associated with faster success growth with respect to both popularity and perceived utility and quality of the software. The values of Δt before the change (t < 0) are close to zero, meaning that the success trends between the lead-change and their matched repositories are close on average before the transition. This underlines the good quality of the matching procedure. To check the robustness of the result, we also consider the median of the success difference Δt, showing that the observed positive association is not due to the skewness of the distribution of Δt (see Supplementary Fig. S13). Moreover, we verified that the observed association is not confounded by the heterogeneity in the skills and abilities of lead developers by performing a fixed effect regression, which yielded consistent results (see Supplementary Table S2). This finding is consistent for JavaScript and Python in both direction and magnitude, as shown in Supplementary Fig. S21a, d.

Fig. 4: Lead developer changes are associated with faster success growth.
figure 4

a Average effect of lead developer change Δt for stars. Repositories' success grows faster compared to similar repositories that did not undergo such a change. Success growth Δt for stars stratified by b the success before the change of lead developer and c the experience of the old lead developer. Worst-performing repositories exhibit a large positive effect following the change, whereas top-performing ones are minimally affected. Repositories started by an experienced lead developer benefit more from the change than those initiated by an inexperienced one. Error bars in (a) and (c) correspond to 95% confidence intervals of the estimated quantities. In (b) box plots indicate median (middle line), 25th, 75th percentile (box) and 5th and 95th percentile (whiskers) as well as outliers (single points).

Full size image

Finally, we investigate how success before the transition and lead developer experience affect success growth. As depicted in Fig. 4b, we find that lowly successful repositories (i.e., those in the bottom 30% of the success distribution) have larger Δt in terms of number of stars when compared to average (i.e., those between the 50th and the 80th percentile) and top (i.e., top 10%) repositories (Kendall’s τb = − 0.18, p = 0.03). This indicates that repositories gaining relatively more visibility after the change of lead developers are the least popular. We found no significant differences in the case of downloads (Kendall’s τb = − 0.01, p = 0.92; see Supplementary Fig. S14). Regarding the previous experience, we observe in Fig. 4c that both repositories initiated by an experienced or not experienced lead developer have a significant growth in terms of stars (Not experienced: Wilcoxon’s T = 1682, n = 72, p = 0.02, one sided; Experienced: Wilcoxon’s T = 1488, n = 63, p = 0.0004 one sided) (see Supplementary Fig. S15 for a discussion of the skewness of Δt). Finally, in Supplementary Fig. S16, we consider the combined effect of both the old and the new lead developer’s experience on success growth. We note that these observations are not in line with what found for JavaScript and Python. Specifically, we observe no difference in Δt for different levels of success before the transition (see Supplementary Fig. S21b, e) and mixed results for what concerns the differential effect of lead developers’ experience on Δt (see Supplementary Fig. S21c, f). These discrepancies may be attributed to intrinsic differences of the software ecosystem under study.

Discussion

In this study, we used fine-grained data about software development teams from three popular programming languages to characterize the temporal dynamics of online collaborative projects. By tracking the activity of the most active contributor, we unveiled the emergence of a lead developer who exhibits a distinctive pattern of activity compared to non-lead developers, with lead developers emerging early in a project lifetime. Moreover, we show how an uneven distribution of workload among team members is positively associated with a repository’s success. We identified a sizeable fraction of projects that undergo a change of their lead developer and revealed an association between such transitions and faster success growth.

Our analysis of open-source projects reports that most of the work is carried out by one or a few developers and that this correlates with higher success. This evidence is well-documented in the literature and spans across different programming languages45,46,47,62,63. One possible explanation for such a correlation is the increase in efficiency due to the concentration of workload among few developers, which is likely to reduce the cost of coordination47,64. At the same time, this distribution of work may result in a concentration of knowledge about the functioning of the software around a few developers, thus posing the project at risk should the main developers leave. Drawing on a well-known concept in the software development literature, projects have a small “truck factor”, meaning that the number of key developers who would need to be incapacitated, i.e., hit by a truck, to prevent further development of the project is small65,66,67,68,69. The tension between efficiency and project sustainability highlights a “high risk, high reward” strategy in open-source software development.

Moving beyond the open-source software development literature, whether a hierarchical or flatter organization fosters better team outcomes is a long-standing debate, summarized by the tension between the functionalist and the conflict perspectives. The former posits that team outcomes benefit from a hierarchical structure because it facilitates coordination, whereas the latter predicts a negative effect because of tensions arising from non-aligned goals across the levels of the hierarchy70. Many empirical and theoretical efforts further demonstrate that such a relationship may depend on task type, task complexity, and additional mediators70,71,72,73,74,75. These cross-cutting observations underscore the lack of an overarching understanding of this relationship and motivate further comparative studies to examine the interplay of domain specifics, team dynamics, and task type on team outcomes. Our findings add to this wider conversation by focusing on open-source development, where uneven team structures appear widespread and are linked to higher success. Notably, recent analyses of top-starred GitHub repositories indicate that highly successful projects often exhibit pronounced hierarchical collaboration structures, suggesting that such patterns of division of labor can indeed thrive in large, complex projects76. Such analyses focus only on a few, large projects, and are difficult to scale77. While our broader, commit-level approach enables an extensive coverage of projects, we acknowledge that it does not allow to detect these nuanced hierarchies or reveal the specialized or modular collaboration patterns that may emerge in the largest teams.

More broadly, our study contributes to the ongoing discourse within the field of team science, particularly by addressing the unresolved question of how changes in team composition affect teamwork34. Although the literature presents mixed findings, where team changes can be either beneficial78,79 or detrimental80,81, there is consensus that changes involving core team members deeply affect team functionality22. Our results are not only in line with these general predictions, but lean towards a positive effect of such changes on team outcomes. In addition, the stronger effect observed for experienced lead developers of Rust projects leaves room to speculate about the importance of experienced developers in setting the stage for successful projects regardless of potential changes in such a fundamental role. This observation raises further questions about the characteristics of the old and new lead developers that may influence such a relationship. Drawing on previous studies, the change of a team member is more beneficial the higher the relative skills of the team members involved in the turnover82. Further research is needed to identify factors that make the turnover more beneficial for team outcomes. Additionally, our study mainly focus on the figure of the lead developer but studying the turnover and eventual shifts in workload distribution among the other team members remains an interesting direction for future research.

While our findings relate the change of the lead developer with a significantly higher success growth, the mechanism behind this association remains unclear. Indeed, this relationship highlights a deep connection between the dynamics of teams and their performance, which leaves room for speculation on whether success drives leadership change or vice versa. For instance, as a result of a rapid increase of attention, projects can attract new contributors, and core developers can shift to organizational roles60. This suggests that an increase in success brings more developers to join the team, thus increasing the probability of changing the lead developer. Since we consider three popular programming languages, a similar mechanism may be in place, which likely increases the number of new contributors to projects and may require teams to adapt and undergo structural changes83. Conversely, leadership turnover can unleash creative forces previously bound up in an organization or team, which drive the increase in the project’s success84. At the same time, in our context we saw that new leaders tend to ramp up their activity in a project before taking over, suggesting that there may be value in a balance of previous collaborative ties and new connections in an evolving team24. In short, further research is needed to shed light on the causality between lead developer change and success.

Even though we analyzed three programming languages, we chose to keep their analyses separate and focus on Rust in the main text. Besides the superior quality of the Rust dataset compared to the JavaScript and Python ones, we believe that our analyses benefit from considering the whole development history of one single programming language at a time, providing a controlled environment to characterize team dynamics in open-source software development. Indeed, considering multiple programming languages together may affect the results because coding practices differ depending on the programming language. For instance, it has been shown that different programming languages have varying levels of productivity and require unequal effort to write the same code85,86. In addition, we cannot have access to complete success time series for relatively old programming languages such as JavaScript and Python. Indeed, the success metrics we considered (i.e., GitHub’s stars and downloads) are platform-specific and may not be available for programming languages that are older than software-development platforms, as we may not have data on their repositories’ entire development history. Keeping these challenges and limitations in mind, we have been able to compare such ecosystems obtaining similar results (see Supplementary Section S3 of the Supplementary Material). The generalizability of our findings to three among the largest and most used programming languages indicates that our results may apply to OSS development in general.

Beyond open-source software development, our work provides a fresh perspective on team evolution, leadership dynamics and their relationship to project success, contributing to a deeper understanding of the successful dynamics of collaborative processes.

Methods

In this section, we focus again on the Rust dataset for the sake of consistency with the main text. All the methods were applied consistently to the JavaScript and Python datasets. The major differences regard the construction of the JavaScript and Python datasets, which are detailed in Supplementary Section 3.1 of the Supplementary Material.

Data and selection of repositories

We used data sourced from ref. 54, consisting of a curated dataset containing the activities of developers across 39,671 repositories hosting Rust packages on various online platforms (e.g., GitHub, GitLab). Developers’ activities are tracked through commits, providing a comprehensive record of changes to the project’s codebase, in addition to other activities pertaining more to project management tasks (e.g., pull requests, Q&As). Developers’ user names are disambiguated, and flags identifying bot accounts are provided. The dataset includes platform-specific features that can be used as a proxy for repositories’ success over time. We chose to use the number of stars, which can be considered the most reliable measure of popularity59, and number of downloads, which reflects factors such as utility, necessity, and perceived quality. Stars and downloads provide a multifaceted perspective on the success of repositories. Since stars are only available for repositories stored on GitHub, we discarded those hosted in other platforms (6% of the projects in the datasets).

Inspired by77, we filtered repositories to ensure the inclusion of repositories suitable to study collaborative software development. After discarding the activity of bots, we selected the repositories satisfying the following conditions: (1) first commit with no deletions, (2) total number of lines of code positive across the whole lifetime, (3) first commit in 2014 or later, (4) at least 100 lines of code in total, (5) lifetime of at least one year, (6) at least one commit per month on average, (7) at least one package associated to the repository (since a repository can host more than one package54). Conditions (1) and (2) make us more confident that we study repositories for which their whole history is tracked. Indeed, no repository can be initiated by deleting any line, nor can it have a negative number of lines at any point in its lifetime. Conditions (4-7) select repositories hosting software developed over time and likely discard very small projects. After discarding repositories developed by one single developer, and repositories displaying activity on less than four trimesters, we ended up with a total of 6165 repositories.

Detecting lead developer changes

The lead developer of a repository is defined as the developer with the highest number of commits. However, different developers may be leading the repository at different points in time. To identify changes in lead developers over time, we counted the cumulative number of commits authored by team members at each time period (i.e., trimesters). Then, we defined the lead developer of the repository at time t as the team member that made the largest share of commits up to that time. To avoid the inclusion of spurious changes, such as those in the initial phases of the project when the activity is relatively low, we excluded the repositories that have changed the lead developer within the first three trimesters of activity. Additionally, cases where a lead developer change is followed by the former lead developer re-assuming their role were excluded as well (total repositories discarded Nspurious = 206). This criterion ensures that our analyses rely on repositories in which a meaningful change happened, with the initial lead developer maintaining their position for a significant duration before being succeeded by a new lead developer.

We describe in Supplementary Section S2 of the Supplementary Material a more restrictive definition of lead developer that introduces a statistical test to determine whether the most active developer has a commit count that is significantly larger than the one of the second lead developers. Our findings result robust to this alternative definition.

Matching procedure

To investigate the performance of repositories after the change of their lead developer ("lead-change repositories”), we compared their success trajectory with that of similar ones whose lead developer did not change ("lead-remain repositories"). Specifically, we implemented a matching procedure that, for each lead-change repository, identifies a set of lead-remain repositories that are similar to the lead-change repository in terms of temporal patterns of activity, team composition and success before the change of lead developer happened. Then, we selected the matched repository among those candidates as the one with the most similar success trajectory during the year preceding the change of lead developer.

The details of the matching are as follows. Initially, for each lead-change repository, we identified lead-remain repositories whose first commit date differs by at most six months from that of the lead-change repository. In addition, we required the lead-remain repositories to have lifetime as long as the age at which the lead-change repository changed the lead developer. This ensures that the lead-change repository and its candidates developed within a comparable timeframe. Such a requirement contributes to controlling for the average status of Rust’s ecosystem, thus avoiding potential biases due to the rapid growth of the programming language. In this setting, t = 0 designates the time in which the new lead developer takes over. Then, we refined our set of candidates to select repositories that closely matched the lead-change repository in terms of team composition and prior success for t < 0. The selected set of candidates met the following criteria: (1) similar team size at t = − 1 (see Supplementary Fig. S12), (2) absolute difference in relative effective team size, averaged across \(t\in \left[-4,-1\right]\), smaller than 0.20, and (3) absolute relative difference of (log) number of stars and downloads at t = − 1 smaller than 0.50.

As the last step, we selected the candidate that most closely matched in terms of success growth before the change. To do that, we first defined the success growth as \({Y}_{t}={S}_{t}/{S}_{{t}_{0}}\), where t0 = − 1 refers to the last time period before the change of the lead developer and St is either the number of stars or downloads at time t. In other words, we considered the success growth relative to the success of the repository at the last trimester before the lead developer change. We then chose the matched repository as the one that exhibited the smallest maximum relative difference in success growth during the period \(t\in \left[-4,-1\right]\), considering both stars and downloads. If the maximum difference is larger than 0.50, we discarded the lead-change repository due to the lack of a sufficiently similar repository among the lead-remain ones. Our results are robust against the choice of those thresholds.