The Android phone in your pocket runs on a kernel that started as one Finnish student’s hobby project in 1991. The web server delivering this very page almost certainly runs on free software too. Yet ask most Australians who writes “open source” software, and the honest answer is: nobody really knows, and that gap is worth closing, especially if you’re weighing a tech career or just trying to understand what powers the gadgets you already own.
Open source software is code whose source, the human-readable instructions behind a programme, is published for anyone to read, modify and redistribute, usually under a licence that spells out the rules. That’s different from the Windows or iOS software most readers use daily, where the company that made it keeps the recipe locked away. Our take: the “who” and “why” behind open source is more interesting, and more commercially important, than the slightly nerdy reputation it carries.
Who actually writes it
Three rough groups do the work, and they rarely get equal credit.
The first is large companies. Google, Microsoft, Amazon and Meta all pay engineers to write and maintain open source projects, because it suits their business. Google built the Android operating system and the Kubernetes container system this way partly to commoditise the layer underneath their actual money-makers, search and cloud computing. Microsoft, once open source’s loudest critic in the 1990s, now owns GitHub, the largest hosting platform for open source code, and contributes heavily to the Linux kernel. That reversal alone says something about how the economics shifted.
The second group is volunteers: hobbyists, students, retirees and professionals coding in their spare time, often for reasons that have nothing to do with money. Reputation, learning, scratching a personal itch, or genuine belief that infrastructure software should be a public good.
The third, and most overlooked, is foundations and non-profits such as the Apache Software Foundation, the Linux Foundation and the Mozilla Foundation, which coordinate contributions, hold trademarks, and keep projects from fragmenting when corporate interests pull in different directions.
Short version: open source isn’t one community, it’s an uneasy coalition of billion-dollar companies and people who do it for free, somehow cooperating on the same codebase.
Why companies give away code for free
This is the part that trips people up, because giving away your work sounds like bad business. It usually isn’t.
A company might open source a tool to set the industry standard before a rival does, the way Google pushed Kubernetes to become the default way businesses run cloud software. Giving it away meant nobody could out-compete Google on the underlying plumbing, because Google helped write the plumbing everyone uses. Other companies open source infrastructure code because they’d rather spread the maintenance burden across the whole industry than carry it alone; a shared security patch benefits everyone, including the company that found the bug first.
There’s also recruitment. Engineers often choose employers partly on whether they’re allowed to work on public, portfolio-building code rather than code locked inside a corporate vault forever. And increasingly, there’s a trust argument: publishing the code behind an encryption tool or a password manager lets independent researchers check it isn’t doing anything sneaky. That matters more after a decade of data breach headlines than it did in, say, 2010, and it’s a point worth weighing against our own piece on how to tell if your phone has been hacked, since open auditability is part of why some security tools are trusted at all.
None of this is charity. It’s closer to the old razor-and-blades logic, except the razor is free and the blade is a cloud subscription.
The Australian angle most people miss
Australia doesn’t write much of the world’s open source infrastructure, but we depend on it heavily, often without knowing it. Government agencies, universities and hospitals run systems built on open source databases and web servers because it’s cheaper than licensing proprietary equivalents at scale, and because the code can be audited rather than taken on faith.
Patching rhythms matter too. When a serious flaw is found in a widely used open source library, the fix often arrives faster than with proprietary software because thousands of eyes are already looking at the code. The flip side, which deserves more attention than it gets, is that a small, unpaid volunteer maintainer somewhere might be the only person keeping a piece of software that half the internet depends on from falling over. That’s not hypothetical; it’s roughly what happened with a widely used compression library at the centre of a 2024 supply-chain scare, maintained for years by one burnt-out volunteer before an attacker tried to exploit exactly that fatigue. The Australian Cyber Security Centre doesn’t distinguish between open and closed source in its advice, only whether software is patched and configured properly, which is arguably the more useful frame for ordinary users anyway.
For small Australian businesses thinking about ransomware attacks on small businesses, the lesson is blunt: open source isn’t automatically safer, it’s differently risky, and “it’s free and popular” is not a security strategy on its own.
Licences: the fine print that actually matters
Not all open source is created equal, and the licence attached to a project decides what you can legally do with the code.
- Permissive licences, like MIT or Apache 2.0, let anyone use, modify and even sell the code with minimal strings attached. Most corporate-backed projects use these.
- Copyleft licences, the best known being the GNU General Public License, require that anything built using the code must also be released as open source under the same terms. This is why some companies avoid certain libraries entirely; it can force their own code open.
- “Source available” licences, a newer and more contested category, let you read the code but restrict commercial use, often introduced by companies trying to stop cloud giants from repackaging their product and selling it back as a service.
That last category has caused genuine arguments in the industry over the past few years, as some companies shifted away from fully open licences after larger cloud providers built competing paid services on top of their free code without contributing much back. It’s a legitimate grievance, and also a reminder that “open source” and “free forever, no catches” were never quite the same promise. The World Intellectual Property Organization’s copyright overview is a reasonable starting point if you want the legal underpinnings without wading into a licensing forum argument.
A mildly unfashionable opinion on all this
Here’s where we’ll part ways with some open source purists: we reckon the romantic framing of open source as a pure, community-driven alternative to greedy corporate software is mostly nostalgia at this point, and clinging to it does readers a disservice. The infrastructure of the modern internet, the Linux kernel, the Chromium engine behind most web browsers, the Kubernetes systems running half the world’s cloud computing, is overwhelmingly steered and funded by a handful of enormous companies pursuing their own commercial interests. Volunteers absolutely still matter, especially in smaller, more specialised projects, but the idea that open source is a scrappy underdog movement standing apart from Big Tech hasn’t been accurate for at least fifteen years. It’s better understood as a different business model Big Tech uses when it suits them, not an alternative to Big Tech.
That’s not a criticism of the software, much of which is excellent. It’s a correction to how we talk about who’s really in charge of it.
What this means if you’re eyeing a tech career
For readers considering a move into software, contributing to an open source project is one of the few genuinely useful things you can put in front of an employer that isn’t a certificate or a degree. Unlike most coursework, it’s visible, it’s real, and a hiring manager can look at your actual commits, the individual chunks of code you’ve submitted, rather than take your word for your skills.
You don’t need to write a new programming language to start. Fixing documentation, triaging bug reports, or writing tests for an existing project are all genuine contributions, and most large projects have a “good first issue” tag specifically for newcomers. If you’re earlier in the journey and want structured options before diving into a real codebase, our rundown of tech education opportunities you can learn at home covers several free and low-cost starting points.
It’s also worth being realistic about pace. Most meaningful open source contributions take weeks of reading other people’s code before you write a line of your own; it’s a slower on-ramp than a bootcamp advertisement suggests, but the credibility it buys tends to last longer.
The quiet dependency problem nobody budgets for
If there’s one thing worth remembering from this whole picture, it’s that free software is never actually free of cost, the cost just moves somewhere less visible. Someone, somewhere, is maintaining the library your bank’s app depends on, and that someone might be doing it unpaid, between a day job and family commitments, with no obligation to keep going.
Industry bodies have pushed in recent years for companies that profit from open infrastructure to actually fund its upkeep, through sponsorship, paid maintainer time, or security audits, rather than treating it as a free resource that maintains itself. It’s a sensible push, and one Australian businesses relying on this software, often without realising how deep the dependency runs, should probably be paying more attention to.
Whether you ever write a line of code or not, there’s a decent chance a piece of software maintained by a volunteer somewhere is quietly holding up something you use today. Worth a thought next time an app just works without a glitch.
— Dale Whitfield, Founding Editor, Tech Geek
