So this is not some grieving random person from crowd - Chas is a person whose libraries and contributions I value tremendously and he certainly made LOTS of contributions to clojure OSS landscape for free and out of his good will as well. So ultimately this feels like your parents are arguing (which is never a good thing) - you like them both and you just want the arguing to stop and you just want everybody to live together in harmony. But here you go, Chas has moved away from clojure now. And I have to say I am very sorry to see him go.
Some problems are easy, low hanging, do it yourself. I guess that's not the issue here, but it's worth mentioning as a lot of OSS projects don't cater to solving these. (Expose some little bit from an underlying lib, make something configurable, etc.) And there are the uh-oh we have to refactor half of our codebase to solve that one by the way totally valid problem. And that's usually not a one weekend "project", and it is understandable, that it might take years.
And at that point, I feel that the entitlement of "make this work for me, because there's a project that depends on it" is the problem. Sucks to be the guy who have chosen the wrong tool, even if it looked like the best tool. It happens all the time.
Seems to be an ego thing.
As a power user, to me this doesn't appear to be a community issue. A handful of individuals take themselves way too seriously and don't realize how they are hurting someone emotionally.
The entire idea that a different process would produce better results is an insult in the first place. The progress and effect we got with Clojure with no enterprise funding/influence is a true miracle.
I'm not even mentioning the potential split in the community.
"Never, ever, ever give a talk about a library or other code publicly unless it's in a public repo prior to the talk. Period. (Exceptions to this might be things like case studies and such.) Doing otherwise is surely irritating to talk attendees, but it's even more disrespectful towards organizers, as their acceptance of your talk may have been implicitly preconditioned on the attendees being able to benefit from the code/library/project in question."
Is the expectation now that when you talk about something it is necessarily going to be open source? (And from there the expectations grow and grow...)
People are getting a bit entitled as to what an open source maintainer has to do for them.
It seems that way? To me, it seems like a reasonable response to how many people treat any kind of volunteer-led effort.
For example, I help mod a fairly popular subreddit, r/cscareerquestions. Now, we don't have a problem with people suggesting changes to sub rules or have meta discussions and even complaints. No community is perfect, the mods certainly aren't, etc.
However, the vast majority of complaints are of the completely useless variety. They're the vague one-liners -- "this sub used to be good, and is now bad for generic reasons I will not elaborate on" -- that usually have no clear basis in reality, nor any practical solutions even to the extent they're true.
And when I try to earnestly engage with people who have the most upvoted complaints, 95%+ of the time, there's nothing there. Probably half the time they just don't respond, half the remaining time they just loose another snipe or parting shot before disappearing, and most of the rest is something in the set of {doesn't actually happen/no evidence; assumes everyone agrees with them; problem is actually well-diagnosed but the proposed solutions are laughably naive}. The number of complaints or suggestions that are meaningfully actionable is very, very low.
What I've found looking at other subs and ours, is that generic complaints about sub quality and mod team actions are a quick and easy way to upvotes, but it's rare for someone to actually be well-informed on the topic and have actually thought through the problem and solutions they suggest.
So when Rich says, "Did you know that most patches/issues have poor problem statements, no description of the plan (read my code!), no consideration of alternatives, no tests, no designs, and are ill-conceived and/or broken in some way?" that doesn't surprise me in the least. Even when people nominally want to contribute, they usually don't seem to try very hard. For me, it's gotten to the point where I'm writing a guide for subreddit criticism and suggestions to try and improve the quality of the complaining.
tl;dr - even when something is reasonably well run by volunteers, people love their low-effort gripes and snipes
But honestly the stakes are higher than video games. If you go around advertising your package, get people to depend on it, then compromise them later, that's malpractice on your part. That isn't how society runs so it's rather obvious when people get mad that there's a landscape full of anarchy when it should look more like modern civilization.
Like it or not, npm and the node community has not prioritized its reputation. And the mechanisms that keeps bad operators out of npm open source rely on a relatively small company considering the actual business livelihood that relies on npm integrity. It means the community is okay with continuing to use npm, and that means that the community doesn't have a healthy way to maintain itself and build trust. It's going to rot, I think (and hope). It's just going to be a bunch of tribal nomads moving from project to project until someone social engineers a compromise and they're off to find another huge dependency graph again.
At the very least, Clojure is telling people what it's about upfront.
Other package managers are not immune to this, btw. npm is just often the whipping boy.
I am genuinely curious why you, or anyone else, would think he is right. I can see why people would agree or why he wants to do things a certain way, but to be right you have to have arguments backing up what you are saying. I don't see that in this post. Am I missing something?
As a project maintainer I’ve made the mistake several times of being too permissive with pull requests. Someone comes along with a feature they’re excited to add to my project. I don’t need the feature myself. They exuberantly make a PR, and I eventually merge it. Before long it turns out there’s a bunch of bugs with that feature, and the original author is gone. Do I waste my time fixing their code, for a feature I never wanted and don’t use? Or do I ignore the bugs and let the smell of low quality work waft over my code base?
These days I default to refusing most feature requests, even if they have decent PRs. I write most software for fun, or to scratch an itch. I don’t do it because I want to manage a community. If you want to add features and build a community around a project I’ve written, great. I’m happy to link to your fork in my readme.
Forking is not a symptom of failure. Maintaining a fork is sometimes just the ticket price to control your destiny.
The former will remain exceedingly polite, up to and including the part where they tell you to go f yourself.
The latter are the ones you can actually depend on in a crisis, because they won't be busy playing social games to cover their own behind.
I'd argue that if someone is seen as a giant douche because they won't automatically cater to someone's sensibilities, that's a sign of a real douche, who is so used to being marketed to and "handled", that fair, reciprocal treatment is experienced as rudeness.
That is the gap between the kind of culture open source used to have, and what some want to turn it into today, and which is often incorrectly dismissed as a lack of civility.
Civility is that which allowed civilization to form, not what passes for it once others have already done the work. If that is a problem, it's because it's been manufactured into one on purpose.
I'm out of the loop and didn't get this sense at all. His points seemed fair enough to me. There's way too much entitlement evident amongst people who use, and sometimes even contribute, to OSS[1]. It gets frustrating, and Rich has explained why.
[1] I've never been an maintainer of a popular OSS project, and don't want to be, but a few years ago I was a custodian for a relatively popular free (as in beer, not as in speech) tool, and we'd often get emails from users acting like we owed them something.
Uh-oh. I hadn't been aware of this. Do you have a link, please? (Quick google didn't help much.)
Because Rich has the rights to do what he wants with his time and money. (Like everybody else.) It is completely within his rights to establish his own governance and contribution model for his version of Clojure. At the very least, I don't see an argument why it's NOT within his rights to do so.
Of course, there are several corollaries. The first is that nobody is forced to use or contribute to Clojure. The second is that, given that Clojure is Free Software, it's possible for someone else to pick up the baton, make a fork, and run it their own way. (egcs and XEmacs both come to mind as examples where someone did this and it wound up improving the original.... so there _is_ precedent.)
I wouldn't feel terribly bad if someone made this fork, but I'm not going to do it myself. Unlike Rich, I'm not willing at the moment to make the personal sacrifices that'd be required to make this sort of contribution. Neither, apparently, is anyone else.
So Rich gets to make the rules. Because he (and Cognitect) have paid the dues. Whether that's good for Clojure in the long run remains to be seen. (But honestly, my semi-informed take on the ecosystem is that it needs library maintenance much more than it does core language improvements. The core language has been an excellent choice for many purposes for years.)
I tend to agree with this. I've always had a great deal of sympathy with OSS devs and maintainers, but if you've gone out of your way to evangelise people onto your platform (OSS or otherwise), then leave them high and dry, resulting in a load of complaints/bitterness, you have to bear at least some of the responsibility for that outcome.
Thankfully it's still usually the case that the content of the talk is generally valuable. But ultimately, if I'm paying to fly somewhere and see your talk, I'm there to learn, not to witness your own self-promotion.
Thought experiment: assume for a moment Rich is now running Clojure into the ground, and this is a bad thing. Who are the people that _do_ have standing to try speak up and make things better? If not Chas, who?
> The entire idea that a different process would produce better results is an insult in the first place.
No, it's not. Projects grow in complexity as they are used. It is only natural that they require improving governance models as this happens.
Another thought experiment: Name another successful open source project that's stayed on the same sort of governance model throughout the first ten years of its existence. These all usually work the same way: there's an initial individually driven chunk of core development and then the process broadens out to a more community driven effort. (With individually driven spikes along the way that are contributed into the whole.)
It really reminds me of a phrase I heard fairly recently: "Go fast alone, go far together." At some point, a transition probably has to be made.
> The progress and effect we got with Clojure with no enterprise funding/influence is a true miracle.
True enough.
And now we're looking for the next true miracle: sustained development and use over the next twenty, thirty, or more years.
This feels like a non sequitur. Having a right to do something is completely orthogonal to whether you should do that thing.
If this is a veiled criticism at a major contributor to the community, then I think it's disingenuous. If you're trying to foster a community around your OSS project/product (and Cognitect is doing just that) then you take on a set of obligations to that community, especially those who contribute code to it in good faith.
Yeah... there are really several conversations that could be had:
1. Rich deserves credit and respect for personally taking on a cost that ranges into the hundreds of thousands of dollars to fund Clojure. Very few people do this, and even fewer bring the taste and judgement Rich brought to Clojure.
2. Rich/Cognitect currently own the Clojure governance model and they can do with it what they want.
3. Maybe the current governance model isn't what's going to bring Clojure the next 20-30 years of viability.
My take on it essentially this:
1. Yes. I wouldn't/couldn't do it myself. (And I've started down the path at least once.)
2. Yup. Maybe it will be what the platform needs to grow and thrive. Maybe not. Maybe it will be attractive to users and developers. Maybe not.
3. At some point, this will probably be true. Given the history of companies and projects, this shouldn't be a surprise.
This is false dichotomy. Overwhelming majority of people care about both. When your tone and delivery is insulting or diminishing them, they see it and react to that too - those who don't tend to end up bullied and disrespected.
Also people who dont care about tone and delivery quite often backstab. Just like they dont care about others while there is no crises, they care even less when crisis is there.
https://github.com/dominictarr/event-stream/issues/116
Edit: it attempts to steal crypto-currency; it doesn't mine it.
1) find a work-around (maybe unwind his or her own mess) 2) manage a fork 3) work with the existing process
I've worked around people doing all three of these options but what I've regularly found was that taking a look at unwinding your own mess is the right approach for the vast majority of cases.
Also the person in question is also a well-received volunteer, which is why this is getting traction to begin with, which is why Rich Hickey would even take the time to tell someone that they aren't worth the time of the very response they're reading.
* I don't know exactly who Rich is responding to, but I can't imagine it's for rando users who drop off drive-by TODOs for maintainers. More likely IMO it's in response to a number of people who have contributed significantly to clojure itself and to supporting projects and resources that have spoken up in recent times with various critiques.
* I'm super uncomfortable with any comparison to this kind of "dispute" as being anything like that between parents, etc., though I can see how some might think of it like that. Really, it's a disconnect of expectations and a lack of communication, which I'm glad has been resolved definitively.
* I do still use Clojure (though more via ClojureScript than otherwise), it's just not my primary rig anymore, and I'm strictly a user. The contribution process was a minor factor, not the driving rationale for my looking elsewhere; though, as I said in the posted tweets, I surely wouldn't have tarried so long if I knew earlier what I know now.
If everyone is free to do what they want with their own time and money, they are also free to condition their participation in the project. As far as I can tell that is not what he is saying though. What he is saying is that you are not entitled to anything, meaning that you can't expect anything for your participation.
If he had just said that he runs the project how he want and people can "take it or leave it" that would be another thing. But as I read it he is specially questions the right of others to question the project. Essentially saying that they don't have that right. It is this position I don't see him backing up with an argument.
This is just fact. You can go read the license to learn more about this: https://opensource.org/licenses/eclipse-1.0.php
That part of what Rich is saying is pretty much indisputable.
The second part, is related to what is best for Clojure. And the argument is simple, Rich says what is best for Clojure is a thorough review process of all changes to its core and standard libs, with a very high bar towards contributors and their contribution. His argument is that this has worked so far, and has created the solid piece of software that is Clojure today. Thus its own success is proof that it is a good enough process and is good for Clojure.
The argument against is that contributors find it too hard and too much work and thus very little contributors make it through the process. Though I didn't really see them mention any alternative process suggestion. It seems they were mostly wanted their patch to just be merged in without challenge.
I'm not sure how much he advertised it.
This is part of the problem I have with things like npm, cargo, etc.
They defaults are set to try to suck up your work and get you to make it public.
Consequently, semi-useful things get loose probably long before people intended them to and probably long before people realize how much work they just signed up for.
I think you are misrepresenting what Rich wrote. He said you are not "entitled" to a response. That is not an evaluation of someone's worth, but a statement about what they are owed, or not owed.
E.g. numerous GNU/Linux distros maintain local patches for numerous packages: kernel, gcc, glibc, ... Some of these take years to get upstreamed, if at all.
The problem is that this process doesn't work so well for people who just want to leave their imprint on that project (that one and only official project, not their private fork).
Saying I'm not going to use this as my main tool if I can't have a more or less free reign in shaping the destiny of its one and only official version comes across as a bit of an infantile tantrum.
I don’t see a problem with talks that show code (to support whatever the talk is about) without giving it away.
Read the whole thing in context. He's apologizing for jumping the gun - for giving a talk about a library he intended to release, before it was ready. The implication is that it was probably a "hey try this library!" kind of talk, that has little value to the audience without the code, so he's saying he should have waited.
Giving talks about closed code that will never be released is separate from all that, and clearly not what he's talking about. Hence the exception, "case studies and such".
The dev isn't responsible for the giant mound of stupid that is npm but we all have to take the world as we find it or fix it.
In the context of the world as it is projects deps having deps having deps where the practical protection against a developers machine getting pwned and eventually millions of users getting pwned is more or less developers checking to ascertain that a given library is bob who works for google and not lame hacker number 2388 its poorly considered to hand over libraries to people you have no reason to suppose are trustworthy. A reasonable person could suppose that might not end well for a multitude of projects where 182 deps of deps of deps aren't vetted again per point release because in practical fact its impractical to do so while it is very practical for individual authors to not transfer control of names and publish info about their authorship.
Unlike never updating or expecting individual orgs to vet 182 deps written by anon people with every bump so a reasonable person ought to do their best to make the workflow that might have some hope of working work.
If you didn't want ANY responsibility whatsoever you could have not published it globally.
Anyone who imagines that responsibility is merely transcriptional that it only attaches when money changes hands has literally missed the majority of human civilization including the more recent parts where people that give away free food are still expected to wash their hands, get food handlers cards, practice food safety, pass inspections etc. You aren't required to provide a vegan or kosher option or even make good food but you can't behave maliciously or negligently.
Given how projects are actually used by virtually everyone authors actions appear negligent. Given the hypothetical bad actually already happened it appears that judgement is irrefutable.
You are your brothers keeper whether you want to be or not. Software isn't special it works like every other civilized endeavor. Wash your hands and don't scratch your ass please.
And yes, it's users' responsibility to decide what code they trust. But "I trust developer/organization X" is a reasonable way to decide that, and auditing every single release is far, far more expensive. I'd be betraying their trust if I let a complete stranger release an update in my name.
"You put at risk millions of people, and making something for free, but public, means you are responsible for the package."
"There is a huge difference between not maintaining a repo/package, vs giving it away to a hacker (which actually takes more effort than doing nothing), then denying all responsibility to fix it when it affects millions of innocent people."
Where do these people get off?