The only people entitled to say how open source 'ought' to work are people who run projects, and the scope of their entitlement extends only to their own projects.
Just because someone open sources something does not imply they owe the world a change in their status, focus and effort, e.g. from inventor to community manager.
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.
If you have expectations (of others) that aren't being met, those expectations are your own responsibility. You are responsible for your own needs. If you want things, make them.
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. 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, a mythology that embodies, cult-like, both a lack of support for diversity in the ways things can work and a pervasive sense of communal entitlement.
If you think Cognitect is not doing anything for the community, or is not listening to the community, you are simply wrong. You are not, however, entitled to it being the effort, focus or response you desire. We get to make our own choices as regards our time and lives.
We at Cognitect have to show up to work, every day, to make a living. We get no royalties of any kind from Clojure. We are in no way building Clojure for profit. Far fewer than 1% of Clojure users are our consulting or product customers, and thus contributing to our livelihood.
We take some of what we earn, money that could e.g. go into our retirement savings and instead use it to hire people to work on Clojure and community outreach, some full-time. To be honest, I could use that money in my retirement account, having depleted it to make Clojure in the first place. But I love working with the team on Clojure, and am proud of the work we do.
Alex Miller is extremely attentive to and engaged with the Clojure community. He and Stu Halloway and I regularly meet and discuss community issues. Alex, at my direction, spends the majority of his time either working on features for the community or assessing patches and bug reports. I spend significant portions of my time designing these features - spec, tools.deps, error handling and more to come. This is time taken away from earning a living.
I am grateful for the contributions of the community. Every Clojure release incorporates many contributions. The vast majority of the user community doesn't contribute, and doesn't desire to contribute. And that's fine. Open source is a no-strings-attached gift, and all participants should recognize it as such.
The Clojure process is not closed, but it is conservative. I think Clojure benefits greatly from that conservatism, in contrast to some other projects with high churn rates and feature bloat. If you disagree or imagine otherwise, that's too bad. It's my life and I'm not going to spend it arguing/negotiating on/with the internet. Write your own things and run your own projects as you see fit.
We can always do more, but it is specious to claim that the core team is standing in the way of meaningful contributions to Clojure, as opportunities abound: in library development, outreach, training, tutorials, documentation, giving talks, tool building etc.
And yes, on patches to core. 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? Community efforts to triage matter a lot in moving things forward - thanks Nicola, Ghadi and many others!
The time to re-examine preconceptions about open source is right now. Morale erosion amongst creators is a real thing. Your preconceptions and how you act upon them are your responsibility and yours alone. I am not going to answer for them or to them.
If the way Clojure works isn't for you, a process which produced Clojure in the first place, paradoxically, so be it. I'm sure you know better about the one true way to write software. But kindly don't burn the community down on your way out, with self-serving proclamations. Yes, everyone is entitled to an opinion, but, tragedy of the commons and all that.
I encourage everyone gnashing their teeth with negativity at what they think they can't do instead pick something positive they can do and do it.
Rich
p.s. My partners and coworkers at Cognitect were not consulted regarding this message - I am certain they would have dissuaded me. These opinions are mine alone.
p.p.s. I think the vast majority of people in the Clojure community are wonderful and positive. If you don't recognize yourself in the message above, it's not for/about you!
Hi Timothy, I hope you are well. I'm sorry that you think, and others might presume, that this gist was a direct reply to you or your post. Yours was but one straw of very many. I was certainly under a lot of stress when I wrote it, but it served as a useful release valve (I didn't quit :). I think it started a broader conversation about, and awareness of, the challenges of being a project creator and steward.
I will push back on the Clojure process being "optimized to require the least amount of input from Rich, while still giving him full control". That's not the case. It's a process oriented around increasing confidence. When we write software, we want to be confident it will work, and when we accept patches, we want the same thing.
Within the Clojure core team, a patch is actually the last thing we want from each other. A patch is something you make when the work is finished. A submitted patch on a ticket with only a symptom (if that) leaves all the work to the reviewer, because the code itself rarely contains a root cause analysis and almost never an accounting of other solutions considered with a case for the chosen approach. It can be much more effort to do that work starting with someone else's code than from scratch. So all a patch with no accompanying documentation of work is doing is saying "work on this thing now because I've made a patch for it" vs working on things for which there aren't patches but might be of higher priority/interest for the maintainers.
I agree completely about project development approaches forming a spectrum. And the closer you are to the bottom of the stack the more deliberate you need to be IMO. Unfortunately for many devs (to be clear, not you Timothy), moving from symptom to patch-that-makes-it-go-away is "work" and the patches one sees reflect that. Soon, that kind of symptom-elimination coding will no longer be the province of humans. Yet the challenge of confidently designing and developing reliable, flexible systems will remain, and it will still be the work, primarily, of considering problems and solutions, and only at the end, code and patches.
p.s. Thanks for your work on core.async! It remains a valuable and widely used contribution.