Open source projects use large developer communities to maintain and heighten software security. Linus’ Law states that with a large enough beta-tester and co-developer base, most problems can be categorised fast. This highlights the importance of diversity in developers’ point of view when finding and fixing issues. (Meneely, Williams, 2009)
Open source collaboration needs a variety of these perspectives. More developers mean more problems solved or prevented. However, there’s always a balance; too many contributors can lead to unfocused contributions, similar to the phrase of having too many cooks in the kitchen. (Meneely, Williams, 2009)
An example of collaboration in open source is the development of the Linux kernel. Despite how complex and known it is, the Linux kernel benefits from this large and diverse developer community, allowing issues to be quickly fixed.
The linux kernel open source software is one of the most successful projects to date globally.
From 1994 to 2009 there was over 800 different versions the project evolved to meet the needs to its users, by covering new developments and releases. (Feitelson, Israeli, 2009)
Large open source project, such as linux kernel have since expanded majorly over the years. In 1991 version 0.01 had 10,329 lines of code contributions in comparison to version 4.19 having over 25.58 million lines of code contributions by 1710 contributors, lead through 230 companies.
It has been admitted that keeping up with these contributions are getting harder. The maintainer, often referred to as “gatekeepers”, who check up on the project, are put under more pressure with number of contributions and patches rising.
(Tan,Zhou, Fitzgerald, 2020)
Open source projects should grow overtime in size and complexity, and if successful, will attract and maintain more contributors which adds value to the community.
If we look at another example: the Android ecosystem, whose kernels are derived from linux, and utilised from companies such as Qualcomm.
This open source project is globally known and like Linux Kernel, very popular.
This also causes delays in patches and contributors as maintainers are receiving more contributions as time goes on. This can cause stress on androids security. These delays happen to affect the ecosystem that has evolved from both android and linux kernel, which can affect companies such as Qualcomm, google and other parties.
(Zhang, Zhang, Qian, Lau, n.d.)
These two examples are two of the largest open source projects for contributors, both of which need to enhance their management of decentralised collaboration, as there are delays after contributions due to the number being produced.
However the amount of contributions create a variety of improvements an perspectives globally to meet different needs, More feature can be implemented and problems solved through a digital diverse ecosystem. Collaboration to this extent had a dual-edged nature: celebrating global feedback requiring heavy maintenance and structure.
When I first contributed to “first-contributions” , I quickly realised its a very popular open source project with many contributors constantly contributing, as stated in my first contribution blog it had just over 24,000 contributors, one month later and that number has risen to 25,716. This shows a serious amount checks and maintenance needed to be put in place to ensure stability in a diverse growing community. I also stated that there was not any direct personal communication between the community and I, but the documentation encouraged inclusivity for new contributors, reflecting the project’s commitment for raising awareness to open source.
In relation to my main contribution einsteinpy, the community is significantly smaller, as the project is more niche, this ensured more direct feedback from its maintainers at a faster pace. However, in order to create a more diverse community, more contributors will need to join the community, which can bring advancements in research and new perspectives to the project itself.
Personally, I believe that open-source collaboration is essential for software security as it allows for fast identification and solutions. Keeping focus and coordination among large numbers of contributors is crucial to maintain software quality. Smaller-scale projects will lack the diverse community and additional perspectives, however the maintenance an feedback towards the commuinty is generally better.
Both types of projects are essential in their own way as recognition towards different types of inclusivity among communities is important. For one thrives on a larger collection of perspectives, showcasing different needs or feedback on the project, while the other bring together users in a more intimate setting, fostering deeper engagement and collaboration.
If these look at these different layouts of open source projects from the users’ (specifically my) point of view, contributing to both has challenged me to adapt to open source and understand it in these two categorised environments, which ultimately has boosted my confidence for more impactful future improvements and contributions to other communities.
REFERENCES:
Meneely, A. and Williams, L. (2009). Secure open source collaboration. Computer and Communications Security. doi:https://doi.org/10.1145/1653662.1653717.
Feitelson, D.G. and Israeli, A. (2009). The Linux kernel as a case study in software evolution. [online] Science Direct. Available at: https://www.sciencedirect.com/science/article/pii/S0164121209002519.
Tan, X., Zhou, M. and Fitzgerald, B. (2020). Scaling open source communities. doi:https://doi.org/10.1145/3377811.3380920.
Zhang, Z., Zhang, H., Qian, Z. and Lau, B. (n.d.). An Investigation of the Android Kernel Patch Ecosystem. [online] Available at: https://www.usenix.org/system/files/sec21summer_zhang.pdf.