So is somebody who publishes code, uses OSD-compliant licenses etc etc but doesn't care about users or community or whatever "not doing OSS" (just using its toolset), or "doing it wrong", or "out of scope for this piece of text"?
I think a charitable reading of the article is that if a developer is at all interested in the personal benefits of producing open source software (reputation, influence, help with maintenance), then they are in effect proposing a transaction with any potential users, one that involves some obligation on the part of the developer.
I think this is a useful lens to see why users can feel invested in a project, and why users get angry when projects behave in certain ways (license changes, AI usage, telemetry, etc.)
But I also think that the article starts out a bit clickbaity by claiming that "open source" is one thing, when in usage people use it to mean development processes, communities, and licenses and are often totally unclear about what context they're using the term.
I'm with the author on this, but at the same time I recognise this can be a recipe for burnout. And if I follow that thought to where it leads, I'm with Rich Hickey because nothing is worth sacrificing your mental health for, especially not an unpaid hobby.
Perhaps a good middle ground is to clearly communicate when you are unable/unwilling to keep up with the project so that users know what they can expect, and plan for it.
I'm with Rich Hickey because nothing is worth sacrificing your mental health for, especially not an unpaid hobby.
Perhaps a good middle ground is to clearly communicate when you are unable/unwilling to keep up with the project so that users know what they can expect, and plan for it.
Or communicate that you intend to continue develop it in ways that you want, and you aren't interested in what anyone else thinks.
I was heavily involved in the Clojure community and tried to contribute to the Clojure project before giving up in frustration, so I have some context here. Communicating this stance earlier is exactly the kind of thing which would have avoided conflict and burnout. It's a somewhat reasonable stance to have if you are up front about why you're working on the project.
Rich didn't do that; he went out of his way to ask the community what they were interested in. At the time the overwhelming response was "we want you to move to github" which resulted in a rather funny outcome; the community meant "we want to make pull requests to Clojure" but Rich interpreted it as "please switch hosting platforms without changing anything else about your development process", so ... well, you can imagine how that went.
Yeah, I think the main thing that gets people talking past each other is that there is, for better or worse, an implicit set of social expectations about what "open source" means, specifically that an "open source" project is open to feedback and collaboration and contribution unless that project says otherwise.
And while, yes, someone will always come out of the woodwork to quote license terms and say nothing was promised, the community also has a history of deriding big corps who just lob a tarball at the public as not really being "open source", precisely because of how many people implicitly believe "open source" means two-way or multi-way collaboration.
So a lot of this can be avoided by just setting clear expectations up-front when releasing a project (and again, merely using a license with a warranty disclaimer is not the same thing as setting clear expectations, because every open-source license has such a disclaimer in it, and many projects still are very much open to collaboration and contributions). If someone truly wants to just throw some code somewhere and say "it is what it is, take it or leave it", they're welcome to do so; I just would like them to make clear that's what they're doing.
Ohhh yes! I thought the article was going to be siding with entitled users(it doesn't), but it raises really good points(and the comments here as well) and I think you are wording it very nicely.
Even though good communication is hard to do, it's important to set those expectations.
Also, maybe a factor in how people perceive OSS, the entitled/jerk-y users low effort comments sting a lot more than the good interactions I've read(no matter how tiny the project).
I would say that the article convincingly presents an argument that any small project should be very clear what kind of contributions are welcome, and that the project is the project of and for those who make such contributions (which might be just the sole author, but might be open to change).
Any arguments about needing community of users to be a thing seem stretched. Like the reputation argument: I might want reputation just among people who can reasonably fork and do a fine job maintaining it, this really changes the dynamics for the users I actually want to have!
(And yes, there are open-source projects that are both abandoned and make me grateful, because I can fix myself enough to keep using them, if any fixes are needed)
But does the openness completely remove any obligation for this consideration?
Yes! I don't think any user of an Free (as in beer) application can impose any obligations on the developer, at all. They gave you something for free, and if you don't like it, you should stop using it. You have no right to impose an obligation on someone giving you something for free.
Yeah, this is a great article, but all the arguments have an implied "if you publish open source that you encourage others to use" instead of "if you publish open source". In the case of the piece he's arguing against, it's absolutely still relevant since there was plenty of "you should use this" going on, but there are exceptions.
pgeorgi | 12 hours ago
So is somebody who publishes code, uses OSD-compliant licenses etc etc but doesn't care about users or community or whatever "not doing OSS" (just using its toolset), or "doing it wrong", or "out of scope for this piece of text"?
henderson | 2 hours ago
I think a charitable reading of the article is that if a developer is at all interested in the personal benefits of producing open source software (reputation, influence, help with maintenance), then they are in effect proposing a transaction with any potential users, one that involves some obligation on the part of the developer.
I think this is a useful lens to see why users can feel invested in a project, and why users get angry when projects behave in certain ways (license changes, AI usage, telemetry, etc.)
But I also think that the article starts out a bit clickbaity by claiming that "open source" is one thing, when in usage people use it to mean development processes, communities, and licenses and are often totally unclear about what context they're using the term.
sjamaan | 9 hours ago
I'm with the author on this, but at the same time I recognise this can be a recipe for burnout. And if I follow that thought to where it leads, I'm with Rich Hickey because nothing is worth sacrificing your mental health for, especially not an unpaid hobby.
Perhaps a good middle ground is to clearly communicate when you are unable/unwilling to keep up with the project so that users know what they can expect, and plan for it.
technomancy | 9 hours ago
Or communicate that you intend to continue develop it in ways that you want, and you aren't interested in what anyone else thinks.
I was heavily involved in the Clojure community and tried to contribute to the Clojure project before giving up in frustration, so I have some context here. Communicating this stance earlier is exactly the kind of thing which would have avoided conflict and burnout. It's a somewhat reasonable stance to have if you are up front about why you're working on the project.
Rich didn't do that; he went out of his way to ask the community what they were interested in. At the time the overwhelming response was "we want you to move to github" which resulted in a rather funny outcome; the community meant "we want to make pull requests to Clojure" but Rich interpreted it as "please switch hosting platforms without changing anything else about your development process", so ... well, you can imagine how that went.
ubernostrum | an hour ago
Yeah, I think the main thing that gets people talking past each other is that there is, for better or worse, an implicit set of social expectations about what "open source" means, specifically that an "open source" project is open to feedback and collaboration and contribution unless that project says otherwise.
And while, yes, someone will always come out of the woodwork to quote license terms and say nothing was promised, the community also has a history of deriding big corps who just lob a tarball at the public as not really being "open source", precisely because of how many people implicitly believe "open source" means two-way or multi-way collaboration.
So a lot of this can be avoided by just setting clear expectations up-front when releasing a project (and again, merely using a license with a warranty disclaimer is not the same thing as setting clear expectations, because every open-source license has such a disclaimer in it, and many projects still are very much open to collaboration and contributions). If someone truly wants to just throw some code somewhere and say "it is what it is, take it or leave it", they're welcome to do so; I just would like them to make clear that's what they're doing.
zetashift | an hour ago
Ohhh yes! I thought the article was going to be siding with entitled users(it doesn't), but it raises really good points(and the comments here as well) and I think you are wording it very nicely.
Even though good communication is hard to do, it's important to set those expectations.
Also, maybe a factor in how people perceive OSS, the entitled/jerk-y users low effort comments sting a lot more than the good interactions I've read(no matter how tiny the project).
k749gtnc9l3w | 8 hours ago
I would say that the article convincingly presents an argument that any small project should be very clear what kind of contributions are welcome, and that the project is the project of and for those who make such contributions (which might be just the sole author, but might be open to change).
Any arguments about needing community of users to be a thing seem stretched. Like the reputation argument: I might want reputation just among people who can reasonably fork and do a fine job maintaining it, this really changes the dynamics for the users I actually want to have!
(And yes, there are open-source projects that are both abandoned and make me grateful, because I can fix myself enough to keep using them, if any fixes are needed)
square_usual | 7 hours ago
Yes! I don't think any user of an Free (as in beer) application can impose any obligations on the developer, at all. They gave you something for free, and if you don't like it, you should stop using it. You have no right to impose an obligation on someone giving you something for free.
tonyarkles | 2 hours ago
"If you break it, you can keep both halves; if you don't like it, I'll give you your money back."
[OP] carlana | 12 hours ago
I open source my code because using closed source repos is harder to do and I want to maintain access to my work even if I switch jobs.
technomancy | 9 hours ago
Yeah, this is a great article, but all the arguments have an implied "if you publish open source that you encourage others to use" instead of "if you publish open source". In the case of the piece he's arguing against, it's absolutely still relevant since there was plenty of "you should use this" going on, but there are exceptions.