There is software out there that can be classified either as Free / Open Source or as Closed Source. Lately a new term, Inner Source Software, has been introduced but we will get to that later. The important thing is that the aforementioned classifications of software forms the Source Code Spectrum.
The decisive factor of where a software project will end up in the Source Code Spectrum, is usually its level of openness. This is usually connected with the type of license the project is published under (for example, if a project is published under the MIT license it is considered a permissive open source software project but if it is a proprietary software, copyrighted by a company, it is considered a closed source software project).
The license of a project can, indeed, play a part in the longevity of a software project and that is why license type has been part of the resilience-based framework we proposed in [1] for assessing the evolution of open source projects. However, in this post of Software Antifragility, we will approach the Source Code Spectrum from another point of view. The way it is being developed!
Closed Source Software Development
In the beginning, there was closed source software:
Closed source (or proprietary software) are computer programs whose source code is not published. The source code is not shared with the public for anyone to look at or change. Closed source is the opposite of open source.
~ Wikipedia
Before remote work, before version control, before CI/CD, developers were using collective backups for writing software. A version of this was the anecdotal “shout & ftp” technique in web development: You would shout “is anyone working on the foo page?” If no one piped up, you’d ftp into the server and download it. Make your changes and then load the file back, hoping your coworkers remembered to shout before they made any changes themselves that would stomp on yours [2].
Software was being developed from teams, it was orchestrated in a central release of an executable or server app and it was served to the users. For the desktop applications, the executable files were usually offered via user licenses that prevented them for being copied or shared with others for free.
Unless of course, the application is WinRAR. Because WinRAR offers a 40-day trial that ends… well… never!
From autumn 1993, when it was first released, until now, this software can be used for free even after the 40 days trial has expired 👇
Post version control systems (CVS, SVN, Perforce Helix Core in the past and Mercurial and Git more recently), the teams started working on their code collectively using a centralized version control system that allowed them to keep track of the changes, deal with conflicts and orchestrate their releases better.
What’s interesting is that, even after the adoption of version control systems, some closed source companies kept implementing their software in silos.
In such cases, although the closed source code of the software product was owned by the same company, some engineers might never access specific parts of it, even if they were working with the same company for years. This phenomenon, appearing mainly in bigger companies, is still happening nowadays, usually in large companies that are developing several different software products. In such cases the developers of one project do not have access to the code base of another.
In this sense, the Wikipedia definition of Closed Source could change to:
Closed source (or proprietary software) are computer programs whose source code is not published. The source code is not shared with anybody but the programmers who are responsible for crafting the software.
Open Source Software Development
Then Open Source Software happened! Before we dive in, let’s talk definitions: We have Free Software, Open Source Software and Free / Libre Open Source Software. If you currently look at Wikipedia you will find the following definitions:
Free software, libre software, libreware sometimes known as freedom-respecting software is computer software distributed under terms that allow users to run the software for any purpose as well as to study, change, and distribute it and any adapted versions.
Wikipedia
Free Software as a term is attributed to Richard Stallman who crafted the first formal definition who was then published by Free Software Foundation in February 1986. [3]
Open-source software (OSS) is computer software that is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose.
Wikipedia
In 1997, Eric Raymond’s essay The Cathedral and the Bazaar explored the development model of Free Software, influencing Netscape’s decision in 1998 to release the source code for its browser suite. This code base became Mozilla Firefox and Thunderbird.
To broaden business adoption, a group of developers including Raymond, Bruce Perens, Tim O’Reilly, and Linus Torvalds rebranded the Free Software movement as “Open Source.” The Open Source Initiative (OSI) was founded in 1998 to promote this new term and emphasize collaborative development benefits over ideology. [4]
More or less, Raymond in the Cathedral and the Bazaar essay, described the Open Source Software Development culture as shown (in a simplified version) in this video:
In Open Source Software Development, a community of people are working together to create software. Since they are volunteers they can come and go as they please but this creates the need for the source code, the requirements, the specifications, the roadmap, designs, schematics, bug reports / tickets and so forth to be openly available and transparent to everyone.
Open Source Software Development looks like closed source software development, completely inversed, right?
It is worth mentioning that some of the most used software in the planet is built as open source software. And although Open Source Software is being developed as a collaborative approach based (mainly) in voluntary work, the '“valuation” of some open source software projects is also impressive:
Inner Source Software Development
We have seen what Closed Source Software is and how Open Source Software revolutionized how software development was happening. What about Inner Source? What kind of witchcraft is that and how is it positioned in the Source Code Spectrum?
Inner Source is the use of open source software development best practices and the establishment of an open source-like culture within organizations for the development of its non-open-source and/or proprietary software.
Wikipedia [5]
The term was coined by Tim O’Reilly circa 2000. It is a growing trend in the engineering world. Teams adopting Inner Source aim to work and collaborate more effectively. Although they develop proprietary software, they open up the work internally between teams so that everyone — from developers to product managers — can contribute to the source code.
Here’s a video from Github, explaining the concept of Inner Source 👇
Inner Source is adopted today by a variety of corporations in terms of business sector and size. Some of them are: Hewlett Packard, Red Hat, Philips, IBM, Robert Bosch, Google, Microsoft, SAP, PayPal but also non-technological companies and organizations like Walmart, BBC, Deloitte, Disney, Etsy, Mercedes-Benz, NASA, Harvard Business Review among others.
Characteristics of development in open, close and inner source environments
Closed Source Software Development keeps the source code private and accessible only to authorized developers within an organization. Ownership rests with a single entity, and collaboration is usually limited to internal teams following a hierarchical structure. Transparency is low since decisions, issues, and design choices are not publicly visible. Governance is centralized, and innovation tends to move at a moderate pace due to reliance on internal R&D. A classic example is Microsoft Office.
Inner Source Software Development applies open-source principles within an organization. Code is accessible to all employees, encouraging cross-team collaboration while maintaining company ownership and intellectual property rights. Transparency is high internally, as documentation, reviews, and discussions are shared across teams. Governance follows a hybrid approach; open contribution with internal oversight. This model accelerates innovation and knowledge sharing within large organizations. PayPal’s Inner Source program is a notable example.
Open Source Software Development makes the source code publicly available for anyone to view, modify, or distribute under open licenses like MIT or GPL. Ownership is shared and governed by community norms and licensing agreements. Collaboration is global and community-driven, with contributions from individuals and organizations worldwide. Transparency is very high, as development processes are open to all. Governance is distributed, and innovation occurs rapidly through diverse, continuous contributions. The Linux Kernel is a prime example.
Reference:
[1] Kritikos, Apostolos & Stamelos, Ioannis. (2023). A resilience‐based framework for assessing the evolution of open source software projects. Journal of Software: Evolution and Process. 36. 10.1002/smr.2597.
[2] Quora. Before version control like Git was invented, how did people manage code in a project? Quora website. https://www.quora.com/Before-version-control-like-Git-was-invented-how-did-people-manage-code-in-a-project. Accessed October 15, 2025.
[3] Wikipedia. Free software. Wikipedia website. https://en.wikipedia.org/wiki/Free_software. Accessed October 15, 2025.
[4] Wikipedia. Free and open-source software. Wikipedia website. https://en.wikipedia.org/wiki/Free_and_open-source_software. Accessed October 15, 2025.
[5] Wikipedia. Inner source. Wikipedia website. https://en.wikipedia.org/wiki/Inner_source. Accessed October 15, 2025.
