Comment by newcrobuzon
7 years ago
Though Rich is right, it pains me to read this because it is indicative of some disputes in the clojure community. I might be mistaken, but it seems that Rich is reacting to Chas Emericks' twitter post (https://twitter.com/cemerick/status/1067111260611850240). In his comments he has stated: "Finally, from a practical perspective, my core-level contributions always came from some source of pressing need in an actual, present, needs-to-work project. If I know a problem isn't going to be triaged for months and solved for years, then I'm out."
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.
Rather than reply to any of the various downthread issues, just a few clarifications:
* 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.
Thanks Chas for responding. Apologies for the parents metaphor if that made you feel uncomfortable - since at the time of my writing lots of comments on gist and HN were concurring with Rich and talking about "weeding out toxic personalities" I was just trying to come up with a metaphor that would offer a different perspective - that this is a type of disconnect that benefits no one and that there is no side that is clearly "good" or "bad" since all sides are needed for the whole ecosystem to work. Rich's statement was aimed at some core contributors (I am guessing now probably a bit more at Tim and less at your follow up tweet) and that worries me. Imho this situation is a lose-lose scenario: for Cognitect to lose contributors, for contributors to have spent hundreds/thousands of hours in vain and for anyone from clojure community who placed his bet on clojure and invested substantial time in learning/using/evangelizing it (affecting his/her market value in the process). Anyway thanks for all the work on clojure! I am still using some of your clojure libraries!
Normal people who are using the software to get something done just maintain a local fork where they can fix fires as fast as they want, then treat upstreaming (if any) as a background task that is allowed to take the necessary time.
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.
You clearly didn't read even my post you're replying to, nevermind being aware of the rest of the story/context.
> "If I know a problem isn't going to be triaged for months and solved for years, then I'm out."
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.
As someone not in the know, Rich's post seems like an extremely aggressive and arrogant piece. When you put it in context, it does make more sense.
> As someone not in the know, Rich's post seems like an extremely aggressive and arrogant piece.
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
I don't have any reason to doubt the truth and logic consistency of either Rich's post or your reply. The problem is not the logic, it's the rhetoric. For anyone out of the loop, he sounds like an interstellar douchebag. And, because the article is public, this can become a problem.
10 replies →
The person in question isn't some random dude who just makes demands, but a visible volunteer. Otherwise the tweet would have no voice, and Rich Hickey wouldn't feel like spending the time to tell someone how they weren't worth the time.
It could easily have applied to dominic and the earlier npm fiasco, though.
People are getting a bit entitled as to what an open source maintainer has to do for them.
It's exactly how video game audiences are.
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.
2 replies →
That was a different issue IMO. I've stopped maintaining open source projects that others rely on, and I owe them nothing. They can fork my code if they like.
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.
I can sympathize with that. But I think Rich made a very bad choice of rhetoric, and this is probably going to bite him in the ass.
2 replies →
you mean the guy who gave his project, including namespace, over to a hacker?
> Though Rich is right, it pains me to read this because it is indicative of some disputes in the clojure community.
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?
> I am genuinely curious why you, or anyone else, would think he is right.
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 don't know much about the Clojure community... but this article says "Open Source Is Not About You." If this is the generic "you," ie the random user that's coming in and complaining about something, then sure.
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.
I understand that this is his position, what I don't see is his reasoning.
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.
> Because Rich has the rights to do what he wants with his time and money. (Like everybody else.)
This feels like a non sequitur. Having a right to do something is completely orthogonal to whether you should do that thing.
1 reply →
I mean, he is right about open-source only being a binding license for the source, and in this case, the Eclipse 1.0 license in no way entitle users too any kind of support, decision making authority, opinion, voice, or any other such thing.
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.
Because when you invite me to your house, I do not gain the right to demand you rearrange the furniture. You built that, you put things in their place. If I want something for it I can only make a case for it, and that case hinges on convincing you.
I don’t know this person but there’s a fork button on github. “Pressing need” —> fork
Seems to be an ego thing.
The you have to maintain your own fork. And keep up with changes upstream. And reconcile the two forks. And... And...
I'm not even mentioning the potential split in the community.
Yes; it’s definitely less convenient to write and maintain your own software compared to having someone else do it for you.
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.
You can fork, fix the issue, and issue a pull request and/or start a discussion about the issue and potential fix. That is the core of open source - not demand that others fix the underlying issue for your problem.
5 replies →
So you're asking someone else to do that work for you. Look, the user has a few choices:
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.
If it is for his pressing need, he can maintain a fork. And it is not difficult to maintain a clojure fork given its release cadence.
This is the genuine issue.
No. Whoever is leaving should have left without ranting is the only issue I'm having with this aggravating distraction. Chas knows very well how Clojure is authored. I suppose some people believe their contributions or community status give them higher authority and a right to publicly pressure Rich Hickey. But in reality they are only doing more damage to the community and likely Richs creative process on the way out. If this is the price for their contributions I want to live without them without even thinking about it.
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.
> Chas knows very well how Clojure is authored. I suppose some people believe their contributions or community status give them higher authority and a right to publicly pressure Rich Hickey.
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 thread made me look at Clojure again (it has been a few years since the last time). Searching for Bayesian inference libraries I came across this: https://github.com/cemerick/raposo
"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...)
That quotation is prefaced as "lessons I hope to take to heart". He's not commanding everyone to do it.
Would you agree that talking about unavailable code or libraries is "irritating to talk attendees" and "even more disrespectful towards organizers"?
6 replies →
I'm fuzzy on the details, but there's legal precedent for suing someone for reproducing your code even if they haven't copied any of it.
Otherwise its called marketing and you have to pay for it. (Not get paid for it)
Sometimes I hear presentations just to learn how they approached a problem remotely similar to mine or used tools I am interested in using myself. The library and its exact implementation are mostly irrelevant in that case.
One thing that I've found increasingly distasteful (I've noticed it in the React community, but it may be a wider trend), is the use of conference talks to announce/launch projects.
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.
I guess it's no worse than the other main use of conference talks I've seen, which is to hawk the speaker's latest book. Maybe that's diminished somewhat, I have not been to many conferences lately but 10-15 years ago it seemed like most talks were peppered with phrases like "I talk more about this in my book..."
1 reply →