> As a user of something open source you are not thereby entitled to anything at all
I understand what the author means, but I think that in any human-2-human interaction, we are all entitled to at least basic courtesy. For example, if you show courtesy by contributing to an open source project and following all the guidelines they have, I think it's fair to assume that courtesy will be shown in return. I know that may be difficult to achieve (e.g., a high volume of noise preventing project authors from giving courtesy to those who deserve it), but that doesn'tt mean we are entitled to nothing. And this has nothing to do with open source or software; it's just common sense when dealing with people.
But yeah, if you contribute something of very poor quality (you didn't give it the attention it needed, it's full of bugs, or shows no attention to detail; or these days, it's packed with AI-generated content that makes it 10x harder to digest, even if the intention is good), then perhaps you are not entitled to anything
You as a first-time contributor need to know that the large group of first-time contributors has a lot of poorly behaved people in it, and that the burden is on you to establish that you are not one of them.
Trust is built through iterative exchange. This is Bayesian priors - default is average, and only moves on the introduction of new information.
Lots of examples of this. In 1950's westerns, if a stranger comes to a small town, the default treatment is a guarded form of hospitality with a health measure of suspicion. If you are dating someone new, you are by default understood as the average first date partner, and the average first date partner is not a great match.
I built a commercial product that competes with open source alternatives in my space, and this tension is constant. People ask why they should pay me when they could use the open source version. And the honest answer is: if you have the time and expertise to run, maintain, and interpret the open source tool yourself, you absolutely should.
I'm not owed your money any more than Rich is owed your contributions. But most people asking that question are really asking 'can someone else do the hard part for free,' which is exactly the entitlement he's describing, just pointed at a different target.
It's an interesting world for sure, I maintain a somewhat popular package and got a form to fill from a Deloitte consultant about security once.
They seemed genuinely confused when I told them I was not going to fill compliance form and make patching commitments for free. Really makes you wonder how many maintainers are letting themselves be taken advantage of.
The people who maintain open source software are considered "the vendor" by these compliance types. When it comes to open source, the user is really the vendor and the user has responsibility to themselves for compliance (this is pretty much spelled out in the licence and WARRANTY file). The compliance industry doesn't acknowledge how open source works and have tried, since forever, to shoehorn it into a paid vendor model. Open source maintainers creating destination/marketing websites espousing the advantages of their software as if it is a sellable/buyable product doesn't help and perpetuates that perception.
Yeah, that's what I do. Anytime anyone from a company sends an email about whatever, who wants me to help them (for their company) in private with something, I ask if they're willing to pay for my time spent on it, maybe 20% says yes. Most of the time they end up getting redirected to use the same venues the rest of the community has access to too.
The other common “entitlement” is getting miffed when their suggested enhancement isn't something that you intend to do, or will/might get done but is very low priority so it won't be soon. Common responses are to suggest that you should reconsider “for the community”⁰, or start a moaning campaign on social media to try to get others to chip in and nag you. Or “threaten” to use something else instead, which always amused me¹ [way back] when I had some f/oss stuff out there.
Expecting quick responses to security issues is one thing, and perfectly acceptable IMO, but new features/enhancements or major changes (that might break other workflows, most importantly mine!) is quite another.
---------
[0] My response years ago when I had f/oss code out there was sometimes “why don't you do it for the community, and submit a patch?” which usually got an indignant response. Though these days if I ever publish code again it'll be on more of an “open source not open contribution” basis, so I'd not be accepting patches like that and my response would be more along the lines of “feel free to fork and DIY”.
[1] So, if I do the thing I don't want to do right now, you'll stay and probably keep making demands, and if I don't do the thing that I don't want to do right now, you'll go away and bother someone else? Let me think about that…
my more generous interpretation of the situation is that people do not see the work / effort / complexity of operating a solution. They think that open source is free, when in reality it is cheaper (generally) but not free.
You need to pay the hosting. You need to install it, configure it, and patch it. And when stuff breaks, you have no one to call upon but yourself.
But, as you say, if you can do all of that, open source is amazing value.
Commenting as if this was a comment on yesterday's clawdbot-thread; I know it isn't, and it has previously been submitted here and is a good text.
It's about entitlement and using free OSS vs paying for a software product, I know.
But I think the gist of this gist can be generalized from "why you should not feel entitled to anything as a FOSS user" to "why software is about humans".
Especially because the commercial aspect is not as direct as in paid closed-source software for FOSS, but pressure (including commercial and/or social pressure) still exists.
Crowd dynamics / psychological aspects cannot be ignored anywhere.
Lately I'm seeing more and more value in writing down expectations explicitly, especially when people's implicit assumptions about those expectations diverge.
The linked gist seems to mostly be describing a misalignment between the expectations of the project owners and its users. I don't know the context, but it seems to have been written in frustration. It does articulate a set of expectations, but it is written in a defensive and exasperated tone.
If I found myself in a situation like that today, I would write a CONTRIBUTING.md file in the project root that describes my expectations (eg. PRs are / are not welcome, decisions about the project are made in X fashion, etc.) in a dispassionate way. If users expressed expectations that were misaligned with my intentions, I would simply point them to CONTRIBUTING.md and close off the discussion. I would try to take this step long before I had the level of frustration that is expressed in the gist.
I don't say this to criticize the linked post; I've only recently come to this understanding. But it seems like a healthier approach than to let frustration and resentment grow over time.
Furthermore, writing down the contract calmly, as part of a plan, can avoid having to bang it out in frustration, which leaves a bad taste in everyone's mouths.
Agreed, TFA is a good example of how to write down expectations explicitly.
But as far as dinging Hickey for the fact that he eventually needed to write bluntly? I'm not feeling that at all. Some folks feel that open-source teams owe them free work. No amount of explanation will change many of those folks' minds. They understand the arguments. They just don't agree.
Is there a history of that here? Were there earlier clear statements of expectations (like CONTRIBUTING.md) that expressed the same expectations, but in a straightforward way, that people just willfully disregarded?
I don't mean to "ding" anybody, I mostly just felt bad that things had gotten to the point where the author was so frustrated. I completely agree that project owners have the right to set whatever terms they want, and should not suffer grief for standing by those terms.
I think some might get the impression that you're complaining about Hickey's tone. Perhaps your emotional terms "frustration," "defensive," and "exasperated" may be the reason.
I don't see anything wrong with the way he expressed himself, and I think his point is totally legitimate. I mostly just felt bad that he experienced so much grief about it, on account of a gift he was offering to the world.
I think the issue is answering the question whats the business model ? If the team makes money consulting on clojure, then thats likely a bad model since I have not seen a single example of people paying for advice on coding. Usually the answer is to hire a coder who knows thier stuff and increasingly to use AI.
Open source for infrastructure products work just fine. It simplifies distribution by eliminating the need for procurement, builds some kind of attachment since people love using their own tinkered products and hedges risk for the customer since if the devs stop working on the product someone else will pick up.
But having to fill out forms, doing compliance work are great money making levers for which you just charge through the nose. Ultimately, open soircing is a distribution strategy and whether you should adopt it or not is dependent on the context. Most infra products do and it works out fine. Case in point: Clickhouse, Kafka, Grafana, Sentry, RedHat, Gitlab.
> As a user of something open source you are not thereby entitled to anything at all
As a user of Hackernews you're not thereby entitled to anything at all.
As a member of the thing(forums, discord channels, facebook groups, any online community and real life community) you're not necessarily thereby entitled to anything at all.
Even as a user of some proprietary software, you're still not entitled to anything except perhaps critical bugfixes and security updates. Software is sold on shrinkwrap basis. You got what you bought.
It doesn't mean expressing your opinions about Hackernews, the thing or some proprietary software, even negative ones, is inherently wrong.
It would be nice to have some context on this. I assume there was some drama regarding this "Cognitect" organisation named. As someone not involved with Clojure at, it's difficult to understand the context for why this post was created.
There was also a thread about MinIO not being maintained anymore.
Hard to say without commentary. Maybe the poster here was influenced by multiple threads (I guess that seems likely, if it was just one thread they influenced them, they could have linked it in that thread).
But the link to the post was posted here just now! - which I'm assuming means something.
Both share a theme: the trials and tribulations of running an open source project, I suppose. Some contributions, one way or another, demand more of them than the maintainer might like. How do you deal with this? How do you set the boundaries? And so on.
It was a reaction to the State of Clojure Survey 2018 (https://danielcompton.net/clojure-survey-2018) and discussions it sparked, in which there were depands for Clojure to change to a more community-driven development process.
It's funny how a hobby project becomes "a burden" when you have to consider making it friendly/easy to consume by everyone eg. writing docs from the basics like how to make a venv in python, get your env setup...
I get that. I am a non-programmer who vibe codes personal web apps for Magic: The Gathering and Pokémon TCG. I turn them into github pages for easy access for myself.
I don't share them with my hobby communities because I don't want to hear feedback because I don't want these finished projects to become eternal projects.
Its an interesting situation when an asset (like an open source project) is run by a team of volunteers (community)... but due to licensing, it kind of belongs to the whole world (community)
As a user of a project, I DO have a voice... but unless I am actively contributing (money, time, resources), then my voice has a different weight.
On the one hand, I don't like the idea that anyone should get more influence simply because they pay money... or that anyone should have more power just because they are active in the project. Both of those situations are possible paths for corruption or abuse of power.
On the other hand, the tragedy of the commons is a real thing. People who take, never give back, and then have the audacity to not only ask but demand things... well, that makes me angry.
I've moved from being an idealist to a realist, when it comes to open source. I think the evolving models we are seeing that restrict commercial competition are sometimes pretty good (overall), and the rise in COSS is a positive sign. We need to ensure that good projects have a way to sustain themselves.
The best projects have people (or even teams) who are focused on bringing new people in and helping them contribute. Not everyone can do that, but I think finding ways to enable people to contribute (money, time, etc) is an important part of building the community.
I think community development with repos out in the open and all that is increasingly a too high cost. I will migrate my little open source projects from GitHub as soon as I can decide on what site to post source code releases (tar.gz). Happy to share my code, but no need for everything to be out in the open.
I can't say whether it accomplished its original intent, but my experience is that it's held up in really disappointing situations which sit counter to my collectivist values
I have a ton of experience with community-building, and what's espoused in this essay is an attack on the values of that world imho.
My take-home is that there are many conceptions of what "open source" is about, and from where its value flows
If you want to create and maintain a community that's fine, maybe even great. TFA is just pointing out that the presence of an OSS license is not an implicit signal that the project is interested in any such community. They're separate things, and my read is that the author is frustrated with the constant conflating of the two. It's not an attack on your values at all.
If you personally are willing to invest more, to dedicate attention and effort to every user/contributor/member of the opensource community you are maintaining, then that is great, and does not even conflict with the essay at all.
The only point is that all the time that you and other selfless maintainers are spending on their projects is not something that anyone is entitled to; it's a gift, not a duty.
To actually conflict witht the essay you would need to hold that any developer that ever publishes a piece of software is not only duty-bound to maintain it forever, but also to engage with every potential (crackpot) user or collaborator, and that's simply not a defensible perspective to me.
I feel much better after reading this because our organizations are:
- funding OSS developers
- engaging with OSS developers to determine potential funding priorities
- providing project hardware at the project level
- providing hardware to the individual OSS developer
While we are not to the point of hosting events in Hawaii yet, I’m hoping we can see this as a teaming arrangement to accomplish great things together!
- You are entitled to human decency. Maintainers don't get to be rude just because they run a project. This is a common thing in a lot of projects; maintainers have power, and this allows them to be rude without concern. Not ok.
- As a maintainer, if you publish your work as open source, you already acknowledge you are engaging with an entire community, culture, and ethos. We all know how it works: you put a license on your work that (often, but not always) says people need to share their changes. So those people may share their changes back to you, assuming you might want to integrate them. So you know this is going to happen... so you need to be prepared for that. That is a skill to learn.
- Since maintainers do owe basic human politeness, and they know people will be interacting with them, maintainers do owe this culture some form of communication of their intentions. If they don't want to take any changes, put that in CONTRIBUTING and turn off GH PRs. If they want to take changes, but no AI changes, put that in CONTRIBUTING. If they don't want to do support, turn off GH Issues. If they require a specific 10-point series of steps before they look at a PR or Issue, put that in CONTRIBUTING. It's on the user to read this document and follow it - but it's on you to create it, so they know how to interface with you.
Be polite, and tell people what you will and won't accept in CONTRIBUTING (and/or SUPPORT). Even if it's just "No contributing", "No support". (My personal issue: I spend hours working on preparing an Issue or PR to fix someone's project, and they ignore or close it without a word. Now I don't want to contribute to anything. This is bad for the open source community.)
> As a user of something open source you are not thereby entitled to anything at all
I understand what the author means, but I think that in any human-2-human interaction, we are all entitled to at least basic courtesy. For example, if you show courtesy by contributing to an open source project and following all the guidelines they have, I think it's fair to assume that courtesy will be shown in return. I know that may be difficult to achieve (e.g., a high volume of noise preventing project authors from giving courtesy to those who deserve it), but that doesn'tt mean we are entitled to nothing. And this has nothing to do with open source or software; it's just common sense when dealing with people.
But yeah, if you contribute something of very poor quality (you didn't give it the attention it needed, it's full of bugs, or shows no attention to detail; or these days, it's packed with AI-generated content that makes it 10x harder to digest, even if the intention is good), then perhaps you are not entitled to anything
You as a first-time contributor need to know that the large group of first-time contributors has a lot of poorly behaved people in it, and that the burden is on you to establish that you are not one of them.
Trust is built through iterative exchange. This is Bayesian priors - default is average, and only moves on the introduction of new information.
Lots of examples of this. In 1950's westerns, if a stranger comes to a small town, the default treatment is a guarded form of hospitality with a health measure of suspicion. If you are dating someone new, you are by default understood as the average first date partner, and the average first date partner is not a great match.
I built a commercial product that competes with open source alternatives in my space, and this tension is constant. People ask why they should pay me when they could use the open source version. And the honest answer is: if you have the time and expertise to run, maintain, and interpret the open source tool yourself, you absolutely should.
I'm not owed your money any more than Rich is owed your contributions. But most people asking that question are really asking 'can someone else do the hard part for free,' which is exactly the entitlement he's describing, just pointed at a different target.
It's an interesting world for sure, I maintain a somewhat popular package and got a form to fill from a Deloitte consultant about security once.
They seemed genuinely confused when I told them I was not going to fill compliance form and make patching commitments for free. Really makes you wonder how many maintainers are letting themselves be taken advantage of.
The people who maintain open source software are considered "the vendor" by these compliance types. When it comes to open source, the user is really the vendor and the user has responsibility to themselves for compliance (this is pretty much spelled out in the licence and WARRANTY file). The compliance industry doesn't acknowledge how open source works and have tried, since forever, to shoehorn it into a paid vendor model. Open source maintainers creating destination/marketing websites espousing the advantages of their software as if it is a sellable/buyable product doesn't help and perpetuates that perception.
Maybe that would be a good opportunity to offer them a quote for how much you could do the work for.
Yeah, that's what I do. Anytime anyone from a company sends an email about whatever, who wants me to help them (for their company) in private with something, I ask if they're willing to pay for my time spent on it, maybe 20% says yes. Most of the time they end up getting redirected to use the same venues the rest of the community has access to too.
Missed opportunity here. You could have offered consulting services, $10,000/hour. Compliance form requires at 40 hours of work minimum.
The other common “entitlement” is getting miffed when their suggested enhancement isn't something that you intend to do, or will/might get done but is very low priority so it won't be soon. Common responses are to suggest that you should reconsider “for the community”⁰, or start a moaning campaign on social media to try to get others to chip in and nag you. Or “threaten” to use something else instead, which always amused me¹ [way back] when I had some f/oss stuff out there.
Expecting quick responses to security issues is one thing, and perfectly acceptable IMO, but new features/enhancements or major changes (that might break other workflows, most importantly mine!) is quite another.
---------
[0] My response years ago when I had f/oss code out there was sometimes “why don't you do it for the community, and submit a patch?” which usually got an indignant response. Though these days if I ever publish code again it'll be on more of an “open source not open contribution” basis, so I'd not be accepting patches like that and my response would be more along the lines of “feel free to fork and DIY”.
[1] So, if I do the thing I don't want to do right now, you'll stay and probably keep making demands, and if I don't do the thing that I don't want to do right now, you'll go away and bother someone else? Let me think about that…
my more generous interpretation of the situation is that people do not see the work / effort / complexity of operating a solution. They think that open source is free, when in reality it is cheaper (generally) but not free.
You need to pay the hosting. You need to install it, configure it, and patch it. And when stuff breaks, you have no one to call upon but yourself.
But, as you say, if you can do all of that, open source is amazing value.
But it is about humans in general!
Humans who want to use the software.
Commenting as if this was a comment on yesterday's clawdbot-thread; I know it isn't, and it has previously been submitted here and is a good text.
It's about entitlement and using free OSS vs paying for a software product, I know.
But I think the gist of this gist can be generalized from "why you should not feel entitled to anything as a FOSS user" to "why software is about humans".
Especially because the commercial aspect is not as direct as in paid closed-source software for FOSS, but pressure (including commercial and/or social pressure) still exists.
Crowd dynamics / psychological aspects cannot be ignored anywhere.
Lately I'm seeing more and more value in writing down expectations explicitly, especially when people's implicit assumptions about those expectations diverge.
The linked gist seems to mostly be describing a misalignment between the expectations of the project owners and its users. I don't know the context, but it seems to have been written in frustration. It does articulate a set of expectations, but it is written in a defensive and exasperated tone.
If I found myself in a situation like that today, I would write a CONTRIBUTING.md file in the project root that describes my expectations (eg. PRs are / are not welcome, decisions about the project are made in X fashion, etc.) in a dispassionate way. If users expressed expectations that were misaligned with my intentions, I would simply point them to CONTRIBUTING.md and close off the discussion. I would try to take this step long before I had the level of frustration that is expressed in the gist.
I don't say this to criticize the linked post; I've only recently come to this understanding. But it seems like a healthier approach than to let frustration and resentment grow over time.
Furthermore, writing down the contract calmly, as part of a plan, can avoid having to bang it out in frustration, which leaves a bad taste in everyone's mouths.
Agreed, TFA is a good example of how to write down expectations explicitly.
But as far as dinging Hickey for the fact that he eventually needed to write bluntly? I'm not feeling that at all. Some folks feel that open-source teams owe them free work. No amount of explanation will change many of those folks' minds. They understand the arguments. They just don't agree.
> he eventually needed to write bluntly
Is there a history of that here? Were there earlier clear statements of expectations (like CONTRIBUTING.md) that expressed the same expectations, but in a straightforward way, that people just willfully disregarded?
I don't mean to "ding" anybody, I mostly just felt bad that things had gotten to the point where the author was so frustrated. I completely agree that project owners have the right to set whatever terms they want, and should not suffer grief for standing by those terms.
> I don't say this to criticize the linked post
What you have written is obviously a criticism of the linked post.
If I'm criticizing the linked post, then I'm also criticizing myself, because I could easily imagine having written it.
I think some might get the impression that you're complaining about Hickey's tone. Perhaps your emotional terms "frustration," "defensive," and "exasperated" may be the reason.
I don't see anything wrong with the way he expressed himself, and I think his point is totally legitimate. I mostly just felt bad that he experienced so much grief about it, on account of a gift he was offering to the world.
I think the issue is answering the question whats the business model ? If the team makes money consulting on clojure, then thats likely a bad model since I have not seen a single example of people paying for advice on coding. Usually the answer is to hire a coder who knows thier stuff and increasingly to use AI.
Open source for infrastructure products work just fine. It simplifies distribution by eliminating the need for procurement, builds some kind of attachment since people love using their own tinkered products and hedges risk for the customer since if the devs stop working on the product someone else will pick up.
But having to fill out forms, doing compliance work are great money making levers for which you just charge through the nose. Ultimately, open soircing is a distribution strategy and whether you should adopt it or not is dependent on the context. Most infra products do and it works out fine. Case in point: Clickhouse, Kafka, Grafana, Sentry, RedHat, Gitlab.
> As a user of something open source you are not thereby entitled to anything at all
As a user of Hackernews you're not thereby entitled to anything at all.
As a member of the thing(forums, discord channels, facebook groups, any online community and real life community) you're not necessarily thereby entitled to anything at all.
Even as a user of some proprietary software, you're still not entitled to anything except perhaps critical bugfixes and security updates. Software is sold on shrinkwrap basis. You got what you bought.
It doesn't mean expressing your opinions about Hackernews, the thing or some proprietary software, even negative ones, is inherently wrong.
It would be nice to have some context on this. I assume there was some drama regarding this "Cognitect" organisation named. As someone not involved with Clojure at, it's difficult to understand the context for why this post was created.
This was the context back then: https://old.reddit.com/r/Clojure/comments/a0pjq9/rich_hickey...
I was reminded of this gist when reading the discussion about MinIO (https://news.ycombinator.com/item?id=47000041).
Presumably this: https://news.ycombinator.com/item?id=46990729
There was also a thread about MinIO not being maintained anymore.
Hard to say without commentary. Maybe the poster here was influenced by multiple threads (I guess that seems likely, if it was just one thread they influenced them, they could have linked it in that thread).
TFA was posted in 2018; that drama is from the past few days. What connection is there?
But the link to the post was posted here just now! - which I'm assuming means something.
Both share a theme: the trials and tribulations of running an open source project, I suppose. Some contributions, one way or another, demand more of them than the maintainer might like. How do you deal with this? How do you set the boundaries? And so on.
I guess we were responding to different things: my reading of GP's question was why the gist was posted (back in 2018), not why it was shared today.
But indeed yes, I can see that connection.
I think you're right anyway. Re-reading the post with your comment in mind, I think it's clear enough that this was what was actually meant.
You're not able to connect these two subjects?
A thesis on "don't abuse people in open source" and a bot "abusing people in open source"?
It was a reaction to the State of Clojure Survey 2018 (https://danielcompton.net/clojure-survey-2018) and discussions it sparked, in which there were depands for Clojure to change to a more community-driven development process.
I love this article.
Nobody owes you a new release, or a signed binary, or a feature you care about.
Tangent
It's funny how a hobby project becomes "a burden" when you have to consider making it friendly/easy to consume by everyone eg. writing docs from the basics like how to make a venv in python, get your env setup...
I get that. I am a non-programmer who vibe codes personal web apps for Magic: The Gathering and Pokémon TCG. I turn them into github pages for easy access for myself.
I don't share them with my hobby communities because I don't want to hear feedback because I don't want these finished projects to become eternal projects.
Curious what does your app do/web app? And how good is the vibe coding part, do you generally get what you're trying to achieve in first few runs?
That's cool you're able to make what you want with that tech.
Its an interesting situation when an asset (like an open source project) is run by a team of volunteers (community)... but due to licensing, it kind of belongs to the whole world (community)
As a user of a project, I DO have a voice... but unless I am actively contributing (money, time, resources), then my voice has a different weight.
On the one hand, I don't like the idea that anyone should get more influence simply because they pay money... or that anyone should have more power just because they are active in the project. Both of those situations are possible paths for corruption or abuse of power.
On the other hand, the tragedy of the commons is a real thing. People who take, never give back, and then have the audacity to not only ask but demand things... well, that makes me angry.
I've moved from being an idealist to a realist, when it comes to open source. I think the evolving models we are seeing that restrict commercial competition are sometimes pretty good (overall), and the rise in COSS is a positive sign. We need to ensure that good projects have a way to sustain themselves.
The best projects have people (or even teams) who are focused on bringing new people in and helping them contribute. Not everyone can do that, but I think finding ways to enable people to contribute (money, time, etc) is an important part of building the community.
Sometimes you just gotta get the frustration out in a gist
I think community development with repos out in the open and all that is increasingly a too high cost. I will migrate my little open source projects from GitHub as soon as I can decide on what site to post source code releases (tar.gz). Happy to share my code, but no need for everything to be out in the open.
I fail to see the difference between public on github or public elsewhere.
No public version control. No issues or pull requests or other social features. Like every project, more or less, before GitHub or Sourceforge.
Well we had RCS, CVS and Usenet groups.
And before that, compressed archives on BBS, or type in listings with snail mail.
codeberg is run as a foundation with the explicit aim to help open source projects prosper
github is run by microsoft to sell tools to your CEO with the ultimate aim of making you redundant
> Sign in to GitHub to continue to Gist
That's new
Edit: https://web.archive.org/web/20260213161600/https://gist.gith...
I'll just leave this here: https://madnight.github.io/githut/#/stars/2024/1
Just look at clojure's stats and understand what this "wisdom" brings
correlation does not imply causation
I dislike this essay so much
I can't say whether it accomplished its original intent, but my experience is that it's held up in really disappointing situations which sit counter to my collectivist values
I have a ton of experience with community-building, and what's espoused in this essay is an attack on the values of that world imho.
My take-home is that there are many conceptions of what "open source" is about, and from where its value flows
If you want to create and maintain a community that's fine, maybe even great. TFA is just pointing out that the presence of an OSS license is not an implicit signal that the project is interested in any such community. They're separate things, and my read is that the author is frustrated with the constant conflating of the two. It's not an attack on your values at all.
If you personally are willing to invest more, to dedicate attention and effort to every user/contributor/member of the opensource community you are maintaining, then that is great, and does not even conflict with the essay at all.
The only point is that all the time that you and other selfless maintainers are spending on their projects is not something that anyone is entitled to; it's a gift, not a duty.
To actually conflict witht the essay you would need to hold that any developer that ever publishes a piece of software is not only duty-bound to maintain it forever, but also to engage with every potential (crackpot) user or collaborator, and that's simply not a defensible perspective to me.
I think "Open source is a licensing and delivery mechanism, period." is a statement that bears repeating.
It comes down to beggars asking skilled people for free labor. If the "community" really wants something, they can send a pull request.
I feel much better after reading this because our organizations are: - funding OSS developers - engaging with OSS developers to determine potential funding priorities - providing project hardware at the project level - providing hardware to the individual OSS developer
While we are not to the point of hosting events in Hawaii yet, I’m hoping we can see this as a teaming arrangement to accomplish great things together!
Ultimately it is about you.
That you are entitled to have say too.
That such & such says should be followed, nope.
But one could say it's even less about you with close source.
Can you add the year (2018) to the submission title? https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Counterpoints:
- You are entitled to human decency. Maintainers don't get to be rude just because they run a project. This is a common thing in a lot of projects; maintainers have power, and this allows them to be rude without concern. Not ok.
- As a maintainer, if you publish your work as open source, you already acknowledge you are engaging with an entire community, culture, and ethos. We all know how it works: you put a license on your work that (often, but not always) says people need to share their changes. So those people may share their changes back to you, assuming you might want to integrate them. So you know this is going to happen... so you need to be prepared for that. That is a skill to learn.
- Since maintainers do owe basic human politeness, and they know people will be interacting with them, maintainers do owe this culture some form of communication of their intentions. If they don't want to take any changes, put that in CONTRIBUTING and turn off GH PRs. If they want to take changes, but no AI changes, put that in CONTRIBUTING. If they don't want to do support, turn off GH Issues. If they require a specific 10-point series of steps before they look at a PR or Issue, put that in CONTRIBUTING. It's on the user to read this document and follow it - but it's on you to create it, so they know how to interface with you.
Be polite, and tell people what you will and won't accept in CONTRIBUTING (and/or SUPPORT). Even if it's just "No contributing", "No support". (My personal issue: I spend hours working on preparing an Issue or PR to fix someone's project, and they ignore or close it without a word. Now I don't want to contribute to anything. This is bad for the open source community.)