A new essay on the glyph.im blog challenges one of the most influential arguments in the open source community. The author contends that Rich Hickey's famous 2021 post, which argued that open source is not about the user, mischaracterizes the relationship between maintainers and the people who depend on their code. The critique reframes open source as a sustained exchange with real obligations on both sides, rather than a one-way gift.
The Claim That Open Source Is Not About You
Rich Hickey's original essay described open source as a process where a maintainer creates software, makes it available as a gift, and a small fraction of users eventually contribute back. In that framing, maintainers are motivated by pride in their work and love of the team, while users are expected to be grateful recipients. The essay became influential partly because it resonated with maintainers who felt burdened by demands from users expecting immediate support.
The new essay argues that this description is incomplete to the point of being misleading. If a maintainer is earning money from consulting clients and releasing code as a gift to the community, the question of what the maintainer gets in return is left entirely unanswered. The essay examines what that return actually is, and concludes that the exchange is not as simple as a gift with no expectations attached.
Four Motivations Behind Open Source
The essay identifies four distinct reasons maintainers release and sustain open source software, each involving its own kind of trade.
The first is reputation. A visible contributor to an open source project gains attention, esteem, and professional credibility. For someone operating a consultancy, that reputational currency translates directly into advertising for their services. The trade resembles a traditional gift economy: the maintainer gives code, and the users give back recognition and, potentially, business.
The second is influence. Open source infrastructure gives developers a way to shape how an entire community solves a class of problems. When an organization releases a preferred tool and others adopt it, the organization gains the ability to direct the technological agenda. Employees who already know the tool can onboard faster, and potential hires can evaluate the code before deciding to join. This trade is less like a gift and more like soft power.
The third is improvement. Writing proprietary software can limit learning because the developer is isolated from external feedback and may build only within what is commercially viable. Releasing code openly invites bug reports and potential co-developers. The trade is straightforward: code for knowledge.
The fourth is outsourcing. When multiple organizations depend on the same infrastructure tool, the maintenance burden can be shared. The main maintainer provides a central place where contributors can coordinate and release changes. This creates a market-like structure where contributors trade code within a shared namespace. The essay notes this produces a game theory problem: when maintenance drops below a critical threshold, the resulting crisis forces some stakeholders to start contributing.
The Corporate Accounting Problem
The essay identifies a practical problem inside organizations. Most companies account for open source maintenance as simple overhead, buried under general wages or IT costs. This obscures the real benefits that open source generates, such as better hiring, improved reputation, or marketing reach. When a cash crunch arrives, that undifferentiated overhead is the first thing to get cut, along with all the ancillary benefits it was producing.
The author argues that open source expenses should be allocated across departments based on the actual benefit they generate. If it helps hire engineers, part of the cost belongs in recruitment. If it improves reputation, it belongs in goodwill. If it drives product visibility, it belongs in marketing.
The Obligation to Not Abuse Trust
The essay turns to the security dimension of the maintainer-user relationship. When a user installs an open source dependency, they are granting a third party control over their system, even if that control is indirect. There is a strong consensus that code should not contain backdoors or malware, but the essay points out that policy around what constitutes acceptable content is often murky.
The npm registry, for example, explicitly bans malicious code but allows payment information, while also forbidding runtime ads. Other registries like PyPI ban cryptocurrency mining. These inconsistencies reveal that what is considered acceptable is determined by platform policy rather than by any transcendent principle of open source. The underlying rule is simple: a user has placed trust in a maintainer, and that trust creates an obligation not to exploit it, whether intentionally or through negligence.
An Ongoing Relationship
The essay also challenges the framing of open source as a one-time transaction. In practice, the relationship is ongoing. Users add dependencies to their project configuration files, and those dependencies carry forward through updates, security patches, and compatibility changes. The maintainer's decisions about when and how to update affect everyone who depends on the code.
Security updates, the essay argues, are a form of command and control. When a maintainer pushes a change, downstream users must decide whether to accept it. The power dynamic is not symmetrical, and the essay suggests that acknowledging this dynamic is a prerequisite for understanding the full scope of what is at stake when someone releases code as open source.
The author closes by calling for a broader social conversation about the obligations implicit in this exchange, noting that the exact consequences are not yet defined but that the conversation itself is overdue.