Why do developers give their work away for free?

Why do developers give their work away for free?

Developers give work away because public work pays them in currencies other than money: reputation, a portable portfolio, better tools, and leverage in every future negotiation. The gift is also an investment, and it is one of the most reliable ones available in this field.

No other profession the average recruiter has hired for works this way. A lawyer does not publish winning briefs for rivals to reuse. A salesperson does not hand their call scripts to the market. Yet a large share of working engineers spend evenings and weekends on code anyone can take, and the strongest of them often have the most public work. The previous lesson covered what GitHub is and what lives on a profile. This one covers the motive underneath it, because once the motive is clear, the behavior stops looking strange and starts looking like career strategy.

What is open source?

Open source is software whose code is published for anyone to read, use, and change. The repository is public, the full history of commits is visible, and anyone can propose a change through a pull request.

The name describes the arrangement. "Source" is source code, the human-written text of a program. "Open" means that text is published rather than kept as a trade secret. The opposite arrangement, where a company keeps its code private and sells only the finished product, is called closed source or proprietary software. Most companies run both at once: a private codebase for their product, built on top of open source parts.

The scale of it surprises people. Open source is the material most software is made from. The tools that run websites, the databases that store customer records, and the languages developers write in are overwhelmingly open source projects. A typical commercial application is a thin layer of private code on a deep stack of public code, maintained by people the company has never met. When a developer says "everything runs on open source", that is a description of the industry rather than a slogan.

What does a developer get out of it?

The most concrete return is a portfolio. An employed developer does most of their work in private repositories, and when they change jobs, none of it comes with them. Public work does. A contribution to a known project is durable, verifiable proof of skill that survives every job change. For a developer, open source work is the closest thing the field has to a published record, and reading that record is a skill a later station of this path teaches.

The second return is self-interest in the plainest sense. Developers depend on shared tools every working day. When one of those tools has a bug or lacks a feature, a developer can wait for someone else to fix it or fix it themselves and send the fix back. Sending it back means the fix survives future versions of the tool, and the project's maintainers take over its upkeep. Contributing to a tool you use is closer to repairing your own workshop than to charity.

The third return is standing. A developer whose fixes keep getting accepted into a serious project has passed code review by strangers with no reason to be polite, repeatedly and in public. Other engineers treat that record the way your industry treats a strong book of business. It draws inbound offers, speaking invitations, and consulting work, and it compounds for years.

And underneath all three sits craft. Building software is the part of the job many developers enjoy most, and open source is that part with the meetings removed. Nobody assigns the work, nobody sets the deadline, and the builder picks the problem. Some of the free work on any profile exists for the same reason a chef cooks on their day off.

What is a license?

A license is the legal document attached to published code that says what others may do with it. It sits as a file in the repository, and it is the difference between code that is merely visible and code a company can legally build on.

Without a license, published code defaults to full copyright, and using it in a product is legally risky. The license grants permission in advance, to everyone, without negotiation. That single mechanism is what lets a startup assemble a product from hundreds of open source parts without signing hundreds of contracts.

Licenses vary in what they demand in return. Permissive licenses, with MIT and Apache the names you will see most, allow nearly anything, including selling products built on the code, with little more than a credit line required. Copyleft licenses, with GPL the common name, add a condition: if you build on this code and distribute the result, your code must be published under the same terms. Companies track this difference carefully, and some employ people to audit which licenses their products depend on. When engineers debate a project "changing its license", they are debating whether a tool their employer relies on will stay free to use.

Why do companies pay employees to work on it?

Companies pay for open source work because they depend on it. When your product runs on a shared tool, the health of that tool is a business concern, and funding its development is cheaper than replacing it. Some of the largest engineering employers have whole teams whose full-time paid job is maintaining public projects.

Funding also buys influence. The maintainers of a project decide its direction, and a company that employs maintainers has a voice in decisions that affect its own product. That is why "paid to work on open source" appears on the resumes of very senior people: the role means an employer valued their standing in a public project enough to buy their time for it.

There is a recruiting consequence hiding in this. For a developer with a strong public record, open source involvement can be part of the compensation. Some companies allow contribution time as a matter of policy, and for certain candidates that policy weighs like a benefit. It belongs in the same mental category as a developer's attachment to their tech stack: part of the offer that never appears in the offer letter.

Why do developers write blog posts and give talks?

The same motive drives every public artifact. A technical blog post, a conference talk, and a patient answer to a stranger's question on a forum are all reputation built in public, and they pay out the same way code does: standing among peers, inbound opportunity, and proof of skill that stays with the person.

These artifacts carry real signal. Writing clearly about a hard technical subject demonstrates the same understanding the work itself required, plus the ability to explain it, which is scarce. A talk at a serious conference means a program committee judged the person worth an audience. Teaching in public is how many developers become known in a niche, and known people are the ones a market bids on.

So the gift economy resolves into one sentence: in this profession, giving work away is how a career gets built in the open. The free code, the posts, the talks, and the answered questions are one behavior with one motive, and that motive is the subject of the rest of this module. A developer's public generosity is a market position, maintained deliberately, and it is one of the richest records a recruiter can read.