Maintaining Online Communities
“Nobody else talks about this,” says Katz, as he explains the trade-off between user growth and community health. “Anyone can grow — but if your goal is to create something that lasts longer than 18 months, you have to invest in social cohesion.” Being a member of the Rust Core Team, and a former member of the Ruby on Rails and jQuery Core Teams, Katz is no stranger to open source communities, and he attributes Ember’s longevity to the community approach they’ve had since the beginning.
According to Katz, the foundations of a strong developer community hinge on two major factors: shared values, and being clear that you’re not trying to cater to all front-end developers. Ember knows what it’s trying to achieve and therefore has a carefully designed scope, which means people are working toward the same goals. “This allows the team to create spaces in the community for every type of developer,” says Katz, “and to bring the community forward into new phases of the Ember lifecycle much easier.”
Creating Space For Everyone
As Chad Hietala says in the Ember documentary, “without strong communities, the technology fades away.” For Katz, his priority is to create space for the members of the community so they can have opportunities to contribute. Emphasis is placed on democratic decision-making and empowerment so that every member feels like they’re doing their part. “There are three kinds of people in a community and they correspond to three different stages in open source development,” says Katz. “There are pioneers, settlers and town planners.” The pioneers are those developers who enjoy the bleeding edge of technology and drive the growth of the framework through experimentation. Settlers are responsible for a long-term strategy, and town planners are responsible for tactics and execution.
Finding roles for these three categories of developers is important for maintaining any open source community especially, as the project matures. The core team understands that the majority of day-to-day app developers just want to build great functional apps without being caught up in the progression of the framework. Katz explains “it’s important to shield [the day-to-day developers] from the excitement.” The core team makes sure the ‘settlers’ can see the activity happening in the Ember ecosystem but are free to continue their everyday work while the pioneers chart the next course.
What sets Ember apart in the open-source community is their focus on non-technical innovation — particularly the team’s migration strategy. The migration process is a strong part of that ‘social cohesion’ Katz mentioned earlier, which pulls the framework forward with the users so that everyone is always on the same page.
Refactoring apps so they’re compatible with major framework updates can take weeks, even months, to fully transition, which is a hard bargain for startups and smaller firms with smaller engineering teams. So what you find is a community spread across different eras, but since Ember was founded on the value of ‘togetherness’, it’s an issue they tackle head-on.
The RFC process
“Everything we do, we do together,” Katz said during his keynote speech as he discusses Ember’s RFC process. “We’ve used RFCs for things no other community would use, like switching to Discord or updating the website.” These are things outside of the actual framework that people do want to engage with. The engagement also shows a different side of the community, one which considers all opinions and allows members to be heard. The same process is used to consider the future of the framework and where the community would like to see it go — and if something doesn’t make sense for the majority of users then it’s dropped. “Nothing is communicated to the community until the team has one-hundred percent confidence in it,” says Jessica Jordan of the core team.
The team has made it easier for app developers to migrate, encouraging a gradual transition instead of a huge leap which helps users and teams work at their own pace. You can’t force anyone to update but you can motivate them to stay as up to date as possible. And the core team does this in a number of ways, most notably giving the community plenty of heads up in advance; they don’t have to wait until the next conference to find out what’s going on. “I want to make sure the depreciation process is going to help people move at the same speed,” says Katz, which is why old features are marked several months in advance, giving plenty of time for teams to incorporate in their depreciation workflows. Code mods, CLI tools and user guides are also available well in advance to aid in a smoother community transition meaning the majority of users can take the next step together.
The Ember team recently introduced a new concept called Editions, where they launch features outside of major updates that can be easily adopted and integrated. Taken from the Ember website, Edition releases are “the time to synchronize Ember and the wider ecosystem and help ensure that Ember users are getting a cohesive, polished experience.” Ember’s first Edition, Octane was a package of new features and upgrades and was compatible with any code used in the 3.0 era. This meant minimal code refactoring for developers upgrading to Ember Octane, which significantly reduced the upgrading burden and encouraged more people to opt-in.
Just the beginning for Ember
“We will be there to help you migrate across anything that happens in the ecosystem.” Migration is Ember’s best selling point, and while other frameworks might be growing at exponential rates, Ember’s track record of longevity suggests social cohesion is paramount when facing the major challenges of open source and popularity. There has always been a cloud of doubt surrounding the Ember framework from the beginning. Despite these claims, both founders and core members are hopeful it will remain stable and relevant over the next decade. As co-creator Tom Dale says: “Really, I think we’re just getting started.”
Thanks for reading! Subscribe for more original content from .cult