Most people think software belongs to somebody.

Microsoft owns Windows. Adobe owns Photoshop. Spotify owns the app you open when the office becomes too quiet. The logo is right there, the subscription charge appears every month, and somebody emails you whenever the privacy policy changes.

Underneath that branded surface, modern technology is messier.

A surprising amount of it is built from code that no single company fully controls written in public, improved by strangers, argued over in GitHub threads, and maintained by people whose names will never appear in the product credits. Open source is less like a category of software and more like the plumbing of the internet. Nobody talks about it. Everybody notices when it breaks.

Your expensive app is made from free parts

Very few software companies build everything themselves.

That would be absurdly slow. A team creating a food delivery app doesn’t want to spend six months inventing a database and another year building an operating system. They use tools that already exist. Many are open source.

This is normal, not lazy.

Developers are paid to solve the part that is actually new. The rest is assembled from libraries, frameworks, databases and utilities built by other people. Companies love saying they built a product “from the ground up.” Usually they built the interesting floors. The ground was already there.

Free is not the interesting part

Open source is often described as free software, which is useful and slightly misleading.

The price matters, especially to students and startups running on optimism and a nearly expired cloud credit. But the bigger advantage is permission. You can inspect the code. Change it. Run it yourself. Adapt it when it doesn’t quite fit.

With closed software, you’re mostly renting someone else’s decisions. A feature disappears, prices rise, the company gets acquired, or support suddenly becomes “enterprise only.” You can complain perhaps loudly on LinkedIn but you still wait.

Open source gives you options. Not always pleasant ones. Sometimes the option is to hire an engineer, read years of chaotic documentation, and discover that the configuration file cares deeply about spaces. Still, an ugly option is better than none.

The internet runs on invisible favours

This part makes me slightly uncomfortable.

Some important software is maintained by tiny groups, occasionally by one tired person. Meanwhile, large companies use that work to serve millions of customers and earn very real money.

A familiar startup story goes like this: five developers are shipping quickly and the dashboard is full of upward arrows. Then a security alert appears in a small dependency nobody remembers installing. They open its project page and discover the maintainer has been answering bug reports after work for years.

That dependency may sit several layers below the company’s own code. It still matters.

People contribute for all kinds of reasons curiosity, reputation, frustration, or the satisfaction of fixing something properly. Companies contribute because sharing infrastructure is cheaper than rebuilding it privately.

But the system relies on goodwill more than it should. We’ve created an economy where billion-dollar products may depend on a volunteer’s weekend availability.

That’s not a criticism of open source. It’s a criticism of how casually businesses consume it.

Public code doesn’t magically become good code

There is a lazy argument that open source must be safer because “many eyes” can inspect it.

Sure. They can.

Whether they actually do is another matter.

A popular project with regular updates and a healthy community can be extremely reliable. An abandoned repository last updated when everyone was making sourdough bread is a different story. The licence tells you almost nothing about maintenance quality.

I’d still rather have inspection than a black box and a cheerful support chatbot. But companies need to stop treating every GitHub repository as industrial-grade infrastructure.

Check who maintains it. Look at recent releases. Read the issue tracker. Notice whether security reports are taken seriously. See how painful replacement would be. This is boring work, which is exactly why it gets skipped.

Then one Friday evening, it becomes exciting.

Big tech figured this out years ago

People sometimes imagine open source as a rebellion against large technology companies. That picture is badly outdated.

Big companies depend on open source, employ contributors, release projects and build profitable services around software anyone can download. They aren’t doing it out of pure generosity. Shared foundations are practical.

If ten companies need the same basic tool, ten private versions create ten sets of bugs and ten maintenance teams. A shared project lets everyone improve the common layer while competing elsewhere.

Of course, companies can take far more than they give. They may package community software into a paid service, grow enormous, and return very little money or engineering effort. Open source has ideals, but it lives in the real economy. Things get awkward.

Anyway, awkward cooperation is still cooperation.

AI made the argument louder

The AI boom didn’t invent open collaboration, but it made the tension harder to ignore.

Developers can download models and tools, experiment on ordinary hardware, and build prototypes without asking a large vendor for permission. A small team can test an idea over a weekend instead of beginning with procurement.

At the same time, the word “open” gets stretched. A model may be downloadable while its training data remains unknown. Code might be visible but restricted in ways traditional open-source licences would not allow. Marketing departments enjoy flexible language.

I don’t think everything must be open. Some systems are expensive to build or risky to release. But we should be precise. “You can use this” is not always the same as “you can understand, modify and redistribute this.”

Use it, but don’t act entitled

For developers, open source is one of the best places to see how real software evolves. Not clean tutorial code. Real code with old decisions, compromises, confusing names, excellent fixes and comments written during bad afternoons.

You don’t need to arrive with a heroic contribution. Improve documentation. Reproduce a bug. Answer a question you already solved. Sponsor a project your company relies on. Give maintainers useful information instead of writing “it doesn’t work” and disappearing.

Mostly, treat open source as a relationship rather than a pile of free components.

The next time Gmail loads, a payment clears, a streaming app remembers your place, or a work dashboard refreshes, some open-source project is probably doing quiet work underneath. You won’t see its logo.

That’s partly the point.