Method and system for predicting loss of open source software long-term contributor based on multi-dimensional features

Abstract

The application discloses a long-term contributor loss prediction method and system of open source software based on multi-dimensional features, belongs to the technical field of information processing and software engineering, and comprises a data layer, a feature layer, a model layer and a monitoring layer; by constructing a long-term contributor state transition model, multi-dimensional features of long-term contributors of open source software are extracted, a long-term contributor loss prediction model of open source software is constructed, and real-time and effective prediction of long-term contributor loss of an open source community is realized.

Description

Technical Field

[0001] This invention belongs to the fields of information processing technology and software engineering technology, and relates to open source software project development prediction technology, and in particular to a method and system for predicting the churn status of long-term contributors in open source software communities based on multi-dimensional features. Background Technology

[0002] Since the late 1980s, open-source software has been driving innovation and creating numerous outstanding products, such as the Linux kernel, Android, and TensorFlow. However, the development model of open-source software is community-driven, and these communities are loosely organized. This loose organization often leads to high contributor turnover, posing a risk to the sustainable development of open-source software communities. In particular, the loss of long-term contributors can have a serious impact on the sustainability of open-source software projects. This is because long-term contributors not only contribute a large amount of code but also participate for a long time, gaining in-depth understanding of the project's technical core and details. In addition, long-term contributors are usually actively involved in various activities, such as code reviews and mentoring newcomers. Cultivating these long-term contributors often requires years of effort from the community.

[0003] To prevent the loss of long-term contributors in open-source communities and maintain their healthy development, it is necessary to establish state transition models for contributors' development cycles within the community. This allows us to understand the possible states a contributor might be in before leaving and the likelihood of transitions between those states. Furthermore, it is necessary to build predictive models for long-term contributor churn to anticipate those who will leave, helping the community intervene early and retain these long-term contributors. Existing technologies have done extensive work on state transition models for core contributors and predictive models for new contributors becoming long-term contributors. These include methods based on social network / collaborative network analysis to identify key contributors, using machine learning techniques to predict the likelihood of contributors becoming long-term contributors, and analyzing project codebase activity to understand contributor behavior patterns. However, these existing technologies suffer from high model complexity, large data requirements, and a lack of real-time predictive capabilities, making them difficult to widely apply and promote in real-world open-source communities. Summary of the Invention

[0004] To overcome the shortcomings of existing technologies, this invention provides a method and system for predicting the churn status of long-term contributors in open-source software communities based on multi-dimensional features. By designing a state transition model for long-term contributors and a churn prediction model for long-term contributors, it supports real-time and effective prediction of the churn of long-term contributors in open-source communities.

[0005] To support real-time and effective prediction of long-term contributor churn, this invention first constructs a long-term contributor state transition model based on the activity history of long-term contributors in the open-source community, which characterizes the state changes of long-term contributors before churn.

[0006] This invention categorizes contributors in open-source communities into ordinary contributors, long-term contributors, non-coding long-term contributors, and churned long-term contributors. Based on a constructed long-term contributor state transition model, this invention obtains contributor states by collecting, processing, and calculating relevant data. The following defines contributor states and the transition methods between states; these terms focus on a specific open-source community.

[0007] A contributor is a developer who has contributed code to an open-source software community (code repository) at least once. Contributors include: regular contributors, long-term contributors, non-coding long-term contributors, and churned long-term contributors. These four types of contributors do not overlap but can be converted into each other.

[0008] Long-term contributors are those who have been contributing code to an open-source software community for at least one year and have demonstrated high productivity during this period, meaning their historical code contribution count ranks in the top 10% among all contributors to the open-source project.

[0009] Non-coding long-term contributors refer to contributors who were once long-term contributors but no longer contribute code, though they may show interest in the project in other ways, such as answering questions and participating in discussions. This invention defines a scenario where, if the time interval between the current time and the time of a long-term contributor's last code commit exceeds their maximum historical coding interval (i.e., the maximum time difference between two consecutive historical code commits observed at the current time), it indicates that the long-term contributor is no longer contributing code and is converted to a non-coding long-term contributor.

[0010] A lapsed long-term contributor refers to a contributor who was once a long-term contributor or a non-coding long-term contributor, but now not only ceases to contribute code for a period of time, but also stops participating in any other activities within the open-source software community; in other words, a contributor who has left the project. This invention defines a contributor as having left the project if the time interval from the current time to their last activity (including code commits, pull requests, comments, and issue reports) exceeds their maximum historical activity interval (i.e., the maximum time difference between two consecutive historical activities observed at the current time).

[0011] Regular contributors refer to contributors who are not long-term contributors, not long-term code contributors, and not long-term contributors who have left.

[0012] Based on the above terminology, this invention provides a long-term contributor churn prediction technology, which can be further used to solve the problem of open source communities' sustainability being difficult to maintain due to the churn of long-term contributors.

[0013] The technical solution of this invention:

[0014] A method for predicting the churn status of long-term contributors in open-source software communities is proposed. Based on log data from the open-source software community, a churn prediction model for long-term contributors is constructed to achieve real-time and effective prediction of churn. The method includes the following steps:

[0015] 1) Identify long-term contributors to the open-source software community based on historical commit data; including:

[0016] Long-term contributors are defined as those whose last code commit and first code commit occurred more than a year apart, and whose total commits rank in the top 10% of all contributors. We constructed a long-term contributor state transition model, which includes the following states: contributor state, long-term contributor state, non-coding long-term contributor state, and churned long-term contributor state. Contributors who reach the top 10% in commit count and have been in the community for more than one year transition to long-term contributor status. Long-term contributors who fail to commit code beyond the maximum commit interval transition to non-coding long-term contributor status. Long-term contributors / non-coding long-term contributors who fail to make any activity within the maximum activity interval transition to churned long-term contributor status.

[0017] By using the GitHub API, you can obtain all the commit records of open source software community projects, including the code commit time and code commit author information;

[0018] Sort the commit records by timestamp to determine the time of each contributor's first and most recent code commit;

[0019] Long-term contributors to the open-source software community are identified by calculating the difference between each contributor's first commit time and most recent commit time and the number of commits made by the contributor.

[0020] 2) Extract data from long-term contributors via the GitHub API, including their issues (number of issues), pull requests, commit comments, issue comments, pull request comments, branches (i.e., the number of forks; on GitHub, contributors can copy a repository by forking), likes, and personal information.

[0021] 3) Extract effective structured information from data features, including the monthly contribution, collaboration, sentiment analysis features, interest shift features, and affiliation of long-term contributors;

[0022] 4) Construct a long-term contributor churn prediction model; including:

[0023] The long-term contributor churn prediction model comprises a data interface module, a core booster module, an objective function module, and a performance evaluation metric module. The data interface module stores and manages data. It extracts data from the file system and performs preliminary processing and cleaning for subsequent modules. Its role is to extract, clean, and store data, providing data support for model training and prediction, while ensuring data integrity and consistency by storing processed data in data frames. The core booster module is the core of the model, responsible for training and prediction. It includes the implementation of the decision tree model and provides interfaces for training and prediction. This module supports various objective functions and evaluation metrics. Its role is to use training data to build a decision tree model and use the trained model to predict new data. We set some key parameters for the core booster. Specifically, we obtained the optimal parameters through grid search, traversing multiple set learning rates, and multiple tunings. The objective function module defines the objective function of the prediction model, guiding the model optimization process. Our objective function... As shown below:

[0024]

[0025] in Represents the cross-entropy function; Let be the complexity of the Kth decision tree; n is the number of samples, representing the number of monthly data samples from all long-term contributors. In our model, we collected a total of 221,525 monthly activity samples from long-term contributors. This represents the actual labeled data, and its value is either 0 or 1. The value is specifically obtained according to the long-term contributor state transition model defined in this invention. When a long-term contributor's commit interval exceeds the historical maximum commit interval, the long-term contributor will transform into a non-coding long-term contributor. Non-coding long-term contributors are highly likely to transform into churned long-term contributors; therefore, we predict here the timing of a long-term contributor's transformation into a non-coding long-term contributor. If the data for a certain month of a long-term contributor... A value of 0 indicates that the long-term contributor will not leave after 3 / 6 / 9 months, meaning they will remain a long-term contributor after 3 / 6 / 9 months. Otherwise, they will leave, meaning the long-term contributor will enter a non-coding long-term contributor state after 3 / 6 / 9 months. The result of the inference from the Kth decision tree is calculated using the following formula:

[0026]

[0027] The input for the i-th sample is a 17-dimensional feature vector, specifically including a long-term contributor's contribution in a given month (number of submissions, number of issues, number of pull requests, number of submission comments, number of issue comments, number of pull request comments, and total number of current historical submissions), collaboration degree (degree centrality, cluster centrality, center centrality, proximity centrality, and eigenvalue centrality of the long-term contributor in the collaboration network in that month), sentiment analysis features (number of positive and negative comments of the long-term contributor in that month), interest shift features (number of forks and stars of the long-term contributor in that month), and affiliation features (the long-term contributor's email suffix determines whether the long-term contributor belongs to a company or organization; 1 if yes, 0 otherwise). L is the cross-entropy function in our model. The complexity of the Kth decision tree is represented by the sum of the number of leaf nodes and the squares of the leaf weights. This guides the optimization process, ensuring the model learns in the correct direction, with the learning rate controlling the convergence speed of the model weights. The performance metrics module evaluates the model's performance. It provides various metrics to measure the model's predictive effectiveness, such as accuracy, precision, recall, and F1 score. Its purpose is to evaluate and measure model performance, helping to select the optimal model. The data interface module provides data to the core booster module for model training and prediction. The core booster module uses the data provided by the data interface module for model training and optimization based on the objective function defined by the objective function module. The objective function module guides the optimization process of the core booster module, ensuring the model's learning direction. After training, the core booster module passes the model's prediction results to the performance metrics module. The performance metrics module calculates evaluation metrics based on the prediction results, providing feedback on the model's performance.

[0028] The long-term contributor churn prediction model takes five-dimensional features as input: the long-term contributor's contribution level in a given month, collaboration level, sentiment analysis features, interest shift features, and affiliation. The model output is the prediction result: whether the long-term contributor will become a non-coding long-term contributor after a period of time (3 / 6 / 9 months). If so, the output is 1; otherwise, the output is 0.

[0029] Model training: We first selected the top 100 open-source software communities by number of likes, and then performed the following filtering:

[0030] a) Projects with no programming language, as these are typically unrelated to software development. For example, the project paper-we-love / papers-we-love is a collection of papers.

[0031] b) Projects that only use GitHub as a mirror, such as torvalds / linux, use Bugzilla as their issue tracking system instead of GitHub's own issue tracking system.

[0032] c) Projects that branch off from other projects.

[0033] We obtained data from 47 open-source software communities. We used five-dimensional feature data from long-term contributors in these communities from community creation to October 2023 as the training dataset. We randomly used long-term contributor data from 80% of the projects in the training dataset as the training set and long-term contributor data from 20% of the projects as the test set. We used GridSearchCV (a hyperparameter optimization method from the scikit-learn library) to perform five-fold cross-validation on the training set. We used Area Under Curve (AUC, defined as the area under the ROC curve and the coordinate axes, hereinafter referred to as AUC) as the evaluation metric for the long-term contributor churn prediction model to determine the optimal parameters (including the number of iterations and the learning rate). We iterated through all model parameters and determined the model with the highest AUC on the test set, thus obtaining the trained long-term contributor churn prediction model. Because the monthly data volume varies greatly among different long-term contributors (for example, some long-term contributors have more than 1,000 issues per month, while some long-term contributors have 0 issues per month), and much of the data does not follow a normal distribution, we use the MinMaxScaler function to normalize all the monthly data.

[0034] 5) Predict the churn status of long-term contributors in open-source software communities;

[0035] Because different time spans have different influencing factors and prediction needs, we use three models to predict the churn rate of long-term contributors after 3 / 6 / 9 months. The model inputs are the current month's contribution, collaboration, sentiment analysis features, interest shift features, and affiliation data of long-term contributors in the current project. The output is whether long-term contributors in the current project will churn after 3 / 6 / 9 months. (The output is 0 or 1; 0 indicates no churn after 3 / 6 / 9 months, and 1 indicates churn). Through our trained three models, we can obtain the churn rate of each long-term contributor in the current project after 3 / 6 / 9 months.

[0036] The above steps enable the prediction of the churn status of long-term contributors in open-source software communities.

[0037] Using the aforementioned method for predicting the churn status of long-term contributors in open-source software communities, this invention also implements a real-time and effective prediction system for the churn of long-term contributors in open-source communities, comprising: a data layer, a feature layer, a model layer, and a monitoring layer.

[0038] The data layer is used to obtain the monthly commit count, issue count, pull request count, comment count, comment content, like count, branch count, and user information data of all long-term contributors to the top 100 repositories by like count and the current system application repository.

[0039] The feature layer obtains data from the data layer and derives structured information features, including contribution, collaboration, sentiment analysis features, interest shift features, and membership relationships.

[0040] The model layer is used to train the long-term contributor churn prediction model, resulting in a well-trained long-term contributor churn prediction model after 3 / 6 / 9 months.

[0041] The monitoring layer is used to infer the churn rate of long-term contributors in the current open-source software community after 3 / 6 / 9 months using a trained long-term contributor churn prediction model. It obtains the list of long-term contributors who will churn after 3 / 6 / 9 months and sends emails and GitHub notifications to the repository administrators via GitHub Actions to list the long-term contributors who will churn (long-term contributors at high risk of churn).

[0042] Compared with the prior art, the beneficial technical effects of the present invention are as follows:

[0043] The technology provided by this invention enables real-time prediction of long-term contributor churn in open-source communities. Through the technical solution of this invention and the embodiments provided below, the churn rate of long-term contributors in open-source communities after 3 / 6 / 9 months can be accurately predicted. On the test dataset, the AUC of the long-term contributor churn prediction algorithm constructed by this invention reached 0.7555 / 0.7417 / 0.7416, respectively.

[0044] By utilizing the technical solution and embodiments provided in this invention, real-time prediction of the loss of long-term contributors in open-source communities can be achieved, filling the gap in the technology for predicting the loss of long-term contributors in open-source communities. Attached Figure Description

[0045] Figure 1 This is an overall flowchart of the method for predicting the churn status of long-term contributors in open-source software communities provided in this embodiment of the invention.

[0046] Figure 2This is a structural block diagram of the system implemented in an embodiment of the present invention. Detailed Implementation

[0047] The present invention will be further described below with reference to the accompanying drawings and embodiments, but the scope of the invention is not limited in any way.

[0048] This invention provides a method and system for predicting the churn status of long-term contributors in open-source software communities. It designs and constructs a state transition model for long-term contributors to characterize the state changes before churn; then, it constructs a churn prediction model to support real-time and effective prediction of long-term contributor churn in open-source communities. This can be further used to address sustainability issues in open-source communities caused by the churn of long-term contributors. By predicting the churn of long-term contributors in open-source communities, community administrators can intervene in advance or retain these long-term contributors to help the stable development of the open-source community.

[0049] This invention is implemented using the GitHub API, GitHub Actions, and XGBoost, and specifically includes:

[0050] The GitHub API is a set of interfaces that allow users to interact with resources on the GitHub platform. These resources include repositories, branches, commits, issues, pull requests, and more. The GitHub API communicates using the HTTP protocol and primarily adopts a RESTful architectural style, providing a rich set of endpoints for users to manipulate various resources.

[0051] GitHub Actions is a continuous integration and continuous deployment service provided by GitHub that allows contributors to automate software development processes on GitHub. By configuring predefined workflows, custom tasks such as building, testing, and deployment can be executed when events such as code commits and pull requests are triggered, thereby automating the software development and release process, improving team collaboration efficiency, and ensuring code quality and reliability.

[0052] XGBoost (eXtreme Gradient Boosting) is a high-efficiency machine learning algorithm based on decision tree ensembles, designed to solve classification and regression problems. It iteratively trains multiple weak classifiers, fitting the residuals of the previous model in each iteration to obtain a powerful ensemble model. XGBoost employs gradient boosting, optimizing the model by minimizing the loss function. It introduces a regularization term in each iteration to prevent overfitting and provides interpretability through feature importance evaluation. Therefore, it performs exceptionally well on various datasets and is one of the most highly regarded algorithms for prediction in software engineering today.

[0053] In its specific implementation, this invention provides a method and system / tool ​​for predicting the churn of long-term contributors in open-source communities. By extracting features from the data of long-term contributors in open-source projects on GitHub and training a long-term contributor churn prediction model, the invention periodically monitors the application's community and notifies community administrators of long-term contributors who are about to churn. Specifically, the method of this invention includes five steps: long-term contributor discovery, data extraction, feature engineering, model building, and periodic monitoring.

[0054] A. Long-term contributor discovery. Based on code-related information in the open-source software community, long-term contributors are identified to obtain the corresponding long-term contributors in the open-source software community. The implementation method is as follows:

[0055] Compared to the loss of ordinary contributors, the departure of long-term contributors has a more profound impact on the sustainability of open-source software projects. Long-term contributors not only contribute important code but also maintain long-term involvement, possess a deep understanding of the project scope, and actively participate in various activities such as code reviews and mentoring newcomers. Cultivating such long-term contributors typically requires years of effort and investment from the community. Therefore, our first step is to identify long-term contributors in open-source software projects. This invention focuses on open-source projects hosted on the GitHub platform. GitHub is the world's most popular hosting platform for open-source and private software projects. We obtained the time and author information of each commit in the repository through the GitHub API, and calculated that authors whose last commit time and first commit time exceeded one year and whose number of commits (number of commits) accounted for the top 10% of the repository were considered long-term contributors in the corresponding open-source software community. The technical challenge of this step lies in the large number of commits in some open-source software communities, the slow retrieval speed, and the problem of data loss due to network interruptions. To address these challenges, we control the amount of data retrieved each time using pagination parameters provided by the GitHub API and concurrently retrieve all commit information of the repository using a thread pool. When the number of pages of data retrieved reaches a certain integer multiple, we persist the retrieved data to reduce the risk of data loss due to network interruptions.

[0056] B. Data Extraction. Collect activity data from all long-term contributors on GitHub. The implementation method is as follows:

[0057] This step is responsible for retrieving the activity data of long-term contributors on GitHub identified in step A. Through the GitHub API, we obtain the monthly commits of all long-term contributors in the open-source software community, including: issues, pull requests, commit comments, issue comments, pull request comments, branches, likes, and personal information. This step can be completed in parallel on the server. The challenge lies in the massive amount of comment data for some repositories, making it difficult to obtain complete data using only the GitHub API pagination parameters (maximum 100 data entries per page, maximum 300 pages). To address this challenge, when retrieving all comment data for a repository, we first obtain the repository's start date information through the GitHub API. Then, by controlling the GitHub API pagination and start time parameters, we retrieve all comment data in batches according to different start times, in ascending chronological order. When persisting the data, we record the start time of the currently retrieved batch of comments.

[0058] C. Feature Engineering. Extract features from long-term contributors, including multiple features across five dimensions, as input to the long-term contributor churn prediction model. The implementation method is as follows:

[0059] To identify whether long-term contributors are likely to become non-coding long-term contributors, we extracted 17 features from five dimensions. These features were proposed based on assumptions about factors that might influence contributor churn, while also considering data availability. We performed feature engineering on the extracted data from the five dimensions (extracting effective structured information from the data obtained in step B). These included:

[0060] C1. Contribution: The contribution dimension includes the following seven characteristics: the number of commits, issues, pull requests, commit comments, issue comments, pull request comments, and the current total number of historical commits for long-term contributors each month. This dimension reflects the contributions of long-term contributors to the open-source community in the current month;

[0061] C2. Collaboration Degree: `git log` is a command in the Git version control system used to view the commit history of a repository. This command displays all commit records, including commit information, author, date, and commit hash for each commit. We use `git log` to obtain the author and file information of each month's commits in the open-source software community. Then, we construct a collaboration network for the open-source software community. Using contributors as nodes, if the files submitted by contributors overlap, we connect the contributors with an undirected edge. We use the `networkx` library in Python to extract five features—degree centrality, cluster centrality, center centrality, proximity centrality, and eigenvalue centrality—from the monthly collaboration network as collaboration degree features.

[0062] C3. Sentiment Analysis: Sentiment analysis is performed on monthly submissions, question comments, and pull request comments from long-term contributors using the Roberto ROBERT model, outputting positive, neutral, or negative. We obtain the sentiment attribute of each comment for each month from long-term contributors using the Roberto ROBERT model. Then, we separately count the number of positive and negative comments for each long-term contributor each month. Finally, we use the number of positive and negative comments from long-term contributors as the two features for the sentiment analysis dimension.

[0063] C4. Interest Shift: Since long-term contributors often fork or star other open-source software communities, it usually indicates that they have developed an interest in those communities. Therefore, the number of forks and stars a long-term contributor makes in a given month serves as a characteristic for assessing whether their interest has shifted.

[0064] C5. Affiliation: Determine whether a long-term contributor belongs to a company or organization by the email suffix of the contributor. This is a characteristic of the affiliation of long-term contributors.

[0065] In step C3, when acquiring the sentiment characteristics of long-term contributors within the community, previous methods mostly used SentiStrength or SentiStrength-SE. However, our ROBERT method better utilizes GPU performance for more efficient computation and reduces the false positive rate for negative comments. ROBERT (Robustly Optimized BERTPretraining Approach) is a method to optimize the BERT model. By extending training time, increasing data volume, removing the next-sentence prediction task, adjusting hyperparameters, and using a dynamic masking strategy, it improves the model's generalization ability and accuracy. Its underlying principle is based on the Transformer architecture and self-attention mechanism, which can efficiently capture global contextual information in sequences. In sentiment analysis tasks, the optimization of ROBERT enables it to more accurately understand and analyze the sentiment tendency in text, thus providing more accurate sentiment classification results.

[0066] D. Model Construction. Construct and train a long-term contributor prediction model to obtain well-trained long-term contributor prediction models at different time granularities. The implementation method is as follows:

[0067] The model comprises a data interface module, a core booster module, an objective function module, and a metrics module for evaluating model performance. The data interface module stores and manages data. It extracts data from the file system and performs preliminary processing and cleaning for subsequent modules. Its role is to extract, clean, and store data, providing data support for model training and prediction while ensuring data integrity and consistency by storing processed data in data frames. The core booster module is the core of the model, responsible for training and prediction. It includes the implementation of the decision tree model and provides interfaces for training and prediction. This module supports various objective functions and evaluation metrics. Its role is to use training data to build a decision tree model and use the trained model to predict new data. We set some key parameters for the core booster as follows: For predicting long-term contributor churn after 3 months, the learning rate is 0.05 and the number of decision trees is 80. For predicting long-term contributor churn after 6 months, the learning rate is 0.02 and the number of decision trees is 100. For predicting long-term contributor churn after 9 months, the learning rate is 0.05 and the number of decision trees is 70. The above parameters were obtained through grid search, iterating through learning rates of 0.01, 0.05, 0.1, 0.4, 0.5, and 0.6, and tuning to the optimal parameters at 10, 20, 30, 40, 50, 60, 70, 80, 90, and 100. The objective function module defines the model's objective function, which guides the optimization process. Our objective function is shown below:

[0068]

[0069] Where n is the number of samples, representing the number of monthly data samples from all long-term contributors. In our model, we collected a total of 221,525 monthly activity samples from long-term contributors. This represents the actual labeled data, with a value of 0 or 1. According to our defined long-term contributor state transition model, when a long-term contributor's commit interval exceeds the historical maximum commit interval, the long-term contributor will transition to a non-coding long-term contributor. Non-coding long-term contributors are highly likely to transition to churned long-term contributors; therefore, we predict the timing of long-term contributors transitioning to non-coding long-term contributors. If the data for a long-term contributor in a certain month... A value of 0 indicates that the long-term contributor will not leave after 3 / 6 / 9 months, meaning they will remain a long-term contributor after 3 / 6 / 9 months. Otherwise, they will leave, meaning the long-term contributor will enter a non-coding long-term contributor state after 3 / 6 / 9 months. The result of the inference from the Kth decision tree is calculated using the following formula:

[0070]

[0071] The input for the i-th sample is a 17-dimensional feature vector, specifically including a long-term contributor's contribution in a given month (number of submissions, number of issues, number of pull requests, number of submission comments, number of issue comments, number of pull request comments, and total number of current historical submissions), collaboration degree (degree centrality, cluster centrality, center centrality, proximity centrality, and eigenvalue centrality of the long-term contributor in the collaboration network in that month), sentiment analysis features (number of positive and negative comments of the long-term contributor in that month), interest shift features (number of forks and stars of the long-term contributor in that month), and affiliation features (the long-term contributor's email suffix determines whether the long-term contributor belongs to a company or organization; 1 if yes, 0 otherwise). L is the cross-entropy function in our model. The complexity of the Kth decision tree is represented. Its role is to guide the model's optimization process, ensuring the model learns in the correct direction, where the learning rate controls the speed of model weight convergence. The performance metrics module evaluates the model's performance. It provides various evaluation metrics to measure the model's predictive effectiveness, such as accuracy, precision, recall, and F1 score. Its function is to evaluate and measure model performance, helping to select the optimal model. The data interface module provides data to the core booster module for model training and prediction. The core booster module uses the data provided by the data interface module to train the model and optimizes it according to the objective function defined by the objective function module. The objective function module guides the optimization process of the core booster module, ensuring the model's learning direction. After training, the core booster module passes the model's prediction results to the performance metrics module. The performance metrics module calculates evaluation metrics based on the prediction results, providing feedback on the model's performance.

[0072] The input to the long-term contributor churn prediction model consists of five features: the long-term contributor's contribution level in a given month, collaboration level, sentiment analysis features, interest shift features, and affiliation. The model output is a prediction: whether a long-term contributor will become a non-coding long-term contributor after a certain period (3 / 6 / 9 months); if so, the output is 1; otherwise, the output is 0. This step requires building our long-term contributor prediction model. We obtained data on all long-term contributors from the 100 most popular open-source software communities through the GitHub API as our training data. These repositories have a long history, a large number of long-term contributors, and are sufficiently representative. After further filtering, we obtained 47 open-source software communities, including:

[0073] Projects without a programming language are excluded because they are typically unrelated to software development. For example, the project paper-we-love / papers-we-love is a collection of papers.

[0074] Projects that only use GitHub as a mirror, such as torvalds / linux, use Bugzilla as their issue tracking system instead of GitHub's own issue tracking system.

[0075] Projects that branched off from other projects.

[0076] We used five-dimensional feature data from long-term contributors in these 47 open-source communities, spanning from community creation to October 2023, as our training dataset. We randomly used data from 80% of the projects in the training dataset as the training set and data from 20% of the projects as the test set. We used GridSearchCV (GridSearchCV is a hyperparameter optimization method that exhaustively searches through predefined combinations of hyperparameters. For each parameter combination, GridSearch trains and evaluates the model, ultimately selecting the best-performing combination) from the scikit-learn library to perform five-fold cross-validation on the training set. AUC was used as the evaluation metric for the long-term contributor churn prediction model to determine the optimal parameters (including the number of iterations and the learning rate), resulting in a trained long-term contributor churn prediction model. Because the monthly data volumes from different long-term contributors vary significantly, and much of the data is not normally distributed, we used the MinMaxScaler function to normalize all monthly data. Then, we trained three models using XGBoost to predict whether long-term contributors would churn after 3, 6, and 9 months. For the XGBoost model, we split the dataset (training and testing sets), performed data preprocessing (including normalization using MinMaxScaler), tuned parameters using grid search, set the evaluation function (AUC), and trained the model using the `xgboost.fit` method in sklearn. The uniqueness of our model lies in using a representative and diverse dataset to ensure the broad applicability of the prediction results. We also introduced an innovative five-dimensional feature to enhance the model's accuracy. Finally, we provided multi-stage, finer-grained prediction results to facilitate project managers in implementing different intervention measures.

[0077] E. Timed monitoring. The implementation method is as follows:

[0078] Finally, we need to promptly report our predictions to the open-source community administrators. Using GitHub Actions, we will trigger the predictive model daily to obtain information on long-term contributors to the current open-source software project, perform data extraction and feature engineering, and then use the trained model to infer the churn rate of long-term contributors after 3, 6, and 9 months. For long-term contributors who are about to leave, we will notify the designated administrators via email or GitHub.

[0079] As a preferred approach, the results of historical extractions in step B are cached on the server, and only the data of the latest month is extracted at regular intervals each month. This reduces duplicate data extractions and greatly reduces time.

[0080] As a preferred solution, step D is implemented by caching the feature data of long-term contributors from the 100 most popular repositories on the server, and extracting only the data from the latest month at regular intervals each month. This reduces redundant data extraction and greatly reduces time.

[0081] The tool design provided by this invention supports real-time prediction of long-term contributor churn in open-source communities. Through the technical solution and embodiments provided by this invention, the churn rate of long-term contributors in open-source communities after 3 / 6 / 9 months can be accurately predicted. On the test dataset, the AUC of the long-term contributor churn prediction algorithm constructed by this invention reached 0.7555 / 0.7417 / 0.7416, respectively.

[0082] like Figure 2 As shown, in a specific implementation of the present invention, the prediction method for the churn status of long-term contributors in the open-source software community is used to realize a real-time and effective prediction system for the churn of long-term contributors in the open-source community, including: a data layer, a feature layer, a model layer and a monitoring layer.

[0083] The data layer is used to retrieve commits, issues, pull requests, comments, likes, branches, and user information data from the top 100 repositories by number of likes and all long-term contributors to the current system application repository.

[0084] The feature layer obtains data from the data layer and derives structured information features, including contribution, collaboration, sentiment analysis features, interest shift features, and membership relationships.

[0085] The model layer is used to train the model and obtain prediction models for long-term contributors' churn after 3 / 6 / 9 months.

[0086] The monitoring layer is used to infer the churn rate of long-term contributors in the current repository after 3 / 6 / 9 months by training models, and to send emails and GitHub notifications to the repository administrator via GitHub Actions to list long-term contributors at high risk of churn.

[0087] Figure 1 The diagram illustrates the flow of a method for predicting the churn status of long-term contributors in open-source software communities. The specific implementation includes the following steps:

[0088] A. Long-term contributor discovery

[0089] To accurately identify long-term contributors in open-source project communities, we adopted a comprehensive analysis and identification process. Long-term contributors are defined as those whose last commit to the project was more than one year after their first commit, and whose total number of commits ranks in the top 10% of all contributors to the project.

[0090] First, we retrieved all commit records for the project via the GitHub API. The GitHub API provides rich interfaces to obtain detailed information for each commit in the repository, including timestamps and author information. To address the issue of a large number of commit records and slow retrieval speed, we innovatively proposed a combination of paginated retrieval and concurrent requests, along with a user token pool and a periodic persistence strategy. Specifically, we adopted the following measures:

[0091] Pagination: The GitHub API returns a limited number of data entries by default. We use pagination parameters (such as per_page and page) to retrieve all commit records page by page.

[0092] Concurrent requests: To accelerate the data retrieval process, we use a thread pool to concurrently request the API. Specifically, we can use Python's `concurrent.futures.ThreadPoolExecutor` to manage multiple concurrent requests.

[0093] User Token Pool: The GitHub API limits the request frequency for each user. We built a user token pool and rotate between different tokens to increase the request frequency and avoid rate throttling.

[0094] To reduce data loss due to network outages, we have implemented a periodic persistence strategy during the data retrieval process. When the number of pages retrieved reaches a certain integer multiple (200 by default), we persist the retrieved data to the local file system so that data retrieval can resume from where it left off in the event of network problems.

[0095] After obtaining all commit records, we sort these records by timestamp to determine the time of each contributor's first and most recent commit. The specific steps are as follows:

[0096] Timestamp sorting: Sort each commit record in ascending order according to its timestamp.

[0097] First and most recent commit times: Traverse the sorted records and record the first and most recent commit times for each contributor.

[0098] Next, we will count the total number of submissions for each long-term contributor and use a threshold to filter out eligible long-term contributors. The specific steps are as follows:

[0099] Submission count: Iterate through all submission records and count the number of submissions for each contributor.

[0100] Threshold screening: Select the top 10% of contributors by number of submissions as long-term contributors.

[0101] To ensure the portability and consistency of the analysis process, we encapsulated the above analysis process into an automated script and deployed it using containerization technologies such as Docker. The specific implementation is as follows:

[0102] Automation scripts: Use Python to write data acquisition and analysis scripts, use the requests library to interact with the GitHub API, and use the pandas library for data processing and analysis.

[0103] Containerized deployment: Use Docker to package scripts and the required environment into container images to ensure consistent operation in different environments.

[0104] This process has low hardware resource requirements and can be executed on ordinary servers, such as those using Intel E5-2670 CPUs. By rationally designing the data acquisition and processing flow, long-term contributors to large-scale open-source projects can be identified in a relatively short time. Through these technical means, we can effectively identify long-term contributors to open-source projects, providing crucial support for the sustainable development of these projects.

[0105] B. Data Extraction

[0106] We used a server configured with a 16-core CPU and 64GB of memory to execute this parallel task. First, we divided the list of long-term contributors into 16 groups, each group responsible for processing the data of one long-term contributor. We chose to use the Python programming language and combined it with multithreading techniques to implement the parallel task. Specifically, we used `concurrent.futures.ThreadPoolExecutor` to manage the thread pool and achieve parallel processing. Each thread is responsible for retrieving the GitHub activity data of one long-term contributor. Retrieving data from GitHub requires using the GitHub API. Through the GitHub API, we can obtain various types of data, including but not limited to:

[0107] User information: Obtaining users' personal information, such as username, email, profile picture, etc.

[0108] Repository Information: Retrieves basic repository information, such as name, description, and language. Commit Information: Retrieves detailed commit information, including the committer, commit time, and commit details.

[0109] Issues and pull requests: Retrieves detailed information about issues and pull requests in the repository, including title, description, status, comments, etc.

[0110] Likes and Branch Information: Retrieves information about user likes and branch repositories.

[0111] Comment information: Retrieves detailed information about submitted comments, issue comments, and pull request comments in the repository, including time, content, author, etc.

[0112] Compared to existing methods, we significantly accelerate data acquisition and processing through multi-threaded parallel processing. Our comprehensive extraction of multiple data types offers greater depth and completeness compared to traditional methods. We also address the pagination limitations of the GitHub API, particularly for comment data. Using the `since` and `sort` parameters to control the start time of batch comment retrieval is an innovative pagination approach. Furthermore, we implement rate limiting and retry logic. When acquiring data, we consider the rate limits of the GitHub API and implement appropriate rate limiting and retry logic as needed to ensure the effectiveness and continuity of data acquisition. This strategy to prevent API rate limiting is an important and innovative technical point for large-scale data extraction tasks. Specifically, for each long-term contributor mentioned in the steps, we can obtain their activity data in a specified repository through the GitHub API, including monthly commits, issues, pull requests, commit comments, issue comments, pull request comments, branches, likes, etc. For example, for commit information, we can use the GitHub API's commits endpoint to retrieve commit data from a specified repository. By setting appropriate query parameters (per_page = 100, author parameter specifies the author of the submission), we can retrieve the submission records of a specified contributor for each month. Similarly, we can use other endpoints to retrieve other types of data, such as issues, pull requests, etc. For comment data, we need to additionally set the since and sort parameters to control the start time of batch comment retrieval to address the pagination limitations encountered when retrieving data from the GitHub API. When writing the code, we need to construct HTTP requests using the corresponding API endpoints and query parameters, and parse the returned JSON data to extract the required information. When retrieving data, we need to be aware of GitHub API rate limits and implement appropriate rate-limiting and retry logic as needed to ensure that we can efficiently retrieve data without limitations. During the runtime phase, we expect the entire task to take approximately 2 to 3 hours, depending on the GitHub API response speed and server performance.

[0113] C. Feature Engineering

[0114] To investigate whether long-term contributors will become non-coding long-term contributors, we extracted 17 features from five dimensions. These features were proposed based on assumptions about factors that might influence contributor churn, while also considering data availability. Compared to existing methods, we innovatively proposed a five-dimensional feature set (including 17 features) for constructing subsequent predictive models. Among these innovations, we constructed and analyzed a collaborative network: using `git log` to obtain commit author and file information, we built a collaborative network and extracted multiple centrality features using the `networkx` library. This approach of quantifying collaborative features using social network analysis is relatively innovative in open-source community contributor behavior analysis. Furthermore, when obtaining sentiment analysis features, we used the ROBERT model to perform sentiment analysis on long-term contributor comments and used the sentiment analysis results as features. Quantifying contributor sentiment states through a sentiment analysis model and using it as features is an innovative attempt. Finally, we determined whether long-term contributors belonged to a company or organization based on their email suffixes, and used regular expressions to parse the email suffixes, matching user affiliation through email suffix regular expressions. This approach of determining affiliation through email suffix parsing is innovative in feature engineering design because it attempts to infer the professional background of long-term contributors from external information. We perform feature engineering on the extracted data from five dimensions, including:

[0115] C1. Contribution: Write a script to calculate the monthly submissions, issues, pull requests, submission comments, issue comments, and pull request comments from long-term contributors in step B. Use a server configured with a 16-core CPU and 64GB of memory to perform this task.

[0116] C2. Collaboration Degree: We obtain the author and file information of each month's commits from the open-source software community using `git log`. Then, we construct a collaboration network for the open-source software community. Using contributors as nodes, if the files submitted by contributors overlap, we connect them with an undirected edge. We extract the degree centrality, cluster centrality, center centrality, proximity centrality, and eigenvalue centrality from the monthly collaboration network using the networkx library as collaboration degree features. The configuration is the same as above.

[0117] C3. Sentiment Analysis: Sentiment analysis is performed on monthly submissions, question comments, and pull request comments from long-term contributors using a Robertt model, outputting as positive, neutral, or negative. The number of positive and negative comments from long-term contributors are used as features for sentiment analysis. A GPU server (such as an NVIDIA Tesla P100 or higher) and at least 16GB of memory are required. The estimated runtime is approximately 1 hour, depending on the number of comments in the community.

[0118] C4. Interest Shift: Write a script to calculate the number of branches and likes for long-term contributors in the current month, extracted from the data in step B. Configuration is the same as C1.

[0119] C5. Affiliation: Determine whether a long-term contributor belongs to a company or organization based on their email suffix. This is a feature indicating the affiliation of long-term contributors. The specific encoding is achieved by parsing email suffixes using regular expressions. Configuration is the same as C1.

[0120] D. Model Building

[0121] This step requires building our predictive model. Compared to existing methods, our data acquisition and filtering are more systematic: we obtain data on long-term contributors from the 100 most popular open-source software communities through the GitHub API and systematically filter the data based on a series of criteria (such as programming language, use of issue tracking systems, and whether it is a forked project). This systematic data acquisition and filtering method ensures the representativeness and quality of the data. In addition, our innovative feature engineering and model building combine various innovative features (such as collaborative network features, sentiment analysis features, interest transfer features, and membership features) with advanced machine learning methods, ensuring the high accuracy and broad applicability of the predictive model. The specific implementation method is as follows:

[0122] 1. Data Acquisition and Preprocessing

[0123] We used the GitHub API to obtain data on all long-term contributors from the 100 most popular open-source software communities as training data. The selection criteria for these repositories were the top 100 projects sorted by the number of upvotes, as these projects have high visibility and representativeness, and possess significant potential for continued development.

[0124] Perform data filtering and cleaning, excluding the following items:

[0125] a) Projects with no programming language, as these are typically unrelated to software development. For example, the project paper-we-love / papers-we-love is a collection of papers.

[0126] b) Projects that use GitHub as a mirror only, such as torvalds / linux, use Bugzilla as their issue tracking system instead of GitHub's own issue tracking system.

[0127] c) Projects that branch off from other projects.

[0128] Based on the above criteria, 47 projects were selected. For each project, we observed and collected data from its start date to October 2023 to ensure coverage of the entire duration of each project.

[0129] Monthly activity data is collected through the GitHub API and Git logs, including commits, issues, pull requests (PRs), and comments.

[0130] 2. Definition and data organization of long-term contributors

[0131] 3,827 long-term contributors were identified, and monthly data from these contributors during the observation period were collected, totaling 255,894 data points.

[0132] 3. Feature Extraction

[0133] Five-dimensional features are extracted for training the model. These five-dimensional features include:

[0134] Contribution; Collaboration; Sentiment Analysis; Interest Transfer; Affiliation.

[0135] 4. Model Training

[0136] We trained three sub-models using XGBoost on a server configured with a 16-core CPU and 64GB of memory to predict whether long-term contributors would churn after 3, 6, and 9 months, respectively. The model includes a data interface module, a core booster module, an objective function module, and a performance metrics module. The data interface module stores and manages data. It extracts data from the file system and performs preliminary processing and cleaning for subsequent modules. Its role is to extract, clean, and store data, providing data support for model training and prediction, while ensuring data integrity and consistency by storing processed data in data frames. The core booster module is the core of the model, responsible for training and prediction. It includes the implementation of a decision tree model and provides interfaces for training and prediction. This module supports various objective functions and evaluation metrics. Its role is to use training data to build a decision tree model and use the trained model to predict new data. We set some key parameters for the core booster as follows: for the model predicting long-term contributor churn after 3 months, the learning rate is 0.05, and the number of decision trees is 80. For the model predicting long-term contributor churn after 6 months, the learning rate is 0.02 and the number of decision trees is 100. For the model predicting long-term contributor churn after 9 months, the learning rate is 0.05 and the number of decision trees is 70. These parameters were obtained through grid search, iterating through learning rates of 0.01, 0.05, 0.1, 0.4, 0.5, and 0.6, and tuning to the optimal parameters of 10, 20, 30, 40, 50, 60, 70, 80, 90, and 100. The objective function module defines the model's objective function, which guides the optimization process. Our objective function is shown below:

[0137]

[0138] Where n is the number of samples, representing the number of monthly data samples from all long-term contributors. In our model, we collected a total of 221,525 monthly activity samples from long-term contributors. This represents the actual labeled data, with a value of 0 or 1. According to our defined long-term contributor state transition model, when a long-term contributor's commit interval exceeds the historical maximum commit interval, the long-term contributor will transition to a non-coding long-term contributor. Non-coding long-term contributors are highly likely to transition to churned long-term contributors; therefore, we predict the timing of long-term contributors transitioning to non-coding long-term contributors. If the data for a long-term contributor in a certain month... A value of 0 indicates that the long-term contributor will not leave after 3 / 6 / 9 months, meaning they will remain a long-term contributor after 3 / 6 / 9 months. Otherwise, they will leave, meaning the long-term contributor will enter a non-coding long-term contributor state after 3 / 6 / 9 months. The result of the inference from the Kth decision tree is calculated using the following formula:

[0139]

[0140] The input for the i-th sample is a 17-dimensional feature vector, specifically including a long-term contributor's contribution in a given month (number of submissions, number of issues, number of pull requests, number of submission comments, number of issue comments, number of pull request comments, and total number of current historical submissions), collaboration degree (degree centrality, cluster centrality, center centrality, proximity centrality, and eigenvalue centrality of the long-term contributor in the collaboration network in that month), sentiment analysis features (number of positive and negative comments of the long-term contributor in that month), interest shift features (number of forks and stars of the long-term contributor in that month), and affiliation features (the long-term contributor's email suffix determines whether the long-term contributor belongs to a company or organization; 1 if yes, 0 otherwise). L is the cross-entropy function in our model. The complexity of the Kth decision tree is represented. Its role is to guide the model's optimization process, ensuring the model learns in the correct direction, where the learning rate controls the speed of model weight convergence. The performance metrics module evaluates the model's performance. It provides various evaluation metrics to measure the model's predictive effectiveness, such as accuracy, precision, recall, and F1 score. Its function is to evaluate and measure model performance, helping to select the optimal model. The data interface module provides data to the core booster module for model training and prediction. The core booster module uses the data provided by the data interface module to train the model and optimizes it according to the objective function defined by the objective function module. The objective function module guides the optimization process of the core booster module, ensuring the model's learning direction. After training, the core booster module passes the model's prediction results to the performance metrics module. The performance metrics module calculates evaluation metrics based on the prediction results, providing feedback on the model's performance.

[0141] The input to the long-term contributor churn prediction model consists of five features: contribution level, collaboration level, sentiment analysis features, interest shift features, and affiliation. The model output is a prediction: whether a long-term contributor will become a non-coding long-term contributor after a certain period (3 / 6 / 9 months); if so, the output is 1, otherwise 0. This step requires building our long-term contributor prediction model. We obtained data from all long-term contributors in the 100 most popular open-source software communities through the GitHub API as our training data. These repositories have a long history, a large number of long-term contributors, and are sufficiently representative. After filtering, we obtained 47 open-source software communities. We used the long-term contributor data (commits, issues, pull requests, etc.) from these 47 open-source communities as the training dataset. We randomly used the long-term contributor data from 80% of the projects in the training dataset as the training set and the long-term contributor data from 20% of the projects as the test set. We used GridSearchCV (GridSearchCV refers to grid search, a hyperparameter optimization method that exhaustively searches through predefined hyperparameter combinations. For each parameter combination, grid search trains and evaluates the model, ultimately selecting the best-performing combination) from the scikit-learn library to perform five-fold cross-validation on the training set. AUC was used as the evaluation metric for the long-term contributor churn prediction model to determine the optimal parameters (including the number of iterations and the learning rate), resulting in a well-trained long-term contributor churn prediction model. Because the monthly data volumes of different long-term contributors vary greatly, and much of the data is not normally distributed, we used the MinMaxScaler function to normalize all monthly data. Then, we trained three models using XGBoost to predict whether long-term contributors will churn after 3, 6, and 9 months. The uniqueness of our model lies in using representative and diverse datasets to ensure the broad applicability of the prediction results. We also introduced innovative five-dimensional features to train the model, enhancing its accuracy. Finally, we provided multi-stage, more granular prediction results to facilitate project managers in implementing different intervention measures.

[0142] 5. Multi-stage prediction results

[0143] We use the model built in step 4 to infer the long-term developer data in the current open-source software community obtained in step 3 (and call the predict interface of the XGBoost model in the sklearn library) to obtain more granular predictions for each long-term contributor in the open-source software community at multiple stages (including after 3, 6, and 9 months). The output is 0 or 1; 1 means that the contributor will become a non-coding long-term contributor after 3 / 6 / 9 months, and 0 means that the contributor will not. This allows project managers to take different intervention measures. For example, for the 3-month prediction, measures can be taken in time to retain contributors who may leave; for the 6-month and 9-month predictions, long-term strategy planning can be carried out.

[0144] Through the steps described above, we have built a long-term contributor churn prediction system based on GitHub data. By leveraging diverse and representative datasets and innovative features, we ensure that the model has high predictive accuracy and broad applicability.

[0145] E. Regular monitoring

[0146] Finally, we need to promptly report our predictions to the open-source community administrators. We'll use GitHub Actions to schedule this tool to run daily. Specifically, create a `.github / workflows` directory in your GitHub repository and create a YAML file within that directory to define the automated workflow. Define the daily scheduled GitHub Action workflow, using cron syntax to set up the scheduled task. Execute steps A, B, C, and D, and then use the model trained in step D to infer long-term contributors who might churn after 3 / 6 / 9 months. Send notifications to designated administrators using GitHub Actions' email functionality or the GitHub API.

[0147] It should be noted that the purpose of disclosing the embodiments is to help further understand the present invention. However, those skilled in the art will understand that various substitutions and modifications are possible without departing from the scope of the present invention and the appended claims. Therefore, the present invention should not be limited to the content disclosed in the embodiments, and the scope of protection of the present invention is defined by the scope of the claims.

Claims

1. A method for predicting the churn of long-term contributors to open-source software based on multi-dimensional features, characterized in that, A state transition model for long-term contributors is constructed. By extracting multidimensional features of long-term contributors to open-source software and building a churn prediction model for long-term contributors, the churn of long-term contributors to open-source software can be predicted. Includes the following steps: 1) Based on open-source software log data, define long-term contributors to the open-source software repository and construct a long-term contributor state transition model; the constructed long-term contributor state transition model includes multiple states of the contributor and the transition methods of each state; In the constructed long-term contributor state transition model, a contributor refers to a developer who has contributed code to an open-source software community or code repository at least once; Contributor status includes: Regular Contributor, Long-Term Contributor, Non-Code Long-Term Contributor, and Churned Long-Term Contributor. Specifically: Non-Code Long-Term Contributors are contributors who were once long-term contributors but no longer contribute code, though they may show interest in the project in other ways; Churned Long-Term Contributors are contributors who were once long-term or non-code long-term contributors but have not only stopped contributing code for a period of time but also cease participating in any other activities within the open-source community—i.e., they have left the project; Regular Contributors are contributors who are neither long-term contributors, non-code long-term contributors, nor Churned Long-Term Contributors. When the time interval between the current time and the last code commit of a long-term contributor exceeds their historical maximum coding interval (i.e., the maximum time difference between two consecutive historical code commits observed at the current time), the long-term contributor stops contributing code or ceases contributing code and is converted to a non-code long-term contributor. 2) Perform data collection and extraction in parallel on the server to identify long-term contributors to open-source software repositories and obtain activity data of all long-term contributors; including controlling the amount of data retrieved each time through pagination parameters and persisting the retrieved data; 3) Extract effective structured information from the data obtained in step 2) as features of long-term contributors, including multiple features across five dimensions, as input to the long-term contributor churn prediction model; the five dimensions include: contribution level, collaboration level, sentiment analysis level, interest transfer level, and affiliation level. 4) Build and train a prediction model for long-term contributor churn in open-source software to obtain a well-trained prediction model for long-term contributors at different time granularities. The open-source software long-term contributor churn prediction model includes a data interface module, a core booster module, an objective function module, and a metrics module for evaluating model performance. The data interface module is used to store, process, and manage long-term contributor data. The core booster module includes a decision tree model and supports multiple objective functions and evaluation metrics. It uses training data to build a decision tree model and uses the trained model to predict the data to be predicted, providing an interface for training and predicting the constructed long-term contributor churn prediction model. 5) By using the trained prediction models for long-term contributors at different time granularities, churn prediction can be performed on real-time data to obtain the churn status of long-term contributors at different time granularities. Through the above steps, we can predict the churn of long-term contributors to open-source software based on multi-dimensional features.

2. The method for predicting the churn of long-term contributors to open-source software based on multi-dimensional features as described in claim 1, characterized in that, In step 1), long-term contributors to the open-source software repository refer to authors whose last code commit time and first code commit time in the open-source software project are more than one year apart and whose code commits account for the top 10% of the repository. When identifying long-term contributors, the time and author information of each commit in the open-source software repository are first obtained through the GitHub API. The pagination parameters of the GitHub API are used to control the amount of data retrieved each time, and all commit information of the open-source software repository is retrieved concurrently through a thread pool. When the number of pages of data retrieved reaches a set integer multiple, the retrieved data is persisted. Then, the long-term contributors of the open-source software repository are calculated.

3. The method for predicting the churn of long-term contributors to open-source software based on multi-dimensional features as described in claim 1, characterized in that, Step 2) Extract the activity data of all long-term contributors, including: the issues, pull requests, submission comments, issue comments, pull request comments, branches, likes, and personal information of all long-term contributors in the open-source software repository each month.

4. The method for predicting the churn of long-term contributors to open-source software based on multi-dimensional features as described in claim 3, characterized in that, In step 3), the features of the contribution dimension include: the number of submissions, the number of issues, the number of pull requests, the number of submission comments, the number of issue comments, the number of pull request comments, and the total number of current historical submissions for long-term contributors each month; The features of the collaboration dimension include: degree centrality, cluster centrality, center centrality, proximity centrality, and eigenvalue centrality in the monthly collaboration network; the collaboration network for building open-source software repositories is based on contributors as nodes; when the files submitted by contributors have intersections, an undirected edge is connected between the contributors. The characteristics of the sentiment analysis dimension include: the number of positive comments and the number of negative comments from long-term contributors; the characteristics of the sentiment analysis dimension are to perform sentiment analysis on the comments submitted, question comments, and pull request comments of long-term contributors each month using a sentiment model, and the resulting sentiment of long-term contributor comments includes positive comments, neutral comments, or negative comments; Features of the interest shift dimension include: the number of branches a long-term contributor has in a given month, and the number of likes a long-term contributor has in a given month. The affiliation dimension features include: the email suffix of long-term contributors, used to determine whether long-term contributors belong to a company or organization.

5. The method for predicting the churn of long-term contributors to open-source software based on multi-dimensional features as described in claim 4, characterized in that, Step 4) Specifically, the five-dimensional features extracted from the data of all long-term contributors in multiple open-source software repositories are obtained through the GitHub API and used as training data; the decision tree model is specifically trained using the XGBoost model at different time granularities. The model is trained using the five-dimensional features, and the objective function adopts the cross-entropy loss function to predict whether long-term contributors will leave after different time periods, thereby obtaining multi-stage prediction results at different time granularities. Objective function of the prediction model Represented as: in, It is the cross-entropy function; Let be the complexity of the Kth decision tree; n is the number of samples, representing the number of monthly data samples from all long-term contributors. Represents actual labeling; The result of the inference of the Kth decision tree is represented as: in, Let be the i-th input sample, i.e., the multidimensional feature vector of long-term contributors; This is the result of inference for the (K-1)th decision tree.

6. The method for predicting the churn of long-term contributors to open-source software based on multi-dimensional features as described in claim 1, characterized in that, In step 2), the thread pool is managed using Python's `concurrent.futures.ThreadPoolExecutor`, with each thread responsible for retrieving GitHub activity data from a long-term contributor, thus achieving parallel processing. For comment data, additional `since` and `sort` parameters are set to control the start time of batch comment retrieval, thereby resolving the pagination limitations encountered when retrieving data from the GitHub API. When writing code, HTTP requests are constructed using the corresponding API endpoints and query parameters, and the returned JSON data is parsed to extract the required information.

7. The method for predicting the churn of long-term contributors to open-source software based on multi-dimensional features as described in claim 1, characterized in that, In step 4), the GridSearchCV function from the scikit-learn library is used for hyperparameter optimization. It uses an exhaustive search method to traverse predefined combinations of hyperparameters. For each parameter combination, the model is trained and evaluated.

8. A system for predicting the churn of long-term contributors to open-source software based on multi-dimensional features, implemented using the method described in claim 1, characterized in that, include: Data layer, feature layer, model layer, and monitoring layer; The data layer is used to retrieve submissions, pull requests, comments, likes, branches, and user information data from the top repositories with the most likes and all long-term contributors to the current system application repository. The feature layer obtains data from the data layer and obtains structured information features, including contribution, cooperation, sentiment analysis features, interest shift features, and membership relationships. The model layer is used to train the long-term contributor churn prediction model, resulting in a well-trained long-term contributor churn prediction model after 3 / 6 / 9 months. The monitoring layer is used to infer the churn rate of long-term contributors in the current open-source software repository after 3, 6, and 9 months using a trained long-term contributor churn prediction model, and obtain the long-term contributors who churned after the corresponding month.

9. A computer-readable storage medium on which a computer program is stored, characterized in that, When the computer program is executed by the processor, it implements the open-source software long-term contributor churn prediction method based on multi-dimensional features as described in claim 1.

Images