I’ve never needed to interact with the core team because there seemed to be an answer for any type of technical question on platforms like Stackoverflow. Actually, no. A long time back, I asked a core member to check out my library I had spent a bit of time on and was basically told straight up by the individual that they had no time, to go write a blog post and maybe if enough people tweeted about my blog post, they would then come back take a look. Each have their own experiences I guess.
There’s countless discord communities out there that are thriving because the lead dev/team are answering all the questions. Not 10 mins mind you, but usually pretty quick.
I don’t think forking clojure is fringe tech idea. However, I’ve seen enough of dead/zombie forks to know that there better be a damn good reason to do so.
For me, a smaller runtime with more basic features will solve a pain that I’m currently experiencing. I find that the tooling sometimes breaks down on larger sized projects. For example, on the current project I’m working on, clojure is not used a production runtime but as a build tool. There may be memory leaks due to repeated reevaluation of vars and namespaces. Sometimes macro expansion runs out of memory due to JVM byte code restrictions. This is tolerable and does not affect production code. If it gets painful enough and if I have the time, then I would definitely think more about it.
What I wrote down was how I’d go about ‘forking clojure’. That would probably be the first thing I would do as I tend to like to see what others are doing before making a decision. Finding common ground between all the clojure derivatives out there would be a pretty good start. Others might have a more straight forward approach. Either way, I should think that people interested in such things will definitely find it more productive than trying to convince others that the language is easy.