Open Source

Buy a packet of biscuits and you get the biscuits — you can eat them, share them, even try to guess the recipe by tasting. What you do not get is the actual recipe card: the exact list of ingredients, the exact quantities, the exact baking time. The company that makes the biscuits keeps that locked away, because the recipe is what makes their biscuits taste different from every other brand's. Now imagine a different situation: your grandmother writes out her recipe for aloo paratha on a card and hands you a photocopy. You can read every step, change the amount of chilli, add your own twist, and hand your improved version to a cousin — who can improve it further and pass it on again. Software works exactly like this. Some software comes to you only as the "biscuit" — a finished, working program you can run, but with its inner recipe locked away. Other software comes to you as the "recipe card" — the actual instructions the programmer typed, which you are allowed to read, change, and pass on. That second kind is called open source software, and this chapter is about what that really means, how it is built, and why it quietly runs a huge share of the technology around you — including, almost certainly, the phone in your pocket.

From Code You Type to a Program That Runs

To understand what "open" and "closed" mean here, you first need to understand what actually gets shipped when someone gives you a piece of software. When a programmer writes a program, they type it in a language designed for humans to read — Python, C, Java, JavaScript, and so on. This is called source code. Here is a tiny, complete example in Python:

print("Namaste, World!")

That single line is source code. When you run it, the Python interpreter reads it and immediately prints Namaste, World! to the screen. Python is unusual in that it is interpreted line by line, so the source code and the "running" code are almost the same thing. Many other languages work differently. Consider this equivalent program written in C:

#include <stdio.h>

int main() {
    printf("Namaste, World!\n");
    return 0;
}

You cannot hand a computer's processor this text file and expect it to run. First it must pass through a program called a compiler (for C, commonly gcc), which translates the human-readable source code into machine code — a long sequence of binary instructions specific to the processor, completely unreadable to a person. The compiler produces an executable file (on Windows, something like myprogram.exe). Running that command prints exactly the same line, Namaste, World!, but by this point every trace of the readable structure — the variable names, the comments, the logic laid out step by step — has been thrown away in the translation.

This distinction is the whole story of open source. When a company sells you "closed source" (also called proprietary) software, what actually reaches your computer is the compiled executable — the machine code, the equivalent of the finished biscuit. You can install it, click its buttons, and use its features, but you cannot open it up and read how it decides what to do, and you are legally forbidden from trying to reverse it back into readable form and redistributing your own modified copy. When a project is open source, the actual source code — the .py file, the .c file, every line the original programmers typed — is published for anyone to download, read, compile themselves, change, and share onward.

What "Open Source" Actually Means

"The code is visible" is necessary but not sufficient for something to count as open source. A company could publish its source code on a website purely so you can inspect it, while still legally forbidding you from copying, changing, or redistributing it — plenty of companies have done exactly this, and it is usually called "source-available," not open source. What makes software genuinely open source is that it is released together with a license — a legal document — that explicitly grants you at least these rights:

• The right to run the program for any purpose.
• The right to study how it works by reading the source code.
• The right to modify the source code to make it do what you want.
• The right to redistribute copies — original or modified — to other people.

Without that license, "I can see the code" and "I am legally allowed to change and reshare the code" are two completely different things, and only the second one is open source.

A Short History: From a Stubborn Programmer to a Billion Phones

The idea has a fairly specific origin. In 1983, a programmer at MIT named Richard Stallman grew frustrated that he could no longer get the source code to fix a printer driver he needed, because the company that made it had made the code secret. In response he started the GNU Project, an effort to build a complete, freely shareable operating system from scratch, and in 1985 he founded the Free Software Foundation to support it. Stallman's famous one-line explanation of the idea is that free software is "free as in freedom, not free as in beer" — the point was never that it had to cost nothing, but that users must be free to study, change, and share it.

By the early 1990s, the GNU Project had built almost every piece of a full operating system except the core piece that talks directly to the computer's hardware — the kernel. In 1991, a Finnish university student named Linus Torvalds, working independently, released the source code for exactly that missing piece: a kernel he called Linux. Combined with the GNU tools, this produced a complete, freely shareable operating system, generally called GNU/Linux or simply Linux. It is genuinely hard to overstate how far this project has travelled since 1991: today, essentially every machine on the TOP500 list — the ranking of the world's fastest supercomputers — runs on Linux, and the Linux kernel sits at the core of Android, which runs on the majority of smartphones sold in India.

The term "open source" itself is younger than the movement. In January 1998, Netscape — maker of the Netscape Navigator web browser, hugely popular at the time — announced it would release the browser's source code to the public, partly influenced by an essay called "The Cathedral and the Bazaar" by programmer Eric S. Raymond, which argued that opening code up to outside contributors tends to produce more reliable software than a small closed team working in secret. Later that year, a group including Raymond and Bruce Perens coined the term "open source" and founded the Open Source Initiative (OSI) to define it precisely and promote it — partly because they felt the word "free" confused business audiences who heard "free of cost" instead of "free to change." Netscape's released code eventually grew into the Mozilla project, and years later, the Firefox browser.

Licenses: The Rulebook Attached to the Code

Publishing source code publicly is only half the story — the license attached to it decides exactly what you are and are not allowed to do with it, and different projects deliberately choose very different rules. Broadly, open source licenses fall into two families.

Permissive licenses, such as the MIT License and the Apache License 2.0, are close to "do almost anything you like, just keep the original copyright notice." The MIT License is famously just a few sentences long. Apache 2.0 is a little longer because it also explicitly grants you rights to any patents the original authors hold on the code, which protects you from being sued later. Critically, permissive licenses allow someone to take open source code, modify it, and ship the modified version as part of a closed-source, paid product — without publishing their changes. A company is perfectly entitled to build a proprietary app on top of MIT-licensed code and never show anyone their additions.

Copyleft licenses, the best known being the GNU General Public License (GPL) — first published in 1989, with the widely used GPLv2 arriving in 1991 and GPLv3 in 2007 — work differently. The GPL says: you may use, modify, and redistribute this code freely, but if you distribute a modified version to anyone else, you must release your modified source code under this same license. This is sometimes nicknamed a "share-alike" rule, and it is a deliberate design, not an accident: Stallman wanted to make it legally impossible for someone to take community-built code, improve it, and then lock those improvements away from the community. The Linux kernel itself is released under GPL version 2, which is one reason Android's underlying kernel modifications must remain open even though Google adds plenty of other, separately licensed code on top.

The diagram below traces what happens to the same original project depending only on which family of license its author chose.

Notice that both companies in the diagram are equally "allowed" to use the code — a copyleft license does not stop commercial use. It only stops a company from taking the community's work private once they redistribute their version. Understanding which branch a project sits on tells you, instantly, what you are permitted to do if you ever build on top of someone else's open source code — an important thing to check before reusing any code you find online.

How an Open-Source Project Actually Gets Built

An open source project is not one company's private work made visible — it is usually a genuine collaboration between people who may never meet, coordinated through a version-control tool. The tool almost every major project uses today is Git, which — fittingly — was itself written by Linus Torvalds in 2005, specifically to manage contributions to the Linux kernel from thousands of unrelated programmers. Websites like GitHub (founded 2008) host Git repositories and add a social layer of comments, reviews, and discussion on top.

The typical workflow looks like this. Imagine the project is a shared class notebook that anyone in the world may propose edits to, but a designated class monitor — called a maintainer — decides which edits actually get written into the official copy.

1. A contributor makes their own personal copy of the entire project. On GitHub this copy is called a fork.
2. They make their changes inside that fork — fixing a bug, adding a feature, improving documentation — usually on a separate branch so their in-progress work does not disturb the main copy.
3. When they believe the change is ready, they open a pull request: a formal proposal asking the maintainers, "please review this and merge it into the official project."
4. Maintainers and other contributors read the proposed change line by line, leave comments, and often ask for revisions before accepting it.
5. If accepted, the change is merged into the official copy, and it becomes part of the project that everyone downloads from then on.

This is precisely why open source projects can grow to have thousands of contributors even though only a small core team has the authority to merge changes: anyone can propose, but the maintainers still gatekeep quality, exactly as the license permits them to.

Version Numbers: Reading a Project's History at a Glance

Because open source projects change constantly, often with contributions arriving daily from around the world, they need a disciplined way to label releases so users know how risky an update is. The convention almost universally used today is called semantic versioning, written as three numbers separated by dots: MAJOR.MINOR.PATCH.

• PATCH increases when a bug is fixed without changing how the software behaves for anyone relying on it correctly.
• MINOR increases when a new feature is added, but everything that worked before still works exactly the same way.
• MAJOR increases when something changes that could break programs depending on the old behaviour.

Here is what a real project's version history might look like as it evolves, purely from the numbers:

1.0.0   first stable release
1.0.1   fixed a crash on empty input        (bug fix -> PATCH)
1.0.2   fixed a spelling mistake in an error (bug fix -> PATCH)
1.1.0   added a new "export to PDF" option   (new feature -> MINOR)
2.0.0   renamed a core function everyone used (breaking change -> MAJOR)

A real, well-documented example of a MAJOR jump is Python itself. Python 2 let you write print "Namaste, World!" as a special statement, without brackets. When Python 3.0 was released in 2008, this was changed so that print became an ordinary function, requiring brackets: print("Namaste, World!"). Old Python 2 scripts using the bracket-free form would simply crash under Python 3 — exactly the kind of incompatible change that forces a MAJOR version bump rather than a MINOR one, and exactly why the jump was numbered 2.x to 3.0 rather than to 2.8.

Open Source Around You

Once you know to look, open source software is everywhere in an Indian student's daily technology use, not just in obscure server rooms. Android — running on the majority of smartphones sold in India — is built on the open-source Linux kernel and the largely Apache-2.0-licensed Android Open Source Project (AOSP); Google adds its own closed apps like Play Store and Gmail on top, but the base layer anyone can inspect and, in principle, build their own phone operating system from. The Firefox browser traces directly back to that 1998 Netscape release. VLC Media Player, developed by the VideoLAN project and released under the GPL, plays almost any video format precisely because volunteers worldwide have contributed decoders for formats VLC's core team never had time to write themselves. WordPress, GPL-licensed, powers a large share of the websites you visit without you ever noticing. Python — the language in the very first example in this chapter — is open source under the Python Software Foundation License and is the language most CBSE Computer Science and Informatics Practices classes are built around; Scratch, the block-based environment many of you used in earlier grades, is likewise built and released as an open project by MIT.

India has its own concrete stake in this. BOSS GNU/Linux (Bharat Operating System Solutions) is an Indian, Debian-based open-source operating system developed by the Centre for Development of Advanced Computing (C-DAC) under its National Resource Centre for Free and Open Source Software, aimed particularly at government offices and Indian-language computing. In 2015, India's Ministry of Electronics and Information Technology released a formal policy asking government departments to actively consider open-source options when procuring new software systems, rather than defaulting to proprietary vendors. And it is worth separating two things people often blur together: Wikipedia's articles are published under a Creative Commons license (open content, about text and images), while the actual software running Wikipedia's servers, called MediaWiki, is a separate open-source project released under the GPL. "Open content" and "open source software" are related ideas but are not the same license family, and mixing them up is a common but avoidable mistake.

Even the largest technology companies routinely publish open-source projects rather than treating everything as a trade secret. Google released its machine-learning library TensorFlow as open source; Meta's AI research division released the rival library PyTorch, also open source; and the core editing engine behind Microsoft's popular VS Code editor — the company most associated with decades of closed-source Windows and Office — is itself open source under the MIT License.

Two Big Misconceptions, Corrected

Misconception 1: "Open source means the code costs nothing, so nobody can run a real business on it." This confuses freedom with price. The license guarantees you may read, modify, and redistribute the code — it says nothing about whether a company can charge money for related services. Red Hat built an entire company around packaging, supporting, and maintaining open-source Linux for paying enterprise customers, and was strong enough as a business that IBM acquired it in 2019 for roughly $34 billion. The code Red Hat ships is genuinely open source — anyone can download and modify it for free — but the support contract, guaranteed response times, and certified stability that businesses pay for are not the same thing as the code itself.

Misconception 2: "Open source has no rules — it is basically public domain, so I can do anything with it without asking." This is false, and it is worth being precise about why. Open source code is still protected by copyright, exactly like closed-source code; the difference is that the author has attached a license granting you specific permissions in advance instead of forcing you to negotiate for them. But that license still has terms you must follow — an MIT-licensed project still requires you to keep the original copyright notice attached; a GPL-licensed project still legally obligates you to publish your modified source code if you redistribute it. Ignoring those terms is not a grey area — it is a straightforward violation of copyright law, and companies have been taken to court over exactly this. "Open" describes generous permissions, not the absence of any permissions at all.

A related, more subtle claim deserves a careful look rather than a flat correction: "because anyone can read open-source code, bugs get found and fixed faster." This idea even has a name, Linus's Law, usually phrased as "given enough eyeballs, all bugs are shallow." Here is a simplified way to see the intuition behind it, using nothing more than the multiplication rule for independent probabilities. Suppose a particular bug is subtle enough that any single reviewer, working alone, has only a 10% chance of spotting it — meaning a 90%, or 0.9, chance of missing it. If 50 independent reviewers each look at the same code, the chance that every single one of them misses the bug is:

P(all 50 miss it) = 0.9^50
0.9^10  ≈ 0.349
0.9^50 = (0.9^10)^5 ≈ 0.349^5
0.349^2 ≈ 0.122
0.349^4 ≈ 0.122^2 ≈ 0.0149
0.349^5 ≈ 0.0149 × 0.349 ≈ 0.0052

So P(all 50 miss it) ≈ 0.52% — meaning there is roughly a
99.5% chance that at least one of the 50 catches it.

This is a deliberately simplified model (real reviewers are not perfectly independent, and most open-source code is not actually read line by line by dozens of volunteers) — treat it as intuition-building arithmetic, not a guarantee. It is not automatic, either: the Heartbleed bug, a serious flaw in the widely used open-source encryption library OpenSSL, sat undiscovered in the published source code for about two years before anyone caught it in 2014, precisely because very few of OpenSSL's actual users were among the "many eyes" — most people using it never looked at its code at all. Openness makes wide scrutiny possible; it only pays off when people actually show up to look.

Check Your Understanding

1. A programmer downloads a compiled .exe file from a company's website with no source code attached and no license mentioning modification rights. Is this open source? Explain using the four rights described in this chapter.
2. A start-up takes an MIT-licensed library, changes 40 lines of it, and ships it inside their paid closed-source app without publishing their changes. Have they violated the license? Would your answer change if the library were GPL-licensed instead?
3. A project moves from version 3.4.2 to 3.5.0. Based on semantic versioning rules, what kind of change most likely happened — and would you expect any of your existing code that uses this library to break?
4. Explain, in your own words, why "open source" and "free of cost" are not the same idea. Use the Red Hat / IBM example in your answer.
5. Why does the Linus's Law calculation in this chapter use 0.9 raised to the power of 50, rather than simply 0.9 multiplied by 50?

Answers: (1) No — without a license explicitly granting the rights to study, modify, and redistribute, an available executable with no accompanying source and no permissive license is closed/proprietary, even if you can download it for free. (2) No violation under MIT — permissive licenses allow shipping modified code inside a closed product, as long as the original copyright notice is retained; under GPL, this would be a violation, since GPL requires publishing the modified source code when you redistribute the software. (3) A MINOR bump (3.4 → 3.5) signals a new, backward-compatible feature was added; by the semantic versioning convention, existing code should keep working without changes. (4) Open source describes the freedom to read, change, and redistribute source code, which is independent of price; Red Hat proves you can build a large paying business around open-source software by selling support and services rather than the code itself, which anyone can still download for free. (5) Because the events are treated as independent, and the probability that several independent events all happen together is found by multiplying their individual probabilities, not adding them — multiplying 0.9 by itself 50 times (0.9^50), not multiplying 0.9 by 50.

Summary

• Software is written as human-readable source code and, for compiled languages, translated into unreadable machine code before it runs; closed-source software ships only the machine code, open source ships the source code too.
• Open source requires both a visible source code and a license granting the rights to run, study, modify, and redistribute it — visibility alone is not enough.
• The movement traces from Richard Stallman's 1983 GNU Project and the Free Software Foundation, through Linus Torvalds's 1991 Linux kernel, to the term "open source" being coined in 1998 around Netscape's decision to release its browser code.
• Permissive licenses (MIT, Apache 2.0) allow code to end up inside closed-source products; copyleft licenses (GPL) require redistributed modifications to stay open under the same license.
• Real projects are built through forks, branches, pull requests, and maintainer review — coordinated using Git, a tool Torvalds built specifically for managing Linux kernel contributions.
• Semantic versioning (MAJOR.MINOR.PATCH) signals how risky an update is: patches fix bugs, minor releases add compatible features, major releases can break old code.
• Open source is everywhere in Indian computing — Android's Linux kernel, Firefox, VLC, WordPress, Python, Scratch, MediaWiki, and India's own BOSS GNU/Linux from C-DAC — and it is not free-of-cost by definition, as Red Hat's business (and IBM's acquisition of it) shows.
• Wide visibility of code can help bugs get caught faster, but only when people genuinely review it — as Heartbleed's two years of hiding inside OpenSSL shows, "open" creates the opportunity for scrutiny, not a guarantee of it.