| Both sides previous revision Previous revision | |
| p5js-supplement-01 [2024/02/20 23:34] – renick | p5js-supplement-01 [2026/03/26 01:20] (current) – renick |
|---|
| ====== p5js supplement 01: sharing code, open source software ====== | ====== p5js supplement 01: sharing code, open source software ====== |
| |
| ===== why you should use open source software ===== | ====== Understanding Open Source Software: How Collaborative Code Shapes Technology ====== |
| |
| ===== why you should make open source software ===== | Open source software (OSS) is code whose source is publicly available for anyone to inspect, modify, and share. Think of it as a recipe posted online: anyone can cook the dish, tweak the ingredients, or pass it along. This collaborative model now underpins much of the world's digital infrastructure, from the Linux operating system to the frameworks behind popular mobile apps [1]. |
| |
| ===== how to make open source software ===== | ===== Philosophical Foundations: Freedom vs. Pragmatism ===== |
| | |
| | Two distinct philosophies drive collaborative software development. The first, championed by Richard Stallman and the Free Software Foundation (FSF), treats software freedom as a moral issue. Stallman announced the GNU Project in 1983, and founded the FSF in 1985, arguing that users deserve four essential rights (numbered 0 through 3): the freedom to run a program for any purpose, to study and change its code, to redistribute copies, and to distribute modified versions [2]. For the FSF, proprietary software is not merely inconvenient; it is a social injustice [3]. |
| | |
| | The second philosophy emerged in 1998 when Eric Raymond, Bruce Perens, and others founded the Open Source Initiative (OSI). Rather than emphasizing ethics, the OSI presented open source as a superior way to build software because of its collaborative, peer-reviewed nature [4]. Where the FSF asks, "Is the user free?" the OSI asks, "Is the software better?" Despite this tension, both camps view proprietary software as a common opponent [3]. |
| | |
| | ===== The Cathedral and the Bazaar ===== |
| | |
| | In an influential 1997 essay, Eric Raymond described two models of software development [5]. The "Cathedral" model resembles traditional corporate engineering: a small team designs software behind closed doors, releasing polished versions at planned intervals. This approach offers predictability but can limit creativity and slow the discovery of bugs. |
| | |
| | The "Bazaar" model invites the whole world to participate. The Linux kernel was built this way: developers release early, release often, and treat every user as a potential co-developer [5]. Raymond captured the core insight in what he called Linus's Law: "Given enough eyeballs, all bugs are shallow" [5]. This approach also sidesteps Brooks's Law, the observation that adding manpower to a late software project makes it later [6]. The Bazaar avoids that trap by distributing bug-finding across a vast, loosely coordinated community. Today, most successful projects blend elements of both models [7]. |
| | |
| | ===== The Open Source Definition ===== |
| | |
| | The term "open source" carries formal weight. The OSI maintains ten criteria that a software license must satisfy [8]. These ensure that software can be freely redistributed, that source code is available in modifiable form, that derivative works are permitted, and that no person, group, or field is discriminated against [9]. The definition also requires that licenses be technology-neutral and not restrict other software distributed alongside the licensed program [9]. Together, these rules prevent any party from enclosing shared resources. |
| | |
| | ===== Licensing: Permissive vs. Copyleft ===== |
| | |
| | A license is the legal mechanism that translates philosophy into enforceable terms. Open source licenses generally fall into two families. Permissive licenses, such as MIT, BSD, and Apache 2.0, impose minimal restrictions. They allow anyone to use, modify, and redistribute the code, even within proprietary products, asking only for attribution [10]. Apache 2.0 adds an explicit patent grant, making it attractive for corporate use [10]. |
| | |
| | Copyleft licenses, most notably the GNU General Public License (GPL), include a "share-alike" requirement: if you modify and distribute copyleft code, you must release your modifications under the same terms [10]. This ensures that improvements flow back to the community. Teams seeking maximum adoption tend to favor permissive licenses; those committed to keeping all derivative work open tend to choose copyleft [11]. |
| | |
| | ===== Governance Models ===== |
| | |
| | Because open source contributors can leave at any time, governance matters [12]. In the Benevolent Dictator for Life (BDFL) model, the original creator retains final authority, as Linus Torvalds does with the Linux kernel [12]. Meritocratic projects, such as those under the Apache Foundation, grant authority to contributors who have earned trust through sustained, quality work [12]. Foundation-backed projects place a nonprofit board in charge of trademarks and resources, separating commercial interests from technical direction [12]. Some projects use a "do-ocracy," where authority follows effort: whoever does the most work holds the most influence [13]. Clear governance fosters trust and attracts contributors. |
| | |
| | ===== Contribution Workflow ===== |
| | |
| | Contributing to an open source project typically follows a "fork and pull request" process [14]. A developer copies (forks) the repository, makes changes on a dedicated branch, and submits a pull request proposing that maintainers merge those changes. Maintainers review the code, suggest revisions, and accept or decline the contribution [14]. Good documentation, particularly a README and a CONTRIBUTING guide, is essential to welcoming newcomers. |
| | |
| | ===== Security Considerations ===== |
| | |
| | Open source transparency allows anyone to audit code for vulnerabilities, and many organizations value this visibility [15]. Critics note that openness also lets attackers study code for weaknesses, but closed-source software is not inherently safer; its vulnerabilities simply remain hidden. Security professionals widely regard this reliance on secrecy, known as "security through obscurity," as dangerous because flaws exist whether or not outsiders can see the code [21]. With proprietary software, the true extent of vulnerability is unknown and unverifiable. A 2022 Sonatype report documented a 633% increase in cyberattacks targeting open source repositories [16], and the Log4j incident of 2021 showed how one flaw in a widely used library can ripple across thousands of applications [16]. To manage these risks, organizations increasingly adopt Software Bills of Materials (SBOMs) to track every open source component [18]. |
| | |
| | ===== Open Source AI ===== |
| | |
| | The OSI has extended open source principles to artificial intelligence through its Open Source AI Definition, released in 2024 [19]. For an AI system to qualify, it must provide detailed information about its training data, the code used for training and data processing, and the model parameters (the learned weights that produce outputs) [19]. This transparency aims to enable the same collaborative scrutiny that has strengthened traditional software, though it introduces new challenges around privacy and adversarial attacks on models [20]. |
| | |
| | ===== References ===== |
| | |
| | - Free Software Foundation 2024, //What is free software?//, GNU Project, accessed 24 March 2026, <[[https://www.gnu.org/philosophy/free-sw.html]]>. |
| | - Wikipedia contributors 2026, 'Free and open-source software', //Wikipedia, The Free Encyclopedia//, accessed 24 March 2026, <[[https://en.wikipedia.org/wiki/Free_and_open-source_software]]>. |
| | - Stallman, R 2024, 'Why open source misses the point of free software', //GNU Project//, Free Software Foundation, accessed 24 March 2026, <[[https://www.gnu.org/philosophy/open-source-misses-the-point.html]]>. |
| | - Open Source Initiative 2024, 'History of the OSI', Open Source Initiative, accessed 25 March 2026, <[[https://opensource.org/about/history-of-the-open-source-initiative]]>. |
| | - Islamgomes, A 2025, 'Reading 07: "The Cathedral and the Bazaar"', //Hackers in the Bazaar Blog//, University of Notre Dame, accessed 24 March 2026, <[[https://sites.nd.edu/arvin-islamgomes/2025/11/03/reading-07-the-cathedral-and-the-bazaar/]]>. |
| | - Brooks, FP 1995, //The mythical man-month: essays on software engineering//, anniversary edn, Addison-Wesley, Reading, MA. |
| | - Fitzgerald, B 2020, 'How the cathedral embraced the bazaar, and the bazaar became a cathedral', in S Nyman (ed.), //Towards Engineering Free/Libre Open Source Software (FLOSS) Ecosystems for Impact and Sustainability//, Springer, pp. 127-144, accessed 24 March 2026, <[[https://pmc.ncbi.nlm.nih.gov/articles/PMC7198250/]]>. |
| | - Open Source Initiative 2024, //Frequently answered questions//, Open Source Initiative, accessed 24 March 2026, <[[https://opensource.org/faq]]>. |
| | - Open Source Initiative 2024, //The Open Source Definition (Annotated)//, Open Source Initiative, accessed 24 March 2026, <[[https://opensource.org/definition-annotated]]>. |
| | - Rahman, MM 2024, 'The ultimate guide to choosing the right license for your software project: from MIT to GPL explained', //DEV Community//, accessed 24 March 2026, <[[https://dev.to/m-a-h-b-u-b/the-ultimate-guide-to-choosing-the-right-license-for-your-software-project-from-mit-to-gpl-h9e]]>. |
| | - Exygy 2024, 'Which license should I use? MIT vs. Apache vs. GPL', //Exygy Blog//, accessed 24 March 2026, <[[https://exygy.com/blog/which-license-should-i-use-mit-vs-apache-vs-gpl]]>. |
| | - Learn WordPress 2024, //Governance and decision-making in open source//, WordPress.org, accessed 24 March 2026, <[[https://learn.wordpress.org/lesson/governance-models-in-open-source-project/]]>. |
| | - GitHub 2024, //Leadership and governance//, Open Source Guides, accessed 24 March 2026, <[[https://opensource.guide/leadership-and-governance/]]>. |
| | - GitHub 2024, //Contributing to a project//, GitHub Docs, accessed 24 March 2026, <[[https://docs.github.com/en/get-started/exploring-projects-on-github/contributing-to-a-project]]>. |
| | - Bitwarden 2024, 'Why open source delivers transparency and security for enterprises', //Bitwarden Blog//, accessed 24 March 2026, <[[https://bitwarden.com/blog/why-open-source-delivers-transparency-and-security-for-enterprises/]]>. |
| | - SentinelOne 2023, //Open-source software security risks: how to secure them?//, SentinelOne Blog, accessed 24 March 2026, <[[https://www.sentinelone.com/blog/software-management-a-guide-for-every-business-using-open-source-in-2023/]]>. |
| | - Meneely, A & Williams, L 2009, 'Secure open source collaboration: an empirical study of Linus' law', //Proceedings of the 16th ACM Conference on Computer and Communications Security//, ACM, pp. 453-462. |
| | - Radical Compliance 2025, 'Study: open-source software risks are rampant', //Radical Compliance//, accessed 24 March 2026, <[[https://www.radicalcompliance.com/2025/02/25/study-open-source-software-risks-are-rampant/]]>. |
| | - Open Source Initiative 2024, //The Open Source AI Definition - 1.0//, Open Source Initiative, accessed 24 March 2026, <[[https://opensource.org/ai/open-source-ai-definition]]>. |
| | - Nguyen, DC, Ding, M, Pathirana, PN, Seneviratne, A, Li, J & Poor, HV 2023, 'Open-source artificial intelligence privacy and security: a review', //Computers//, vol. 13, no. 12, article 311, accessed 24 March 2026, <[[https://www.mdpi.com/2073-431X/13/12/311]]>. |
| | - Cobalt 2024, 'Risks of open source software', //Cobalt Blog//, accessed 25 March 2026, <[[https://www.cobalt.io/blog/risks-of-open-source-software]]>. |
| |