In the Ember community, dissent is not just tolerated, it is encouraged. We will fail if people believe they have to stay silent when they disagree with the core team or community consensus.
I want to quote from one of my blog posts, all the way back in 2013:
Developer communities have a habit of crafting mantras that they can repeat over and over again. These distill down the many nuances of decision-making into a single rule, repeated over and over again, that the majority of people can follow and do approximately the right thing. This is good.
However, the downside of a mantra is that the original context around why it was created gets lost. They tend to take on a sort of religious feel. I’ve seen in-depth technical discussions get derailed because people would invoke the mantra as an axiom rather than as having being derived from first principles…
Mantras are useful for aligning a developer community around a set of norms, but they don’t take into account that the underlying assumptions behind them change. They tend to live on a little bit beyond their welcome.
The topic at the time was “progressive enhancement.” Ember has been around long enough now that we’ve since developed our own mantras. We need to make sure that the ease of falling back on those mantras doesn’t cause us to lose sight of the bigger picture. When we engage with other community members, particularly those who are new, we need to ensure that we’re understanding and validating their unique circumstances, not shutting them down with terse dogma.
Ember is also a big tent. Even though each new app comes with the same set of defaults, it’s unrealistic to believe those defaults are right for every situation.
To quote from the Rails doctrine:
As with anything, though, the power of convention isn’t without peril. When Rails makes it so trivial to do so much, it is easy to think every aspect of an application can be formed by precut templates. But most applications worth building have some elements that are unique in some way. It may only be 5% or 1%, but it’s there.
With so many controversial ideas to its credit, Rails could quickly become an insular group of ideological hermits, if we required everyone to exhibit complete deference to all tenets, all the time. So we don’t!
We need disagreement. We need dialects. We need diversity of thought and people. It’s in this melting pot of ideas we’ll get the best commons for all to share. Lots of people chipping in their two cents, in code or considered argument.
There is no “right way” to build an Ember app. You are not “doing it wrong” if you want to use GraphQL or Redux or MobX or TypeScript or Flow or Mocha just because that’s not what comes out of the box. No one but you knows whether a particular tool will make you and your team more productive.
We will continue to add primitives and stabilize private APIs in Ember, so that it’s easier for you to integrate with other tools while preserving the compatibility and shared solutions we value as a community.
While that happens, I have a request of you: whether it’s on Twitter, Slack, Discourse, or anywhere else we gather, validate the pain people are experiencing. Before getting defensive, acknowledge their frustration and offer to help—which has a tendency to defuse the situation altogether. If someone shares an experiment or an idea, encourage it or provide constructive criticism that is respectful of the work they’ve already put into it.
And if you see me or anyone else getting this wrong, call it out (gently). It’s a bad habit that’s easy to slip into, and we can only change our culture if we all help each other spot it when it happens.
As Sir Jony Ive said, “While ideas ultimately can be so powerful, they begin as fragile, barely formed thoughts, so easily missed, so easily compromised, so easily just squished.”
Let’s make sure we’re fostering a community that doesn’t squish ideas.
Would love to hear your thoughts and feedback.