Open source software is software whose code is published under a licence that lets anyone read it, change it and share it. Much of what you use every day, from the server behind a website to the language you write code in, is built this way.
What makes software open source
Every program starts as source code: the human-readable instructions a developer writes. Most commercial apps ship only the compiled result, so you can run them but can't see how they work. An open source project publishes the source as well.
Publishing the code isn't enough on its own. Code is protected by copyright the moment it's written, so code sitting on a public page with no licence still belongs to its author, and you have no right to copy or change it. What makes a project open source is its licence: a document that grants everyone permission to use, study, modify and redistribute the code.
The Open Source Initiative maintains the widely used definition. Among other things, an open source licence must allow free redistribution, include the source code, allow modified versions, and not discriminate against any person, group or field of use. A licence that says 'free for students only' or 'no commercial use' fails that test.
Free as in freedom
Open source doesn't always mean free of cost. The free software movement puts it as 'free as in free speech, not free beer'. The freedoms are to run the program, to study and change it, and to share it, changed or not. Nothing stops someone charging for a copy, for support or for a hosted version, and many companies built on open source make their money exactly that way.
Open source vs closed source
Closed-source, or proprietary, software keeps its code private. You get a compiled program and a licence agreement that usually forbids taking it apart. That isn't automatically worse: the vendor is responsible for fixes, and there's often a support contract.
The difference shows when something goes wrong or you need something new. With closed source you file a request and wait. With open source you can read the code to see why it behaves as it does, fix a bug yourself or add the feature you need, then offer the change back so everyone gets it.
There's also a middle ground called source-available: the code is public, but the licence restricts what you can do with it, for example by banning competitors from offering it as a hosted service. You can read it, but it isn't open source by the OSI definition. Some companies have moved projects from an open source licence to a source-available one, and in more than one case the community has forked the last open version and carried on without them.
How a project works together
Most open source projects live on a code hosting platform such as GitHub or GitLab, built on Git. A small group of maintainers can change the main repository directly. Everyone else contributes through a few routes:
- Issues report a bug or suggest a feature, so the problem is written down before anyone codes a fix.
- Pull requests (merge requests on GitLab) propose a change: here is my code, please consider adding it.
- Code review is where maintainers and other contributors read the change, ask questions and request fixes before it's merged.
- Docs and triage count too. Reproducing someone's bug report or improving the README is a real contribution.
Anyone can propose a change, but the maintainers decide what gets merged. A project has a direction, and a pull request that doesn't fit it can be turned down even when the code is good.
A worked example
Say your app uses an open source date-parsing library, and it reads '2024-03-10T09:00+05:30' with the wrong offset. Here's how you'd get that fixed:
- Search the issues. Someone may have reported it already, or a fix may be waiting for review.
- Open an issue if not, with the smallest input that shows the bug, what you expected and what you got.
- Read
CONTRIBUTING.md. It tells you how the project wants changes made: code style, how to run the tests, and whether to discuss a fix first. - Fork and fix. A fork is your own copy of the repository, where you can push freely.
git clone <your-fork-url>
cd date-lib
git switch -c fix-utc-offset
# add a failing test, then fix the parser
git add .
git commit -m "Fix parsing of +05:30 offsets"
git push origin fix-utc-offset- Open a pull request from your branch to the original project, and link the issue.
- Respond to review. A maintainer might ask for another test or a different approach. Push more commits to the same branch and the pull request updates.
Once it's merged, the fix ships in the next release, and every project that depends on the library gets it.
Licences, briefly
Open source licences fall into two broad families.
- Permissive licences, such as MIT and Apache 2.0, let you do almost anything with the code, including using it in closed-source products, as long as you keep the copyright and licence notice. Apache 2.0 also grants an explicit patent licence.
- Copyleft licences, such as the GPL, let you use and change the code too, but if you distribute software built from it, you must release your version under the same licence, with its source. The aim is that the code stays open as it spreads.
Copyleft is where people get caught out. Using a GPL tool, such as a compiler, doesn't make your own code GPL. Shipping a product that includes GPL code usually does bring obligations. If a project matters to a business, check the licence of every dependency, not just the ones you picked deliberately.
Why you can trust it, and where that stops
Because anyone can read the code, nothing important has to be taken on trust. Security researchers can audit it, and a company can check that a library doesn't send data anywhere it shouldn't. That openness is a big part of why open source runs so much of the internet: the Linux kernel, web servers such as nginx, databases such as PostgreSQL and languages such as Python are all open source.
Public code still needs someone to read it, though. Plenty of widely used projects are kept going by one or two unpaid volunteers, and bugs, security bugs included, can sit in public code for years. Attackers also publish packages that look legitimate and hide harmful code, as Malicious Packages covers. Treat open source like any other dependency: check it's maintained, pin its version and keep it updated.
Common mistakes
- Treating public code as free to use: code with no licence isn't open source. Look for a
LICENSEfile before you copy anything. - Assuming open source means free of cost: it means freedom to inspect, modify and share. Hosting, support and some editions may still cost money.
- Ignoring licence conditions: even MIT asks you to keep its notice, and the GPL asks for much more if you distribute.
- Opening a large pull request out of the blue: for anything beyond a small fix, raise an issue first, so you don't spend a week on something the maintainers won't merge.
- Confusing open source with open weights: an AI model whose weights you can download isn't necessarily open source; Open weight models explains the difference.
Key takeaways
- Open source means the code is public and licensed so anyone can use, study, modify and share it.
- It's about freedom, not price: open source software can still be sold, supported or hosted for a fee.
- Contributions flow through issues, pull requests and code review, and the maintainers decide what's merged.
- Permissive licences ask little; copyleft licences require distributed changes to stay open.
- Public code can be inspected, but someone still has to inspect it, so check a project is maintained before you depend on it.
