Skip to content

Instantly share code, notes, and snippets.

@mike-thompson-day8
Last active December 1, 2018 20:22
Show Gist options
  • Save mike-thompson-day8/2464b652b4e3378b5c6ffbb951966db6 to your computer and use it in GitHub Desktop.
Save mike-thompson-day8/2464b652b4e3378b5c6ffbb951966db6 to your computer and use it in GitHub Desktop.

Recently Rich Hickey's communicated to the Clojure community via a Gist. When reading it, I was struck by how similar it was to his previous communication via Reddit.

And that lead me to wonder: if that previous communication didn't do the job, why would this latest one work when it is so similar? Will his new communication cause some useful structural change or will we just see an action replay of this same community processes in another 6 months?

Unfortunately, I think we are stuck in a cycle and we'll soon see a repeat of this angst. Do the same thing, you get the same result. Fine, but what is it that might cause Rich Hickey's interventions to be ineffective? What could be done differently?

Before going on, we should acknowledge that there is a cost to these interventions. Rich Hickey appears angry when he writes them and he is striking out and down, and this is likely do some kind of damage to the community's social fabric. Now, that might be a necessary evil if they worked, but if nothing really gets resolved, it is all cost without compensatory benefit.

So, if this attempt from Rich Hickey's won't work, can I be helpful and suggest an alternative communication which would be more likely to cause structural change and, in the process, do less damage? That's crazy presumptuous of me, I know. But, if I were to try, how would I do it I wonder ...

Well, first, I believe his Gist is working with an inaccurate problem statement. He assumes the only problem is "developer entitlement". But, I only sometimes see that when I talk to people in the community. But I see other drivers too and so I think Rich has somewhat misdiagnosed the problem. Or at least not used something like the "5 Whys? technique" to get to root cause. He's striking at a branch of the problem, not at the roots.

The Second problem is that of "tone". When you are in a position of power, you get a lot of accolades AND you also get some shit. Good and bad comes with the territory, but unfortunately basic human psychology causes us all to focus disproportionately on the negative part. But, as a leader, you can't react just to that bad stuff and deploy your power against it. And you absolutely shouldn't deploy shaming and playing the victim card. Instead, you must largely ignore the negative and simply project a forceful clarity about how things are going to work. A firmer the message (without being tyranical) from the leader, the more people understand where they stand and they'll find that a relief and coomforting.

In addition to tone, in my opinion a large part of the current problem is what ISN'T said which leaves community participants performing Kremlinology to infer what's going on (which, again, leads to unnecessary/unproductive squirming around). So let's be brave and lay all the cards on the table, even if it is a litte concomfortable.

So here's goes ... here's what I think Rich Hickey should have communicated (I'll no doubt get shit for this attempted mindreading, after all I'm just a rando on the internet with no special insight, but whatever ...):


There's been rancour in the Clojure community and that, in turn, leads to unhappiness among the Clojure leadership group, so that's bad all around. I will now try to address that.

I've come to realise that the root of all these problems is poor communication, and incorrect expectations. I do apologise for my part in this and please accept this document as my attempt to put these matters right. I intend to be very direct. You may not like what I say but at least we will all enjoy clarity.

My first job here is to make it crystal clear that Clojure is not a "normal" Open Source project. Yes, the code is licenced as Open Source, but the processes around Clojure do not work like, say, Python which has a consultative, open, community-oriented process centred around PEP documents. In contrast, the Clojure process is much more closed and, occasionally, surprising. This is not to say it is completely closed, just more closed. Think "ajar".

This more-closed processes is designed to support me and my productivity. Early on, when Clojure was young, I tried a more open processes, and frankly it didn't work for me and I found I wasn't happy or productive engaging in that way.

So I changed the process. As a result, Clojure is how it is today. It is very important you realise that this is no accident and that it isn't going to change. Please adjust your expectations accordingly.

On the upside, you can look at Clojure's progress to see that this more closed process works well along many dimensions. The language is evolving under a singular vision supplied (mostly) by one person (me) and there are benefits to that (providing you trust my technical aesthetics and those of my advisors). There has been progress on Clojure over many years, with a steady stream of improvements, many of them significant, innovative and beneficial. This will likely continue.

On the downside, everything has to go past me, so I am the rate determining factor in progress and, yes, that slows things down. That's the tradeoff you accept for the benefits of a singular guiding vision. I accept the pressure that puts on me. Further, realise that I also work on Datomic and other projects, so Clojure does not get anything like 100% of my time. Luckily, Clojure started life on a high plateau supported by 50 years of Lisp research and production use. What a gift. As a result, a lot is already right.

Many of the significant new things we'd like to add to Clojure are not trivial and require deep thought and careful gestation. We can dwell on a problem for years before inspiration supplies us with a solution. For many problems, we can't force good solutions to appear faster with more people or will.

Another downside is that Clojure's progress is subject to my interests. If an area does not particularly engage me it can suffer from a lack of my attention. Yes, that will be frustrating if the area is of urgent interest to you. Improving "the beginner experience" is one area where this has been an issue. Let's all acknowledge that will be a problem from time to time and move on. I don't want you frustrated, I really don't, but equally I achieve a better overall result when I do things on my terms. To avoid frustration, you will need to adjust your expectations. This isn't going to change.

Having said that, please be aware that I am always actively listening. Right now, we're in the process of concretely addressing every one of the top 3 issues reported as problematic in the most recent Clojure Survey. I'd like to continue to be responsive to community feedback as possible, but I'm not promising anything. Sometimes my attention will not be where you think it should be, and there's probably nothing you can do about that. One thing that really won't help is whinging. Please remain as constructive as possible and assume best intentions from me even if you aren't getting what you want, which is difficult because none of us are saints. But please try. Please encourage others to try.

You'll notice that I have been saying "we" sometimes. I actually do have a very small group of people who I allow to help me. But the group is tiny, and unlikely to change. Alex Miller takes a great deal of administrative load off my shoulders and it is he who engages with the community. Yes, it would be better if I was directly engaging with the community on a daily basis, I know that, but that doesn't work for me, I've already tried that, so Alex acts as my proxy and I think he does a great job. I hope you appreciate that this can sometimes mean Alex gets wedged between me and outside agendas. Please continue to be kind to him. Further, I have technical confidants like Stu Hollaway who I lean on greatly. In addition, I'm very grateful to those that triage issues like Nicola, Ghadi and others. Finally, there's David Nolan and his team who look after ClojureScript - they are relentlessly kicking valuable goals (a soccer term).

While I do keep my distance from the broader Clojure community, I am genuinely grateful to all those who add so much to it, writing and maintaining the myriad high-quality Clojure and ClojureScript libraries and tools, many working like me on their own time. I really do understand how important community is and how much vitality it gives Clojure. Genuine, beautiful vitality.

I'd also like to acknowledge that people in the community have invested a lot in Clojure building code bases and skills. Many are "all in" on Clojure. It really matters to them. As a result, many have a vested interest in Clojure, its momentum, and its direction, and that's where things can get awkward. It leads to strong emotions about what should and shouldn't happen with Clojure, particularly if you feel stuff of interest to you isn't happening fast enough. I'm aware of this and I know this comes from a place of caring. But I might not choose to do anything directly about it. Sorry. I have to work at the pace and in the direction which makes sense to me. To avoid frustration, you will need to adjust your expectations. This isn't going to change.

I'd encourage you to get your company to sponsor ClojuristsTogether because that is a valuable community process and they too are kicking goals. Often their goals will make good sense to you personally.

When it comes to contributing to core, please don't be alarmed if you feel stifled or thwarted. This isn't personal. It isn't you. Even someone as knowledgeable about, and important to Clojure as Stu Halloway says contributing to core is "uncomfortable" for him too, and that it can have "disappointments". And please don't try to work out how it could be changed for "the better". I don't want it changed. Please set your expectations accordingly.

Having said that, we really DO take community engagement on Clojure core seriously and consider all patches and suggestions. It's just that the process WILL BE too slow for many. If you still want to go ahead and participate, please be sure to read this description of what you are getting into.

Realise also that my primary job is to say "No" - ask any language designer. Bloat is an insidious enemy and everyone has at least one idea about a new feature to add. So I say "No" a lot, and often tersely. Don't be offended. It might not be you. Sometimes I don't have time for long explanations.

Community engagement is not all rainbows and unicorns and it is hard, grinding work being on the recieving end as a maintainer. For every useful nugget of gold that comes your way via issues and PRs, there are 20 nuggets which are poorly thought through, misunderstand priorities, have no viable problem statement, are subtly wrong or just outright wrong. And behind a lot of them is someone very ardent about the "easiness" of their suggestion, certain of its correctness and wanting explanations (now!). So, there's a lot of triage work to be done. A lot of teasing out the issues. A lot of developing better problem statements, etc. At scale, this represents a considerable, grinding cognitive load.

This is a problem for all maintainers of Open Source projects. My solution is to keep my direct community contact to a minimum and to pay Alex to front the process, which he does manfully and well. I realise that Clojure does not match some people's, sometimes religious, ideas of how Open Source "ought to happen". Please don't try to convince me of your alternative point of view because I've heard it all before, I assure you. I'd ask that you acknowledge that every approach has tradeoffs, and that there is no universal good.

Using Clojure and contributing to the community does not confer upon you any right to say how Clojure is developed. It will be uncomfortable for you if you care a lot about Clojure and have strong feelings about what "ought to happen". To avoid any disappointment or rancour please don't engage with the Clojure development process with any sense of "entitlement".

If this is distressing for you, please go with my blessing to a technical space that better matches your sensibilities. Don't stay with Clojure and be unhappy because that does no one any good. Instead, do as I do, and try to get the best out of yourself by moving to an environment which best supports your own productivity and happiness.

So, onward. I'm excited by some of the stuff coming at Conj.


Useful?

Test: is it less damaging? (less victim-card, less guilt-hiving and less of an accusational tone, hopefully)

Test: is this communication more likely to cause a "structural change"? Would it reduce the chances of another cycle of angst?

Test: does it identify ALL the root causes? Does it deal with each sufficiently?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment