To imagine a world without free and open-source software (henceforth “FOSS”) would be quite a difficult picture to paint: a snippet of it would be to live without Firefox, WordPress, Linux, VLC – all built on FOSS. Yet despite being so integrally woven in our digital lives, how often does FOSS cross our minds (to admit, I hadn’t thought of it much before), but the truth of the matter is that open-source software more generally, and FOSS more specifically is everywhere, and still often invisible in our daily runs.
The three-part blog post will take a dive into the world of FOSS. In the first part, I will explore what exactly is FOSS and attempt to shed light on how it does (or does not) affect innovation. As software development intersects with intellectual property, the second part will subsequently zone into patentability of software and the related hurdles that impede innovation in India and its implications for FOSS. The third part will turn to the question – how does FOSS affect technological sovereignty.
What is FOSS?
To understand FOSS better, one might need to familiarize oneself with certain computing jargon. Source code is the language used by programmers to communicate to computers and bring about a certain result. The catch is that a computer does not quite understand the source code, rather it has to be converted into an object code. As Prof. Unni explains, in a closed model, software is distributed such that the user is provided only with an object code, using which they can merely run the program. To the contrary, the open source model distributes software along with its source code under licenses that allow the user to use, examine, alter, and redistribute the source code.
Until the mid-1970s, source code was commonly distributed freely along with hardware, however, gradually, software began to be sold separately with restrictive licenses. With the growth in demand for customized software, organizations faced greater uncertainty regarding development timelines and costs. This made the bundled sale economically unattractive (see here), leading to the emergence of a “software-industry” wherein software’s tradability as a standalone product enabled its commercialisation (this shift ignited debates at that time, see this discussion in a 1988 ed. of Computer World). Consequently, the commodification of software ushered in a shift towards the closed model.
In response to the increasing restrictions, Richard Stallman launched the GNU Project and the associated GPL license to develop free software – a replacement for the UNIX operating system. This led to the inception of the Free Software Movement (“FSM”) where free is to be understood as “free as in free speech, not free beer” – free in the sense of libre (liberty, freedom), not gratis (price). He led the “ideological movement” to make source code freely available and accessible, providing four essential freedoms, but on the pre-condition that access to the derivatives will not be restricted. In 1998, a group of developers, including Eric Raymond, coined the term “open source” which eventually gained widespread adoption. While the two stand for accessibility of software, it is the underpinned values which differentiate free software from open (Stallman made a point to distinguish FSM from the open source movement).
At this juncture, one must not conflate free software, open-source software, and public software. The first two, though overlapping in scope, are distinguishable on the basis of their underlying philosophies. FS places emphasis on its commitment to user freedom, whereas the open source movement focuses on the practical and developmental aspects of software. Both are distributed under specific licenses that the user must comply with while on the flip side, the public domain software imposes no such obligations (here). Nowadays, the FS and OSS are used interchangeably and this piece adopts the umbrella term Free Open Source Software (“FOSS”) to encompass both the movements.
How does Openness drive Innovation in FOSS?
FOSS grows through a continuous creation of modular building blocks, i.e., software components that anyone worldwide can use or improve. It can be understood as a bedrock created over which developers and hobbyists around the globe constantly build and contribute to at all hours of the day.
The four essential freedoms of FOSS, central to the entire ecosystem, allow users to alter the software as they wish and distribute such modified versions. This freedom provides one with a free hand to customize as one deems fit, distinguishing it from a proprietary model, where vendor lock-in keeps users dependent on the vendor for products or updates.
One might never get to know about vulnerabilities or even potential backdoors covertly built into closed software, as it is hidden from public eyes. However, one need not have that anxiety while working with FOSS since the user can inspect and verify the code themselves.
Peer-review, an integral component of FOSS, fastens bug detection and its fixing. It is all due to the fact that a number of people can scrutinise the same source code and when an issue surfaces, it gets resolved swiftly, which is not the case with closed-source systems where bugs, if reported, can take weeks or months to get fixed (if at all). This is popularly referred to as “Linus’s Law”, “[g]iven enough eyeballs, all bugs are shallow.” The caveat being that since FOSS is built on voluntary participation, the possibility of more eyes on the source code does not instantly translate into high level participation.
With the entry of FOSS in the market, it has contributed to both intra-FOSS and extra-FOSS competition, giving a pro-innovative effect. FOSS, first of all, dramatically cuts R&D costs as the ventures can tap into existing commons and “pull” building blocks at virtually no cost, eventually reducing the total cost of ownership. Accessibility of the source code leads to the emergence of knowledge spill overs in the community. This happens in two ways – programmers gain either through working on a FOSS project or reusing software code from an existing FOSS project (see here). Since the code is publicly accessible, external investors get to see what they are investing into and this transparency builds trust and reliability. For start-ups specifically, in addition to the zero-costs effect, FOSS offers this much-needed support.
As for FOSS developers, they typically work on a voluntary basis, however, their payoff is attribution – the attachment of the author’s name to their programming work. This enables them to signal their skills and enhance their reputation in the market, which in turn heightens their motivations to deliver better, knowing that their contribution is visible to others (see here, pg 13).
When Openness Splinters – or Does it?
FOSS has its own set of limitations. The constant threat of forking and branching of FOSS projects could result in an anti-innovative effect. Forking and branching are used to describe the splitting of FOSS projects into rival developments (an oft-quoted example is of LibreOffice, which splintered from OpenOffice.org). While the “forking effect” is said to instill democratic principles in developing an open-source based project, it increases the risk of community fractures, which decelerates the pace of innovation.
In addition, since FOSS allows anyone to construct anything, it results in the possibility of the same programmes co-existing in the ecosystem, making it a redundant development. In FOSS communities, one of the scarcest resources is developers’ attention towards maintaining code and fixing bugs. Duplication of programmes fragments the already limited attention, which, from an economic perspective, is wasteful. Moreover, having outdated or poorly maintained open source codes contribute to technical debt, which would impose future maintenance costs.
To put into a broader perspective, proprietary software, whose codes remain hidden from public sight, is developed in silos, thereby making duplicity likely and at times, unavoidable, since similar functionalities are unknowingly replicated.
Extensive code reuse can paradoxically also impede innovation. When the foundational pieces change or are not maintained, it causes ripple effects. As explained by Spinellis and Szyperski, copied code diverges from the original, and while the source continues to evolve, the copy would not automatically get those updates. Re-using codes, moreover, creates unintended dependencies as developers might not be aware of the underlying components on which that specific module is built. Lastly, the lack of centralized administration results in two-fold compatibility issues: one, some hardware drivers might not exist for FOSS programs (see here and here), and two, new software might never receive support, and this incompatibility can limit FOSS usage.
I would like to thank Swaraj, Praharsh, Bharathwaj, and Ambika for their comments on the draft.
