Open Source Resistance: How to Keep OSS Alive on Company Time

Almost every piece of software you touched today — from the banking app that paid your rent to the dashboard your boss stares at — is sitting on a tower of open-source code maintained, in large part, by people doing it for free. That arrangement has always been a bit weird. Lately it has started to look fragile.

Burnt-out maintainers are stepping back. Supply-chain attacks like the xz-utils backdoor have shown how dangerous a single exhausted volunteer can be to global infrastructure. AI companies are scraping the commons at industrial scale while contributing comparatively little back. And inside the companies that depend on this software, the appetite for letting engineers spend Tuesday afternoons polishing a library nobody is paying for is, to put it gently, not what it was in 2015.

If you write code for a living in Australia — at a bank, a SaaS startup, a government department, a mining-tech firm — this matters. Not in a romantic way. In a practical, the-stack-you-rely-on-is-quietly-eroding way. Here is the case for what I am calling open-source resistance: keeping OSS contributions alive on company time, even when the structural pressure is to stop.

Why the commons keeps the lights on

Open-source software is not a charity sector adjacent to the tech industry. It is the tech industry's foundation. Linux runs the cloud. PostgreSQL runs the databases. OpenSSL, curl, and a handful of obscure compression libraries sit underneath the encrypted connections that keep your customer data away from criminals. None of this is replaceable on any reasonable timescale.

The economics, though, have always been odd. A company can extract enormous value from a project without contributing a line of code, a dollar, or even a thank-you. That free-ride dynamic works fine when there are enough contributors to absorb it. It breaks when the ratio tips — when the people taking outnumber the people maintaining by orders of magnitude, and when the maintainers themselves get tired.

The xz-utils incident in 2024 was the loudest warning shot. A widely-used compression library was nearly backdoored at the source because a single overworked maintainer was looking for help and a patient attacker offered to volunteer. The lesson was not 'open source is dangerous.' The lesson was: the people holding up critical infrastructure are stretched so thin that social-engineering them is a viable nation-state tactic.

What you actually get out of contributing

Let's leave ideology aside for a moment. Contributing to open source is also one of the highest-leverage career moves a working developer can make, and it is worth making that case bluntly to anyone — including your manager — who treats it as a hobby.

None of that is hypothetical. It is the unspoken career ladder a significant chunk of senior engineers have climbed.

The company-time problem

The hard part is doing it inside the constraints of paid employment. Most contracts have an intellectual property clause that, read strictly, claims everything you write — including the README typo you fixed at lunch. Most managers, even sympathetic ones, are judged on roadmap delivery, not on whether their team improved the wider ecosystem.

This is where 'resistance' is the right word. Not in any combative sense, but in the sense of pushing back gently and continuously against a default that wants to swallow your time entirely. A few practical moves:

1. Get the IP question answered, in writing, early

Australian employment contracts vary, but most have language broad enough to be a problem if your employer ever decided to be difficult. Ask HR or your manager, on email, whether you can contribute to open source in your own time, and whether contributions made during work hours to projects the company uses are permitted. Get a yes in writing. Many companies will say yes immediately because they have never been asked; the document is what protects you later.

2. Frame contributions as risk reduction, not generosity

'I want to spend Friday afternoons on OSS' is a hard sell. 'We have a production dependency on this library, it has two maintainers, and I think we should be one of them' is a different conversation entirely. Map your company's critical dependencies. Pick one that is genuinely under-resourced. The pitch writes itself: if that project dies or gets compromised, your incident response cost dwarfs the engineering hours you are proposing to invest.

3. Upstream your fixes by default

The easiest contributions are the ones you are already making. Every time someone on your team patches a bug in a vendored library, monkey-patches a framework, or writes a workaround for a known issue, that fix should be a candidate for upstreaming. Make 'did we try to upstream this?' a normal code-review question. Over a year, this alone turns a team from pure consumers into visible contributors with very little extra effort.

4. Protect a small, defended slice of time

Twenty percent time, as a formal program, mostly does not exist anymore. But an hour on a Friday, or the slow week between Christmas and the new financial year, is defensible if you ask. The trick is consistency rather than volume. A maintainer who reviews three PRs a week for a year is more valuable than one who disappears for six months and then dumps a giant patch.

5. Pick projects that align with the day job

If you work on payments, contribute to payment libraries. If you work in data, contribute to the database driver you use every day. This makes the company-time justification trivial and means the skills you build at home and at work compound instead of competing.

What employers should do (and what to ask for)

Australian tech employers — particularly the ones in financial services and government, who are deeply dependent on OSS and rarely visible contributors — should treat upstream investment the way they treat security training: a non-negotiable cost of operating. That looks like:

If you are a senior engineer, these are reasonable things to advocate for. If you are an engineering manager, they are reasonable things to fund. The cost is small. The cost of not doing it shows up later, as a CVE on a Tuesday morning, or as a key dependency unmaintained when you most need a fix.

The quiet bargain

The deal that built modern software was always implicit: companies use the commons, and enough people, often inside those companies, give back to keep the commons healthy. That deal has frayed. It will keep fraying if working developers treat open source as something that happens elsewhere, on someone else's time, by someone else's hands.

Keeping OSS alive on company time is not radical. It is just refusing to be only a consumer of something you depend on. Fix the bug. File the PR. Ask your manager. Sponsor a maintainer for the price of a coffee. Multiply that across a generation of engineers and the commons holds. Stop doing it, and at some point the stack underneath all of us gets thin enough to fall through.

Related on Bleen

Sources