# Survivability Prediction of Open Source Software with Polynomial Regression
## 3 Proposed Methodology: Predicting OSS Survivability with Maintenance Activity
### Feature and Target Data  
To predict bug-fixing activity, we use data related to popularity, contributors, and code complexity, as shown in Table 2. To focus on the issue of project dependencies, we set bug-fixing activity as a maintenance criterion. It requires the identification of bugs by users and their resolution by developers. Moreover, for developers to efficiently maintain the project, the code should be easy to understand. Therefore, we utilize five types of data falling into three categories.  
**Star** represents the number of stars in an open source repository. Stars go up when GitHub users are interested in a repository, so they represent the popularity of the repository [18,19]. The more popular a repository is, the more people are interested in it and the more likely it is to have users. Therefore, we use stars as user-side data.  
**Contributor** is the number of people who contribute to the development of an open source repository. The more people contribute, the fewer features need to be developed and the fewer bugs need to be fixed per contributor. Therefore, the more contributors there are, the more likely it is that maintenance will be performed quickly and continuously, even if there are more bugs to fix. Therefore, we use contributor as a feature.  
**LoC (Line of Code)** comprises data that indicate the size of a project. Based on research from [20], we found that a higher LoC require more maintenance effort. Based on this fact, we chose code as the data representing LoC because it can also affect the maintenance activity of bug-fixing.  
**Cognitive complexity** is a metric that indicates the degree to which a person can understand code [21]. It is used to measure how much logical thought and cognitive work is required to understand and manage code from a developer's perspective. In other words, it is an indicator of the intellectual burden of understanding code. Code with high cognitive complexity can be difficult to understand and harder to find and fix bugs, which can reduce the readability and maintainability of the code. That is why we use it as a feature.  
**Cyclomatic complexity** is one metric of code complexity and is measured by analyzing the control flow of the code [22]. High cyclomatic complexity can increase the likelihood of bugs. We use this as a feature because it can affect the growth of bugs and increase maintenance efforts.  
**Target** is the _Trend\({}_{bug}\)_. The trend indicates the increase or decrease in the number of residual bugs over time. [PERSON] et al. and [PERSON] et al. analyzed the state of OSS through  
\begin{table}
\begin{tabular}{c c c c} \hline \hline  & **Type** & **Name** & **Description** \\ \hline \multirow{4}{*}{Feature} & User & Star & Interest level of open source users \\  & Developer & Contributor & Measure of development and maintenance activities. \\  & & LoC (line of code) & Project size \\  & Code & Cognitive complexity & Developers’ code comprehension \\  & & Cyclomatic complexity & \\ Target & Maintainability & \(\begin{array}{c} Trend_{bug}\end{array}\) & Bug-fixing activity \\ \hline \hline \end{tabular}
\end{table}
Table 2: Feature and target data.  
Figure 1: Detailed process flow for predicting OSS’ bug trends with polynomial regression.  
issue creation and resolution progress [23, 24]. We adopt this approach and use the trend of bug issue activity as the target to focus on bug resolution activity. Additionally, we calculate the trend value to quantitatively represent the current state of the OSS. If the value is above 0, it means that the number of residual bugs may increase in the future, indicating a higher risk of exposure to bugs due to a decrease in bug activity. Therefore, we adopt this as a criterion for identifying maintenance issues as it can indicate the risk of project dependency problems.