The Social Contract of Open Source  ## Metadata - Author: [[Tall, Snarky Canadian]] - Full Title: The Social Contract of Open Source - Category: #articles - Document Note: --- tags: - #open-source - #maintainership - #ethics Author: Tall, Snarky Canadian Source: Blog Reference: https://snarky.ca/the-social-contract-of-open-source/ date created: 2025-08-22 00:00 --- # Title: The Social Contract of Open Source — Entitlement, Ethics, and Sustainable Participation ## Table of Contents: - 🔗 [📝 Summary](#-summary) - 🔗 [📖 Main Content](#-main-content) - 🔗 [🗒️ Notes](#️-notes) - 🔗 [📖 References](#-references) - 🔗 [🗣️ Paraphrase](#-paraphrase) - 🔗 [📰 Newsletter](#-newsletter) - 🔗 [✅ Action Items](#-action-items) - 🔗 [🧪 Hypotheses](#-hypotheses) - 🔗 [📊 Methodology](#-methodology) - 🔗 [❓ Questions](#-questions) - 🔗 [🔮 Future Research](#-future-research) - 🔗 [💡 Implications](#-implications) - 🔗 [🧠 Learning Styles Assessment](#-learning-styles-assessment) - 🔗 [📊 Accessibility Assessment](#-accessibility-assessment) - 🔗 [🌍 DEIB Assessment](#-deib-deib-inclusion) - 🔗 [✅ Logical validity](#-logical-validity) - 🔗 [🔍 DARVO Analysis](#-darvo-analysis) - 🔗 [🔍 SEO Evaluation](#-seo-evaluation) - 🔗 [🎯 Conclusion](#-conclusion) ### References: - “Setting expectations for open source participation” (companion post): https://snarky.ca/setting-expectations-for-open-source-participation/ - Keynote video segment: https://youtu.be/tzFWz5fiVKU?t=48m55s - Changelog podcast episode embedded at the end of the article - Kant, Groundwork of the Metaphysics of Morals (for the categorical imperative) ## 📝 Summary: The author argues that open source maintainers owe users “quite literally nothing” beyond a license permitting use of the code. Using vivid analogies—a pile of “FREE” USB drives on the front lawn and a free ice cream—the post critiques entitlement and abusive behavior toward maintainers as both rude and unethical. Drawing on Kant’s categorical imperative, the author contends that treating maintainers as mere means to an end violates basic moral respect. The piece outlines how abuse drives burnout and pushes maintainers toward more closed or abandoned projects, ultimately harming everyone. The core takeaway: “Every commit of open source code should be viewed as an independent gift,” and we should treat maintainers as ends in themselves. ## 📖 Main Content: The post distinguishes the legal from the social contract of open source. Legally, open source is “source code that is licensed in such a way that I can use it for free.” Socially, if maintainers choose to be reachable, the interaction must be grounded in basic dignity and respect. Key analogies anchor the argument: - “FREE” USB drives on a lawn: Users take code voluntarily; harassment over a free gift is unreasonable. - Free ice cream: Disliking a flavor you chose doesn’t justify berating the giver. From a moral perspective, invoking Kant’s categorical imperative, the author reframes abusive demands as using maintainers merely as tools. The right posture is to treat maintainers as people who may choose to help, not as service providers bound by obligation. A concrete example mirrors real events: a project added Rust for security, which incensed users reliant on legacy or esoteric platforms (e.g., Alpha). The author argues it’s unreasonable to be angry when a maintainer changes direction for their own productivity and security. Consequences of abuse are tiered: more opinionated code; accepting code visibility but closing participation; abandonment; archival; and ultimately deletion. Each escalation is rational from the maintainer’s perspective but worsens outcomes for the community. The author advocates bystander intervention: defuse, support maintainers, and ban bad actors. The closing thesis: view each commit as a gift; release expectations about future commits or support. This reframing reduces frustration and strengthens ethical, sustainable community norms. ### 🗒️ Notes - Thesis and framing - Entitlement harms open source and is unethical. - Maintainers owe nothing beyond the license. - If maintainers open channels, treat them as humans, not vendors. - Legal vs social contract - Legal: freedom to use, per license terms. - Social: optional two-way engagement governed by respect and civility. - Analogies - “FREE” USB drives: voluntary uptake; harassment is like yelling at someone after taking a free item. - Free ice cream: preference ≠ entitlement; constructive feedback ≠ abuse. - Ethical grounding (Kant) - Treat people as ends, not means. - Abusive demands instrumentalize maintainers. - Ethical posture: ask respectfully; accept “no.” - Practical example - Project adding Rust for security; users of legacy platforms reacted with hostility. - Maintainer autonomy over stack and scope is legitimate. - Burnout and consequences - Abuse leads to: - More opinionated, narrower scope. - Open code, closed participation. - Maintainer departure and project abandonment. - Read-only archives. - Full deletion and yanked releases. - Even “wins” from harassment push maintainers toward burnout, harming the project long-term. - Community responsibility - Don’t tolerate abuse; defuse, support, and remove bad actors. - Recognize wide ripple effects beyond single interactions. - Core principle - “Every commit is a gift.” - Drop expectations about next releases, features, or support. - Maintain a gift mindset to preserve goodwill and sustainability. ## 📖 References: - The article itself: https://snarky.ca/the-social-contract-of-open-source/ - Companion blog post on expectations: https://snarky.ca/setting-expectations-for-open-source-participation/ - Keynote excerpt: https://youtu.be/tzFWz5fiVKU?t=48m55s - Kant’s categorical imperative (overview): Stanford Encyclopedia of Philosophy’s “Kant’s Moral Philosophy” - Changelog podcast (embedded in the article) ## 🗣️ Paraphrase: 1) Original idea: Open source maintainers owe you nothing and abuse is unethical; think of code as free USB drives left on a lawn. Paraphrase: Publishing open source doesn’t obligate the author to you. Imagine a person leaving out a box of USB sticks labeled “FREE” on their front porch. You’re welcome to take one, but storming up to their door and shouting about what you found on a free drive is out of bounds. That’s what it looks like when people rage in issues or email over software they chose to use without paying for. 2) Original idea: Applying Kant—don’t treat maintainers as a means to your end; treat them as people with autonomy. Paraphrase: If you approach a maintainer primarily as a tool for getting your preferred features or fixes, you’ve reduced them to an instrument. Kant’s rule tells us to respect people as ends in themselves. The ethical alternative is to ask for help with courtesy and be prepared to accept “no,” recognizing the maintainer’s right to choose. ## 📰 Newsletter: This week in WordPress and Open Source: Learning, Building, and Being Better Neighbors - Learn to build smarter: Whether you’re just starting with HTML/CSS or scaling complex PHP and JavaScript projects, remember that every commit you rely on is someone’s hard-won insight. Treat it like the gift it is—because it is. - Recent updates: A growing number of security-focused projects are adopting Rust for critical components to boost safety and reliability. If you’re curious about why, check out discussions around memory safety and the shift toward more secure supply chains. - Community highlights: Shout-out to maintainers who keep the lights on, review PRs at odd hours, and write docs that save us all time. If a project changed and it broke your flow, consider opening a constructive issue—clear repro steps beat caps-lock any day. - New plugins: Keep an eye out for tools that automate testing of backward compatibility in WordPress plugins and themes; they reduce friction when upstream dependencies evolve. - Pro tip: Want to help your favorite project? Triage old issues, write docs, create minimal repros, or sponsor the work. Your kindness and clarity go further than you think. Further reading: “The social contract of open source” explores entitlement, ethics, and how we can all be better collaborators: https://snarky.ca/the-social-contract-of-open-source/ ## ✅ Action Ite - Document Tags: [[open source]] - Summary: Even though I gave a keynote [https://youtu.be/tzFWz5fiVKU?t=48m55s]with an accompanying blog post [https://snarky.ca/setting-expectations-for-open-source-participation/] all about setting expectations for open source participation, I felt it was time to do another blog post to directly address the issue of entitlement by some open source - URL: https://snarky.ca/the-social-contract-of-open-source/ Even though I gave a [keynote](https://youtu.be/tzFWz5fiVKU?t=48m55s) with an [accompanying blog post](https://snarky.ca/setting-expectations-for-open-source-participation/) all about setting expectations for open source participation, I felt it was time to do another blog post to directly address the issue of entitlement by some open source users which is hurting open source, both for themselves and for others. I want to get the point across that open source maintainers owe you quite literally nothing when it comes to their open source code, and treating them poorly is unethical. And to me, this is the underlying *social contract of open source*. If you prefer to listen to me discuss this topic, I spoke about it [on the Changelog](https://changelog.com/podcast/444) podcast (audio embed at the end of the post). ### The legal contract Let's start with what open source software *is*. To me, > Open source software is **source code** that is licensed in such a way that **I can use it for free**. Do open source projects that produce open source code *need* to provide anything beyond this? I say **no**: open source software starts and stops with the software and its license. But what if you want to have a more social aspect to your open source project and somehow be reachable by users? In that case I believe there's a bit more to be expected in the exchange and it mostly revolves around treating each other like human beings. ### What is the relationship between a maintainer and user? To set the stage, I think it's important to establish what the relationship is between me as a maintainer and you as a user. I have been trying to come up with a real world example that maps well, and the best I have come up with is, > Open source code is like me putting a stack of USB drives with my open source code on them on my front lawn with a sign that says "FREE", and you coming by and taking a USB drive when you want the latest copy of my open source code. That's the actual, typical relationship I have with most users of my open source code: I push out a new commit, you use it, and we never speak to each other. With this example in mind, do you think it is reasonable to go up to my front door, knock, and then proceed to yell at me if you didn't like the software you chose to pick up off of my front yard for free? 🤨 How about leaving an angry letter in my mailbox? Or a flaming bag of 💩 on my doorstep? Or standing in the middle of the street in my town and yelling about how much you hate my software? This is what it's like when you email me angrily, open an issue in anger, or complain loudly on the internet. Does any of that seem reasonable? To me, this actually ranges from rude to unethical. Remember that I didn't force you to take the software. The act of taking the software was done under free agency, so getting mad about the **free** gift of some open source code that you chose to take seems to be more your own problem than mine; you are totally capable of using that free agency again and stop using the source code. This is equivalent to me giving you a free ice cream, licking it, not liking the flavour, and then proceeding to scream that the free ice cream is horrible because you don't like it. Doesn't seem like a reasonable response to something you chose to pick up for free and try, does it? Now this isn't to say you can't give constructive criticism or say why something didn't work for you. But if you saw someone walk up to me and begin berating me over some free ice cream would you view that as acceptable or unreasonable? There's a big difference between, "this isn't for me", and, "this is utter trash and you should be ashamed of the job that you have done" or "you had cookies & cream ice cream yesterday, why don't you have it today?!?" ### The categorical imperative You may have noticed I used a rather strong word earlier to label folks who abuse maintainers: *unethical*. That was very much on purpose. I actually have a bachelors degree in philosophy, and in reflecting on the idea of users chastising maintainers simply because they don't like something made me have an epiphany grounded in moral philosophy. The philosopher [Immanuel Kant](https://en.wikipedia.org/wiki/Immanuel_Kant) had a moral philosophy system known as the *[categorical imperative](https://en.wikipedia.org/wiki/Categorical_imperative).* A key tenant of Kant's moral philosophy is summed up by the following from his work, **Groundwork of the Metaphysic*s *of Morals**: > Act in such a way that you treat humanity, whether in your own person or in the person of any other, never merely as a means to an end, but always at the same time as an end. Let's tease apart what is meant here by "means to an end" and "as an end". In the former case, using something as a "means to an end" is basically what it sounds like: using something in order to get something else. This could be something like I'm going to perform some action *as a means* to getting something specific out of it in the end. As for "as an end", that is the concept of simply not using someone for an expected outcome. For instance, chances are the people in your life who are your friends not so because you expect to use them to get something, but because you simply like them for who they are. You are treating them *as an end* in and of themselves because you are not spending time with them with expectations you will get something specific in the end. How does this play into open source? When you treat a maintainer as a means to getting something from their software you are not morally treating them appropriately as an end (in other words, you're simply *using* them), and thus not treating them morally as a human being. But when you treat a maintainer as a fellow human being who may be able to do you a favour of their own volition, then you end up in an appropriate relationship where you are not trying to *use* the maintainer for something specific. ### An example Let's expand on this free USB drive example and say that some of my C code *happens* to work with the [Alpha chipset](https://en.wikipedia.org/wiki/DEC_Alpha) (which happened to be discontinued in April 2007; 14 years ago as I write this). You use my software and you like it, so you keep using it. Then one day I inadvertently stop supporting Alpha because I want to use [Rust](https://www.rust-lang.org/) to be more productive, secure, and generally just happier when I write such low-level code than coding in C (yes, I'm a fan of Rust 😁). Do you think it's reasonable to get mad at me just because I changed the software such that you can't use it anymore? Remember you have been coming to my front yard to pick up a USB drive every time I make a change; I didn't ask you to use my software. I'm the one doing all the work here in producing this open source code and I don't find supporting Alpha useful anymore, so why is it in any way reasonable to be mad at me for "dropping" Alpha support? To me, it feels like if you get mad at me for no longer supporting some platform that is treating me as a means to an end for getting to use *my* software instead of as an end in and of myself. If you treated me as a human being you might ask if I would reconsider, but if I said "no" you would accept that and move on instead of getting mad at me. To make this real for people, this entire scenario involving Alpha and Rust is based on an actual event in the Python community where a project got severely yelled at by some users who support Alpha and various other esoteric platforms because the project added Rust code to their project for Rust's security benefits (and for a project whose sole purpose is security, by the way). ### How bad actors ruin things for you **and** themselves The really sad thing in all of this is that those people who decide that yelling is acceptable and treat maintainers as a means to an end are actually hurting you as much as they are hurting themselves. Burnout for open source maintainers is a real problem. If someone constantly wrote you hate mail for some USB drives you left on your front yard you wouldn't want to bother putting things on your front yard anymore either. Every time an open source maintainer gets yelled at, the closer they are to doing something that makes things worse off for you. There are levels to the ramifications (which are all ultimately reasonable since they are up to the maintainer to do what they want with their open source code). The most common one is open source code becomes less considerate of others' needs and more opinionated and focused on what the maintainer wants. That is reasonable, but it does mean someone's open source code has less of a chance of being useful to you since the focus is narrowed. Probably next is having [open source code but not open participation](https://github.com/benbjohnson/litestream#open-source-not-open-contribution). This is when you're happy to share your open source code with others but you simply don't want the hassle of something like pull requests. This is very much like opinionated open source code, but now you're really at the mercy of the maintainer to implement it. After this it's abandoning the project. The issue tracker is still open so people can collect issues with the open source code, maybe even coordinate on patches or a fork, but the maintainer is gone and the commits have ceased. Next up is locking down the project. Now it's just an archive of a project and all you get is what's already there. Lastly, there's full-on deletion. No more repository with releases yanked from PyPI; if you didn't keep your own copy of the open source code then it's gone forever for you. All of this is what makes it frustrating when bad actors "get" what they want because they only sort of do. While some specific feature or bug fix might go in, they still pushed the maintainer closer to burnout due to their actions. That could lead to the project being eventually shut down which is likely worse than that single feature or bug fix the harasser wanted. And it all sucks for you, too. This is why I try not to stand by when a maintainer is receiving abuse since there are impacts much wider than the single bad interaction. I'm not condoning stooping to the level of the person who's mistreating the maintainer to get them to go away, but stepping in and trying to defuse the situation and stick up for the maintainer is something I wish more people did (as well as simply banishing bad actors from their projects). ### View every commit as a gift If you wanted a short, concise point from all of this, > Every commit of open source code should be viewed as an independent gift from the maintainer that they happened to leave on their front yard for others to enjoy if they so desire; treating them as a means to and end for their open source code is unethical. There should be no expectations toward the next commit, next release, etc. when you realize open source maintainers really don't owe you anything. If you view open source code from that perspective then you will view it as a gift when it exists at all. As such, hopefully you feel less frustrated when open source doesn't go the way you want since it was all a gift to begin with. And that then will lead you to treat maintainers as an end in and of themselves and thus as a fellow human being. [](https://changelog.com/podcast/444), The Social Contract of Open Source, Tall, Snarky Canadian, 01h55702852dn524zjrzah3p5z.