Choosing Open-Source WiselyWhat developers should look for in open-source software
There's an important reason why open-source software (OSS) represents an advantage for rapid development: Developers can use code that's already been perfected by the open-source community without having to write their software from scratch. Further, OSS implementation with the cloud's offering of Software-as-a-Service has been identified as an important reason for OSS success. However, the use of OSS is an opportunity for projects to inherit vulnerabilities already present in OSS code. Therefore, developers need to mitigate the risks as much as possible. That's why they need to evaluate and choose their open-source carefully.
The question of what indicators can be used to assess OSS has been addressed scientifically. Researchers Yuhang Zhao and colleagues reviewed 56 papers published between 1999 and 2020 that aimed to identify the indicators of OSS success. The authors define success as OSS meeting users' functional needs without causing problems such as security issues, license misusing issues and program crashes. In this post, we would like to share the five indicator categories the authors found across the reviewed studies. We argue that these are basic aspects by which development teams can guide their choice of OSS.
Developers can base their choice of OSS partially on code qualities. Three key aspects can be identified:
To understand what a vulnerability is, we offer a combination of two separate definitions provided by the National Initiative for Cybersecurity Careers and Studies (NICCS):
A characteristic of location or security posture or of design, security procedures, internal controls, or the implementation of any of these that renders an organization or asset (such as information or an information system) open to exploitation by a given threat or susceptible to a given hazard.
Some very important things are at stake when addressing code vulnerabilities, including the system or its application data's access control, availability, confidentiality, integrity and monitoring mechanisms. There's always a possibility of finding vulnerabilities in any given software. Then, OSS choice becomes a matter of how likely a patch is to be released quickly. The current concern surrounding vulnerabilities in Log4j highlights the importance of addressing these issues promptly with upgrades.
The risk of supply chain attacks is quite serious. We have mentioned while discussing the OWASP Top 10 that developers need to verify the integrity in the entire software build chain. This implies that they need their suppliers to think about security too. Also, they need to ensure their software components come from trusted sources and are digitally signed.
It's important to ensure that the code is understandable and can be modified for other uses. The authors say these factors are related to how long it takes to actually fix any vulnerabilities present.
Open-source licenses allow developers to use, modify and share software freely. Notably, licenses may differ in their requirements for redistribution rights. This means some licenses require developers to make their source code freely available, while others don't ask for this. Fulfilling license obligations is especially tricky when software includes other software with incompatible licenses. Because of this, developers need to check license compatibility across software components.
The authors identify developers' liking, admiration and support as indicators of OSS success. Metrics commonly used to quantify user interest for a project are the number of downloads over its lifespan, hit number and number of subscribers. Further, one study surveyed 400 Stack Overflow users and found that they perceive a GitHub project's stars to be the most useful metric to assess its popularity. Later in the same study, a survey of 791 GitHub users from all over the world revealed that they star a project to show appreciation (e.g., because they liked the solution), bookmark for later retrieval or because they used or are currently using the project.
The review suggests that popularity has some ties to other indicators, such as license and sponsorship. So, more restrictive licenses are less popular and sponsored projects are more popular. Other aspects linked to popularity are project status and density. So, projects where users participate actively in discussions and bug reports are preferable. Also, it's been suggested that the users infer that more connected projects are of higher quality. By connected, it's meant that the target project has many contributors who also help in other projects.
OSS success is linked to the number of developers working on the project and role diversity. It's helpful to understand what attracts people to become contributors. For instance, one study observed 72 weeks of growth of newcomers in 450 OSS projects on GitHub. The properties that attracted more contributors were project popularity (number of stars) and time to merge. This shows they're interested in good practices like giving timely review, feedback, and closing pull requests.
Regarding contributor engagement, another study surveyed 233 participants and found that their belief that they produce the intended effects and have control over the desired outcomes correlates with their perceived performance in terms of quality and quantity of contribution. Lastly, the review found that social values such as altruism, reputation and ideology are important motivators for developers' engagement.
A final indicator refers to financial support. In the context of OSS, the common sponsors are enterprises and universities, which may enhance a project's publicity and innovation capacity. According to the review, "sponsorship improves the ability of OSS to deal with risks and the possibility of maintaining long-term support from developers." However, there could be cases in which corporate sponsors may place restrictions on the OSS community that could negatively impact innovation capacity.
Time to choose!
We just talked about the five broad indicators that developers should keep in mind when deciding for OSS. In short, these are some questions teams should know the answers to:
What are the characteristics of this OSS code?
What license obligations apply to their particular use of this OSS?
How many users like the solution implemented by this OSS and/or are using it?
How many people work on the OSS project and how readily do they respond to issues found?
Is the OSS project sponsored? If so, how does sponsorship affect innovation capability?
we aim to find all the vulnerabilities in your team's software.
Hesitate no more and contact us!