---
title: "Who Is Open Source About?"
slug: who-is-open-source-about
url: https://listedarticles.com/articles/who-is-open-source-about
canonical_url: https://blog.glyph.im/2026/09/who-is-open-source-about.html
content_type: essay
language: en
published_at: 2026-09-24T00:00:00.000Z
updated_at: 2026-09-25T09:17:07.367Z
author: "Glyph Lefkowitz"
author_url: https://blog.glyph.im/
authored_by: human
publisher: "Deciphering Glyph"
publisher_url: https://blog.glyph.im/
topics: ["Open Source", "Opinion", "Culture", "Programming"]
license: all-rights-reserved
word_count: 5200
reading_minutes: 23
citation: "Glyph Lefkowitz, Deciphering Glyph. \"Who Is Open Source About?.\" 24 Sept 2026. https://blog.glyph.im/2026/09/who-is-open-source-about.html (all-rights-reserved)"
# The full text follows. The web page shows an extract and sends readers
# to the source above; quote the citation and link the canonical URL.
---
# Who Is Open Source About?
> Glyph Lefkowitz argues open source is a web of ongoing relationships—not a one-way gift from maintainers to users—and asks who the community is really for.
# Who Is Open Source About?
Open source is, at least in part, **about *you***, where “you” refers to the
user.
## Open Source Is Not About “Open Source Is Not About You”
In other words: Rich Hickey was wrong when he wrote “Open Source Is Not About You” and I’m tired of pretending otherwise.
Of course he’s not *completely* wrong, or his famous post would not have
resonated quite so much in the first place. Obnoxious users who demand their
*personal* use-cases be immediately addressed by volunteer maintainers for free
should indeed be viewed as the pariahs that they are. Similarly, corporate
users who want free support from the community that supplies their
infrastructure to lower their costs. As should those who
profit
from this type of externalization by their own customers.
But the exchange of “open source” (or even “free software”) is not as simple as “I have prepared some software for you, please enjoy it, you have no right to complain”, and maintainers ought to have a precise understanding of the costs and benefits — as well as the ethical implications — of that exchange.
Right now we barely even articulate that the exchange *exists*, let alone that
it establishes a long-term, subtle, and implicit relationship between
maintainer and user.
Let’s fix that.
### A Brief Aside about Meta-Ethics
When we talk about “obligations” and “rights”, of “shoulds” and “musts”, we are
constructing an ethical system. The *purpose* of such a system is to develop
social expectations and social consequences. There is not much use in me
telling you that you are *transcendentally evil* for failing to follow some
arbitrary recommendation that I have. But I am implying that I believe there
should be consequences for your behavior. I am also implying that there
probably already *are* some consequences, and they’re just not written down
anywhere yet.
Therefore, a post like this, where I say that we *should* view our social
obligations in a certain way, that is the *beginning* of a broader social
conversation. I think there should be some consequences, so I am gesturing
towards that possibility. Exactly what consequences?
For now, I’m not sure. Let’s figure it out.
## What Are We Doing When We Do An Open Source?
Hickey, and his many acolytes in the years since his fateful post, asserts that the process of “open source” goes like this:
1. Maintainer makes a thing, and makes it available to users as a gift.
1. Maintainer may “love working with the team”.
2. Maintainer may be “proud of the work we do”.
2. Users accept the gift, and extract utility from it.
1. (Users MUST be grateful for this.)
3. A tiny fraction of users reciprocally contribute to the thing.
1. (Maintainers may be grateful for this.)
He makes various oblique references to the specific activities of his company,
which does things vaguely related to his projects for money1. These
activities are exclusively characterized as for “customers”, however, a subset
of the aforementioned users so tiny (“fewer than 1%”) as to nearly be an
entirely distinct group.
Breezing past this process in an essay about obnoxious users demanding things they are not entitled to, one might nod along, as this sounds mostly sensible. Giving gifts is nice. I too love working with good teams and taking pride in things.
Examined more closely, however, it starts to logically fall apart. If you have
consulting clients and that’s where all of your money is coming from, why are
you *bothering* (as he repeatedly insists) “doing [things] for the community”?
What was the point of releasing this code in the first place? You could love
working with your team and be proud of the work that you do in a lot of
different contexts; why bother implicating this horde of entitled and obnoxious
people, if that’s all you’re getting out of it? *What’s in it for you?*
If we’ve left out something as fundamental as “why is the maintainer doing
this”, perhaps this story leaves out some *other* important bits as well.
## Why Are You Doing This?
There are *many* possible motivations for releasing and maintaining open source
software. They are often subtle, often overlapping, and rarely clearly stated.
Maintainers are not a monolith and not everyone does it for similar reasons.
But let’s review a few reasons that someone might want to contribute.
### Reputation
One reason that you might want to release some open source software is
*advertising*. The most common form of this is self-promotion; if you are a
visible, prominent contributor to an open source project, it stands to reason
that you will have an easier time finding work in the domain of that project.
If you operate a consultancy, as Rich Hickey did at the time of his famous rant, then this reputational currency translates into advertising for your services. It’s a practical demonstration of the skills of your team.
The trade in this benefit is most like the traditional “gift economy” that open source has been compared to. You give the code to your users, which has some value, but the users give you back some reputation, in the form of their attention, their esteem, and possibly even their money if they become customers or employers.
### Influence
Infrastructure is the most popular type of open source for a good reason. Programmers working on a problem are often hemmed in by sclerotic architectural choices which prevent them from solving problems in the way that they’d prefer to solve them. Major infrastructural investments are difficult to justify in a planning process, as their benefits are hard to prove. Sometimes the benefits are highly personal; different engineers have different aesthetic preferences about what types of equally-valid solutions they’d prefer to work with.
If you can develop your preferred type of solution and release it as open
source, then you can influence *how* everyone else solves this type of problem.
As an individual, such a position of influence can allow you to have some
transferable expertise between employers. You know how to use the tool you
developed, so you can be very quick and effective with it, and you can shape it
to your ongoing taste over time.
If you’re an employer, and you can get everyone *else* to use your open source
thing2, this can reduce *both* your hiring and training costs. Potential
employees can read the code, see that it’s good, and want to work at a place
that produces good code like that. They can also read the code and become
familiar with it in advance of coming to work for you, which means that you
have a ready supply of developers who already know how your internal systems work.
The trade in this benefit is more like “soft power” than a gift economy. You give the code to your users, which has some value, but the users give you back the ability to dictate their technological agenda. You gain both the ability to influence their initial direction, and, as part of ongoing maintenance, to dictate their behavior over time.
### Improvement
As an engineer, you might want to improve your own skills. Writing something proprietary and commercial cuts against this in two ways.
First, you will want to build something that already exists within your skill set, so that it will attract commercial interest and actually be competitive. Within the context of a larger team, you will want to personally be able to be immediately effective for similar reasons. But you still need a way to learn new things.
Second, you will want to build something somewhat secretively, so that the value you are producing is captured rather than released to the community. This means that you will be cut off from external sources of expert feedback.
As an organization, you might want to build the skills of your staff in similar ways.
The trade in this benefit is code for knowledge. You release the code or changes, and in return you expect your users to provide you good bug reports, and to induce at least some of them to become co-developers.
### Outsourcing
As an engineer, you can only do so much on your own. Perhaps you want to have
some influence over your infrastructure so you want to write it, but you also
want to have a communal place to keep your infrastructure such that you can
*make* a change to something to suit your needs, but you know that even if you
walk away, someone else will *maintain* that change and keep it working across years or even decades of changes to underlying platforms, hardware, etc.
This sort of communal maintenance effort can be shared among all interested
participants; if a thousand companies all need the same tool, if even a few
dozen can share it, that reduces even their *own* load massively, let alone
everyone else’s.
The trade in this benefit is more complex, since there’s less symmetry between
the main maintainer and peripheral community members who also contribute code.
The main maintainer is actually trading a *namespace*, a central place for
people to contribute, coordinate, and release changes, rather than the *code*.
They are a sort of market maker where then all the other contributors trade
code *for* code within that market-ish structure.
In practice, this motivation produces a game theory
problem where, when
maintenance drops below a critical threshold, it creates a big enough
crisis that at least *some*
freeloading stakeholders will be forced to start making contributions.
Ultimately, however, this saves *all* involved parties a ton on maintenance,
more eager volunteers who do not freeload in the first place get all the other
benefits mentioned above as well.
### A Brief Aside about your Chart of Accounts
Most companies account for open source maintenance work as simple overhead on ongoing projects. Sometimes it’s CapEx, sometimes it’s OpEx, but it’s just “whoever happens to be working on this thing to support whatever random product it’s a part of”.
This type of accounting creates distorting incentives, because it doesn’t recognize all the benefits above. Under such a fiscal regime, ongoing healthy maintenance becomes a ZIRP because when resources are more constrained, this apparent indulgence gets corrected.
The ancillary benefits that open source creates ought to be properly
recognized. It shouldn’t just be buried as Wages or IT or whatever. If it’s
helping you hire better engineers, some of that expense should be allocated to
Recruitment Costs. If it’s materially improving your reputation among your
customer base, some of it should go to Goodwill. If it’s getting your product
in front of developers who are your customers, it should be in Marketing. Most
importantly, if maintenance on an open source project is actually helping you
maintain your enterprise-wide platform, it should not be squirreled away in
some small team who happened to be the first one to adopt it.3
Exactly how these costs should be allocated and cross-charged to different departments depends heavily upon your organization and your specific chart of accounts. But “whatever, it’s just part of the software product” or “I guess it’s DevRel because the SDK is in there” is guaranteed to have your open source organization destroyed along with all those side-benefits the next time that there’s a cash crunch.
## The Things that Aren’t Supposed To Be Benefits
These categories *could* be made as explicit, rational trade-offs, even if they
are often implicit and subtle in practice. They are transactions where the
maintainer gets something and the user gets something.
However, not everything that you are getting as a maintainer is something you
are actually *supposed to use* to your own benefit. Being given trust in
service of a responsibility is not a transaction.
### “Oops, All Root Shells”
Open source code *is code*. In our modern world of absolutely pathetic
sandboxing,
installing code from somebody else gives them control over your system, even if
it is somewhat indirect.
There is an unwritten rule that if I create an open source library, and you use
it, it probably *shouldn’t* have a backdoor in it that gives me the credentials
to your bank account. There is a trust relationship between the user and the
maintainer, and here, we see the first *obligation* that the maintainer has.
The maintainer is obligated *not to use the user’s computer for their own
gain*.
This rule might seem obvious and straightforward. It might even seem unfair to
you that I call the rule “unwritten”, because the rule *is*, in fact, written
down in a few places: for example, in the npm Acceptable Content
Policy,
it says right there:
A few examples of unacceptable content:
…
- Content containing malicious computer code, such as computer viruses, computer worms, rootkits, back doors, or spyware. This includes content submitted for research purposes. Tools designed and documented explicitly to assist in security research are acceptable, but exploits and malware that use the npm registry as a deployment or delivery vector are not.
I think we can all agree that a script which steals your bank credentials and sends them to me to buy a totally sick jet ski would qualify as “malware”, so clearly that is forbidden.
There is also an enormous gray area here. npm also explicitly *allows*
“Information on how to pay, donate to, and otherwise support Package
development”, but then goes on to explicitly *forbid* “Packages that display
ads at runtime, on installation, or at other stages of the software development
lifecycle, such as via npm scripts.”4 How are the lines drawn around these
gray areas? “npm will continue to apply its judgment when deciding what
content is acceptable.”
But also... this is forbidden *by npm*, not by the transcendental nature of
“open source”. I could give away code that displays all kinds of ads to its
users as a “gift” on my website. The exact structure of this policy is not
uncommon, but it also isn’t exactly the same as other such sites. PyPI, for
example,
explicitly bans “cryptocurrency mining”, which NPM does not. Is cryptocurrency
mining “not open source”? A lot of judgement calls are happening here about
what is allowable in these “gifts” that you are giving to your users.
But I digress.
My point is that policy-making around this concept is not clear, there are lots
of little disagreements around the edges, but there is a very strong consensus
that while the user is giving you their trust here, that is **not a trade**.
The deal is not “you give the user some code, the user gives you unlimited
compute and access to all their financial accounts”. The user has made
themselves vulnerable to your code on the strength of your reputation.
This creates an obligation for you to not do anything evil with that code, either intentionally or through negligence.
#### Security Updates Are Just Command And Control In A Funny Hat
All of this is just about the initial download of some code, and that is the way that Rich Hickey describes it, as if you just grabbed some code off a web page and put it in a folder that you like on your desktop. But that is not how open source relationships work today, if indeed it ever was.
The way it works today is that you add a dependency to your `pyproject.toml` or
your `package.json` or your `Cargo.toml` and now your users are vulnerable not
just to whatever you happened to upload in the first place, but to *whoever
happens to have your package index credentials*.
This creates an obligation to maintain an operational security posture that protects your users from malicious updates.
### The Roadmap Is Someone’s Life
Another kind of trust that the user is placing in you is the trust that you are
going to have at least *some* kind of regard for their usage of your software.
In a perfect world, the user’s expectations could be clearly circumscribed. Whatever ongoing maintenance you commit to perform would be encapsulated in clear policies that you’d write up in advance, about exactly what kind of security response policy you have, how you will communicate when you no longer have the resources for maintenance, and so on.
But anyone who has been involved in any project at anything but the most extreme tier of operational maturity knows that 99% of the ecosystem relies on a set of loose conventions around how all that stuff works. We expect that maintainers will generally be around, that they’ll use existing tools like an issue tracker for triaging user bugs, GHSA and CVEs for security reporting, that they will mark the project as “archived” and maybe do a final release before abandoning it, that they will maintain a ChangeLog explaining at least a little bit of what is going on.
Users assume that those conventions will be followed when there are any gaps in
explicit policy, or indeed if policy is lacking entirely. This assumption is
reasonable, because otherwise nobody could ever *use* any open source without a
stack of service contracts that nobody has any time to write.
The strongest such convention is that an actively maintained program will, at
least, more or less *keep doing what it does* as time goes on. A user who has
elected to use a bit of open source software has made themselves vulnerable to
changes and breakages in that software by the mere fact of using it. In the
time that they have used it and invested in it, they have *not* invested in:
- *creating* alternative software to meet their needs,
- *maintaining data* in formats that other software can read, or
- *learning how to use* existing alternative software.
This can, and does, go badly wrong, when those expectations are mismatched.
#### How It Goes Wrong
Let’s say a maintainer creates an open source paint program, OpenPaint.
An artist, known for their unique style of making blended collages, switches from their previous app, ProprietaryPaint, to this new OpenPaint to make these culturally significant works of art. However, the maintainer decides that the ‘blend’ tool is kind of a pain to maintain, and they remove it in OpenPaint 2.
A few months later, the artist’s operating system vendor issues a security update that breaks OpenPaint, because older versions of OpenPaint were unknowingly abusing some platform API.
The maintainer releases a new OpenPaint 2.0.1 that addresses this incompatibility, but doesn’t care about version 1.x any more so they don’t bother to update that one.
This places the artist in an impossible situation. They can stay on an old version of their operating system, putting all their personal data at risk. Or they can upgrade to the new operating system, effectively either cutting off access to their livelihood, or forcing them to change their art style entirely.
Now, proprietary software can place users in similarly untenable positions (and
in fact, it is *more often* proprietary software that does). But does the
openness completely remove *any* obligation for this consideration? Should
the OpenPaint team have to at least *communicate* the reasons for doing this,
to give the artist some recourse?5
The only thing that “open source” does is that it allows the artist to pay a prohibitive amount of money to a new maintenance team to create a fork. This is rarely the kind of thing that individuals can manage.
This creates an obligation to *at least consider how your users might be
relying on you*.
This is the most complex obligation of the bunch. Obviously it does not
entitle every single user to infinite work from the maintainer, but it also
shouldn’t entitle the user to *nothing* for having trusted these subtle implied
claims that the maintainer is making by making their work public.
It is a nuanced and ongoing negotiation and I do not think we have a clear moral intuition about how it should work out. But we do need to figure out a way to work it out.
It also raises a clarifying question.
## Why Are We Even Doing This, and Who Are We Doing It For?
People generally like to do things for more than one reason. We live in an economy where people need to make money, but we mostly prefer to make that money doing things that are useful, and that make other people happy.
So, yes, we create open source for self-interested reasons to improve our
reputations, to improve our skills, to increase our influence and to share our
maintenance burdens. In so doing we take on *some* level of obligation to not
abuse the trust that is placed in us, even if that level of obligation is not
clear.
But if we are not doing it to *serve* those users at least a *little* bit, then
those motivations are going to quickly ring hollow. We will not increase our
reputation with a person if we respond to their every request by telling them
that we owe them nothing and that their opinions are worthless. We will not
gain influence over a community if we ignore their desires.
Many interactions with open source maintainers are unnecessarily adversarial. This is of course partially the fault of those users, who should calibrate their expectations appropriately.
Still: maintainers could do a better job of listening *before* these
interactions become toxic. There’s no reason that “open source users” should
be an especially toxic group of people. At this point in history, that group
is basically just … people with computers.
It’s like that old truism. If you meet one person who is a jerk to you, that’s their problem. But if everyone you meet, everywhere you go, is constantly abrasive to you and treats you like you’re doing something wrong, maybe it’s time to look inward.
If all open source users are entitled assholes, maybe it’s time to look for a structural problem.
### Surprise, It’s About AI Again
Sigh.6
*Users* *hate* *slop.*
I know, dear AI-positive reader, *your* AI outputs are different from everyone
else’s, *you* aren’t pushing thoughtless slop into your code, just because
everyone else is and it is the inevitable terminus of using those tools. You
aren’t “lazy vibe coding” with Claude, you’re doing “responsible agentic
engineering”, which is different because you’re just built different.
Still, humor me, for a moment. Your *users* don’t know that. They know what
it looks like when products that they like adopt slop. They know that they
will start leaking
data.
Developers know that it will make them personally less
secure.
They know that they can expect more
outages
and that your code will inexorably decline in
quality.
In other words, your users are going to assume that this means you are
violating that final obligation that the software should *keep working*.
Your users are going to tell you to stop, and they are probably going to get
mad. Maybe you, or a plurality of your team, *also* want to stop, maybe you
disagree with them, but in any case you need some way to *have that
conversation* in a way that does not immediately overflow into every adjacent
discussion forum. Users need to feel welcome in some space so they can have
the discussion *in* that space, and not explode out into a thousand different
group chats and social media threads.
*This* post was inspired by yet another prominent open source community
discourse where a ton of angry users showed up to yell at developers to stop
accepting LLM-generated code. I’m not going to link to any of these, because
we don’t need any more fuel for the discourse fire. But there is more than one
such case and the pattern is becoming familiar.
On social media - usually BlueSky or Mastodon, but sometimes a user group
forum - users become aware of some AI-adjacent policy. They show up in a horde
to the developer forum or mailing list. They loudly start demanding the
project take a hard stand7 against AI. This pressure is simultaneous, but
uncoordinated; extremely repetitive, very diverse, often inconsistent, and
pretty stressful, especially if you’re a burnt-out maintainer with other things
to be doing who may not even like AI yourself in the first place.
Believe me, I get it. It can be very unpleasant to deal with.
Like most problems that AI is causing, though, it’s not really an “AI” problem
as much as it is a pre-existing dumpster fire that “AI” is pouring gasoline
onto. In this case, an online mob is the language of the unheard8.
## If Users Are Mad It’s Probably Already Too Late (But Maybe You Can Get Ready For Next Time)
One day, all of a sudden, you’re getting feedback from a bunch of users that
are using inappropriate channels to complain. But did they already have
*appropriate* channels to use?
Did you have a place for people to congregate and discuss your project? To make orderly complaints in a way that will be legible to you? Or do you just have a GitHub Issues page, which non-technical users have no idea how to interact with, and a forum for developers, where users don’t know the norms and any arriving brigade of pissed-off users will be seen as disruptive and inappropriate?
I don’t want to be throwing any stones from within my particular glass house. Setting up such a place has gotten harder over the years. I don’t really have one, either.
*Could* I have one, though? IRC has been slowly dying, mailing lists are
unpopular and present increasingly annoying moderation challenges, forum
software is expensive to operate and keep maintained, Discord is a confusing
mess and the upshot of all of this is every community needs community
management and forum moderation. Which means that for my own small solo
projects, I couldn’t possibly have such infrastructure because such
infrastructure requires a *dedicated second person* to maintain it, and until
someone volunteers for that, it’s not really feasible. Even for my larger
projects you’d be surprised how slim of a skeleton crew
we are getting by with, and we definitely don’t have a whole spare maintainer
to go manage this, especially as we are under attack from the slopocalypse
ourselves.
The nature of open source community is that most communities start too small to
need such a thing, grow incrementally until one day they are suddenly *way* too
big and needed one yesterday, and then suddenly they are too small again when
interest wanes even a little bit. Even as we need it more and more, building
and maintaining community infrastructure remains a challenge.
Even so, having a dedicated place for *users* — not maintainers — to converse
amongst themselves, be an actual community, and present feedback to the
developers, is fast becoming a necessary component of a successful community
and not a nice-to-have.
## In Conclusion
As trying as it can be sometimes, we maintainers all do get something out of
open source, and it is good to be honest with your users — and with yourself —
exactly *what* you want to get out of it. In order to know whether the juice
is worth the
squeeze, we
must know both what the juice is, *and* what the squeeze is.
Part of the metaphorical squeeze *is* a set of obligations, and those are the
most poorly defined of all. We should try to be clear about what those are
too. Both about exactly what we believe we are signing up for, and also, about
how we are willing to let our users hold us to account for them. Codes of
conduct are a start here, but only the absolute barest bare minimum; “do not
harass your colleagues or your users” is not a standard of excellence to aspire
to, it’s just basic manners.
I can’t tell you exactly what your obligations are, only try to gesture at my idea of the outlines of the fuzzy moral intuition we’ve all been implicitly sharing up until now.
Drawing this line is not just for the benefit of the users, either.
Maintainers already feel pressure, we already feel obligations. We *resent*
that feeling of obligation. While there are a diverse array of reasons for that
resentment, one big one is that it’s not clear, even to ourselves *where the
obligations end*. Lashing out by saying “I promised nothing and I owe you
nothing!” followed by some choice expletives feels cathartic, but it doesn’t
really solve the problem, because we clearly don’t really believe that’s where
the line is, or we would have already stopped there. We wouldn’t feel the need
to say it.
It is going to be a very big collective endeavor to figure out exactly where that line is. The best time to have gotten started on that endeavor was 50 years ago.
But the second best time is today.
## Acknowledgments
Thank you to my patrons who are supporting my writing on
this blog. If you like what you’ve read here and you’d like to read more of
it, or you’d like to support my various open-source
endeavors, you can support my work as a
sponsor!9
1.
Somewhat to everyone’s surprise, I, too, do things for money, like writing this post. Please remember to like and subscribe ↩
2.
Whether it was originally yours, or developed by an employee who happened to be on staff at the time, or adopted by an employee who just started contributing to it a lot, in any of these scenarios a company can benefit from increased consistency and increased familiarity. ↩
3.
If the rule is that they must forever endure the searing budgetary pain of gripping the white-hot potato that they unwittingly caught when they first made a good technical choice, this creates a perverse long-term incentive. ↩
4.
I also find it darkly amusing that there is an explicit affordance here made for advertising, specifically, “Packages with code that can be used to display ads are fine. Packages that themselves display ads are not.” This distinction rather gives the game away, that this is a website for carnies and not for marks, and that at some level we expect our users to deserve a lower level of respect than ourselves. But a full exploration of that is another blog post, or maybe a book, that I don’t have time to write right now. ↩
5.
If you want the turbocharged ultra-dramatic version of this problem, make it open source drivers for an optical prosthesis that lets the users *see* instead of an art app. That level of immediate physical dependency could
be clarifying. It does also start to edge into an area where you could say
that biomedical devices ought to be regulated differently, and that’s not
really a “software” problem but a “healthcare” problem and I’d mostly
agree. Except for the fact that this is a*very* short distance away from
breaking everyone’s screen-reader with no notice or
recourse. ↩
6.
Did you believe I could write a blog post in 2026 which wasn’t somehow about AI? I wish I could still believe that. ↩
7.
It doesn’t help that many of the most pro-AI voices are starting to have an, ahem, discernible political valence that is very unpopular among users. ↩
8.
My apologies to MLK. ↩
9.
If you read this whole post you can see that I sure need the help with all that. ↩