Today, I want to discuss trust. Not in trusting our code or our tools, but how we trust each other as people. I want to address trust, because it’s something everyone agrees is important, but not something I see anyone discussing how we can actually build. And actually I see several behaviors in the community which generate distrust, yet are not being addressed.
Starting with some definitions: what is trust? It’s a fuzzy thing, but generally, it’s that we expect others to do good by us, even when we make ourselves vulnerable (e.g. by showing something we’ve built or speaking up when we think something is wrong). When we have trust, things go smoother and people are happier. When trust isn’t there, relations and communication break down, and if you stay in an environment where you feel distrusted, it can make you sick.
It’s important to note that “being nice” does not mean you are trustworthy. It’s definitely a part of building trust, but you can easily be nice, and still be untrustworthy. And yet, much of our focus in the community has been being nice to each other, as maybe a way to implicitly build trust. But let’s focus explicitly on building trust some more.
First off, I want to apologize to anyone I’ve not inspired trust in personally. I know I’ve come off harshly in the past and it will probably happen again in the future. But secondly, though my behavior is my responsibility, I’m here to talk about trust, precisely because my harsh reactions have been partly driven by distrust.
As examples of where the trust breaks down, see e.g. when Evan recently did a talk at GOTO about the future of Elm, and one of our members responded like so:
If the trust had been strong, his initial reaction would likely have been more charitable. Similarly, if Evan had wanted to build more trust, then I believe the best course of action would have been to give some kind of heads-up about the talk here on the official forum.
Another example was when Luke’s infamous post went up, where the main instigation for him was that Richard had responded to him without trust. And that post triggered other stories where trust was missing.
Before we continue, I want to highlight some important points about trust and distrust:
- Neither trust nor distrust need be explicit. It can just be a feeling you have.
- Different people have different dispositions towards trust and distrust. What is trustworthy to me may not be for you.
- Distrust and trust are two separate things which can be present at the same time. I.e. distrust is not the lack of trust and vice versa.
So what’s generating distrust today, and how might we address it?
Transparency
You may think that “transparency” would be about roadmaps for Elm, what’s Evan working on, etc., but actually I think Evan has been decently transparent about that. Not in the sense that we know what’s coming when, but in the sense that we know he’s off somewhere doing his thing, and Elm will remain stable in the meantime.
But even though this information is out there, a key part of transparency is also that this information is easy to find, which I don’t think it is. You can’t find it on the main Elm page for example, and there’s no stickied post in this forum with relevant links for example. You have to search around to find things.
I’ve already talked at length about this particular issue before, because it extends to other aspects of the community too. In short, just figuring out how things operate is a very opaque task. Is Evan still around? Is the core team still operating? Who maintains various libraries and tools? Is my code going to break with the next release?
Overall there are some important analogies to The Tyranny of Structureless. Though it doesn’t apply 100%, there are some choice quotes about the kind of informal structure we have in the community:
As long as the structure of the group is informal, the rules of how decisions are made are known only to a few and awareness of power is limited to those who know the rules. Those who do not know the rules and are not chosen for initiation must remain in confusion, or suffer from paranoid delusions that something is happening of which they are not quite aware.
And
The second is that informal structures have no obligation to be responsible to the group at large. Their power was not given to them; it cannot be taken away. Their influence is not based on what they do for the group; therefore they cannot be directly influenced by the group. This does not necessarily make informal structures irresponsible. Those who are concerned with maintaining their influence will usually try to be responsible. The group simply cannot compel such responsibility.
In other words, the informal structure we have today works well for the people who are “in” on it, but can be a big barrier of entry for those on the outside. Not because anyone is acting unfriendly, but because the rules of the community are often not well documented and also differ from what other open source communities do.
This is one place where I’ve always felt a level of distrust in the community, where we say we’re welcoming to outsiders, but only in the way we speak and act directly to each other. In the end, I have a strong feeling this informal structure is a hindrance for people to feel included, and it makes the community feel two-faced; a simple and welcoming facade that makes people want to be part of it, but then also a complicated structure that makes it hard to answer how to get things done that are not entirely in your control.
I get that things are the way they are because Elm isn’t being built by a big organisation, but I don’t think we’ve really discussed the implications of this setup on how it sows distrust quite easily. I think it would be a big improvement with a bit more formal structure, and better documentation of the way in which things work. And if Evan wants to keep the informal structure, then at least make it abundantly clear how that’s working (which I had some suggestions for in my previously linked post).
A and B teams
The Elm community is separated into two “teams”: the A team (core team and blessed contributors) and the B team (everyone else). As per the above, it’s a very informal structure, but it’s there none the less. It’s also important to state that this constellation isn’t bad in itself, but I do think it requires a good deal of trust to work well. That is, both teams need to have good trust in the other. Unfortunately I don’t think that’s much the case these days. A few examples:
- With version 0.19, the B team lost capabilities they previously had: a foreign function interface (FFI) for calling JavaScript directly (restricting it to only the indirect calling via ports), and custom infix operators. Glossing many things over, I would say this was taken away because the A team did not trust the B team to use these features well.
- With these capabilities taken away, the B team also lost abilities to solve some of their own problems. For example, creating good Elm APIs for interacting with various browser APIs now became something only the A team could do.
- Evan has begun presenting his work on the next version of Elm in limited fashion, partly because he feels the B team has overloaded him in the past.
In other words, it feels like not much trust flows in either direction between the teams these days. There are other examples too, but I want to focus a bit more on the example with the browser APIs. When 0.19 was released, the A team essentially said “The B team cannot be trusted to build things which upholds the guarantees that Elm needs when calling JavaScript directly”. It may not have been intended that way, but I believe it was interpreted that way by many people on the B team. This also doesn’t have to be a bad thing, but it does put a lot of responsibility on the A team to then build Elm-native ways of doing the things that people want to achieve via calling JavaScript directly. If the A team had produced a lot of Elm APIs for accessing those web APIs, the B team would likely have a lot more trust in the A team today.
So why hasn’t that happened? Web APIs have been high on the wishlist for years now (as highlighted by State of Elm in both 2018 and 2022), and much work has already happened in the community, but much of that effort never made it into a state where it could be used with 0.19’s restrictions. I haven’t been part of all the discussions, but going via different threads and messages, my feeling is that the effort got bottlenecked on the A team for different reasons.
The A team had good intentions of course, wanting such APIs to be adhere to Elm ideals, and making sure they were of good quality in general. They also asked the B team for help, in theory making room for anyone to step up and add the APIs they needed. However, the A team had basically backed everyone into a corner: they put a lot of up-front requirements in this work, making it untenable for many people to engage in, while also making it opaque how to participate in it, since it’s very informal. It’s the point about transparency all over again, and now people were properly blocked by this process, because they could no longer build Elm code wrapping JavaScript code themselves.
Ultimately, the effort failed, and the web APIs you can use from Elm in 2023 are much the same as in 2018. And I think trust is at the core of it. Because I don’t think the B team felt they could trust the A team in this. It seemed like there was a low success rate in general, and the A team was asking for a lot up front before you could even start trying to write code to wrap the API you wanted, rather than more pragmatic access to APIs. Reinforcing for B teamers, that you’re better off not trying to improve your situation, and instead hoping someone else would be able to navigate their way through the process.
An alternative route that could have been taken could have been for the A team to build tools and documentation for people to use to verify that their JavaScript FFI was sane, and help them understand when to use it. There could also have been different distribution models for packages wrapping JavaScript APIs for example. Many of the pains people with using web APIs in Elm today would undoubtedly have been solved ages ago this way. This would hopefully have led to more blossoming in the community, where more people were able to step up and do good work, rather than be hindered.
This post isn’t about the specifics of web APIs in Elm though, so I won’t dwell more on that, but I think it’s a very strong example of where the Elm community has not been able to manage trust. The A team didn’t trust the B team, forcing the B team to trust the A team, and that trust has arguably not been rewarded. And so the relationship sours.
Which leads us to:
The echo chamber
When 0.19 was released with its new restrictions in place, many people who really liked Elm ended up leaving because they ultimately lost trust in the project for one reason or another. This also meant that a form of survivor bias built up in the community, where dissenting opinions became fewer, because if you were on the B team and unhappy about something in Elm, you had few options but to suck it up or leave.
The survivor bias also reinforced something that was already prevalent in the community before: a high reverence for Evan. This is not without reason, as Evan is very charming and tends to do well thought out work, but the trust of the B team was now becoming blind trust in my opinion. Part of the problem here is that, when the B team lost the ability to experiment with things like kernel code and infix operators, then that also artificially limited the B team from picking up some of the skills that Evan has built up, which just reinforces the distinction between the A and B teams. That is, there are very few people with experience in building APIs that bridge the gap between JavaScript and Elm without going through ports, and the B team now lacked a way to build that experience.
Ultimately this leads to a community where it becomes hard to criticize the A team because of a skillgap that is difficult for people to address, and where people are loathe to talk about the downsides of Elm, because it just reminds everyone how powerless they are to do something about it.
As an example of the echo chamber effect, in this discussion of VDOM rendering, Evan implicitly assumed use of lazy rendering in Elm when comparing to other implementations. This is a misleading assumption in my opinion, because lazy rendering in Elm is very easy to break without realising it. And yet Evan’s detailed (but, IMO, misleading) reply was one people supported a whole lot. After I posted my concern in there, a few people came out to agree about the downsides of lazy rendering, but I wonder, if I had not posted, would anyone else have questioned Evan’s premise?
I really wish for more introspection from the A team here. For example, listening to Evan’s talks, it’s very clear that he has thought a lot about how to manage other people’s expectations when they come to Elm from e.g. JavaScript. But it’s less clear to me how much effort he has spent on considering the consequences of his own actions on the community (like how an informal organisation can sow distrust).
For example, in the “What is Success?” talk from 2018, Evan discusses release cycles, and why people expect Elm to have frequent releases. His take is that this is an expectation coming from the JavaScript community, which simply doesn’t apply to Elm. But that sidesteps a few important points:
- Up until 0.18, Elm actually had “frequent” releases (multiple releases a year).
- Evan compares Elm to languages which had had long periods without new releases (Java, C, etc.), but doesn’t talk about how other compile-to-JS languages like CoffeeScript and TypeScript actually did have frequent releases back then.
- A key difference between Elm and the languages that Evan wants to compare it to, is that Elm does not guarantee backwards compatibility. This is also often associated with frequent releases.
- Though Elm is of course a language, it’s also a framework for web applications, which there have been many of, and which have often had frequent releases too.
In other words, maybe it was totally reasonable for people to expect Elm to have frequent releases in 2018, and this was a failure on Evan’s part to communicate how Elm should be perceived. That’s just an example of course, and not too important in itself, but I feel like I’ve seen a recurring pattern of “The problem is people bringing the wrong expectations to Elm”-like comments from the A team. Which feels like a lack of accountability, and unintentionally sows distrust, because it’s focused on what others are doing and perhaps shifting blame. A great way to build trust here, would be to acknowledge the precedents the A team are setting themselves, and how those might actually be damaging.
Summary
Distrust causes people to leave and frustrations to simmer, and I would guess that many B teamers have stopped engaging with the community because of it. And I know some people will feel like I’m beating a dead horse, but I think it’s really important that we realise how damaging some of the structures in the community can be. Which is also why I’ve acted frustrated before. Because I’ve felt the distrust, without having been able to put it into words. So at least now this is off my chest, and maybe there are others who are relieved that someone put this in writing because they felt something similar. I also hope this can be used constructively going forward.
I also want to say that it feels a lot like people are waiting for the next version of Elm to make things great again, but I really think Elm the language is not what is holding the community back. It’s the community management. And if Elm is to be positioned for the backend as well as the frontend, then that only means that the B team will come to rely even more on the A team, exacerbating any existing trust issues and potentially surfacing all-new ones too. For example, for those who do not feel their issues are being addressed currently, where Elm is only used on the frontend, why should Elm running on the backend build that trust?
+ round trip plane tickets + hotel nights with the interdiction to talk about what they saw. The justification of this is to protect Evan from being overwhelmed by community requests.
