Open source, explained: why companies give away software, and how it still makes money · Pulse Beat

Almost every app you use today is built on top of software that someone wrote and gave away. Browsers, phones, servers, programming languages and databases all rest on projects that anyone may read and copy. It sounds like a business mistake. It is actually one of the most successful models in the history of computing.

What "open source" means

Software is written as source code, text that humans can read. Usually a company keeps that text secret and sells you only the finished program. Open source means the text is published under a licence that lets others read it, use it, change it and share it, within certain conditions.

Notice "within certain conditions". Open source does not mean no rules. The licence is the rulebook, and licences differ.

The two big families of licence

Permissive licences, such as MIT and Apache 2.0, say roughly: do almost anything, including using this in a closed commercial product, as long as you keep the copyright notice. They are popular with companies because they impose few obligations.

Copyleft licences, such as the GPL family, say: you may use and change this, but if you distribute a program built on it, you must share your changes under the same terms. The idea is to keep the freedom attached to the code as it spreads.

Neither is better in itself. They express different values about what should happen to shared work.

A related term, source available, describes code you can read but not use freely, often to stop a competitor from selling it as a service. People argue about whether this counts as open source; the strict answer is that it does not, because it restricts use.

Why would a company give code away?

There are several honest reasons, and they usually combine.

Shared cost. If ten companies all need the same plumbing, it is cheaper to maintain one version together than ten versions separately. Much infrastructure software exists for this reason.

Quality and trust. Code that many people can read gets more eyes, more bug reports and more fixes. For security-critical software, being able to inspect it matters to customers.

Adoption. A free tool spreads fast. Once many developers use it, a company can sell what surrounds it.

Hiring and reputation. Engineers like to work on projects they can show. Publishing code attracts talent and goodwill.

Standards. Releasing an implementation can help a format or protocol become the default, which grows the market for everyone, including the company.

How the money comes in

A project's code may be free while the business around it is not. Common models:

Support and services. Charge for help, training, customisation and guaranteed response times.
Hosting. Run the software for customers who do not want to run it themselves. This is now one of the largest models.
Open core. Keep a free core and sell extra features, often for larger organisations, under a commercial licence.
Dual licensing. Offer the code under a copyleft licence for free, and a commercial licence for companies who do not want those obligations.
Sponsorship and donations. Individuals and companies fund maintainers directly. This works better for some projects than others.
Employment. Many contributors are paid by companies that depend on the project.

The uncomfortable part

Open source has real problems, and you should know them.

Maintainer burnout. Some very widely used projects are maintained by a few unpaid volunteers. A small library used by millions can depend on one person's free time, and the world has seen what happens when such a person walks away or when an attacker patiently earns their trust.

Supply-chain risk. Modern software is assembled from hundreds of dependencies. A flaw or a malicious change in one spreads to everything above it. This is why companies now track the contents of their software carefully.

The funding gap. Companies often use far more than they contribute back. Several projects have changed licences in response, which has caused real disputes in their communities.

How to take part, as a student

You do not need to write a big feature. Useful first contributions include fixing a typo in documentation, improving an unclear error message, reproducing and describing a bug precisely, or adding a test. Read the project's contribution guide first, look for issues labelled for beginners, and be patient: maintainers are often busy.

Contributing builds the skills employers look for: reading other people's code, communicating in public, taking review feedback calmly. It also leaves a visible record of your work.

Takeaways

Open source is not charity and not chaos. It is a way for many parties to share costs and trust on common foundations while competing on top. When you choose a tool, read its licence, look at how actively it is maintained and who pays for it. And when you can, give something back, even if small. Everything you build stands on someone else's free work.