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!
I get a chuckle out of seeing this thread pop up every 6 or 7 months, as yet more people weigh in. Seems like 8 years later it still strikes some sort of chord with people. I would recommend that people read the post that prompted this response.
Having just gone back and refreshed my memory, I find it fascinating that this post chain is so opinionated and philosophical considering the original statements. Essentially what I said in my post:
The comments about people "owing" something to open source contributors, or even framing this as "it's not about you" is rather orthogonal to my original complaint. Yes it isn't about me, but that was never my claim. My claim was that the majority of people writing patches for Clojure were wasting their time because if the problem wasn't well laid out, concise, and able to be expressed in a single paragraph, it never had a chance of being accepted. And often when patches were accepted they were allowed in months or years later. I remember puzzling at a Clojure changelog that mentioned me as a contributor, as I hadn't submitted a patch in recent memory. Turns out it was a patch I had made 2 years before that release.
Now, almost a decade later, I find myself thinking about this again. I don't think we need to try and constrain open source to a single definition. Some projects work well with a "merge first, ask questions later", others likely need a stronger guiding hand. Much like how we had to differentiate GPL3 OSS from MIT OSS, we likely need to view OSS projects as operating over a spectrum. On one end you have the anything-goes-organically-grown projects that may break at any release, but they innovate quickly and get new ideas out in record time. On the other side are the more ivory-tower approaches, the one person pet project, the polished statue. These projects won't change much over time, but that can be a benefit for many types of projects.
If this chain of posts makes people stop and reflect on the projects they want to spend their time on, and the types of communities they want to build, then I think it was a success.