Abstract
This study examines the connection between repository structure, productivity, and management practices in software development collaboration. Analyzing open-source projects, it finds higher collaboration in Multi repository teams than in Mono repository teams, implying a nuanced interaction with team size. Effective management and well-structured architectures correlate positively with productivity, emphasizing strategic management's importance for optimizing collaboration and efficiency in software projects.
1 Introduction
The subject matter of software developer team collaboration and software development productivity are not novel concepts within the realm of information technology. In the ensuing discourse, this paper endeavors to explore the dynamics of team collaboration among software developers within varying repository structures and the concomitant impact on productivity levels.
The dataset encompasses an extensive compilation of open-source software development projects, categorized into both Mono repository and Multi repository structures. The collection of these projects was conducted through specialized algorithms, whose intricate details are expounded upon in greater depth in the publication referenced as [1].
The collaboration of software team is not a new concept for the researchers. Up until now most of the academic papers focused on the calculation of team collaboration and the relation between these collaboration levels and other parameters of projects haven't been deeply analyzed. In this paper the term of Repository Structure has been put forward and showed the relation between it and team collaboration, which has never been implemented before. Additionally, the concepts like Branching strategy or Team size and their relationship with team collaboration have been analyzed. By doing this it become possible to show some important results which can be useful for the project managers and software team leaders to plan their project and choose right structure or approach for the software development. Beside all these this paper also shows the new way for the calculation of collaboration, which is taking already used approaches from other researchers but put it in a much simpler and more cost-efficient way. This new approach for the calculation of collaboration covers all the basic principles of previous methods which will be discussed in further sections of the paper.
2 Related works
Software development processes are characterized by their collaborative nature, necessitating the coordination of multiple software engineers to create complex software systems. The software design and architectural patterns have been considered as general and reusable solutions much like hardware [2]. A key aspect of this collaborative effort is the development of a shared understanding among team members, which revolves around various artifacts, each representing its own model throughout the entire development process. Paper [3] defines several goals for team collaboration during software development and one of them can be accepted as the main goal: Manage dependencies among activities, artifacts, and organizations.
The collaboration of developer teams has gained importance in software development, particularly with the popularity of version control systems. Innovations in the field of software development have brought and idea of New Product Development (NPD). NPD is a process used by businesses to conceptualize, design, develop, and bring new products to market. It involves a series of steps that help a company to convert ideas into saleable products or services [4]. According to this concept there are several tools for the improvement of software team collaboration during the development process. Some of the most popular tools can be listed as: Basecamp, Asana, Teamwork etc. These tools and other have gained huge popularity among the developers for last years and several research papers have been published to check the impact of these tools to the collaboration of the software team [5, 6]. But almost none of them show the measurement of the collaboration during the development process.
There are several approaches for the measurement of collaboration in software team. For example, papers like [7, 8], which analyses the collaboration of software team through communication between team members. Basically, in both papers' researchers checked the comments about issues and code changes and checked the level of collaboration among software team. This approach can be quite useful for analyzing single big project where all the communication between team members have been stored or recorded. However, creating this type of communication scheme can take hours even days thus making this process unpractical while working with huge number of projects like in this case. One of the successful analyses about collaboration and productivity can be the paper [9] which uses “pull requests” as a main source in their research. One of the main advantages of this paper is that they created graphs like previous cases, but they used only the Pull Requests (PRs) to do it thus avoiding huge time-consuming tasks like in previous papers. But since they have used only the PRs it can create some inaccuracies. That is why a rather more complex approach has been chosen for the calculation of productivity.
Another similar approach can be observed in paper [10]. Researchers used logs to measure the workload of developers. This way they were able to how much work have been done by each developer and thus calculating the work centralization. This approach is much simpler than the previous ones and can be applied to almost every repository in GitHub platform. Similar approach also will be used in this paper although be it in much simpler and more efficient way.
The investigation into the connection between repository structure and team collaboration did not yield any academic work in this field. This highlights that there are still aspects of software development that have not been thoroughly considered in research on team collaboration.
3 Methodologies
3.1 Database
Due to lack of available database of Mono/Multi repository projects a special approach has been developed to identify and collect Mono and Multi repository projects from GitHub platform. First, several GitHub API queries have been created to get potential Mono/Multi repository projects. Later those repositories were analyzed to identify them. This identification process is based on the structure of each repository type. These structures can be explained by following definitions:
Mono repository (Monorepo): A Monorepo is a centralized development approach where codebases for various projects, along with their histories, branches, and dependencies, are maintained within a single, unified version control system, facilitating holistic management and coordination across projects.
Multi repository (Multirepo): A Multirepo strategy involves managing each project or components codebase in distinct, separate version control repositories, providing greater independence in development, versioning, and release cycles for each project or component.
A machine learning model has been developed to identify Mono repository project according to its file structure. Additionally, we also have developed another ML model for identification of Multi repository projects. This way it becomes much easier to both identify and collect these types of projects. A much more detailed description of model training and other steps can be found in paper [11]. For other researchers the Uniform Resource Locator (URL) of database has been shared [12].
3.2 Collaboration
As it is mentioned in the above chapters, collaboration of the developer team has been analyzed from different aspects so far. Some researchers check the types of collaboration like in [13] or simply improve it by using different methods like [14]. After analyzing all these methods it became clearer that measuring the workload of the team members would be the most suitable approach. First, it is much easier and less time consuming than the first two options. Secondly not every repository contains those different communication logs between developers and other development parameters thus making previous approaches not very suitable for this research. Obviously only measuring the workload share of developers cannot give as the perfect collaboration rate but in this case, it is much more convenient and as it has been mentioned earlier there is already similar approaches which proved the efficiency of this method.
The value of Contributions parameter is given by number, and it represents sum of all activities, which have been performed by developer during development process. To determine if a team has a relatively equal work share among its members, you can calculate the Coefficient of Variation (CV) for the work distribution. The coefficient of variation measures the relative variability of data points compared to their mean (average). So, the algorithm for calculating the coefficient of variation of project is as following:
Calculate the total sum of contributions;
Calculate the mean value of contributions;
Calculate the standard deviation of the contribution values;
Calculate the coefficient of variation.
To make the algorithm more understandable the mathematical formal specification also has been present for it:
Input: A dataset X with n data points:
Output: The CV for the dataset X.
- 1.Calculate the Mean (Mean) value of dataset X:
- 2.Calculate the Standard Deviation (StandardDev) of the dataset X:
- 3.Calculate the CV:
- 4.Return calculated
as result.
A higher coefficient of variation indicates greater variability in work distribution among team members. Perfect collaboration would typically result in a lower coefficient of variation, closer to 0%.
4 Measurements
4.1 Repository structure and collaboration
Figure 1 shows clearly that there is a relationship between repository structure and collaboration rate. Percentage share of high collaboration projects using Multi repository approach is two times more than Mono repository projects. This tendency returns to the opposite for the last two categories, which represent a lower collaboration rate. Here the percentage share of Mono repository project is nearly four times more. It enables us to say that Mono repository projects tend to have medium or low collaboration rates in general.
Percentage share of Mono and Multi repository projects in four main collaboration rates
Citation: Pollack Periodica 20, 1; 10.1556/606.2024.01123
4.2 Productivity vs. collaboration
It is worth mentioning that productivity has been calculated according to the method described in paper [15]. In this method they basically calculate the productivity according to the work intensity of developers. In this approach all activities of each developer have been calculated and activity of bursts has been created. These bursts basically represent how much workload each developer had during the whole development process. If most of the developers in the project have high activity bursts, then this development process is accepted as highly productive. For the sake of clarity, productivity has been divided into three groups which are High productivity, Low productivity, and None. Here High productivity means that the work intensity of the developer for this project has been much higher than usual one and for the Low and None productivity categories this work intensity was lower or zero. This method has been chosen because of the similarities in the databases and perfect balance between the complexity and objectivity of method.
4.2.1 Mono repository
Figure 2 has a similar structure to the previous figure. Here the percentage share of Mono repository projects with high and low productivity has been demonstrated. Figure 2 shows that highly productive projects tend to have also high collaboration rate. For example, in the first category high productive projects has almost 7 times more percentage value than low productive ones. A similar trend also continues in the 2nd category where again high productive projects have more share than low productive ones. However low productive projects have much higher percentage values for lower collaboration rates and this connection enables us to put forward a hypothesis.
Percentage share of high and low productivity of Mono repository projects according to the collaboration rates
Citation: Pollack Periodica 20, 1; 10.1556/606.2024.01123
According to observation it can be said that high productive projects also have high collaboration rates. Obviously there can be done much more research to prove that but our results can shed light for future ones.
4.2.2 Multi repository
Figure 3 demonstrates the results of similar analysis but for the Multi repository projects. In this case some similarities and differences can be seen. In the 1st category, which represents a very high collaboration rate, high productive projects have nearly 12% share while low productive ones have 3%. This is a similar trend with the previous Fig. 2. It shows that high productive projects from both Mono and Multi repository structure have much higher percentage value than low productive ones in the very high collaboration rate. Results are very different from any previously examined trend in the 2nd category of the collaboration rate. Here both high and low productive projects from Multi repository side have almost similar percentage value. One of the possible reasons for this can be overall nature of Multi repository projects.
Comparison of collaboration rate in different productivity levels among Multi repository projects
Citation: Pollack Periodica 20, 1; 10.1556/606.2024.01123
As it is presented in Fig. 1 Multi repository projects tend to have much higher collaboration rate than Mono repository ones, which can explain why the low percentage is observed value in the medium and low collaboration categories in Fig. 3. This again proves that Multi repository projects tend to have much higher collaboration rate rather than Mono repository ones. The productivity level in the Multi repository project was also affected by collaboration rate but not as much as in Mono repository case.
4.3 Commit count vs. collaboration
Figure 4 provides insights into the relationship between commit count and collaboration rate in both Mono and Multi repository projects. The correlation coefficient is approximately 0.40 for both Mono and Multi repository projects as it is shown in the chart. Moreover, it is important to mention that the correlation has been calculated according to the Pearson method and again standard deviation value of collaboration has been used instead of the any percentage or category.
Comparison of commit count and collaboration rate of Mono and Multi repository projects
Citation: Pollack Periodica 20, 1; 10.1556/606.2024.01123
This positive correlation between commit count and collaboration ratios must be understood as a negative way. Since the lower value of collaboration rate (standard deviation) means higher collaboration. Results here are the same for both Mono and Multi repository projects. In both cases there is medium correlation between commit count and standard deviation, which means the collaboration of the software teams decreases when the commit count increases. A huge number of commits means a huge amount of workload, which in the end can be resulted with unfair distribution of workload among the developers. As has been mentioned in the paper the activity of contributors is decreasing as the time project continues, which in this case also can be said about commit count and size of the project. But it again had been kept in mind that the correlation value is medium and there can be other much more complex reasons for that. Also, the database, which has been used, contains only opens source projects from GitHub platform and this view can be different in any commercial or much more professional projects. In the end it becomes clear that there is a medium correlation between commit count and collaboration rate for both Mono and Multi repository projects.
4.4 Development characteristics vs. collaboration
4.4.1 Developer team size vs. collaboration
Figure 5 has some differences from previous charts. In this case collaboration ratio is shown in the x axis of the chart and again Pearson method has been used for the calculation of correlation between team size and collaboration. Since the higher value in the x axis means lesser collaboration, it means that the correlation between team size and collaboration rate is negative which is not very surprising. In both cases the correlation is higher than 0.60, which is above the medium. According to this it clearly can be assumed that collaboration of the small size software team is much higher than big teams in both Mono and Multi repository structures. Also, this chart again proves that Multi repository projects tend to have much higher collaboration rather than Mono repository ones.
Comparison of team size and collaboration rate of Mono and Multi repository projects
Citation: Pollack Periodica 20, 1; 10.1556/606.2024.01123
Additionally, most of the dots from both repository structures are concentrated below the y axis where the team size is 10, which means most of the projects in the database tend to have less than 10 developers in their teams. Again, it is important to mention that these results are solely based on the database and can be different for some specific research or much more professional projects.
4.4.2 Development period vs. collaboration
By employing the following calculations and visual representations, this study aims to provide a clear and concise understanding of the development periods associated with both Mono and Multi repository structures.
Figure 6 presents a comparative analysis of the development period and collaboration rate within both Mono and Multi repository structures. The correlation values depicted in this chart are not as significant as it was in previous case. Despite that, the chart reveals a noteworthy observation: most projects utilizing the Multi repository structure exhibit significantly longer development periods, which aligns with the typical characteristics of this structure. Conversely, in the case of the Mono repository structure, an increase in the development period coincides with a slight decrease in the team collaboration rate, indicating a negative correlation between the two variables.
Comparison of Development period and collaboration rate of Mono and Multi repository projects
Citation: Pollack Periodica 20, 1; 10.1556/606.2024.01123
These findings contribute to the understanding of dynamics between development period, collaboration rate, and repository structures. The disparities observed between the Mono and Multi repository approaches shed light on the unique challenges and considerations associated with each structure. By recognizing these patterns, software development practitioners can make informed decisions regarding the choice of repository structure, considering the potential impact on team collaboration and the duration of the development process.
5 Conclusion
This paper introduces an innovative methodology for quantifying software developer team collaboration, employing the collaboration values provided by the GitHub API for individual contributors. In addition, it offers a distinctive analysis of the interconnections between collaboration and various project parameters, including repository structure, and productivity.
The empirical analysis conducted unequivocally asserts that Multi repository projects consistently exhibit a higher degree of collaboration, while Mono repository projects, in the most cases, demonstrate a relative deficiency.
This paper presents empirical evidence demonstrating that the productivity of Mono repository projects exhibits a positive correlation with collaboration rates. High productivity projects correspondingly manifest elevated collaboration rates, whereas their low productivity counterparts exhibit a diminished level of collaboration. Analogous associations are also observable within Multi repository projects, albeit primarily among those projects characterized by robust productivity and collaboration rates.
5.1 An advice system for optimal team size
According to the driven results from the analysis of this paper it is possible to create an advice system for the estimation of the most optimal team size for projects. This system will work based on choosing the most “successful” projects and give advice about team size based on their parameters. It is also important to mention that in order preserve the unbiased nature of our results we choose the project between the years 2016 and 2023. These types of projects are chosen according to their high productivity and collaboration values.
For example, users can add the parameters of their project (like, development period, branching strategy etc.) and then the model will give them optimal team size suggestion based on the previous similar successful projects. Obviously this model can be improved by adding more and more “successful” projects and even being customized according to the needs of users.
In summation, this paper contributes novel and in-depth analyses concerning software developer team collaboration, alongside an exploration of various project parameters and the developmental processes of projects. These empirical findings augment understanding of the intricate dynamics underpinning collaborative software development endeavors. These findings are important and can be useful for the planning team of the projects, which will help them to choose a more suitable repository structure and branching strategy to improve both productivity and team collaboration.
References
- [1]↑
U. Shakikhanli and V. Bilicki, “Comparison between mono and multi repository structures,” Pollack Period., vol. 17, no. 3, pp. 7–12, 2022.
- [2]↑
G. Kokrehel and V. Bilicki, “The impact of the software architecture on the developer productivity,” Pollack Period., vol. 17, no. 1, pp. 7–11, 2022.
- [3]↑
J. Whitehead, “Collaboration in software engineering: A roadmap,” in Proceedings of Future of Software Engineering, Minneapolis, MN, USA, May 23–25, 2007, pp. 214–225.
- [4]↑
T. J. Marion and K. F. Sebastian, “The transformation of the innovation process: How digital tools are changing work, collaboration, and organizations in new product development,” J. Product Innovation Management, vol. 38, no. 1, pp. 192–215, 2021.
- [5]↑
T. Marion and S. Fixson, “The influence of collaborative information technology tool usage on NPD,” Proc. Design Society: Int. Conf. Eng. Design, vol. 1, no. 1, pp. 219–228, 2019.
- [6]↑
J. F. Marques and J. Bernardino, “Evaluation of asana, odoo, and projectlibre project management tools using the OSSpal methodology,” in Proceedings of the 11th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management, Vienna, Austria, September 17–19, 2019, pp. 397–403.
- [7]↑
T. Wolf, A. Schröter, D. Damian, L. D. Panjer, and T. H. D. Nguyen, “Mining task-based social networks to explore collaboration in software teams,” IEEE Softw., vol. 26, no. 1, pp. 58–66, 2009.
- [8]↑
N. Bettenburg, “Mining development repositories to study the impact of collaboration on software systems,” in Proceedings of the 19th ACM SIGSOFT Symposium and the 13th European Conference on Foundations of Software Engineering, Szeged, Hungary, September 5–9, 2011, pp. 376–379.
- [9]↑
N. Zöller, J. H. Morgan, and T. Schröder, “A topology of groups: What GitHub can tell us about online collaboration,” Technol. Forecast. Social Change, vol. 161, 2020, Art no. 120291.
- [10]↑
S. Saadat, O. B. Newton, G. Sukthankar, and S. M. Fiore, “Analyzing the productivity of GitHub teams based on formation phase activity,” in 2020 IEEE/WIC/ACM International Joint Conference on Web Intelligence and Intelligent Agent Technology, Melbourne, Australia, June 24, 2020, pp. 169–176.
- [11]↑
U. Shakikhanli and V. Bilicki, “Optimizing branching strategies in Mono- and Multi-repository environments: A comprehensive analysis,” Computer Assisted Methods Eng. Sci., vol. 31, no. 1, pp. 81–111, 2024.
- [12]↑
U. Shakikhanli, “Mono/Multi repository database,” Mendeley Data, V1, 2024. https://doi.org/10.17632/3n8mffbf6p.1.
- [13]↑
P. N. Robillard and M. P. Robillard, “Types of collaborative work in software engineering,” J. Syst. Softw., vol. 53, pp. 219–224, 2000.
- [14]↑
T. F. Kusumasari, I. Supriana, K. Surendro, and H. Sastramihardja, “Collaboration model of software development,” in Proceedings of the 2011 International Conference on Electrical Engineering and Informatics, Bandung, Indonesia, July 17–19, 2011, pp. 1–6.
- [15]↑
S. S. Choudhary and C. Bogart, “Modeling coordination and productivity in open-source GitHub projects,” Technical report, no. CMU-ISR-18-101, School of Computer Science, Carnegie Mellon University, 2018.
