Risk Factors and Practices for the Development of Open Source Software From Developers’ Perspective

Open source software (OSS) has achieved popularity, however there are various software product quality problems, security issues and certain challenges confronting the OSS growth that need to be identified and addressed. The main focus of this research is to identify the risk factors associated with open-source software and the practices for those risks which will help software development companies and individuals to mitigate the risks. A systematic literature review (SLR) is employed for the identification of potential risk factors in OSS whereas questionnaire survey is used to validate the findings of the SLR from the relevant expert community. In the second round another SLR is carried out to identify the practices for softening the effect of risk-factors in OSS development. A total of 14 risk factors from the developers’ perspective are identified via SLR in OSS. Amid the risk factors identified bugs, insufficient product documentation, and lack of communication and coordination among developers are considered the most important Further, we performed a secondary SLR to identify the practices for mitigating the effects of the risk factors in OSS. Therefore, a total of 31 practices for mitigating and addressing the risk factors in OSS were identified. In this work, we identified 14 risk factors and 31 practices for mitigating the critical risk factors, through SLR for adapting OSS development from developers’ perspectives. We argue that focusing on the identified risk factors would minimize the risks associated with OSS. We also recommend that OSS developers should diligently consider all the risk factors that have been identified in the study for increased software productivity and distribution of reliable and robust source code.


I. INTRODUCTION
Open Source Software (OSS) is a software, where the source code is freely available and contained within for reuse, enhancement and further delivery [1]. OSS is considered to be a future model to deliver automation through robust software development, and to meet the everchanging requirements The associate editor coordinating the review of this manuscript and approving it for publication was Fabrizio Messina . through free code. Even organizations like the Microsoft are joining the open source community. OSS has also good effect on the economic development of a country [2]. Numerous countries across the world have started to use OSS solutions for increased software productivity. This trend has attained a high degree, an approach towards established economies [3].
However, the OSS benefits will not be achievable until the associated risks are mitigated. Irrespective of the acceptability of OSS, there are various software product quality problems, security issues and different difficulties limiting the OSS growth. Numerous businesses and professional sectors are practicing or exercising OSS model, since they understand the advantages like low development cost, fast development cycle and many others [4]. However, there are doubts regarding quality assurance in the shape of program code quality and maintenance of the code throughout the life cycle of the software [4]. It may cost too much for stakeholders if serious open source module crashes halfway over the development phase of a marketable software [5]. Most of OSS projects do not achieve maturity, that indicates developmental issues [6]. To stay practical, several OSS projects require a steady involvement of fresh volunteers. These newcomers face many difficulties when take part in software development such as, how to start, societal connections, code problems, documentation issues and tenderfoot knowledge [7]. The greatest substantiated obstacles are newcomers' technical abilities, getting reply from community, criticality of social contacts, and finding the suitable path to start contributing [7]. Guidelines [8] have been produced for the purpose of synthesizing of different practices that have been identified for addressing the challenges of OSS.
This research is carried out to identify and highlight the risk factors in adapting OSS. For the achievement of primary idea, four research questions are designed as follow: RQ1. What are the risk factors associated with the adoption of OSS?
RQ2. What are the risk factors for adapting OSS in the realworld industry? RQ 3. Do the recognized/identified risk factors differ within both the data sets i.e., SLR and real-world practices RQ 4. Are there any practices found during the SLR for lessening the challenges/risk factors during development of OSS from the developers perspective A short summary of the sections of the paper is presented as follow.
Section II poses background study of the OS; Section III gives detailed description on the adapted research methodology for the identification of factors and practices. Section IV presents the results. Section V discusses the implications of the findings, whereas section VI presents the conclusion and future work. Finally, section VII discusses the limitations of the study.

II. RELATED WORK
OSS is affordable, re-useable, adaptable, low cost and provides the liberty of choice. These key characteristics have facilitated open source as a first-choice platform for many software companies and individuals [9], [10], [11]. The key strength of OSSD is its motivation of outside uniqueness; for example, free access, practicing, assessing, debugging and enhancing new competences [10], [12]. OSS inspires individuals to use their expertise to create a value-added software at a lower cost [4], [9].
Though OSS has many benefits, yet it faces distinctive difficulties and challenges in widespread adoption. For instance, one such challenge is the absence of proper documentation. Programmers from various parts of the world and societies are engaged with advancement process who do not properly document their code. Likewise, there are usability, configuration, and design issues.
Opensource programming is preferred as an answer for majority of computing challenges confronting public sector organizations. Coelho et al. [13] states that one of the harmful effects of an abandoned project is a number of bugs. Rashid [14] pointed out that usually developers are geographically spread out, thus the management and coordination is not performed face to face hence OSS face many difficulties.
In this study we have used systematic literature review (SLR) as a research methodology to identify the risk factors and the practices for the risk factors in OSS from the developers' perspective. As far as our knowledge, there is no SLR conducted and published for the identification of risk factors till date which has significant influence on adaptation of OSS. The findings of this study demonstrates that the companies have been updated concerning all possible risk factors/challenges for familiarizing with OSS for further secure and up to date software production. Suitable familiarity regarding the risk factors/challenges in OSSD will similarly insist the outcomes of the methods, solutions, tools and a model, for mitigating the challenges faced by OSS developers, which we will deal in our future study.

III. RESEARCH DESIGN
For the identification of risks during the development of open-source software we have used systematic literature review and survey as means of research methods. Once the possible risks were identified, we then validated the findings from worldwide relevant experts and groups for its pertinence. These methods were exercised due to the nature of the research and data used. This kind of research design is also used by other researchers [15], [16], [17], [18], [19], [20].

A. SYSTEMATIC LITERATURE REVIEW (SLR)
In this study Systematic Literature Review (SLR) is exercised as research tool as SLR is detailed, fair, and yields dependable and consistent outcomes in comparison with ordinary literature review [21]. A systematic review gives a high-level authenticity in trying to find, evaluate and summarize all possible available proofs on an exact research question, as compared to ordinary literature reviews. A similar methodology has been adopted by several researchers [15], [16], [17], [18], [19], [20]. For the purpose of reviewing the literature. The below sub units define certain phases for SLR approach, which have been taken in the conduction of this study.

1) IDENTIFICATION OF PROBLEM
The core focus and the objective of this study is to find out the risks or challenges in OSSD with developers' perspective. To this end, research questions are designed to achieve the objective. The set of research questions are in Section I.

2) SOURCES OF DATA
During this phase, we designed and implemented a experimental search string on certain digital libraries. We searched the digital libraries including IEEE Xplore, Science Direct, ACM Digital Library, Wiley online Library and Springer Link. A total of 4, 289 articles were found. The same sources are used in the literature as well [15], [16], [17], [18], [19], [20]. Table 1 presents the search query string. Table 2 gives a summary of the conclusively chosen list of sources which were examined in this phase. The total articles found were different in each digital library.

3) SELECTION OF PUBLICATIONS
For final selection of the relevant publications, an inclusion criterion was used which is as follow: • Only Computer Science background related papers were selected and written in English language only.
• Research papers that describe the idea and risk factors/challenges/of Open Source Software.
• Study that reports practices/patterns for developing OSS.
• Research study which reports tools/expertise for the OSSD.

4) QUALITY ASSESSMENT OF PUBLICATION
Once the selection of publications was finalized, a quality assessment check was performed. Some questions were check listed in the process of selection, in order to make sure the quality of the chosen study is met. To facilitate the study selection, process the quality criteria is applied and it is made sure that only related papers are chosen. The following questions are used in the quality criteria: (a) Do we have a strong portrayal for adapting OSS development? (Yes/No/Partially) (b) Do we have a clear demonstration of the methodology used for the identification of risk factors/challenges for OSS?
(c) Do we have a clear idea that how the risk factors/challenges in OSSD were identified? (Yes/No/Partially) (d) Have the research questions been reflected through results in understandable way?
For the purpose of validation, a small subset of secondary reviewers scored the selected publications. Through quality assessment, some publications were excluded that did not meet the quality criterion. Studies that focused only the risk factors in Open Source Software were selected. In a similar way, studies which did not provide convincing outcome in risk factors related to Open Source Software were left out.
During searching phase, 4, 289 papers were searched initially which has been showed in Table 1. Afterwards thru title-based evaluating and studying the abstract of each article during searching phase, 833 papers were chosen as primary selected papers through the search string showed in Table 1. Afterwards using the inclusion criteria already described, we chose 159 papers for our final review. Note that the selection was made in January 2020.

5) DATA EXTRACTION AND SYNTHESIS
During extraction phase, data was extracted through a predefined form while studying each of 159 papers. The form had the fields including date of review, paper title, authors, publication year, database it was taken from, most importantly the risk factors that have impact on OSS, research methodology, population which was targeted, organization type, company size and the country. When the data extraction was conducted, we applied data synthesis to finalize and synthesize the risk factors. We identified 14 risk factors, as shown in Table 3 along with their research paper ids in which the risk factors have been identified. The paperid details 159 are mentioned in Appendix. Subsequently identification of risk factors or challenges for open-source software from the perspective of vendor, we classified risk factors as revealed in Portion IV. A certain risk/challenge was labeled as critical, if its occurrence or frequency in the finally selected number papers is greater than or equal to 15%. Significant risk factors are ''bugs in source code,'' ''Insufficient product documentation,'' ''Lack of appropriate Communication and Coordination among developers'' and ''Lack of Knowledge.''

B. EMPIRICAL VALIDATION THROUGH QUESTIONNAIRE SURVEY
After conducting the systematic literature review, we developed a questionnaire survey in OSSD environment in order to validate the identified risk factors. There were two purposes of this questionnaire survey, first, we wanted to certify the outcomes of our SLR with OSS developers from Software development organizations and secondly to identify any other risk factors not identified through SLR. Hence, we chose questionnaire survey as a means to meet the self-reported data.
We benefitted from Google Forms, which is a free online tool for preparation of questionnaire. The questionnaire too has certain open-ended questions that permitted the respondents to add new risks/comments, besides the ones already identified, if any. A similar method has been used by other researchers [15], [16], [17], [18], [19], [20]. We requested the participants of survey to provide feed-back on a 7-point Likert scale.
To access our targeted population, several online professional forums, sponsored by LinkedIn and Facebook were   accessed. Some OSS development related online research groups were also joined to approach open source software professionals to request the related specialists for contribution to our research survey. Contact was also made with the experts and writers of papers by sending them emails individually. We observed a quite diversified participant's list, where professionals from different geographical sectors took part.
A sum of 78 feedbacks were recorded, from OSS practitioners from various countries. The basic demographics including experience and company size are summarized in Fig 1 and Fig 2 respectively. Table 3 answers RQ1. Table 3 portrays a sum of 14 risks/challenges in open-source software from developers' perspective. Then, we classified four risk factors as critical risk factors. We organized the factors based on their frequency percentage and few were labeled as critical; those having frequency percentage ≥ 15 are called critical. The critical risk factors are bugs in source code (45%), insufficient product documentation (18%), lack of appropriate communication and coordination among developers (18%) and lack of knowledge (15%). Lack of project  management practices (13%) was also identified in this study as an important risk factor. This risk factor describes that since developers are geographically dispersed and lacks appropriate communication and synchronization, so the standard managerial and project management processes are not practiced. Rashid [31] mentioned in her study that OSS systems are mainly developed by volunteers who  Code is open and programmers all over the globe are able to make modification to the code according to their needs and distribute it further. One of the big hurdles in OSS is how to develop its environment, particularly enhancements in the security and quality standards of these systems [32]. Oliver et al. [33] identified that OSS practice faces difficulties such unanticipated code contamination, loss of intellectual property rights, license violation or mistreat, and probable copyright violation. It could eventually lead to legal implications for the organization with major aftereffects (it should be noted however that license infringement is not particularly an OSS matter, but it relates the commercial software too) [33]. Inappropriate service support (11%) is identified as another important risk factor. Lorraine et al. [34] has argued that there is no guard as there is no backing and no organization to support it.

B. FINDINGS OF QUESTIONNAIRE SURVEY (RQ2)
A questionnaire survey was led to answer RQ2 as described in Section III-B. The data of survey, as depicted in Table 3, validates that entire identified risk/challenges have obtained ≥ 50% responses as positive in the sample. The result demonstrates that entire identified risks are of considerable significance for OSS developers. Table 4 gives a list of risks factors which have been validated via questionnaire survey, where 72 OSS experts from various demography took part. The Table 4 results show that most of the risk factors identified have attained more than 70% rates in the positive list. As ''Bugs in source'' is seen to be the extremely momentous risk factor in the optimistic list, i.e. 93%.

C. VALIDATION OF CRITICAL RISK FACTORS VIA QUESTIONNAIRE SURVEY, FOR OSS
These outcomes furthermore show that ''Compatibility Issues'' (88%) is the 2nd most considerable risk factor for the development of open-source software. ''Lack of appropriate Communication and Coordination among developers (87%) 3rd and ''Integration Complexities'' (86%) were seen to be the fourth extremely momentous and significant risk factor in the positive list in the below Table 4.

D. RELATIVE ANALYSIS OF THE RFS THRU THE TWO DIVERSE DATA SETS (SLR VS QUESTIONNAIRE SURVEY) (RQ3)
For investigating the likeness and differences amongst the identified risks/challenges, across the SLR and the questioners survey, we evaluated both SLR and questionnaire data, as presented in Table 6. It is valuable to observe that in Table 6 the risks with maximum values are specified with highest ranks. Those risk factors which are having same values are given equal average rank. Likewise, the succeeding risk factor is adapted with next value correctly. Through analysis we have highlighted the resemblances and dissimilarities among the results of the two datasets. To compare these two datasets, Figure 3 demonstrates the ''Positive %'' of the risks/challenges taken through the slrs and surveys results.
To explore unobserved challenges and to improve the acknowledged list, we put some open-ended questions, which granted choice to the contributors to include more factors, they have come across. However, the response from the survey responders was not significantly different than that observed in SLR.
Empirical results in Table 6 prove that no single risk factor has zero frequency in the survey. It is worthy to mention 63338 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply. that the ranks of both data sets are almost dissimilar e.g., insufficient product documentation is rank number 2.5 in SLR data, while it drops to rank 5 in the questionnaire survey, as portrayed in Table 6.
To analyze resemblance among the risk factors which have been identified by the SLR and the survey, a Spearma's rankorder correlation is carried out as shown in Table 6. It is important to mention that ranking of the challenges of the two datasets are not completely similar. The value of Spearman's correlation coefficient is 0.11137. This demonstrates a strong correlation among the ranking gained from the datasets, with the value of p = 0.704. The value of p is not statistically significant, it is signifying that there is no major dissimilarity amongst the outcomes of the survey and the SLR according to the relative significance of the risk factors. The conclusions of the statistical analysis portray that SLR as well as survey have maximum likenesses than dissimilarities. The stated outcomes are illustrated through scatter plot as well in Figure 3.

E. THE PRACTICE/SOLUTIONS IDENTIFIED BY SLR2 FOR THE MITIGATING/SOLVING OF THE CHALLENGES IN OSS
We reviewed the papers selected for SLR again for practices. SLR guide lines [8] have been followed for the purpose of synthesizing of different practices that have been identified for the challenges of OSS. We identified a total of 31 practices for the mitigating and addressing of OSS critical risk factors. These practices are distributed across different risk factors as discussed in the following section.

1) PRACTICES FOR ADDRESSING BUGS IN SOURCE CODE
This section discusses the practices or solutions meant for the critical risk factor Bugs in Source Code. It has a frequency of 45%. As program code in OSS software is available to  everybody, there are more chances that a non-expert may make changes to source code which may not work properly. Coelho et al. [13] has rationale that one of the adverse effects of a cancelled project is bugs. So, it is significant to note the practices identified in this study in order to mitigate the risk. Table 7 summarizes the key practices and recommendations for addressing bugs in source code.

2) PRACTICES FOR ADDRESSING INSUFFICIENT PRODUCT DOCUMENTATION
This section discusses the solution/practices for the challenge ''Insufficient product documentation.'' ''Insufficient product documentation'' has a frequency of 18%. Most of the software documentations is usually considered as outdated [22], [23], weak and inadequate [24], [25], vague [26], of not good quality [27], and mainly ignored [28]. The non-existence of good quality documentation is mainly predominantly acute for large-scale systems [29] Scott2009. One of the drawbacks which has been argued by researchers [14] that the documentation may be out-of-date or might have perished in development. Table 8 highlights the practices identified to minimize the risk associated of insufficient documentation in OSS.

3) PRACTICES FOR ADDRESSING LACK OF APPROPRIATE COMMUNICATION AND COORDINATION AMONG DEVELOPERS
In this section the practices/solutions for ''Lack of appropriate Communication and Coordination among developers'' are discussed. It has a frequency of 18%. Rashid [14] has urged that maximum number of developers are geologically dispersed and the organization of tasks among them is by  means of asynchronous communication. Table 9 summarizes recommendations for addressing lack of appropriate communication and coordination among developers in OSS.

4) SOLUTIONS/PRACTICES FOR ADDRESSING LACK OF KNOWLEDGE
Lack of knowledge challenge has a frequency of 15%. Various researchers [4], [7], [8], [30] have highlighted the issue of lack of knowledge. It may be technical knowledge or any skill that may contribute to the OSS projects. Table 10 presents the recommendations for addressing the challenge of lack of knowledge in OSS.

V. IMPLICATION OF THE FINDINGS
Open Source Software (OSS) is a software where the source code of the software is willingly available, usually accessible with no charges or cost, and often developed by voluntary efforts. Besides the many benefits it has many risks associated with it. In this study first we have identified a total of 14 risk factors using SLR by studying a total of (N = 159) final chosen research papers. Then we used a questionnaire survey to validate these risk factors through OSS experts belonging to different countries. The findings of our SLR and questionnaire survey were almost identical as described in the above results section. Thus, we came into the conclusion that if the OSS practitioners take guidance from our findings, they will come into knowledge that the above mentioned are some of the risks that are associated with OSS.
After the identification of risk factors, we also identified 31 practices to mitigate the critical risk factors, using SLR and questionnaire survey in OSS. These practices were also validated through questionnaire survey from OSS experts. The critical risk factors were the factors whose frequency percentage was greater or equal to 15. Our study describes that if the OSS practitioners take advantage of the identified practices for each of the critical risk factor, the risk factors can be mitigate.

VI. LIMITATIONS OF THE STUDY
In this study, a sum of 14 risk factors and 31 practices are identified in order to mitigate the risk factors, using SLR and questionnaire survey in OSS. We identified these risk  factors and practices by studying a total of (N = 159) final chosen research papers. Nevertheless, certain shortcomings to the research methods adopted exists in this study which is essential to be acknowledged.
One probable threat to validity is that we have a conclusive list of articles achieved during the systematic literature review, where the study method was interviews, case studies, experience reports, and survey. Considering the study strategy, the papers were not in right ratio. With the rising amount of articles available on this subject, some latest publications with precise study strategy would have been unused while combining the results of the SLR. We might have also obtained different paper count if we could conduct the search on various databases. Another threat to validity is it is likely that the inclusion criteria may have unintentionally omitted some related and important resources. Along this, non-English language and abstract only papers were disqualified from inclusion in the SLR.

VII. CONCLUSION AND FUTURE WORK
Open Source Software (OSS) is a software where the source code is freely available. OSS is considered to be a future model for the delivery of IT solutions, according to current and future world computing demand. Organizations like Microsoft are moving to open source community. But there are certain limitations/risks associated with it which are making the practitioners reluctant to adopt OSS.
In our research work, we identified 14 risk factors, through SLR for adapting Open Source Software development from developers perspectives. Through our final outcomes, it is developers may take care of all the risk factors that have been identified in our study for increased software productivity and distribution of reliable and more advanced source code.
Based on our findings, the following goals have been planned, to be carried out in near future.
• To identify unidentified risk factors in the adopting Open Source Software from developers' perspective.
• To discover unidentified practices for implementation of the identified risk factors.
• To develop open sources software vendo's readiness maturity model (OSSVRM) to assist and measure the maturity of vendor organization in implementing open source development strategy for software development.
• To carry out several case studies at software vendor organizations to assess the effectiveness of the model.