Open Source is Not About You: Rich Hickey's Manifesto on OSS Expectations

The open source community has long grappled with a fundamental tension: the disconnect between what users expect from free software and what maintainers are actually obligated to provide. In a candid and controversial post, Rich Hickey, the creator of Clojure, cuts through the mythology surrounding open source to deliver a stark reality check about entitlement, expectations, and the true nature of OSS contributions.

The Core Problem: Entitlement Without Contribution

Hickey's central argument is deceptively simple: open source is a gift, not a contract. When someone releases software under an open source license, they're granting you the right to use and modify the code—nothing more. Yet a pervasive sense of entitlement has developed within the community, where users feel they deserve not just the software, but also the maintainer's time, attention, and alignment with their personal vision.

This entitlement manifests in several ways:

• Expecting maintainers to prioritize feature requests
• Demanding explanations for development decisions
• Assuming the right to contribute without understanding the project's standards
• Feeling owed a response to every issue or complaint
• Believing the project should adapt to individual needs rather than collective ones

The Myth of "Community-Driven Development"

One of Hickey's most provocative claims is that the concept of "community-driven development" is largely mythological. While the rhetoric suggests that open source projects should be democratic and responsive to community input, the reality is far more complex.

The only people entitled to say how open source 'ought' to work are people who run projects, and the scope of their entitlement extends only to their own projects. This statement cuts to the heart of the matter: maintainers have complete autonomy over their work, and users have no inherent right to dictate direction.

This isn't to say community input is worthless—Clojure, for instance, incorporates many community contributions in each release. But the integration of these contributions is at the discretion of the core team, not an obligation.

The Hidden Costs of Open Source Maintenance

What many users fail to recognize is the substantial personal and financial investment required to maintain popular open source projects. Hickey reveals that he and his team at Cognitect:

• Receive no royalties from Clojure despite creating it
• Use personal funds (including retirement savings) to hire people to work on Clojure
• Spend significant time away from income-generating activities to develop the language
• Maintain Clojure despite fewer than 1% of users being their consulting or product customers

We get no royalties of any kind from Clojure. We are in no way building Clojure for profit. This reality check exposes the often-unseen sacrifices maintainers make, challenging the assumption that open source development is purely altruistic or that maintainers have unlimited capacity to serve user demands.

Why Patches Often Fail

Hickey provides a sobering assessment of why many community contributions don't make it into projects: most patches/issues have poor problem statements, no description of the plan, no consideration of alternatives, no tests, no designs, and are ill-conceived and/or broken in some way.

This isn't a condemnation of contributors, but rather an explanation of why the integration process is more complex than many realize. Quality contributions require:

• Clear articulation of the problem being solved
• Thoughtful consideration of alternative approaches
• Comprehensive testing
• Well-designed implementation
• Alignment with the project's overall vision and standards

The Conservatism Advantage

The Clojure team's conservative approach to development—prioritizing stability and thoughtful design over rapid feature addition—is presented not as a limitation but as a feature. In contrast to projects with "high churn rates and feature bloat," Clojure's methodical pace ensures long-term sustainability and coherence.

This conservatism reflects a deeper philosophical commitment to quality over quantity, substance over speed. It's a reminder that not all open source projects share the same goals or values, and users should choose tools that align with their needs rather than expecting every project to conform to their preferences.

What Users Can Actually Do

Rather than dwelling on what they can't control, Hickey encourages users to focus on what they can contribute:

• Library development - Create tools and extensions that solve specific problems
• Outreach - Help grow and educate the community
• Training and tutorials - Create educational resources
• Documentation - Improve project documentation and examples
• Tool building - Develop development tools and integrations
• Giving talks - Share knowledge and promote the project
• Triage efforts - Help organize and prioritize issues

These contributions, while not directing core development, add substantial value to the ecosystem and demonstrate a more constructive approach to open source participation.

The Call for Self-Responsibility

Perhaps the most important message in Hickey's post is the emphasis on personal responsibility. If you have expectations (of others) that aren't being met, those expectations are your own responsibility. You are responsible for your own needs.

This reframing shifts the burden from maintainers to users: if you need something that doesn't exist, build it. If you want features prioritized differently, create your own project or fork. The open source license grants you the freedom to act, not the right to demand action from others.

The Morale Crisis in Open Source

The post concludes with a warning about "morale erosion amongst creators," acknowledging that the constant criticism and entitlement demands take a real toll on maintainers. This psychological burden often goes unrecognized in discussions about open source sustainability.

When maintainers burn out or abandon projects due to negative community interactions, everyone loses. The solution isn't to suppress criticism entirely, but to cultivate a culture of gratitude, understanding, and constructive engagement rather than entitlement and demands.

A Balanced Perspective

Hickey is careful to note that his message isn't directed at the majority of the Clojure community, whom he describes as "wonderful and positive." The post targets a specific pattern of behavior—entitlement masked as community advocacy—that can poison open source ecosystems.

If you think Cognitect is not doing anything for the community, or is not listening to the community, you are simply wrong. You are not, however, entitled to it being the effort, focus or response you desire. This distinction between appreciation and entitlement is crucial for healthy open source communities.

The Path Forward

The open source movement has achieved remarkable things, but its continued success depends on recalibrating expectations and fostering healthier relationships between creators and users. This means:

• Recognizing open source as a gift, not a service contract
• Understanding the real costs maintainers bear
• Contributing constructively rather than demanding changes
• Choosing projects that align with your values and needs
• Building your own solutions when existing ones don't meet your needs
• Supporting maintainers through sponsorship, gratitude, and patience

The future of open source depends not on eliminating criticism or demands, but on creating a culture where users understand their role as beneficiaries rather than entitled consumers, and where maintainers can sustain their work without sacrificing their well-being or autonomy.

Featured image: The open source landscape requires both creators and users to understand their roles and responsibilities.