# Survivability Prediction of Open Source Software with Polynomial Regression
## 3 Proposed Methodology: Predicting OSS Survivability with Maintenance Activity
### Data Collection and Extraction
#### 3.2.2 Extracting Target Data  
The \(\textit{Trend}_{bug}\) for the target was calculated using GitHub's issue activity. Testing each project to identify the presence and fixing of bugs would require a considerable amount of time. Therefore, we used GitHub's issue activity to determine the existence and fixing of bugs. When users or developers discover a bug, a bug issue is created. When a developer fixes the bug, the related issue is marked as closed. Hence, by tracking created bug issues  
Figure 3: SonarCloud: code data extraction  
Figure 2: Example of feature data (star, contributor).  
and closed issues, we can determine the total number of bugs and the frequency of bug-fixing activity for OSS.  
We utilize the GitHub API to extract issues. However, GitHub issues include not just bug-related problems but also questions regarding simple usage. To exclusively extract bug issues from the multitude, we search for labels categorized under 'bug' as illustrated in Figure 4. Subsequently, leveraging the identified labels, we cumulatively gather created bug issues created and closed bug issues over the past two years, day by day. Thereafter, we compute the number of remaining bug issues for each date by comparing the two sets. Consequently, if bug issues are created but not closed, the count of remaining bug issues will incrementally rise over time. Alternatively, if more are closed than created within a two-year span, the quantity of remaining issues will progressively decrease.  
Based on the collected data, we calculate the \(\mathit{Trend}_{bug}\) using Equation (5) to represent the trend of the data. However, the data do not exhibit an overall decrease or increase over the two-year period. It may show a decrease in some segments and an increase in others. Therefore, we used the code in Algorithm 1 to identify the last segment with a changing slope and utilized the slope of that segment as the target. For a comprehensive understanding of this process, please see Figure 5.  
```
Use library changepoint as cpt input \(\leftarrow\) OSS(date) output \(\leftarrow\) OSS(residual_bug_issue) change_point \(\leftarrow\) cpt_mean(output) slope \(\leftarrow\) calculate_slope(input,output,change_point) if slope is NA then slope \(\leftarrow\) calculate_slope(input,output) endif
```  
**Algorithm 1** Calculating the slope of the last segment  
Algorithm 1 operates using the _changepoint_ library of \(R\). After importing the necessary libraries, it takes the input of each OSS, which includes _date_, and the _output_, which consists  
Figure 4: Issue label of GitHub.  
Figure 5: Example of performing Algorithm 1 (red circle denotes last changed point).  
of residual bug issues. Subsequently, the library is used to find the _change_point_ where the slope changes and calculate the slope of the last segment. In some cases, the slope value may remain constant over the entire segment. Therefore, in such cases, the calculation is performed over the entire segment.  
\[\mathit{Trend}_{\mathit{bug}}=\frac{\sum_{j}{(x_{j}-\bar{x})(y_{j}-\bar{y})}}{ \sum_{i}{(x_{i}-\bar{x})^{2}}} \tag{5}\]  
Equation (5) calculates the rate of change of each piece of data over time, where \(x\) represents the date \(x\) when the issue was created or closed, and \(y\) represents the number of residual bugs. Based on the calculated trends, we can quantify the progress of bug-fixing activities in OSS in the future.