hckrnws

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.

The compliance form thing is wild but predictable. I'm on the other side of that equation now. Companies will pay me to handle their compliance mapping but balk at paying an open source maintainer to fill out a security questionnaire for software they depend on in production. The disconnect is that compliance teams budget for vendors but have no line item for 'critical open source dependency we treat like a vendor but isn't one.

> got a form to fill from a Deloitte consultant about security once.

It could be someone trying to extract free work, but in my experience this person was probably trained by someone else about how to handle vendor compliance for contracted vendors.

Some times the people in these grunt work consulting positions aren't really knowledgable about the space. They're in those positions because they can follow directions and will diligently grind out billable hours. Their default mode for getting things done is to try what worked last time, and if that fails they just start looking for names to send the request to until someone does it.

As others mentioned, you could have said "Compliance forms are $1000, payable to ____" and the consultant may have diligently gone through their mental process about where to direct invoices for work.

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.

Assuming you want to. But if you do, understand that accepting payment for services creates obligation to deliver, and possibly liability for poor performance. You may or may not want that.

Missed opportunity here. You could have offered consulting services, $10,000/hour. Compliance form requires at 40 hours of work minimum.

No kidding. I don't maintain anything of enough popularity to warrant being approached like that, but a good hourly-rate answer would be the no-brainer response.

I do talk with OSS devs about “we need X for security and we are willing to provide X amount of funding”

You’d be amazed how much OSS devs will do for you when your request of something they wanted to do anyways (but had no impetus for prioritization) is matched by a healthy rate

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…

The 'I'll use something else' threat is my favorite. In my space the threat is usually 'I'll just use the AWS native tools.' And my honest answer is: if that works for you, do it. Most of them come back three months later after the first Config rules bill lands.

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.

Exactly this. The sticker price of open source is zero but the total cost of ownership is your team's time. I've talked to CTOs who spent more engineering hours configuring and maintaining free tools than they would have spent on a managed alternative. They just couldn't see it because the cost was buried in salary, not a line item on an invoice.

People are always going to neg you in order to try to get more out of you.

During the 00’s I worked for a place that had to pivot because they had a good tool but it wasn’t a daily driver and so the customers didn’t want to pay. They kept imagining some free alternative must exist that didn’t.

They eventually got an exit. Didn’t make anyone rich but they did. But the thing is I showed up to work on that tool, not knowing they’d already pivoted. I did eventually get to work on it a bit, as we found a way to improve one of our other products by fixing bugs in it. I’m kinda glad in retrospect I didn’t work on it first because the code was a mess.

> 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

> 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.

This only holds up for the "small" number of human interactions the average person gets. If my neighbor comes and rings my doorbell to say hello, I'm fine answering and shooting the shit, maybe invite them in for a quick coffee.

If every 5 minutes a strange comes in and rings my doorbell, I'm not getting up and answering it. And some people visiting will get angry and start pounding on the door and coming to my window and pounding on it glaring at me inside. And say, hey, I drove all the way from hours away to come visit you, the least you could do is open the door and say hello.

For them, it's their first human-2-human interaction that day, with someone they slightly admire even, and they're expecting basic human courtesy. To me, they're just the 42nd doorbell ringer today.

Ah the dehumanizing nature of affluence… a right of passage for those fortunate enough to experience.

The challenge is in how to manage and and maintain the interest, less one falls back into the realm of obscurity or worse be tarnished reputationally so as to never recover.

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'm not saying you're wrong - but I do detest that attitude myself

As you say, trust is a two way street, and first time contributors are being expected to trust that it's not personal when they are met with brusquerie.

I know it's hard when it's the 99th person and you've had to deal with 98 less than nice individuals, but defaulting to an abrupt or blunt manner does nobody any favours.

The demands here are effectively extensions of netiquette[0] and "how to ask good questions"[1]. Every code contributor should at least understand what is asked of them.

[Julia's post sadly does not include the blunt expression "demonstrate that you have done your homework", which is a fundamental tenet.]

0: https://en.wiktionary.org/wiki/netiquette

1: https://jvns.ca/blog/good-questions/

What’s the solution then? This is one of those emotional-labor questions.

Who is responsible for new contributors having a good experience? Especially thousands of eager, misinformed contributors?

It’s a DDOS that exhausts and burns out the maintainer even while the supply of newbie contributors is rarely meaningfully impacted by maintainer conduct.

The world has givers and takers, and we are all both at different times. The newbie thinks they are a giver, but mostly they are a taker.

I've also seen maintainers complain about "drive by contributors" where one complaint is that the submitter has provided a good patch/PR, but doesn't stick around to support it.

From the submitters point of view, why /would/ you stick around if your first (and only) interaction with the project is less than "ideal"

FTR I absolutely understand the "burnout" maintainers experience dealing with contributors that drain energy as well.

> 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.

Correct. The article does not disagree with you.

> we are all entitled to at least basic courtesy

Basic courtesy here, to me, means that the maintainer should be polite and probably should say something (it's not very nice to be ignored), even if it is to say that they won't review the contribution.

But that's about it. My experience as a maintainer is that too often, people feel entitled to a lot more than that.

There is not space in the collective consciousness for an infinite number of solutions to the same problem. I usually get downvoted for pointing this out but it explains why people shit on you when you start getting defensive about people calling your solution or attitude shit.

Reasonable people won’t start a project in an already oversubscribed niche. So yes, it does matter if you’re doing more than the minimum. It’s a social contract because you’re using up the oxygen.

I liken it to throwing a party. Yes it’s your party, but I can’t go to your party if it’s Timothy’s birthday. But if you’re popular enough then people will say “fuck Timothy” and that’s not cool. And you don’thave to be a great host and you can absolutely lock your bedroom door, but there better be snacks and maybe music, or people will talk about you behind your back. Or if you bring lutefisk and nobody there is Scandinavian. Read the room dude.

There are way too many software people who think, “well you didn’t have to come to my party/eat what I brought” is a valid response to criticism.

That’s not how social things work, and open source is one.

The biggest assholes in your example are the people saying "Fuck Timothy". It's also not my fault those people are assholes. If they don't like my party that's fine. If they say i don't have music or whatever that's fine.

If they tell me I don't know how to run parties and all parties need to have music and snacks or else its not a party I'm gonna tell them to fuck off.

I’ve never been the popular kid for more than a few minutes. It felt weird when it happened, both due to impostor syndrome and the unfortunate situations where it most often happened. Like an altercation where I found I was seen more than I thought.

But I’ve been involved with highly successful clubs from a young age, and I have to take things apart to understand them. I also lived for ten years with a woman who wanted to not only be in every club she saw but take over them, and I got a good anthropology study in to what things she made better and which she made worse (did I mention we aren’t together anymore?)

The reasons they were popular often turned out not to be the reasons I would have thought. Stupid little things like keeping a consistent location and meeting time seem small but the outcomes are outsized.

(Inline edit, I’m such a space cadet I left out the punchline) one of the biggest is figuring out how to successfully channel the enthusiasm of new members 90% of which will be gone in 6-18 months. Which OSS has in truckloads.

As I’ve matured I’ve realized that I should not dream of being in charge of these organizations anymore. The qualities (or energies really) I possess in insufficient quantities to keep that many plates spinning. Properly. So I help those people be the leaders we need, and I hop in when the stars align and my energies are sufficient to take something off their plate. And god forbid they get hit by a bus and I become acting president of VP, my first effort would be in grooming a replacement, not trying to take over.

You can’t have an objective conversation about this sort of stuff with people who still have a chip on their shoulder about how they’re right and the universe is wrong for not understanding how amazing you are. You’re right, but you’re also tragically wrong. And until you grasp that you will be railing against the universe for the indignities it thrust upon you.

I get that vibe in a lot of these conversations. And I wish I knew how to find the people who understand this. All I can do is talk to the people who rail and hope the silent audience gets something from it.

I don’t know you but I like you.

Courtesy costs very little.

I agree with you, but this is one of those things where if you haven't had the experience of being part of a popular open source project, you don't realize how bad the scaling effects are.

Let's say courtesy only requires five minutes of my time. There are millions of users of the programming language I work on. Let's say only 0.1% of them desire my courtesy. Even at that small fraction, I'm going to spend 83 hours out of every 24 hour day (including weekends and holidays) giving each of them that cheap courtesy.

> I think that in any human-2-human interaction, we are all entitled to at least basic courtesy

Why? If you are hostile towards me, mock me, or attack me or are in some other way a douche towards me, I reserve the right to handle you in any way that I want to. My opinion of you has to be earned, just like respect. There is no entitlement for my basic courtesy. I am willing to give everyone the benefit of doubt at the beginning, and extend courtesy, but "entitlement"? no. You do not get to decide what I think or how I feel about you.

[dead]

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.

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 remember the exact situation, but I think this relates to this:

Clojure core was sent a set of patches that were supposed to improve performance of immutable data structures but were provided without much consideration of the bigger picture or over optimized for a specific use case.

There's a Reddit thread which provides a bit more detail so excuse me if I got some of it wrong: https://www.reddit.com/r/Clojure/comments/a01hu2/the_current...

*Edit* - actually this a better summary: https://old.reddit.com/r/Clojure/comments/a0pjq9/rich_hickey...

Dissatisfaction n. 3 is the essence of the problem: "Because Clojure is a language and other people's jobs and lives depend on it, the project no longer feels like someone's personal project which invites a more democratic contribution process". This is a common, and modern, feeling that the more users a certain thing has, the more the creators/maintainers have a duty to treat it as a "commons or public infrastructure" and give the users a vote on how the thing is to be managed and developed. This is, of course, utter horsesh*t.

> Is there a history of that here?

I have been maintaining not-super-successful open source projects, and I've had to deal with entitled jerks. Every. Single. Time. I am totally convinced that any successful open source project sees a lot more of that.

> 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?

IMO it's not needed. I don't have to clearly state expectations: I open source my code, you're entitled to exactly what the licence says. The CONTRIBUTING.md is more some kind of documentation, trying to avoid having to repeat the same thing for each contribution. But I don't think anyone would write "we commit to providing free support and free work someone asks for it" in there :-).

Someone once said: Abuse and expectations erode a culture of cooperation.

I am currently seeing this in real time at $work. A flagship product has been placed onto the platform we're building, and the entire sales/marketing/project culture is not adjusting at all. People are pushy, abusive, communicate badly and escalate everything to the C-Level. As a result, we in Platform Engineering are now channeling our inner old school sysadmins, put up support processes, tickets, rules, expectations and everything else can go die in a ditch.

Everyone suffers now, but we need to do this to manage our own sanity.

And to me at least, it feels like this is happening with a lot of OSS infrastructure projects. People are getting really pushy and pissy about something they need from these projects. I'd rather talk to my boss to setup a PR for something we need (and I'm decently successful with those), but other people are just very angry that OSS projects don't fullfil their very niche need.

And then you get into this area of anger, frustration, putting down boundaries that are harmful but necessary to the maintainers.

Even just "sending them to the CONTRIBUTING.md". Just with a few people at work, we are sending out dozens of reminders about the documentation and how to work with us effectively per week to just a few people. This is not something I would do on my free time for just a singular day and the pain-curbing salary is also looking slim so far.

Furthermore, writing down the contract calmly, as part of a plan, can avoid having to bang it out in frustration and leaving a bad taste.

> 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.

"So much grief." It sounds like you're trying to interpret Hickey's emotions. How would you check whether your interpretation is accurate?

I don't know if you're a native English speaker, so apologies if this isn't appropriate. But the word 'grief' has more than one vernacular meaning.

"Giving someone grief" means giving someone a hard time.

So "he experienced so much grief" can just mean that it can just mean that people criticised him. It doesn't necessarily express anything about Rich Hickey's state of mind.

This is the attitude that made me keep my patches to myself.

Hey, you, FOSS maintainer, whoever you are:

- If you make your project public, it means you want and expect people to use it. You could at least write some documentation, so I don't waste my time and then find out, days later, it isn't capable of what I need or I simply don't know how to use it.

- If you set up a bug tracker, then at least have the decency to answer bug reports. Bugs make it unusable. Someone took the time to write those bug reports. I'm not asking to fix them (I lost that hope decades ago), but at least you could give a one line answer or 2-line guidance for some another person that might want to try a fix - "I don't have time to fix it, sorry, but it's probably because of <that thing> in <that file>." I mean, you wrote the stuff! One minute of thinking on your part is the same as 6 hours of digging for someone who never saw the code before.

- If you open it up to pull requests, it means you want people to contribute. Have the decency to review them. Someone took time away from their jobs, families or entertainment to write those PRs. Ignoring them because you don't need that feature, not affected by the bug, or simply because of code aesthetics is an insult to the one who wrote it.

PS:

- And no, don't expect someone else to write the documentation for your code. Same as the bugs: 1 minute of your time is 6 hours of work for someone else.

If you can't do at least these things, just say it's abandoned on the front page and be done with it.

> If you make your project public, it means you want and expect people to use it.

This isn't true. For many people (myself included), making a project open source means "if you find it useful feel free to make use of it, if not I don't really mind". I don't care, at all, if one soul finds my code useful. It's a gift to the commons, not some kind of social obligation I'm agreeing to.

Yeah, I didn't like that attitude either.

> As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation.

Sure, I'm not entitled to anything. At the same time, this text essentially says "you don't matter", which I personally don't like.

Right, it sounds like "you don't matter to me", which I read as "Oops, wrong address, go find somebody else".

The bigger problem here is that the OP author is pretending to be a speaker for all open source, I guess there's no other way to justify the uncompromising attitude he somehow developed.

AI will undoubtedly change how OSS works, bot-submited PRs can be overwhelming, authors should not despair though, where there's a will, there's a way.

> I guess there's no other way to justify the uncompromising attitude he somehow developed.

I disagree. When someone open sources code, they give away some of their work for free. That's all, and that's nice.

I really don't get how so many people think that if you give away some of your work for free, then you must give even more work away for free because they consider it "basic decency".

> people think that if you give away some of your work for free, then you must give even more work away for free because they consider it "basic decency".

I didn't say that and I have no moral objections to the hardline attitude you seem to like, I respect that choice.

However, we have to be careful here, every author may have to take a firm stance from time to time, but that's not a good idea for all or most of the time, thus the latter isn't the best for everyone or every project, a lot of authors will be happier with different approaches.

Building a project is a lot about building a community around it and while I understand that not everyone can do it, I prefer those who can for completely rational reasons.

We've entered a time when OSS is becoming more important while the technical part of it is becoming less problematic, in this environment interpersonal skills grow in importance and it would be hard to manage a successful project without them.

> Building a project is a lot about building a community around it and while I understand that not everyone can do it, I prefer those who can for completely rational reasons.

And I totally agree with that!

I am not saying that authors must take a firm stance. What I am saying is that users need to understand that they are not entitled to anything at all. It's all bonus.

I do help the users of the projects I maintain, as much as I can. Still they are not entitled to anything at all, I do it because I'm trying to be nice. And what I see is that it's not rare for them to not understand that; they behave as if it was my job.

Years ago, I tried the hot new Linux distribution. I tried to install a couple of popular packages, but they failed, due to lacking a dependency. I installed that dependency and it worked.

It's natural to file a bug report for this type of problem. I told them the missing dependency and assumed they'd make a minor adjustment and push out a fix for the buggy package. Instead, they closed the bug with a rude message about how it was a waste of everyone's time to file a bug report without an exact error message, and the buggy package just sat there.

They probably went on to become a SO mod, closing questions because they were duplicates of unrelated questions, but that's speculation.

> This is the attitude that made me keep my patches to myself.

That's your choice. Now if you open source your patches (in a fork, or in PRs to the upstream repo), someone other than the maintainer could benefit from it. So it's still helpful.

> If you make your project public, it means you want and expect people to use it

No. I benefit from others open sourcing their code, so I open source mine when I can. Because if nobody does it, then I don't benefit from it. But I don't care if people use it or not.

> You could at least write some documentation, so I don't waste my time

No. You are responsible for your time. If it takes you days to realise that you struggle understanding what my project does, that's on you. I am not responsible for you wasting days.

> If you set up a bug tracker, then at least have the decency to answer bug reports.

No. If you report a bug there, it can be useful to someone other than the maintainer, so it's still worth it.

> but at least you could give

I gave you a whole project that you apparently find useful, and all you have to say about it is "at least I could give more"?

> If you open it up to pull requests, it means you want people to contribute

No! Again a PR is a way to share a patch. Even if the maintainer never even looks at it, it may be useful to someone else.

> If you can't do at least these things, just say it's abandoned on the front page and be done with it.

I added a licence that explains what you should expect. I don't know of a single popular open source licence that sets any of the expectations you have. All they say is that you can reuse the code under some conditions.

> - If you make your project public, it means you want and expect people to use it.

no, it doesn't, maybe I have a github project, I want to easily share it with ten of my friends for something, I don't particularly care if other people see it, so I make it public. That in no way implies I want random people to come along with bugs and PRs.

> You could at least write some documentation, so I don't waste my time and then find out, days later, i

if it doesnt have any documentation then that is a clear sign you should not expect anything from the author of that software. if reading some code and figuring out if it's useful to you or not is too much of a risk of your time, then assume it's not useful and move onto something else.

> If you set up a bug tracker, then at least have the decency to answer bug reports.

maybe the author had time and energy to answer bug reports a few years ago and maybe right now they don't. When bugs go unanswered (like, all the bugs, not just one in particular), that means the project is possibly in an unmaintained or semi-unmaintained status, might be time to move on. Or if it's just your bug, it usually means your bug is something the maintainers don't care about or dont have the cycles to spend effort on (again, could be time to move on).

certainly, if I'm an OSS author and I want people to use my project and stay with it, then yes, I'm certainly going to answer all bug reports. But I have no such obligation (indeed I have lots of projects and are in both categories and many in between).

> If you open it up to pull requests, it means you want people to contribute. Have the decency to review them. Someone took time away from their jobs, families or entertainment to write those PRs. Ignoring them because you don't need that feature, not affected by the bug, or simply because of code aesthetics is an insult to the one who wrote it.

counterpoint, people who barge in on your project with huge PRs for features or changes that were not discussed at all much less signed off on by the maintainers are incredibly rude and entitled, because they are using exactly your logic above "I starved my family to bring this to you!" to guilt you into taking your project into directions you may not have wanted, and beyond that, PRs are just as much work for maintainers as for the person contributing them. An unannounced PR to me is pretty much a bug report with a guilt trip attached, no thanks. I really wish Github would provide more options in this area.

- a maintainer

> no, it doesn't, maybe I have a github project, I want to easily share it with ten of my friends for something,

Then make it private.

> I don't particularly care if other people see it, so I make it public.

Yeah, I see someone else made the same argument. It's a reckless disregard of other people's time and nerves. Build labyrinths and scatter them around the internet. Leave manholes uncovered. Markov chains to trap humans. You could at least say it's not maintained - no, not in the disclaimer.

> maybe the author had time and energy to answer bug reports a few years ago and maybe right now they don't.

Then close bug tracker and post "Abandoned" on the front page.

> counterpoint, people who barge in on your project with huge PRs for features or changes that were not discussed at all

Then say so and then reject them. That's what PR review means. I don't have a problem with rejected PRs. I have a problem with ignored PRs.

> Then make it private

You don't get to decide that.

> It's a reckless disregard of other people's time and nerves. Build labyrinths and scatter them around the internet. Leave manholes uncovered.

That's a *you* problem, because you have wrong expectations.

> Then close bug tracker and post "Abandoned" on the front page.

You don't get to decide that.

> Then say so and then reject them. That's what PR review means. I don't have a problem with rejected PRs. I have a problem with ignored PRs.

Another case of you having wrong expectations. Like in networking, you should put a timeout on all requests. For all practical purposes a request that times out is to be treated the same as a rejection.

> [...] you have wrong expectations.

I did. (Past tense.) I'm calibrated now.

> You don't get to decide that.

You're exactly right. I only get to decide what I do with my own toys. And I've decided I won't waste any of my time. If you (plural) can't write a one line answer to a bug report or click a reject PR button, then why should I put any effort?

Isn't it nice "git clone" was invented?

> If you (plural) can't write a one line answer to a bug report or click a reject PR button, then why should I put any effort?

You wrote a PR because you benefited from source code that somebody on the internet shared for free, and wanted to share that work for free as well. See the PR as just one way to open source your patch. You could put it on your blog, in an email list, or keep it in a fork.

By opening a PR, you make it visible to other people who also benefit from the project and who may be interested in using it.

> then why should I put any effort?

Something I really want to say about this: if you decided to open a PR to an open source project, it is very likely that you put less effort into your PR than the other put into the open source project. But they gave it for free without complaining. You don't have to do it, but you can. And you will still have put less effort into it than the author.

> You could put it on your blog, in an email list, or keep it in a fork.

Get serious. Nobody's going to look into forks of a project to see what other people improved. Not even github has a search that good that would show bug fixes and improvements from forks that someone is searching for. How would you even search? (Well, to be honest, maybe Github has, or maybe Copilot can do that kind of search based on a half a page text description of what I'm looking for, but I'm really not aware that it exists.)

> By opening a PR, you make it visible to other people who also benefit from the project and who may be interested in using it.

Yeah, but if I have moral standards and care about not wasting those interested people's time, then I have to keep the PR forever maintained and rebased on current HEAD, even if I don't need to update my fork that often, or I stopped using that project altogether. If I didn't do that, then I would be a hypocrite.

Just sounds like you've moved the goal posts to something completely different. This entire statement is addressing people frustrated with their half broken PRs being closed. It has nothing to do with "not clicking the reject button"

No I didn't. I said the same thing from my first comment: Ignoring PRs with no review, accept, or reject is wrong.

Sorry, unless your IP is being infringed, you don't get to decide what's private or public. The internet is a vast and wondrous place. Figuring out which parts of it are worth your time is a you problem.

Picture this scenario.

You make one really good birthday cake. Following the success of this went to your local school fete out of the goodness of your heart and set up a cake stall, had a complaints and suggestions box on the table, maybe even had a donation tin out. You know it's out of the goodness of you heart because everyone will SEE you doing this and maybe you'll get hired by the local bakery.

But then it's a bit of a long day and you start screaming at everyone who came up to you for wasting your time, rejected requests to not put broken glass fragments in the cakes, get into a fistfight with the local health inspector who pointed out you need certain food prep hygiene practices. You get big mad, and leave your stall in a huff, where hapless strangers stumble across your cakes only to find they are now covered in bugs and get sick from eating them.

Would this be acceptable or unacceptable behaviour on your part? Are you as the cake stall operator taking advantage of the the commons in any way (donations, showing off your bake-folio?) Are you damaging the commons or people visiting the commons? Does your free speech expressed in cake form outweigh the rights of people to tell you to change what you are doing? Does your freedom of expression mean you should never be accountable? Should people be thankful that you let them have cakes covered in bugs, even if they get sick as a result? Does the local health inspector who is an expert in a domain that overlaps with everything food have any standing?

This is a contrived thought exercise; obviously.

But I would bet that you clearly identify that violated social norms aren't great; you would agree there are expectations about access to a commons have implied standards of behaviour for all parties; you have expectations around quality vs general safety, etc.

Now imagine I make a weird cake and I think it's interesting. I put up a poster with a photo and a recipe and say "thought this was cool, try it if you want." And then some nonce comes along and tells me off for a reckless disregard of other people's time and nerves. Compares it to an open manhole cover that could get somebody killed.

Throwing some interesting code onto a web site isn't like setting up a booth at a community event. Its not even really like putting up a poster, since posters get seen by whoever happens to come nearby whereas web sites only get seen by people who seek them out, but it's about the closest you'll get to a real-world analogy.

Probably won't get anyone killed, but I've seen loss of data. Valuable data. And now you're going to point to the disclaimer and 321 backups...

Websites are seen by everyone seeking not a site, but a feature, via search engines. Same as a poster if you look in that direction.

Why are you trusting data to some random open-source project with no documentation?

The search engine is only going to direct you to my open source repo if you're searching for whatever it does. It's as if you'd only see my cake recipe if you were searching for cake recipes. And just like cake recipes, your search results will contain everything from superb production-tested projects (if there are any) to random stuff people have put up that isn't really used.

If you're searching for software and you find some random project that isn't very well tested or maintained, and you put that project to use in a place where it can cause data loss, that again sounds like a you problem.

Let me change the perspective:

Are you in any way no matter how small responsible for what you create, what you post online, and what effects those actions have on other people?

Sometimes!

If I post an article about how drinking bleach makes your skin softer, I share responsibility when someone does it.

If I post an article about how to make your own bleach, and a reader says “that sounds tasty” and drinks some, that’s not my responsibility in any way.

If I put up some trash code with a README that says “this is solid, reliable code that you should use for storing all of your financial data and family photos,” I have responsibility for what happens when people do that. If I just put up some trash code and say, I thought this was interesting and wanted to share it, and some numbskull decided to use it for something critical without thoroughly evaluating it first, not my responsibility.

Anything you in a public space, will be made social by someone eventually. If you (GP) don't like it then tough shit. That's a You Problem, not an Us Problem.

And you can make github repositories that others can see but not the rest of us, it just costs a little money. You can host a book club at your house too and not have to listen to other people snicker at your friends' commentary on the book at the coffee shop. But if they're gonna keep saying stupid shit in the middle of a Starbucks, then someone is going to butt in.

Making a PR is also in the public space, and if your PR is lazy spam, you deserve a less generous response than the one Hickey gave.

A less generous response is one thing. Getting defensive about it and saying nobody is entitled to shit is something else entirely. And that's where the antisocial people of HN usually go.

I agree. I would add a pet peeve of mine:

- Don't publish a code of conduct and then be an absolute asshole to contributors (pick a lane and stick to it)

I feel there is a lot of performative policy published, which at the end of the day is lip service. Actual users or contributors come along and follow the guidance, expectations, etc? They then find themselves treated like a hostile entity and there is a weird prevailing attitude here that's "fine".

> me keep my patches to myself.

Exactly.

Nobody is entitled to your patches.

I can't tell if this is satire or not. I fear that it's not.

"If you make your project public, it means you want and expect people to use it. You could at least write some documentation, so I don't waste my time and then find out, days later, it isn't capable of what I need or I simply don't know how to use it."

WTF? If I make it public it's because I think other people might like to see it. That runs the gamut from "this is a production-ready project that solves a major problem" to "this is useless but shows some interesting techniques you might like to learn from."

If you spent days fiddling with an undocumented project that turned out not to do what you need, I'm not the one who wasted your time. That would be you.

If you want to limit yourself to only looking at high-quality projects with documentations and active bug trackers and PR reviewers, go for it. That's probably a good move! But putting some source files on a web server does not imply any further obligation, in those areas or any other.

I sing in the shower all the time. I'd rather have my fingernails pulled out one at a time and the video sold to psychopaths than go to an open mic night or participate in a talent show.

I know what I am and I know the degree to which people suck. Don't walk into abuse teeth first and then make a surprise Pikachu face about it.

You’re right, but for some reason I keep coming back here anyway.

I don't know why people keep sharing this. It's highly offensive and inflammatory. Plenty of open source projects consider themselves a community which welcome newcomers, take governance seriously, and ensure that even if suggestions or contributions are rejected, it's done in a thoughtful and considerate way. Acting like a jerk isn't a blueprint for how to be a good maintainer, it's how to be a jerk. And this "us experts vs. entitled users" mentality is cultural poison.

> Plenty of open source projects consider themselves

I don't think that the article is incompatible with that. If you benefit from an open source project, that's good. If you benefit from more (a community, documentation, support, ...), that's even better! But you are not entitled to any of that.

> And this "us experts vs. entitled users" mentality is cultural poison.

I can't say what the author's mentality is, but after a lot of open source, my opinion is this: users of open source code tend to not understand that they are not entitled to anything at all. I don't say it in a bad way: they just aren't.

If you read the discussions here, it's obvious: many users of open source genuinely believe that it is not enough to share work for free: if one feels like sharing their work for free, they somehow "should have the decency to share even more work for free" (like documentation, support, reviews). But that is wrong! Again:

- If someone shares code for free, it's nice.

- If someone shares code for free, and documents it for free, and reviews PRs for free, and offers support for free, it's even nicer.

That's all there is. Maybe that someone is an asshole. You don't have to like them, you don't have to use their code, you don't have to engage with them. It's not a good thing to be an asshole. But still, you are not entitled to anything. Just take whatever you want from what is offered to you, and don't complain about not receiving even more.

> I don't know why people keep sharing this.

Because:

> It's highly offensive and inflammatory.

We're talking about the internet, pal. It can be traced to How To Ask Questions The Smart Way. "Hackers" normalized the idea that if you can code you don't need basic decency and manner.

Calling someone a jerk for their views on how OSS should or shouldn’t function isn’t appropriate.

It’s actually completely out of line and smacks of the very entitlement described in the piece.

Don’t agree with his views? Go make your own project and run it however you want.

Cultural poison? The truly cultured understand that a monoculture would be the real poison. There’s room for all modes of operation in OSS. Without “jerks”, there’d be no Linux and there would be nothing else of high value either.

If you want to sit around and hold hands then find a project where they do that, or maybe just take up finger painting.

> It's highly offensive and inflammatory.

It is sane and factually correct.

> Plenty of open source projects consider themselves a community which welcome newcomers, take governance seriously

Rich is taking governance very seriously. Others aren't and give nobodies the right to vote. In any case, he's factually correct. Nothing in open source implies anything about any type of governance, as "Open source is a licensing and delivery mechanism, period".

> Acting like a jerk

Pot, meet kettle.

It is sane but not rational, sometimes factually correct in places, highly offensive, and inflammatory. I don't use Clojure and reading it makes me never want to use Clojure.

Everybody is entitled to say (but not dictate) how something should work. Holding and expressing opinions is an innate human right, and the developed world only takes it away in extreme circumstances. Talking about open source governance is not an extreme circumstance.

We are not legally entitled to basic politeness, but politeness is enforced socially rather than morally, and failing to be polite means risking social consequences. If I used Clojure and I read the linked article, I would avoid hiring Cognitech, which is the exact problem Rich mentions.

> It is sane but not rational, sometimes factually correct in places, highly offensive, and inflammatory.

Calling this offensive and inflammatory can only come from someone who is extremely conflict-avoidant. For my Italian sensibilities, it's quite milquetoast.

You might need to go back and read that one again, this is the faintest criticism of a lengthy screed in which the person you are replying to labels user-hostile behaviours as "acting like a jerk" and generally disapproves.

Your counter argument to this is to just be contrarian and imply they are a jerk... because, well, you don't agree with them. You didn't add substance to the discussion (facts, evidence, argument seeking middle ground), you just sought to set fire to someone because you were uncomfortable with the dim prospect you might be wrong/guilty of acting like this/be the subject of the criticism.

Do you see how this undermines your point of view/actually re-enforces the validity of the criticism?

The only thing I get from your reply is that I'm sorry HN doesn't allow blocking users.

The other side of this is that if you want your open source project to be useful to people, relevant, included by default in Linux distributions, highly regarded by the community, and so on then it's expected that you treat your users well.

Not every project aspires to such things, but if you do then the path to success requires at a minimum not treating users as a burden.

Some users might be particularly rude or entitled, in which case you can politely decline their feature requests and move on.

Basically, it's never rude for a user to file a bug report or request a feature. It's never rude for the maintainer to decline to implement a feature if they haven't budgeted time (or other relevant resources) to do it, it doesn't align with the fundamental goals or architecture of the project, or they simply don't know how to do it.

It would be rude for a user to demand of maintainers more than they're willing to give, and it would be rude of a maintainer not to be at least somewhat mindful that spending at least a little bit of effort to respond to reasonable requests, fix known bugs, and keep documentation accurate and up-to-date can prevent a lot of random strangers from wasting a lot of time on something that isn't useful to them. No one has any contractual obligation to provide anything, but I think everyone should treat other people's time and attention as a scarce and valuable commodity, not to be wasted.

> 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 doesn't mean expressing your opinions about Hackernews, the thing or some proprietary software, even negative ones, is inherently wrong.

I agree. I’ve often wondered why open source maintainers get worked up over this. You can just ignore them. Odds are the maintainer spent zero seconds thinking about the person before the negativity over the course of their entire lives to that point. Why let them have free rent in your head now? Chuckle and go on not thinking about them for the remainder of your life.

There's a very good reason: we need the users to be aware of this, and exert self-restraint in communications with the developer team otherwise public fora become untenable and the core team, to avoid being pestered, will be forced to switch to closed, invite-only, comms channels (private mailing lists, private Discord servers, etc...). It's very valuable to be able to keep publicly accessible channels.

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.)

> - 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.

In general it is already in the license. Even permissive licenses like Expat have (in ALL CAPS no less)

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO [...]

There is zero need to indicate anything about CONTRIBUTING whatsoever because already it is clear that the developer already indicates that nothing can be taken for granted.

Of course it helps to be open about expectations.

I for instance don't put CONTRIBUTING instructions online but so far all of my stuff gets so little attention that I have received almost no feedback about my free software at all.

To me, this is perfectly OK and in line with the expectation that I for instance put my code online mostly for my own benefit. If it helps anyone else, all the better. But don't derive any more expectations from it because it's free...?

> you put a license on your work that (often, but not always) says people need to share their changes

Permissive licences do not say that. Copyleft licences say that people need to share their changes with their users.

As a maintainer, if I choose a copyleft licence, it is to protect the users. If someone makes a product using my code, I want the user to be able to see that code even if it is modified. It does not mean at all that I am interested in adopting those changes in my repo. No need to be prepared for it.

> maintainers do owe this culture some form of communication of their intentions

I disagree. I already give you my work for free, that's something. I don't see why I should get out of my way to communicate my intentions. When in doubt, you are free to contact me (e.g. open an issue) and ask. And I am free to not answer.

> 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.

Happened to me as well, and it is very frustrating. But that's on me, I should have asked before doing the work. It has happened to me that I asked, the maintainer explained what they would want, and then I spent weeks in my free time working on a PR that never got reviewed. Just because the maintainer didn't have time. It is frustrating, but I am not entitled to anything. My PR can live in my fork.

If I need my PR to be merged upstream such that the upstream project takes ownership of it and maintains it for me, then I should look into a contractual relationship with them.

Maintainers are sometimes not perfect. But they are providing known value, and you are trying to add something with unknown value. That's an asymmetry which doesn't look like a mutual exchange. So I'd downgrade most of the hard obligations you describe to "it's really smart to do this."

I agree with the behavioral observations. People shouldn't be assholes just because they can. That applies to everyone everywhere. Reminding someone with a bit of power to not be a petty tyrant is fine with me.

I find code I wrote that violates advice I've given other people all the time. I've made release cycle mistakes on projects I maintain that I would have bet money a few years ago that you'd never catch me making.

The siren song of One More Commit or One More PR is out there, and there's always going to be some fraction of your work you do that in retrospect you should have slept on, maybe twice. (I recently fixed a problem I've been staring at for a year in an afternoon after a new, stupidly simple solution presented itself on a walk)

But there are lines, and you have to be careful not to go across them either too far or too often. Or you have to be utterly indispensable like Linus, and have a thick skin to criticism... like Linus. And if you have a thick skin to criticism you don't write long screeds about how everyone else is wrong and you're right. You just move on.

> 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.

There is a subtle line here and I have some sympathy for both sides of this debate because for a long time there, and in some ways is still happening under different names now, we conflated decency with respect. So it gets a little weird.

We treat the guy ringing our doorbell with decency. We treat our new boss with respect. We treat the person spouting nonsense with decency, not respect. Free Speech says I can say anything I want but it also says that you can call me names for doing so. That's the difference between decency and respect, and it's important everyone knows what they mean when they say 'decency', instead of what they think they mean.

I honestly wish there were more women participating in these sorts of conversations because they have to deal with weaponized politeness on a daily basis, and I suspect the correct line for open source is a little closer to their definition of decency than mine.

Women deal weaponized politeness a lot. There. Corrected it for you

That's so edgy.

I just said that?

what you're describing is how to be a nice person, that really has nothing to do with owning a source code repository. Fortunately, most people are nice but there's no requirement or obligation to be that way when setting up a public remote repository (github or otherwise).

> Maintainers don't get to be rude just because they run a project.

Everybody gets to be rude. They don't need your permission.

The rest of this is you just sort of making up standards that you're asserting that other people are obligated by "human decency" to adhere to. You're demanding ownership of other people's time and effort, and declaring that this obligation is triggered by the fact that they've already freely given of their own time and effort. You're the person who has been fed once and sues on those grounds to be fed forever.

If you, yourself, don't want to be rude, maybe reframe this as a list of suggestions that you think might be helpful to interact with people like you.

I don’t disagree with Rich Hickey a lot but this one grinds my gears:

> All social impositions associated with it, including the idea of 'community-driven-development' are part of a recently-invented mythology with little basis in how things actually work,

Open source is effectively a gift economy. And we actually talked about it being so in the late 90’s early 00’s. Gift economies are older than human civilization. This is not a recently invented thing, nor is it a mythology. They have rules about how much either party can impose upon the other.

Yes people on the receiving end of those gifts can be entitled brats. That doesn’t negate all social contract on the other side, until it escalates far beyond propriety.

Edit to add:

Rich’s sense of authority to say things like this comes not from his prowess in writing code, which is noteworthy, but from his substantial participation in that gift economy that he is negating here. That entitlement he feels to say something is how gift economies work. Those who gave more have the authority to comment on what happens next.

No, he's completely right on that point. There's this weird misconception in the tech community that "open source" means "you'll accept my contributions if I send them". I've seen people try to argue (in complete seriousness) that SQLite isn't open source because the developers keep contributions private.

I don't know where the mistaken conflating of "open source" and "developed by the community" comes from, but it is mistaken, and Rich was quite right to push back on it.

> I don't know where the mistaken conflating of "open source" and "developed by the community" comes from

i think people confuse github with a social network and all the extra social conventions that come with that instead of just a place to remotely host a git repository. Open source is just a license model, if no PRs were accepted, all communication ignored, and no bug fixes made globally forever an open source project would still be open source. Take the code and do what you want as long as you comply with the license, that's all open source is.

If you don't want your github work to be considered social, MAKE YOUR REPOSITORIES PRIVATE.

80% of my shit on github is private. And I have taken my licks on mistakes I made on the rest. I had to redo a whole release roadmap because people were rightfully pissed at me for cutting a corner. I didn't have to kiss their asses about it, I just had to say what I was going to do to prevent it from happening again.

It sucked, and I am better for it.

I’m not disagreeing that people get entitled about the gifts they think they’re bringing to someone else’s party. Yeah it’s frustrating and sometimes it’s bonkers. Don’t bring “lutefisk” to someone else’s party and expect to be celebrated as a hero.

That doesn’t absolve the host of all scrutiny in perpetuity, and that’s usually how these conversations go. This is a popularity contest and trying to have that conversation with, frankly, people who have never one a popularity contest is exhausting. But you still have to point out things to your unrepentant friend even if they don’t seem to listen.

It’s not a conflation. Open source is two things. One, a way to trick your boss into letting you keep using tools you developed here at your next job. Two, a gift economy we are all participating in. Gift economies are a community. Whether you want it to be or not, it is.

That we listen to Rich Hickey at all is almost entirely down to the latter. He has given many gifts and this entitled to a soapbox precisely because of the gifts. You can’t have your cake and eat it too. Suck it up buttercup. Or, continue to act confused and indignant as people call you and people like you out for the rest of time. It’s not going to stop.

A gift economy only exists between people who agree that they are participating in one.

Gifts between equals create expectations of reciprocity. If you use open source software, you are expected to contribute. Accepting a gift without an intention to reciprocate is an admission of social inferiority. Users who don't see themselves as socially inferior to developers are not participating in the gift economy and not bound by the social contract.

> If you use open source software, you are expected to contribute.

No, not in a million years.

No, emphatically not. We are surrounded by them and people behave as if they are without acknowledging it. Saying it isn’t so doesn’t change the fact that we give more attention to people who [give] us free shit. It’s baked into our little monkey brains.

> Accepting a gift without an intention to reciprocate is an admission of social inferiority.

I wish I'd read your response more thoroughly before responding from my phone in a parking lot.

You do not understand gift economies at all. You've reduced them to transactionality, which is capitalism, and capitalism kills gift economies for fun.

Robin Wall Kimmerer is a molecular biologist who is also a mother and a member of the Anishnaabe peoples. Braiding Sweetgrass is a book everyone should read, but you especially. The Serviceberry is a much shorter and denser discussion of gift economies but I doubt it's approachable for anyone who has read nothing of hers.

Perhaps we are talking about two different concepts called "gift economy".

The gift economy concept I'm familiar with has been used to describe various non-state polities, where people exchange gifts to maintain relationships and establish social standing. Gifts between peers are expected to be of similar value, while patrons are expected to give their clients more valuable gifts than they receive.

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.

For those who maintain FOSS projects: How often when a user requests/demands your attention to support/fix/enhance the project to suit their particular needs, do they actually pay you something once you explain that what they are asking for, comes with a price?

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.

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.

IME, on GitHub (or the other major public repo services), it's far more likely than not that I can pull up an old version of a project from 10 years ago if I want to experiment with it. (In case other old things used it as a dependency, I really want to reproduce an old result, etc.)

On the vast majority of other distribution platforms, it's at best a 50/50 as to whether (a) the platform still exists with any of its contents, and (b) the authors haven't wiped all the old versions to clear up space or whatever. The former typically fails on academic personal websites (which generally get dumped within 5-15 years), and the latter typically fails on SourceForge-style sites.

That is to say, I am not a big fan of the popular alternatives to Git repos as a distribution method.

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

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...

When I was 25, I, like a lot of developers, wanted to write my own programming language. I realized that I should not create my own programming language around the same time that I realized that neither should most of the rest of us. Your brain has to be bent into a very specific pretzel shape to make that work.

I've since worked with some brilliant devs who were too smart for their own good and a lot of that came down to the difference between being able to create a solution and being able to explain a solution. There's a reason I hold Richard Feynman in very high regard, and it's down to his ability to pluck things from a very high shelf and hand them to 'shorter' people.

The last person to find his way onto my Do Not Hire list, was one of these too smart but inarticulate folks. Since that list is only about half a dozen people over almost 30 years, I think that says a lot about his character and what an absolute bull in a china shop he was. I'd need an Uber after discussing his many flaws over beers. Or maybe a stomach pump at the ER.

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.

My latest apps are

* Cardsphere (Magic card trading website) wishlist to inventory comparer * Scryfall (Magic card database) search result CSV Downloader * Cube Tagger, an app to easily tag cards with function tags for easy categorizing in cubes (boardgamified collection of Magic cards)

The vibe coding part is wonderful because I can "make" the software I want. However, it always takes hours of runs to get to where I need it to be because I'm unpracticed at project planning. I constantly hit critical edge cases and UX problems.

One of the issues is that even if you do write documentation, some people that say they want to contribute will not search for it and directly proceed to ask the overworked maintainer to point them to the exact page of the documentation of their interest.

I don't know. On one hand, they're totally right; their project, their rules. On the other hand, it feels crappy to contribute to an open source project that doesn't actually take contributions (or derides new contributors because they made a mistake in their diff or PR due to missing a sentence in their gigantic contributing doc) or use a project that silently changed hands and is now full of tracking, malware and other junk.

"You are not entitled to this explanation." After reading this, I immediately heard the song "I Don't Care About You" by Fear (https://open.spotify.com/track/6kuSvl812VLLpFhPegnCfY?si=2a0...) in my head.

Related. Others?

Open Source Is Not About You (2018) - https://news.ycombinator.com/item?id=39905557 - April 2024 (1 comment)

Open source is not about you (2018) - https://news.ycombinator.com/item?id=31957554 - July 2022 (205 comments)

Open Source Is Not About You (2018) - https://news.ycombinator.com/item?id=27003713 - May 2021 (5 comments)

Open Source is Not About You - https://news.ycombinator.com/item?id=18538123 - Nov 2018 (277 comments)

But it is about humans in general!

Humans who want to use the software, and humans who author (or control dependencies of) 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.

Edit: "still" is not even a fitting word here, because the reliance of commercial software on FOSS is the societal change that causes this change in issue reporting, I'd say.

Crowd dynamics / psychological aspects cannot be ignored anywhere.

Sometimes you just gotta get the frustration out in a gist

I love this article.

Nobody owes you a new release, or a signed binary, or a feature you care about.

There's a project where almost all the merged PRs since the last release are mine and I'm practically vibrating with trying not making a big deal out of it.

It's not unlike how the game I gave someone as a birthday present on Steam has only been played for 2 hours and I'm absolutely certain it'd be his favorite game if he just got out of the character creator and played the goddamned thing. <cleansing breath> It's fine. Everything is fine.

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.

(edit: I totally misunderstood the parent comment and wrote this reply. I've apologized for it in comment below. I could delete this comment but I am leaving it here so that others don't get confused when they see the replies below it.)

> or that anyone should have more power just because they are active in the project.

So you are saying that although I create a project to solve my problems but as soon as I make it open source (so that others can also benefit) my power on the project will become equal to the power every random person on earth has on my project?

If making my project reduces my power on the project, why would I ever open source anything?

Good thing that open source world does not work like that. When I make my project open source, I still have full power on my project and I decide what goes in it and what is rejected. I have no reason to not use the powers I have on the project.

If it ever became like you say that as the creator of an open source project, my powers will be equal to the powers of every random user, I'd stop making anything open source.

> If making my project reduces my power on the project, why would I ever open source anything?

For me, especially when I'm increasing the bus number of something I worked on at work, it's down to two things. Either I'm hoping that my 'power' will remain the same but the 'power' of the project will grow and the new people will take their share out of the surplus.

Or, I want to focus my power elsewhere, and as long as I'm sole proprietor to this project I will be associated with it to the exclusion of other things. It was having my face pressed against glass of shiny new things I was iced out of at work that finally taught me the value of sharing. Indispensable can make you typecast. Deputizing someone has benefits that usually outweigh the costs.

Straw man + slippery slope.

I never said that, or implied it. It would be dumb to say that someone who creates an open source project is at the mercy of the people who use it.

But, many people have had the experience of dealing with loud voices in open source communities, and sometimes abusive voices. Or people who are pushing/promoting things that they want but are actually contrary to the goals and well being of the project.

As I stated, that power is a potential route to abuse. This is absolutely true whether the person is a maintainer, contributor, or creator.

If you create an open source project, of course you have absolute power over it... to suggest otherwise is foolish.

And we have seen projects that fail or collapse due to lack of leadership, corrosive culture, myopia, or burnout. That is inevitable.

My point is that we need to be realistic about these things. This goes back to the original post that "open source is not about you". Users aren't "owe" anything by a project or its creator. At the same time, creators/maintainers have a relationship with the community.

How they choose to manage that relationship is their choice... but we should be aware and honest about what that means and how it impacts the project (and the community).

Yes, totally fair. I totally misunderstood your original comment. My bad and my apologies!

Wow - I really appreciate you taking the time to look at it again. My original comment was written quickly, and probably no where near as clear as it could have been.

I respect your willingness to modify your original stance upon closer examination. Non-ironic hat tip.

If someone gives ice cream for free in the street, we don't say "you should have the decency to provide chairs and tables so that we can enjoy our ice cream", do we?

Open source users have to understand that when they benefit from an open source project, it's like receiving a gift in the street. You don't get to ask for more: either you accept the gift, or you don't. If you go an complain because they should have a vegan option or different flavours, you are the problem.

> Open source is a licensing and delivery mechanism, period. It means you get the source for software and the right to use and modify it.

Once again confusing the two and proving that “Open Source” was the worst thing to ever happen to “Free Software”

Some businesses confuse Sales with racketeering with a computer. People don't want to hear your pitch deck every time they use a product, or budget for something critical to their operations every month.

FOSS is simply computer users doing what they have always done, and accomplishing things no one (or no company) could ever do on their own.

For those that paid tens of thousands of dollars to keep the office talent happy with what they know software wise, it has been my observation the training and support is often still missing on the commercial options as well... once they get paid.

Finally, most become locked into a vendors up-sold ecosystem as they choke off compatibility with other external product workflows. And you can't add something to fit your specific use-case, as single users don't matter in business products.

FOSS is usually better in almost every way most of the time, but often lacks stability as upstream projects continuously undergo permutation. Note, even the old closed-source Nvidia GPU drivers in kernel <6.0.8 are now abandoned in >6.15 to send a lot of old Linux laptops to the landfill.

Confusing skill issues with the realty of the software business is common. =3

> Sign in to GitHub to continue to Gist

That's new

Edit: https://web.archive.org/web/20260213161600/https://gist.gith...

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!

A tiresome sysadmin I've been talking to is under the impression of: "well, if <open-core-saas> stagnates or otherwise shifts focus away from our interests then someone will just fork it, duh!" .. when glancing thru Discord successors

It balances with ability to fork. So if you’re not happy, then fork.

Open source has many altruistic and smart people that like to learn and build while benefiting others.

But then you also have high ego people motivated by building a personal brand, prestige and status... and open source is just means to that end. While their contributions are valuable, conflicts of interest arise.

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.

Quick questions; as this project clearly exists in a community-less vacuum:

How do people keep finding and using it?

How do complaints or feature requests keep arriving?

Why is the published to an audience that doesn't exist?

Or is it fair to say the project has published in public, so has contact with a very broad community already?

> Quick questions; as this project clearly exists in a community-less vacuum

It clearly does not, however the members of the community need to know their place.

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.

Or.. fork it

I just fucking love this guy.

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.

You are not entitled to that food or land over there, neither am I. What are we gonna do about it?

You're naive if you think your immune to social exploitation just cause you write some words. Your entire being is defined by social exploitation. You adopt our language, our roles etc but you believe you can transcend them when it's convenient. Developers aren't entitled to make people reliant on software and ghost them. I'm sure teachers, firefighters and congress (lol) would all love to stay home and wait out the collapse of society, but they go to work because people rely on them. It's an odd thing for me to build a firetruck, go around pretending to be a firefighter (out compete and make the firefighters lose funding) and then snap back at people expecting me to work for free even though governments do fund open source.

If you volunteer as a crossing guard, even if you aren't paid, you have a duty of care. There aren't currently laws against your behavior, but if there is a pattern of such behavior it may be illegal. The EU through the CRA is doing good work in this regard.

Of course governments shouldn't compel people to work (>.o). But nobody wants to live in a world of abandoned core infrastructure projects. You aren't an exception, but you thought yourself special when you decided to work for free. Now instead of understanding why people work for money you scrawl against human nature.

Could you fix this bug? Please.

https://hibernate.atlassian.net/jira/software/c/projects/HHH...

if you publish something to the public, you are responsible for it to a degree.

You can't just say "i'm not responsible" and avoid responsibility.

"I put rat poison in candies and put it outside my door for halloween, but it had a sign that says 'The owner is not responsible for any harm or effects resulting from consuming these candies'" , see how silly that sounds?

If you advertise your software as intended to do a thing, licenses might protect you legally, but not morally or ethically, from people attempting to use it, and relying on it. Imagine if the maintainers of glibc decided to backdoor it, but since they're not responsible for it, and you're on your own for using it, it's not their fault right? If the maintainers of openssl decided to drop sha256 support, they're not responsible for the chaos that ensues right?

FFS! how clueless are devs sometimes. It's insane.

This right here is the worst part of open source. Don't use open source! that's the message here. If you're in the EU, and you're seeing all these efforts to rely on open source software to avoid American-made software, read this post! Don't use open source software because the authors of that software could sabotage their work or do anything they want with the software and they feel like they have no obligation to anyone. Does that sound familiar? At least American big-tech gets fined on a regular bases for doing nasty things, at least they have executives you can imprison if needed be. And they're not under any illusion that "i'm not responsible" is a get out of jail free card. Use only properly supported software.

I'm a bit salty, because I've relied on and supported Open Source software several times before. Every. Single. Time. Even when i'm creating PRs, they're dicks about it. Even when I create issues. Who cares, they're not even responsible enough to refuse support.

Here is what should be done, if most devs really agree with this take: You can write any software you want, but publishing it to the public should only be permitted after you pass tests, like your identity being verified, support process being established,etc... You can't just give away food, vehicles, houses, just about anything you can think of without some requirement of that sort. If devs are going out of their way like this to be irresponsible, then the chaos and damage they cause must be mitigated.

When you "Open" anything, it could be a door, software, a canister of nerve-gas; you're responsible for what comes out of it and how it affects others. you're also responsible for what happens when others enter it.

The only way around this I can think of is if perhaps in every way a person can download or access your software, publish a clear and unmistakable warning "Do not use this software for any reason at all. Do not read the source code. Do not attempt to build it, or run it." even then, you're not free from all responsibility.

It's like malware authors that put disclaimers like "for educational purposes only" on their malware publications. you'll still go to prison, it isn't a defense.

I'm not claiminng random people have entitlements to get their PRs approved, or issues resolved. But for developers to go so far as show hostility towards people who use their software, is not far from actually publishing harmful software.

A good and reasonable balance might be that software that's used by more than a certain threshold of people should be required to either support their software, or close-source it. You have free-speech, not the right to put the public in harm's way. Honestly, I think this sort of whining is what is driving all these verification laws and restrictions.

I think being glad people are using your software so much, and they're requesting support, creating PRs, and so on is the right attitude with open source software. If you get mad about all that, you're hurting the freedoms of open source devs all over by trying to make your software open for the sake of clout or whatever.

And really, don't publish a repository to the public if you expect no contribution. Just host tarball on your site. "Open source is not about you", yeah, sure, it isn't about irresponsible devs getting free advertisement and farming clout either.

> if you publish something to the public, you are responsible for it to a degree.

Have you read the open source licenses? They say the exact opposite.

I believe I've addressed those licenses multiple times in my comment. you're not responsible for the support of the software, at the same time, you're not free of all responsibility for it either (regardless of what you say in your license). A license is not a contract either. there is a reason even eula's sometimes require you to actually scroll through them before you can hit accept. and even then, eula's have been thrown out of court plenty. "I'm not responsible" does not absolve of you of responsibility, you don't get to decide that, laws decide in court. but in terms of ethics, it's even more dire, if you know what impact your action or inaction will have, legalese can hardly excuse ethical obligations.

Can you add the year (2018) to the submission title? https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

[flagged]

What do you mean?

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

But it is evidence for causation.

Is it?

Yes. If A is correlated with B, is A more likely to cause B than if A is not correlated with B? Clearly yes.

> Open source is a no-strings-attached gift, and all participants should recognize it as such.

I've always felt this is incorrect. First, because lots of people use open source to further their careers, it isn't. Open source contributions are paid work if you benefit from them in any way. Second, if you use open source yourself, your work is no longer a gift. You're contributing back to the community you've taken from. The person you're being a jerk to because it's a "gift" might be the author of other software you've used.

Why is this down-voted? Everything we do in this industry rests upon somebody else's gift of free/open software, that is the reality of it. I do feel an inclination to contribute back however I can, even if it's just documentation, or submitting a (properly detailed) bug report, for precisely the reason described here.

It is correct. Just because your livelihood might hinge on a specific project doesn't mean that its developers have any obligation to accept your patches. It means you have to be very careful in choosing which project you hitch your wagon. Obligations are created, in order, through law, contracts or personal relationships. If you have neither, you have nothing.

> It is correct. Just because your livelihood might hinge on a specific project doesn't mean that its developers have any obligation to accept your patches.

I think you responded to the wrong comment, since I didn't say anything about being obligated to accept patches.

I responded to "You're contributing back to the community you've taken from" which implies that one has some obligation to accept a patch (calling it a contribution). Just because you're offering doesn't mean that others are obliged to accept or even review it.