Software Architecture Degradation in Open Source Software: A Systematic Literature Review

Software architecture (SA) has a prominent role in all stages of system development. Given the persistent evolution of software systems over time, SA tends to be eroded or degraded. Such phenomenon is called architectural degradation. In light of this phenomenon, the current study focuses on problems of architectural erosion in the open-source software (OSS). There has been a significant research activity on the OSS over the last decade. Nonetheless, the architectural degradation problems in the OSS are still scattered and disorganized. In addition, there has been no systematic attempt made on existing studies to provide evidence, insight and better understanding for researchers and practitioners. The main objective of the present study is to provide a profound understanding and to review the existing studies on the architectural erosion of the OSS. In this study, we conduct a systematic literature review (SLR) to gather, organize, classify, and analyze the architectural degradation of previous papers published until the year 2020. The data for this study were collected from eight major online databases (ACM, Springer, ScienceDirect, Taylor, IEEE Explorer, Scopus, Web of Science, and Wiley). A total of 74 primary studies were identified as the final samples of this research. The results indicated that rapid software evolution, frequent changes, and the lack of developers’ awareness are the most common causes occurred in architecture degradation. Meanwhile, the prominent key indicators of architectural erosion symptoms are code smells and architectural smells. Additionally, the results indicated the most commonly used of the proposed solution for addressing architectural erosion is the metrics-based strategy. Acknowledging the limitations of the current study, more studies are needed that focus on determining other causes that are still ambiguous and improving the other solutions to provide better results in the precision and effectiveness of addressing architectural erosion.


I. INTRODUCTION
Modern societies have considerably been relying on largescale systems, which have a huge effect on our daily living, education, finance, healthcare, communication, transportation, entertainment, commerce, security, and defense [1]. Nonetheless, there is an increasing fragility in these systems, leading to cascading failures because of the nature of operating interdependent connected ecosystems [2]. Accordingly, a NATO workshop had been conducted to identify the software crisis as early as in 1968 [3]. Consequently, the The associate editor coordinating the review of this manuscript and approving it for publication was Mario Luca Bernardi . software architecture (SA) domain has been broadly adopted, however, with only mere attention [4] as a significant subfield of software engineering from the past decade, particularly in research and industry [5] as well as software development [6].
SA is considered the basic structure block for establishing any system, as it is the crucial and important factor in defining, succeeding, and developing systems design [7] as well as quality criteria [8], which makes it one of the most fundamental issues in designing and developing software today.
Furthermore, SA has a prominent role in each stage of the system development stages from understanding, analyzing, building, managing, reusing, and requirements to its VOLUME 8, 2020 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ deployment and maintenance [9], [10]. SA deals with the framework and interactions of a system. Interestingly, the utmost fundamental construction blocks of the structure of SA are components and the interconnection among the components. Given the continuous development of software systems over time, SA tends to be eroded or degraded as a result of the requirement change, new features [11], corrections or architectural design change decisions, leading to a considerable systems diverge between the implemented architecture and intended architecture [12]- [14]. The phenomenon of architecture degradation usually takes place when the concrete architecture of a software system deviates from its conceptual architecture. Hence, the sustainability of software architecture will be threatened by the architectural degradation that represents the erosion and drift phenomena [15].
Typically, architectural erosion appears when the design structure of architecture is not properly identical with the source code in terms of the predefined mapping and accomplishing by the architecture engineer. The architectural drift usually occurs when the design decisions of the system are not included in the intended architecture [15]. Both phenomena are generated by several problems such as the undocumented, unforeseen, unplanned, random, scattered, and confused architectural design decisions. Furthermore, the unintentional addition, elimination, and modification occur frequently. These problems will affect even more, specifically in the maintenance and development systems life cycle [16]. It is worth noting that SA is the highest level of abstraction and basic reasoning in taking the consideration for producing software, whether this software is an open source or closed source (proprietary source). Accordingly, this study focuses on the problems of eroded architecture in the open source software (OSS).
Over the last decade, research on the OSS has acquired considerable activity, as the commercial use of the OSS components keeps extending [17]. Besides, the OSS has become one of the most debatable themes among users and practitioners. Therefore, several studies have focused on evolutional aspects of the OSS development in response to long-ranged viability and sustainability concerns of software projects based on community [18].
A number of studies have presented the software architectural structure degradation and its deviation from its initial planned (intended) architecture in the OSS. These studies have investigated several possible causes of the architectural degradation occurrence of the intended architecture and the symptoms that introduce a share in the degradation of the architectural design within the OSS environment. Additionally, SA degradation reflects negatively on software quality, leading to the collapse of the entire architecture or a redesign of the system from scratch. Several studies have also addressed the evaluation of degradation by conducting many experimental studies on the OSS to identity, avoid, minimize or repair architectural degradation. Many studies have suggested the use of some tools, models or measures, which contribute to identifying the architectural degradation and divergence that deviate from the intended architecture and understanding of erosion in its first stages. Such suggestions were made in order to preserve the rest of the architecture and proper redirection towards the stability and constancy for architecture. Conclusively, these efforts yielded a set of abundant results in research, which refer to the need for more recent comprehensive overviews and literature reviews that outline and build upon past findings; a set of current knowledge and future directions for researchers and practitioners in the field.
Nevertheless, as mentioned earlier, the concept of architectural degradation in the OSS is still scattered and disorganized. To our best knowledge, no efforts have systematically been made to analyze, summarize, arrange, and structure the existing studies to further provide evidence and better comprehension for researchers and practitioners. However, it is significant to indicate that there are some systematic literature reviews (SLRs) that may be related to the area of bad smells. Sabir et al. [19] concentrated on smell's growth, modern approaches, and research trends in object-oriented (OO) and service-oriented systems (SO). Rattan et al. [20] focused on code clone and software clone detection through methods and tools in the OO. Zhang et al. [21] conducted an identification aim what currently known is for code bad smells. In this study, we further provide a detailed analysis of architectural decay reasons and key symptom indicators of overall architectural erosion, covering symptoms other than bad smells in open-source software. In addition, we investigate the solutions that address architectural degradation and how effective the superiority of solutions is to provide better results through several different aspects. Therefore, we conducted a systematic study with the aim of gathering, classifying, investigating, summarizing, and synthesizing information about the precision and significance of the previous papers published until 2020. The study aims to provide a comprehensive report on the actual contribution of the empirical and thorough results of the current study including studies on this topic.
Generally, the current study presents three-fold contributions to the domain. Firstly, we identified 74 primary studies that detect architectural degradation within the OSS domains, which can be used as a beginning point to widen the knowledge on the topic. Secondly, we conducted wide explanations and profound understanding to provide the knowledge about: (i) potential causes, (ii) symptoms of degradation, (iii) proposed solutions to reduce the degradation, and (iv) evaluation of the effectiveness of the solutions. Thirdly, we identified the list of existing research in architectural erosion within the OOS to understand the current research trend based on our findings, to support further exploration in this domain.
The descriptions that follow present the structure of the rest of the study. A background of the software architecture, software architecture degradation and open-source software are presented in Section 2. The research methodology applied is discussed in Section 3. The results of the study are presented in Section 4. The discussion of the key findings is explained in Section 5. The threats to the validity of this study are clarified in Section 6. The conclusion is outlined in Section 7.

II. BACKGROUND
This section presents a concise overview and the definition of the SA term along with the software architecture degradation and the OSS to sum up the basic definitions. The details are clarified in the subordinate subsections.

A. SOFTWARE ARCHITECTURE
Over the recent decades of the last century, SA has emerged as the initial comprehension of the large-scope structures of software systems. SA is a collection of the primary design decision made throughout the period of development. Architecture is regarded as a core of software engineering that most accurately specifies the heart of software systems design and development [9]. Accomplishing non-functional and functional requirements is one of the most widely provided parts by SA since it is an integral part of the life-cycle of software evolution [22].
There are several SA definitions, but most terms and common definitions revolve around the concepts of components, modules, and interconnection among the components [23]. For instance, Bass et al. [24] characterized SA as the framework of the system that consists of entities, properties, and relationships that are externally visible among them. This definition remarkably indicates that the internal characteristics of the system structure for each entity have no prominent role in SA [23]. On the other hand, Perry and Wolf [15] defined SA through the characterizing of three parts of architectural aspects: processing aspect, data aspect, and connection aspect. The processing aspect is responsible for the data aspect to process the information by connection aspect, which connects the system parts to each other. In a different light, Crispen and Stuckey [25] described SA as distribution and planning strategies. The distribution strategy describes the systems partition into components or (composed of components). The planning strategy describes the interface of the system components with each other.
Although there are many definitions for SA degradation, most definitions and concepts revolve around the implemented architecture and the intended architecture. For example, Taylor et al. [9] as well as Perry and Wolf [15] described the architectural degradation as a process of the persistent inconsistency between the descriptive software architecture as implemented and the prescriptive software architecture as intended. Gurp and Bosch [30], Lindvall and Muthig [39], as well as Dong and Godfrey [40] described the architectural degradation as a gradual gap usually detected between the actual and planned architecture software, which is implemented by its source code. Macia et al. [41], Bertran et al. [42], and Macia et al. [43] described the architecture degradation as a direct outcome of the gradual injection of code anomalies in the low-level of the systems as the software evolves. Accordingly, the architectural degradation occurs within the systems when implemented software architecture deviates that represents the source code or low-level far from the intended software architecture that represents the high level or the conceptual model of architecture design.

C. OPEN SOURCE SOFTWARE
The term open-source software (OSS) points out something the community can change and participate in because its design is available to everyone.
With the increased interest in the OSS, several researchers and practitioners targeted to explore and study the evolution and design of the OSS and identify some risks such as sustainability [44], making the OSS of significant interest today as a viable alternative to the closed-source development [45]. The OSS is based on a methodology in establishing its projects, which completely differs from the used method in commercial systems [46] such as the source code available to the public, the price associated with the value of the system and modification of the software to individual needs. The OSS systems studies are classified into three categories according to the success factors of OSS: The first category explores the successful OSS projects Apache [47], FreeBSD [48], OpenBSD [49] and Debian GNU/Linux [50]. The second category addresses the similarities that contribute to the composition of the process used in successful OSS Apache, Mozilla [51], fifteen OSS Projects [52] as well as Arla and Mozilla Projects [53]. The third category focuses on the general public aspect of OSS projects [54], [55]. The success of OSS projects has resulted in the reasoning stabilization of many researchers and experts that OSS may extremely contribute to resolving software crises, which in turn, some advocates believe that future software will either be the OSS or not at all [56].

III. RESEARCH METHODOLOGY
The architectural degradation needs a full detail of the selected studies to understand how architectural degradation occurs within OSS projects. Therefore, it was necessary to conduct an organized systematic study that depends on a specific protocol and follows the standards and guidelines by VOLUME 8, 2020 Kitchenham and Charters [57], gather all running evidence for the research question, and provide the protocol of instructions based on the evidence for practitioners [58].
Such a process enables the method to identify and aggregate the sources of primary papers, include and exclude the papers in consonance with the previously identified criteria, investigate the data and synthesize the papers in a systematic manner. Accordingly, four main questions were formulated and defined to achieve the purpose of the current study. These questions specified the planning of search strategies, which in turn, lead to the extraction of the data that answered the research questions of the current study.
The SLR protocol as used by Kitchenham and Charters [57] aims at conducting a comprehensive study and examining the profound detail in a specific part of a topic to identify the gaps and future trends in the current research, contributes to introducing a deep view that helps researchers to fill the gaps.
The SLR process consists of three main parts that are considered as indispensable principles in conducting a reliable research process: (1) planning, (2) conducting, and (3) documentation (reporting). Each part has other activities that settle down within parts that are outlined with its activities (as shown in Fig. 1). The sections that follow explain the steps in the SLR protocol.

A. PLANNING PROCESS
The most significant part of the planning process is defining the research question(s), formulating the review protocol, and identifying the inclusion and exclusion criteria that should be subject to a particular SLR Protocol. The following sub-sections describe the SLR planning process.

1) RESEARCH QUESTIONS
Essentially, the identification and construction of the research question are one of the most important steps, on which the SLR protocol processes are built. It is considered the basic idea, in which the researcher intensely realized the need to identify the details of the previously published studies. Concretely, this research question consists of four questions, in relation to the motivation for each question as demonstrated in Table 1.

2) DEVELOPING A REVIEW PROTOCOL
To conduct a review systematically, Kitchenham and Charters [57] as well as Kitchenham [65] specified a protocol method to reduce the probability of bias in the research. Without a protocol, the selection of the sample studies would be individually adapted by the researcher's expectations. This would result in missing studies that should have been included among the sample studies that are needed in order to provide a profound investigation and broad understanding of the phenomenon.
The stages of a protocol review are clarified by the following processes: (i) identifying research questions, (ii) generating search strategy (iii) studying selection criteria and procedures, (iv) studying quality assessment procedures, (v) implementing data extraction strategy, and (vi) synthesizing of the extracted data. The stages of protocol review for this research are illustrated in Fig. 2.

3) INCLUSION AND EXCLUSION CRITERIA
Performing inclusion and exclusion criteria in the research process for the selected published studies constantly aims at ensuring that the primary chosen studies are reasonably related to the research questions and suitable in response to the defined questions in the SLR. Throughout the search process, several research articles were found (journals, books, chapters of books, conferences, workshops, symposiums and other research articles). Fig. 3 shows the process to conduct the initial comprehensive search process in line with the key search string in the given resources.
We selected only research articles written in the English language while research articles written in languages other than English were excluded. Another selection criterion of the articles was that the articles are related to the identification of the topic of architectural decay in the OSS community that has a direct or indirect association to answer the respective research question of the study. On the other hand, articles that were irrelevant and not clear in addressing the research questions of the study were excluded. In addition, articles which are less than four pages were also excluded because of its insufficiency to introduce a profound understanding and evaluation of the specific topic. Concerning the timing of the SLR procedure in our study, the beginning date of the search for the published articles was not specified since no efforts have been made for architectural degradation in the OSS, only the final time was specified, which was March 31, 2020. This date was the closing up for the search process and the starting time point for the data synthesis process. Table 2 summarizes the inclusion and exclusion of the selected paper criteria in the study.

B. CONDUCTING PROCESS
Once the protocol has been defined in the planning process, the conducting process starts with the review proper, which involves identification of the search strategy, study selection process and selection of the primary studies as well as the quality assessment. The sub-sections that follow explain the SLR conducting process.

1) SEARCH STRATEGY
Defining an accurate and comprehensive search strategy will provide satisfactory results with a wide coverage of published studies regarding the topic, which is identified by the researchers. Kitchenham and Charters [57] presented the search mechanism that identifies the following search strategy for primary studies including search string identification and resources to be searched. Fig. 2 demonstrates the search strategy mechanism, including manual and automatic searches. The section that follows clarifies the search strategy mechanism. VOLUME 8, 2020

a: IDENTIFICATION OF SEARCH STRING
To compose relevant search string, we follow the guidelines stated by Kitchenham and Charters [57] and the procedures by Kitchenham [65], which are: a) getting the derivation of key terms from the research questions; b) looking for all the key terms in synonyms, alternative spellings, and  abbreviations; c) checking through matching the keywords in any relevant research study for the stated previous steps; d) using the Boolean operators ''OR'', ''AND'', whereas ''AND'' operator employed to associate with the key terms, ''OR'' employed to link synonyms, alternative words, and abbreviations to each other; e) incorporating the key terms to compose the final search string.
To better design the key terms, the researchers identified the question structure based on the population, intervention, outcome, and experimental design, as stated below: • Population: Software architecture, OSS. • Intervention: Architectural degradation estimation. • Outcomes: Architectural decay detection, improved software quality.
• Experimental Design: Empirical studies, experimental studies, and case studies.
After conducting and completing the previous steps to form the keywords and after making sure that some tests are conducted by the search string on the selected libraries, the following inclusive search terms were adopted in our study: The search string was investigated in the digital libraries through the keywords, abstract, and title of each study except for SpringerLink and web of science libraries, the search string was investigated through the full text since it is not easy to use the advanced search by keywords, title, and abstract.

b: RESEARCH RESOURCES
The selection of the research resources has a crucial role in the identification of an efficiency result of the SLR. Accordingly, the researchers must identify relevant and appropriate research resources to conduct their research as well as research resources that are public and inclusive to most research. Fig. 2 shows the research resources in this study that had been identified. In some research resources, there may be a need to refine and reformulate the search string due to the difference in its search engine structure from others. Moreover, there is a divergence of the grammars from one search engine to another. For instance, the search in Sci-enceDirect engine requires up to 8 operators whether ''OR'', ''AND'', or integrate them. If the search terms are more than 8 operators, it must be divided into parts, considering the attention to link the operators among them. The search process of conducting the SLR is accomplished by two steps. The first step is an automatic search by searching eight online databases (repositories) as shown in Table 3. The second step is a manual search by the backward-forward search approach to identify the relevant studies among the selected primary studies [66]. Google Scholar search engine was used to determine the citation of relevant studies in the chosen primary studies.

2) STUDY SELECTION PROCESS AND SELECTION OF PRIMARY STUDIES
The preliminary list of studies was extracted from the initial search process, containing 827 (as shown in Fig. 2). The study selection process was conducted by one author and the other two authors checked the selection process. In the case Many steps were conducted to exclude the articles that were irrelevant to the topic, and at the same time to include related articles by following the guidelines and procedures by Kitchenham and Charters [57], Kitchenham [65], and based on some recommendations to detect the relevant studies for conducting the SLR and developing search strategies [66], [67]. In the first step, the inclusion and exclusion criteria (as illustrated in Table 2) were applied to obtain the final studies from this stage, which resulted in 597 articles. In the second step, the duplicate studies, found in many database resources during the search process were removed by using the Endnote reference manager, resulting in 535 articles. In the third step, the abstract and title were considered and assessed, whether or not it is related to the topic and the defined research question, yielding 164 articles. In the fourth step, reading the full text to evaluate and consider indepth in order to issue the final decision to be included or excluded, producing 66 articles. In addition to articles that have two duplicates in this stage, the journal article has to be included rather than the conference paper, provided that it is up to date as in our study, resulting in five articles. In the fifth step, a snowballing search strategy was employed for tracing citations and references of the included studies to identify the relevant missing articles, resulting in 15 articles in the first iteration. In the second iteration, 15 articles were analyzed and no additional studies were found. The search alert was utilized for all the search resources presented in Table 3 to determine the related published articles after the date of the initial research process, producing two articles. In the final step, at the same time as reading the full text, the quality of the articles was evaluated, and six studies were excluded. After applying the criteria for exclusion and inclusion, the total

3) STUDY QUALITY ASSESSMENT
Based on the inclusion criteria for primary studies as stated in [57], [65], an evaluation of the study quality was also applied in order to review and reconsider according to the assessment criteria that are more accurate and more detailed (as shown in Table 4). The evaluation of the study quality aimed at making the final decision for the included studies to ensure the quality in each study before the data extraction for analysis.
The quality assessment process was performed by one author and another author verified the selected studies for quality assessment. In addition, a discussion was also held at the point of disagreement. The study quality assessment was divided into three levels, which are high, medium, and low. Then, the scores for each question were identified in three parts. In the first part, number 1 means an accomplishment of the quality criteria entirely and clearly. In the second part, number 0 means does not meet anything from the stated quality assessment criteria. In the last part, number 0.5 means achieving the stated criteria partially.  After applying assessment quality criteria, the scores of five criteria were collected for quality assessment. The range of the three levels was determined in the quality evaluation. If the range is between the score 4.5 -5.0, it denotes a high level, and if the scope of score is between 3.5 -4.0, it denotes a medium level, and if the range is between the score 2.5 -3.0, it denotes a low level. Most of the scores are represented from the high level, while six studies were excluded since they did not meet the specified criteria. In Fig. 6, the distribution of studies is illustrated after applying the quality criteria for the three levels. The results of the quality assessment criteria for primary studies are described in Appendix B.

C. REPORTING PROCESS
Once the conducting process had been identified, the outcomes of a systematic review could be carried out adequately by extracting the appropriate data in line with the defined research questions. Then, the data were synthesized to identify the final view of the research and a conclusion was made on what revolves around the scope of this research in the current time and future research.

1) DATA EXTRACTION
Once the primary studies had been selected to be utilized for SLR, the data extraction proceeded to precisely record the information to address the defined research questions. VOLUME 8, 2020 In order to facilitate the data extraction process, data design forms according to guidelines in [57] were used from the chosen studies based on their relevance to the research questions. Appendix A demonstrates the details of the primary studies references (SID, title, author, year publication, and publication source). Finally, the data extraction form design was implemented on 74 primary studies with a brief description of all the extracted data items presented in Table 5, which was considered as the main source of data synthesis. The data extraction was saved in the MS Excel spreadsheets and Endnote reference manager.

2) DATA SYNTHESIS
By tabulating the extracted data for the required items in the MS Excel Spreadsheets and the Endnote reference manager, it is possible to synthesize the data with the aims to summarize and collect the results of the extracted items for the selected primary studies to answer the defined research questions [57]. Besides, it is important to determine whether the results obtained from the primary articles are identical or inconsistent to one another. The data synthesis can include the descriptive data (non-quantitative), along with a descriptive synthesis and sometimes it is possible to involve a quantitative synthesis. In our study, the data were extracted to encompass descriptive data (e.g., causes of the decay, the proposed solutions of addressing the degradation, a list of the erosion indictors symptoms) and quantitative data (e.g., the value of obtained results accuracy, which contributes to the extent of effectiveness of the suggested solutions).

IV. RESULTS
This section presents the results of the review to answer the defined research questions outlined in Table 1. The research questions have been answered by the final sample of the primary studies, which was restricted after applying the stated general and quality criteria between the year 2000 to March 2020, in which the research process ended, and followed by the inception for synthesis and report of the final data.

A. RQ1) WHAT ARE THE POSSIBLE REASONS FOR THE OCCURRENCE OF ARCHITECTURAL DEGRADATION?
This question identifies the possible causes that contribute to architectural degradation in the OSS community. The results of the first research question show several reasons, which differ in terms of the actual contribution to the occurrence of architectural erosion.
The results indicated that most of the causes of architectural degradation, which have a significant actual impact, are the rushed evolution of systems, recurring changes, lack of developer's awareness, time pressure and accumulation of design decisions. In the rushed evolution, numerous architectural problems, such as smells, tend to increase through successive system versions. In recurring changes, there are escalated risks on software architecture in making mistakes whenever the systems become more complex due to the frequent changes. For example, adapting new functionalities and features, new technologies, irresponsible or unintended addition, uncontrolled and unsuitable changes in its implementation or removal, and modification of architectural design decisions. In relation to the lack of the developer's awareness, there are problems with a high level of severity, which are not introduced to identify the level of architecture decay severity by developers due to lack of an explicit understanding of architectural basic knowledge, insufficiency of business knowledge, adopting and selecting the inexperienced developers, absence of long-term developer commitment to the project, writing unsuitable and improper code, or the practice and training to generate OSS projects as a distraction or hobby. In time pressure, it may affect the introduction of temporary solutions by the developers under a deadline pressures or time constraints and workloads, which contributes to accumulating architectural debts affecting software architecture over time.
In the accumulation of design decisions, architectural design decisions occur consciously or unconsciously, negatively influencing the quality attributes especially maintainability and evolvability.
Furthermore, there are other reasons such as structural complexity, lack of architecture documentation, poor quality of the architecture design solutions, organizational environment, insufficient development tools, violations of the original architecture rules, scarcity of traceability of history and analysis of software architecture, inconsistent requirements, accumulating architectural debts, the connection of the bug-prone files, and ignoring quality attributes demonstrating in Table 6.
The results also indicated the extent to which the frequency of the causes occurrence according to their statement and impact on the case study in the chosen primary studies at a different ratio. The rush evolution of the systems scored 19.77 %, the recurring changes 18.60 %, the lack developer's awareness 12.79 %, the time pressure and accumulation of architectural design decisions 9.30 %, the violation of the original architectural rules and structural complexity 4.65 %, the poor quality of the architecture design solutions 3.49 %, the scarcity of traceability of history and analysis of software systems architecture, insufficient development tools, and unresolved differences between conceptual and concrete software architecture 2.33 % and ignoring quality attributes, inconsistent requirements, organizational environment, accumulating architectural debts, and connection of the bug-prone files 1.16 %. Fig. 7 shows the frequency for the cause occurrence according to their statement in the chosen primary studies.

B. RQ2) WHAT ARE THE KEY INDICATORS THAT HAVE A PROMINENT ROLE IN THE PERMANENCE OF THE ARCHITECTURAL DEGRADATION SYMPTOMS?
In the first research question, we identified the potential reasons, which clarified the occurrence of architectural degradation. In this question, we specified the prominent key indicators of the architecture degradation symptoms, which appear as a result of the presence of the possible causes.
We found the four key indicators (as illustrated in Table 7), which are code smell, architectural smells, architecture technical debt, and the violation of the architectural constraints. As earlier stated, the key indicators of architectural degradation symptoms are classified. To illustrate, firstly, the code smells were divided into two groups; the code smells individual and the code smells agglomerations (as shown in Table 8). Secondly, the architectural smells were divided into three groups; architectural hotspots, architectural bad smells/architecture anti-patterns, and architectural change/instability (as shown in Table 9). Thirdly, architectural constraints violation was divided into three groups;   internal attributes' violation, violations of object-oriented design characteristics, and architecture inconsistencies (as shown in Table 10).
The results show the extent to which the frequency of the key indicators appearance of the architectural decay symptoms as reported by conducting an empirical case study in the chosen primary studies at a different ratio. The code smells obtained 40.00 %, the architectural smells 28.33 %, the breaking of the architectural constraints 25.00 %, and the architectural technical debts 6.67 % (as demonstrated in Fig. 8).
According to each group of the key indicators groups of degradation symptoms, the results indicate that in code    smells group, code smells individual obtained 79.17 %, while the code smells agglomeration obtained 20.83 % (as illustrated in Fig. 9). In architectural smells group,  architectural hotspots obtained 11.76 %, architectural bad smells/architecture anti-patterns 47.06 %, and architectural change/instability 41.18 % (as stated in Fig. 10). In a group of the architectural constraints violation, the internal attributes violation obtained 13.33 %, violation of object-oriented design characteristics 53.34 %, and architecture inconsistencies 33.33 % (as shown in Fig. 11). The second question discusses the key indicators of architectural decay symptoms and resulting problems as well as the risks for OSS projects. Based on the findings, this question presents the proposed solutions for symptoms of the key indicators in each primary study.
The results showed many solutions that vary in terms of strategies of the used solutions such as models, measurements, approaches, algorithms, tools, techniques, and methods, that may integrate more than one instrument and strategy according to the proposed solution (as shown in Table 18).  The most important of these solutions are the metrics-based detection strategy, prioritization of architectural anomalies, investigating and addressing of architectural rules violations, applying refactoring strategy, applying architectural recovery strategy, and other proposed solutions (as illustrated in Table 11). These stated solutions are originally considered general solutions. Hence, the most important used solutions have been detailed into more clarified solutions as shown in the following tables. For example, metrics-based detection strategy is shown in Table 12, prioritization of architectural anomalies is clarified in Table 13, investigation and addressing of architectural rules violations are indicated in Table 14, applying refactoring strategy is illustrated in Table 15 and applying architectural recovery strategy is shown in Table 16. The proposed solutions are also categorized according to the stated mechanism, whether this mechanism is the identification, avoidance, addressing, reduction, or prediction of architectural degradation within the environment of OSS projects. Table 17 shows the classification of presented solutions types.
The results also indicated that the most suggested solutions to be used are the metrics-based detection strategy obtained 20.27 %, investigation and addressing of architectural rules violations 17.57 %, architectural anomaly prioritization 12.16 %, architectural recovery strategy 9.46 %, refactorings strat-VOLUME 8, 2020 egy 8.11 %, proposing various approaches for automatic detection 6.76%, exploring the architectural impact, analysis and monitoring of inherent complexity, proposing a prediction model 2.70 %, code-based multilevel analysis, presenting the graph kernel approach, identifying causes of architecture changes, analyzing stinkier code, detecting architectural tactics, developing techniques, proposing an approach for tracking, proposing active hotspot, quantifying the diffuseness, proposing Detection, and proposing HIST 1.35 % as shown in Fig. 12.
Additionally, the results of the proposed solution type classification showed that identifying mechanism obtained 52.83%, addressing mechanism 25.47 %, avoiding and minimizing mechanism 7.55 %, and predicting mechanism 6.60% as demonstrated in Fig. 13. The proposed solutions were classified based on the introduced solution strategies in those primary studies. Fig. 14 demonstrates the proposed solutions taxonomy of the architectural decay of OSS projects.

D. RQ4) HOW EFFECTIVE ARE THE PROPOSED USED SOLUTIONS IN THE PRIMARY STUDIES?
The previous question about identifying proposed solutions to handle architectural degradation within the OSS projects environment has been earlier clarified. This question determines the extent to which the solutions are effective and efficient as well as to what extent these proposed solutions can achieve the contributions to address architectural degradation.
Since the proposed solutions are divided according to specific mechanisms, therefore, the effectiveness of the solutions is identified as previously stated in the mechanisms. There . Both (high PageRank and high criticality) metrics provide valuable information to the developers, of which information can be utilized to explore the danger of architectural smells [S13]. The use of architecture-sensitive information for code anomalies detection will introduce critical knowledge for engineers to identify and address smells immediately [S57].
Regarding the solutions sufficiency of anomalies prioritization strategy, the results showed that the agglomeration flood standard introduced good outcomes for the determination of the architectural problem, but it does not necessarily represent the most critical smells [S03], [S13]. Furthermore, the recommended heuristics and architecture blueprints are able to improve and rank the prioritization process compared to the metric-based strategies, from 20 % to 60 % of critical code smells, thereby it motivates for prioritizing architecturally relevant code smells [S48], [S16], [S58].
[S31] indicated that the most optimal models are not accurate enough to specify classes relevant to architectural inconsistencies dependent on the code smell. In contrast, the context-based smell prioritization techniques indicated that relevant results introduce more improvement than the severity-based smell prioritization [S17]. Moreover, all algorithms achieved high performances such as the ones that were obtained by J48 and Random Forest while the worst performance was obtained by the support vector machines, suggesting that machine learning implementation to the detection of the code smells may provide high accuracy (>96 %) [S42]. VOLUME 8, 2020   . The profound understanding of the architectural decay and its impact showed an increasing trend in the degradation pre-refactoring and a decreasing trend in post-refactoring, producing the erosion that is detached from size after the post-refactoring termination [S30]. As for the ArCatch, an architectural conformance checking approach proved to be beneficial in the specification of the current exception handling decay issues and its reasons by detecting 7 violations of the design rules where the 6 design rules corresponded to all the versions [S32].
As for architectural recovery strategy solutions, the structural-and lexical-based layering techniques outperformed structural-based approaches to recover the software architecture of object-oriented (OO) systems [S37]. A more   showed that constructing a ground-truth architecture for the wide systems is feasible unlike prior intuition for recovering architecture, which claimed that it is infeasible. Hence, the outcomes can assist the improvement of the understanding of software architecture.
With respect to proposing various approaches for automatic detection, repair of architectural problems and support VOLUME 8, 2020   software developers during the development in Java projects, the DARCY approach has a significant impact in minimizing the attack surface and enhancement of the encapsulation, maintainability and security [S09]. The automatic architecture validation approach introduced a considerable enhancement by the tool application during the development [S49]. Supporting the automatic analysis of software architecture by Arcan tool, reveals a precision of 100% of the architectural smells except for the external components, which reported false negatives [S29]. The experiment with various tools for code anomalies exploration showed providing various answers, although depending on similar detection algorithms and the tool precision usually differ based on the code anomalies, in which it is analyzed and the levels and contexts difference for the tools.
Concerning analysis and monitoring inherent complexity solutions, the evolutional changes that took place in the architectural stability and structural complexity showed the complex packages excessively as all dependencies are not generated balanced-well, and the dependency relationships nature between packages is relatively abstract [S68].
[S65] found out that the architectural flaws (or multiplecomponent) are more complex to repair than other flaws as over 50 % of the topmost flawed components must change coincidingly with other components to repair a multiplecomponent.
With respect to exploring the architectural impact of the bug-proneness and change-proneness that violate design principles by connections among files, the DRSpaces model showed that the architectural impact is persistently connected among bug-prone files over time [S02]. Moreover, the architecture anti-patterns detection approach indicated that it is robustly associated with greater change-proneness and bugproneness files, which leads to increasing change and bug rate considerably. [S10].
In terms of investigating the relationship between code anomalies and architecture problems, the correlation of the architectural designs and code smells agglomerations The proposed solutions taxonomy of architectural decay. VOLUME 8, 2020 indicated that most of the god classes' m-LOC (67%) flocked around architectural concerns [S18], almost 65% of all code smells were correlated to 78% of all architecture problems [S62].
As for the prediction model for determining architectural anomalies and historical architectural smells data, the machine learning techniques to predict architectural smells, which depends on historical information showed that the prediction performance is very high [S11]. Furthermore, the link prediction (LP) techniques showed an acceptable achievement for the positive class and also indicate high recall concerning the realistic anomalies identification although a specific anomaly type can impact the recall and precision [S21].
The evolution of architectural smells detected by a tool, namely Arcan, showed that Hublike dependency smell is better in terms of complexity, current and future maintenance effort compared to cyclic dependency [S12]. Active Hotspot (AH) model showed that measuring as 100 issue fixes, ranging usually between 2 and 3, and seldom more than 5, to detect significant problems architecturally [S14]. In terms of the repeated occurrence for code anomaly, 59% of anomaly classes are influenced by more than one anomaly [S24]. The DSL allows the identification of many various anomalies that support the detection technique's effectiveness and the generality of its DSL [S69]. The historical information for anomalies disclosure indicated that over 75% of the anomaly is regarded as the design problems where the recall is between 58% and 100% and the precision is between 72% and 86% [S51]. Several design problems were detected by 36.36% of the developers, where these problems explicitly appeared when the analysis of agglomeration smells compared to individual smells [S15]. The easy accessibility of information in the issue and code repositories do not adequately involve the architectural significance of the current classification issues [S19]. The architectural distance indicators can be utilized for both flaw assessment and localization on the dependency graphs of consecutive releases of systems [S66]. The architecture degradation based on the multi-level analysis method indicated that it is useful for detection erosion points and more efficient for fixing architecture decay [S05].

V. DISCUSSION
This section presents an analysis and discussion of the findings based on the objectives of the study and the research questions. Moreover, some recommendations are stated to be an inception point for the direction of future research in this domain.

A. THE POSSIBLE REASONS FOR THE OCCURRENCE OF ARCHITECTURAL DEGRADATION (RQ1)
The findings showed that 17 of the most commonly occurred causes contribute to the architectural decay of the OSS community. Essentially, architectural degradation has numerous causes, which have been discussed by several researchers in their studies [11], [12], [23], [30]. However, these reasons have been discussed from limited aspects such as aging because of changes over time [11], identifying the reasons through only one case study [12] or based on their investigation of industrial case studies [27]. Consequently, these causes need to be further identified in terms of the frequency of their occurrence, especially in the scope of the OSS projects. Moreover, identifying the most important reasons will indeed contribute to the erosion according to the chosen primary studies, which contain several case studies in different domains for the OSS community. These causes differ in their impacts with regard to the actual contribution to the architectural decay prominence.
The rapid evolution of software out of 17 represents a stated reason of 19.77%, which means that the rapid development of software provides a significant chance for the growth of architectural smells across the system versions that increases obscuring in identifying architectural problems within the system. In addition, increasing the conceptual distance between the existing architecture and the designtime one leads to an increase in the amount and complexity of interactions between the elements of the system software. This reveals that the rapid development of software deviates from the original structure by releasing new versions of the system, especially when the development violations of the implemented architecture are not controlled in a systematic manner. One of the reasons that plays a major role in architecture degradation is the frequent changes that represent 18.6% of the stated reasons, such as adding, removing or modifying new features or requirements that have a major impact on the deviation of the architecture far from its origin. A change that is made without adapting the requirements and components leads to the erosion of the architecture over time. This also reveals that changes must be made by considering the adaptation to the current and future requirements to avoid architectural contradictions in the subsequent versions of the system. The lack of developers' awareness is considered a significant reason for the contribution to architecture decay within the OSS, of which it represents 12.79% of the reasons as a whole. The lack of awareness results from a lack of basic knowledge of architecture, writing inappropriate codes that may cause errors that are difficult to maintain later, the practice of building systems as a hobby, lack of training for developers in developing their programming skills and educating them in an analysis of the inherent risks in the system.
These reasons are considered the most contributing to degradation, while the rest of the reasons demonstrated in Table 6 are less important than the three stated reasons depending on what was declared in the selected primary studies. However, further studies should be conducted to find out the other causes as a rooted-deep study in digging up new causes that could have a significant contribution to identifying the architecture erosion, whether over the OSS or industrial systems.

B. KEY INDICATORS OF ARCHITECTURAL DEGRADATION SYMPTOMS (RQ2)
The findings showed that four of the key indicators of architectural degradation symptoms were detected within the OSS, which are code smells, architectural smells, architectural technical debts, and violation of the architectural constraints.
In reality, the code smells are autonomous from architectural smells [68], therefore, architectural smells have to be regarded as one of the main sources for identifying the decay symptoms [69]. While the code smells have a significant impact to increase software's defectiveness [70], [71] and change proneness [70], [72], they correlate with architectural problems [43]. Hence, the architectural smells existence does not imply the code smells existence and vice versa.
The code and architectural smells are considered the highest impact symptoms on the software architecture (as demonstrated in Fig. 8), since several studies were conducted to address the code and architectural smells, including their subcategories.
The results also showed a details group of the key indicators per each stated symptom. In the code smells group, the code smells individual and code smells agglomeration are typically key indicators of the code smells within the OSS. The code smells individual is the most frequent study of the key indicators of code smells than code smells agglomeration (as shown in Fig. 9). However, several studies addressing code smells agglomeration have proven that these smells agglomeration have a significant correlation with architectural problems from code smells individual.
In the architectural smells group, architectural bad smells (architecture anti-patterns) stood out as the most effective smells compared to architectural change (instability) and architectural hotspots smells (as shown in Fig. 10). This reveals that the architectural bad smells were studied in isolation and not combined with more than one smell, which was covered in the prior code smells. Consequently, further research in this domain should be conducted to identify the effect of architectural smells agglomeration and its correlation with architectural problems rather than the architectural smells in isolation in order to prove its inclusion or exclusion as one of the key indicators of the architectural decay symptoms.
In a group of the architectural constraint's violation, violations of object-oriented design characteristics emerged as the most influencing violations of object-oriented properties such as abstraction, encapsulation, modularity, and hierarchy while Internal attributes' violation is regarded essential for architecture software design such as complexity, coupling, and cohesion. Architecture inconsistencies violation that refers to expression, declaration or statements emergence in the source code, which do not correspond to the restrictions forced by the planned architecture that will lead to improper implementation decisions accumulation resulting in an architectural decay or erosion within the community of the OSS.

C. PROPOSED SOLUTIONS FOR ARCHITECTURAL DEGRADATION (RQ3)
The results showed numerous solutions that can be nominated to address architectural erosion. The metrics-based detection strategy solutions are most commonly used to detect architectural decay. These metrics manifest its performance in exploring and estimating the source code metrics effectiveness, addressing modularity to identify indicators of architectural debt, detecting code anomaly problems within the code elements using architecture-sensitive implementation metrics, automatic detection of code anomaly, identifying instability or stability software components, determining architectural anomalies that most critical ones, and measuring code anomalies with regard to their relations and co-occurrences. The cause behind using these metrics in several studies is that the models or intended architecture documentation are usually missing. Therefore, the code is commonly the unique and most significant source of information about the possible violation identification of the architectural desired structures by code smell investigation founded on metrics of the source code.
In the same context, there are also proposed solutions that address architectural degradation, which are less common than the solutions using the metrics-based detection strategy. These solutions are such as investigation and addressing of architectural rules violations, which provide the focus on the locations of violations within the system or place architecturally inappropriate files inside packages or classes, violating the planned architecture rules.
Regarding the priorities of architectural anomalies, it depicts a focus on the most influential anomalies in structure and more closely related to architectural problems rather than the anomalies that have no strong correlation with those problems.
Concerning an architectural recovery strategy solution, it describes the recovering the basic concepts of the planned architecture to conform to straightaway implemented architecture and to identify design decisions that may harm the basic rules of the intended architecture.
The refactoring strategy solutions represent the recommendations and guidelines for changing the structure and the behaviors of the internal system elements. Additionally, there are many other solutions proposed in addressing architectural degradation within the OSS environment.
The results also showed the classification of the proposed solution type in addressing decay that refers to addressing, identifying, reducing, avoiding, and predicting the architectural erosion, whereas several studies revolve around the idea of identifying architectural erosion more than the classification of other solution types (as highlighted in Fig. 13).
With respect to the proposed solutions to address architectural degradation, we have developed its taxonomy to clarify the overall stereotype to contribute to identifying the paths of these solutions and the extent of their facilitation to researchers in enhancing this taxonomy (as demonstrated VOLUME 8, 2020 in Fig. 14). This also reveals that the extent of the proposed solutions to address the decay within the OSS environment is still expanding and discovering other features of these solutions or integrating convergent solutions would provide better meaningful results. However, it does not mean that these proposed solutions have great effectiveness in dealing with degradation, and this is what we will get acquainted within the next section on the effectiveness of the proposed solutions.

D. THE EXTENT TO EFFECTIVENESS OF THE PROPOSED SOLUTIONS (RQ4)
As already discussed in the earlier research question (RQ3), the proposed solutions by the present researchers are based on their studies to address the architectural degradation and the extent of taxonomy identification according to the explicit strategies and convergence of the solutions. Therefore, in this section we explore more about the effectiveness of these solutions and the impact of their potential benefit in addressing architectural erosion within the open-source software community. The solutions are discussed based on the taxonomy stated in the prior research question (RQ3) as shown in Fig. 14.

1) METRICS-BASED DETECTION STRATEGY
We observed that the metrics strategy solutions were the most frequently used in identifying the architectural decay, thereby these metrics can determine the architectural instability growth with the system evolution, identify the probability of the classes contributing to architectural inconsistencies, and diagnose the anomalies, whether agglomerations or individual is more correlated to architectural problems. However, the use of current metrics at the class level may be affected by size bias significantly and inefficiency automatically in detecting architectural problems, indicating that the most likely cause is the problem on how these metrics are implemented through tools and reconsideration in specifying the selection of the appropriate metrics at different locations of software components, especially when compared to the same results that achieved efficiency manually.
In another context, AbdeenMod+RM metrics introduced an acceptable satisfaction in the fault prediction modeling. This satisfaction may increase in the implementation of a large number of alternative metrics and other techniques used in diverse aspects to present different results, which may reflect the overall recommendations of the research.
Modularity metrics refers to the significantly negative interrelationship by modularity indicators IPCI and IPGF. This may improve the performance and accuracy or less effort needed to predict by assuming a new modularity metrics at the system level and adapting current modularity indicators specified in other perspectives (e.g., complex networks). Furthermore, the architecture-sensitive metrics for code anomalies discovery provides the majority of awareness to engineers for the existence of the smells code elements that are more significant to the architecture design than the most traditional metrics that are depending on source code and based on static code metrics combination. This means that the developers and engineers could detect and repair such anomalies promptly.
Therefore, more studies are needed in this field for other metrics to be analyzed in order to provide the most appropriate architecture without any impact of the size bias. Furthermore, there is a need for metrics that have a great ability to discover the inconsistent classes affected by the degradation from the consistent classes. In addition, there is a need to identify the effort required for the metrics strategy to architecturally detect related anomalies and also to derive more metrics that may have an impact on the quality relationships of other software that are closely related to architectural problems.

2) PRIORITIZATION ARCHITECTURAL ANOMALIES
In the anomaly's prioritization strategy, the agglomeration flood standard and most optimal models showed that some agglomerations are overburden with false positives and not precise enough to identify architectural inconsistencies in classes, leading to the inability to capture several various architectural problem types. In contrast, the recommended heuristics, architecture blueprints, and the context-based smell prioritization techniques show the ability to rank and improve in identifying the prioritization of anomalies related to architectural problems. This reveals the need for providing an initial enrichment of the possible results to adopt the solution with a tendency in the ideal combination to prioritize architectural anomalies. Consequently, there is a need to provide various prioritization criteria for seizing the diverse architectural problem types and enhancing the essential techniques used for discovering code anomalies. Moreover, the integration of two or more heuristics would get better ranking results' effectiveness. Additionally, it is possible to introduce the new strategies to produce ranking on numerous criteria in order to provide visualization capabilities that are most relevant to architectural problems for the developers.

3) ARCHITECTURAL RULES VIOLATIONS
In terms of using the architectural rules violations solutions, we observed that many violations were not restricted by the architectural principles of the system, which may not have defined the necessary rules to reduce the severity of major violations. This means that violations still appear over again and over again despite the good violation solutions that were introduced and the approaches that have a significant role in capturing violations with thorough accuracy. Therefore, it is important to highlight the identification of the necessary rules and identification of critical cores through a broad study on architectural conformance using multiple frameworks.

4) REFACTORINGS STRATEGY
The refactoring strategy solutions do not contribute significantly in addressing the architectural degradation, as it showed many excesses in identifying architectural problems and is not positively affecting them, however, it may have a simple contribution in addressing architectural erosion when its problems are minor and easy to repair. This reveals that the quality of these solutions is not efficient at all in the problems of deep analysis and the difficulty of address.

5) ARCHITECTURAL RECOVERY STRATEGY
Based on the obtained findings, the architectural recovery strategy can accurately detect and recover the conceptual design decisions of the system, rather some techniques used in recovery architecture provide an acceptable improvement and may outperform each other as illustrated in the technique of layers based on structural and lexical in its noticeable superiority from the structural-based approaches. This reveals that architecture may be recovered with acceptable accuracy unlike the prior intuition based on its claimed hypothesis in an application difficulty to recover conceptual architecture. However, there is a clear opportunity for many researchers to shed light on checking more efficient approaches to architecture recovery by enriching ARCADE's tool to add further different current code-level analyses to it. Besides, there is also a need to conduct more experiments on a wide scope on more systems, especially industrial systems as well as to increase approach accuracy through documentations, pull requests, commit messages, comments, tests, and much more.

6) OTHER SOLUTIONS
Based on our observation, the other proposed solutions to address the degradation differ in terms of the performance effectiveness of the solutions and highlight a specific part to reduce erosion. Automatic detection for various approaches introduces an acceptable enhancement in the discovery of architectural smells despite providing various answers and excluding the external components that are notified as false negatives. An inherent complexity grants a great opportunity to increase the complexity and its development over time when it is not monitored and analyzed, leading to the multiplication of the change in other components in an unbalanced way. This reveals the extent of the leniency risk for not monitoring the complexity since its early evolutionary of components. Concerning the connected files to each other when bug-proneness and change-proneness constantly occur, it reflects negatively on the architectural influence. This reveals that the increasing rates of change and errors of these files inevitably lead to violate the basic design principles of the architecture. Consequently, reconsideration must be given to how architectural smells evolve and their profound relationship with problems from an architectural perspective, through existing tools that may need to be re-analyzed to cover a wide scope of those anomalies and reduce the current and future maintenance efforts for these systems.

VI. IMPLICATIONS FOR RESEARCH AND PRACTICE
An SLR study provides directions for researchers and practitioners on architectural decay within the OSS domain as follows: 1) There are reasons that could contribute excessively to increasing architectural erosion such as rapid development of software, frequent changes, and lack of developers' awareness. Therefore, further studies should be conducted as a rooted-deep study to find out other causes and to identify architecture erosion whether on the OSS or industrial systems. Practitioners should follow guidelines to avoid architectural contradictions in the new and subsequent versions of the system in terms of identifying the potential reasons within the system environment. 2) Since architectural degradation symptoms present that code smells agglomeration has a considerable correlation to architectural problems compared to code smells individual, researchers should conduct further investigation on architectural bad smells in combination. Practitioners can change their detection way depending on the code smells agglomeration to identify degradation symptoms effectively.
3) The findings of the current study serve as evident that a metrics-based strategy is the most commonly used solution as compared to other proposed solutions. However, more studies are needed in this field for other metrics to be analyzed to provide the most architecturally appropriate solution and identify the effort required for the metrics to detect architecturally related smells. The essential techniques of ranking used should enhance the possibility to get better effectiveness results and the identification of critical cores of architectural violations. Also, there is a clear opportunity for many researchers to highlight enriching ARCADE's tool for efficient approaches to architecture recovery. Additionally, there are solutions, which show that it is not effective at all in the problems of deep analysis and the difficulty of address such refactoring strategy that has no considerably a positive impact to address architectural erosion.

VII. THREATS TO VALIDITY OF THE STUDY
The major threats influencing the validity of SLR are associated with the direction that might have biased our systematic literature review. We identified highlighting search, selection of the relevant studies, and extraction of the adequate data for our investigation. The threats to validity are described [73] as follows: 1) Internal validity: The studies indicated [57], [74] that the common threat to SRL is to explore all researches and relevant studies to the specific research question. We attempted to maximize internal validity by selecting online appropriate databases that include enough relevant studies. Accordingly, eight well-known online databases were selected such as Scopus, Springer, Science Direct, Web of Science, Wiley, and Taylor and some of them specialized in our field of the area such as ACM, IEEE, covering all journal papers and conferences. We also tried to maximize internal validity by identifying effective and sufficient search terms, including the synonyms, other alternative words, and abbreviations that identify and explore, from several recent scientific papers to adequately cover the specific research question. Additionally, the snowballing search strategy was applied by backward and forward investigation of the selected studies in order to explore the relevant papers that may be missed if the lack of a sufficient search term was considered. 2) Construct validity: We evaluated the quality of included studies in order to make sure that all potential articles were properly selected according to the specified criteria. We also tried to maximize the construct validity by excluding or including papers by following the guidelines proposed by Brereton et al. [75] and Kitchenham and Charters [57]. Additionally, we designed data extraction forms to collect the information, check the gathered data, and generate a checklist in order to investigate the required information, which was accomplished by conducting the analysis and discussion among the researchers to reduce the circle of difference and increase the accuracy of extracted information in line with the answer to the specific research question as properly as possible. 3) External validity: The study of software architecture in open-source software was conducted on 74 studies, including the articles obtained by the forward and backward strategies for the snowballing process, thus the study findings are generalizable to other studies that may pertain to architectural erosion in an open-source environment.

VIII. CONCLUSION
In this study, we conducted a Systematic Literature Review (SLR) to explore architectural degradation within the open-source software (OSS) community. The main goal was to systematically investigate and review the existing architectural erosion of the OSS to identify eroded architecture from diverse perspectives: the reasons that assist in the occurrence of architectural degradation, key indicators to initialize a permanence of the architectural degradation symptoms, the proposed solutions contributing to addressing the architectural decay, and the extent of the efficiency of these solutions. Numerous methods and criteria were used to include the relevant studies and exclude studies that were irrelevant to the research questions. A total of 74 primary studies were identified to analyze architectural erosion within the OSS community. Our analysis indicated that 17 reasons contribute to architecture erosion within the OSS projects and the causes most commonly occurred are the rapid of software evolution, frequent changes, and the lack of developers' awareness. Simultaneously, we observed that four of the key indicators of architectural erosion symptoms were revealed within the   OSS projects, which are code smells, architectural smells, the architectural constraint's violation, and architectural technical debts. Our analysis also revealed the proposed solutions addressed degradation, which were categorized. They showed that most solutions were based on the metrics-based strategy.
Other solutions are such as anomalies prioritization strategy, addressing and investigating architectural rules violations, refactoring strategy, and architectural recovery strategy, which were also identified and detected in terms of the extent of the effectiveness and accuracy of these proposed solutions as well as their contribution to identify, address or predict the architectural degradation within OSS projects. It can be concluded that the problems of architectural erosion within the OSS projects, including identifying, addressing, avoiding and predicting are still open research issues, which need further analysis and investigation. Consequently, more efforts on this domain should be focused on identifying the other reasons that are still unclear and suggesting other solutions to provide more performance and accuracy to address architectural decay.

APPENDIX A PRIMARY STUDIES REFERENCES
See Table 19.

APPENDIX B QUALITY ASSESSMENT CRITERION
See Table 20.