Be the Bark

I was in Toronto last week for the excellent Toronto Ember.js Meetup, hosted and organized by @ghedamat. Toronto’s Ember community is second to none, and it was a real pleasure to be back in town! The full slides are here on SlideShare, but this post is a summary of the most important parts.

For my talk I shared a few recent thoughts about open source communities, how they are influenced by the businesses that adopt their software, and how Ember’s priorities can be thought about in 2016. A lot of this talk was inspired by and referenced Larry Wall’s essay Diligence, Patience, and Humility.

I began by talking about the virtues of a programmer: laziness, impatience, and hubris.

These are virtues of passion. They are also virtues of an individual. They are not, however, virtues of community. The virtues of community sound like their opposites: diligence, patience, and humility.

Perl was, for a moment, the future of web development. Just before PHP rose to dominance. Larry watched and helped the Perl community grow, and still shepherds it today.

In this essay he makes a comparison of the Perl community to an onion. This metaphor followed him around for years as the State of the Onion address, you can read them all here.

In this particular essay, he says this:

I’m still a little bit of the onion. Most of the mass is in the outer layers. But here I sit in the middle. I get a bit of honor for my historical significance, but in actual fact, most people see the outside of the onion, not the inside. Unless they make onion rings. But even then, the bigger rings have more to them than the smaller rings. Let that be a lesson to those of you who wish to be “inner ringers.” That’s not where the real power is. Not in this movement, anyway.

Emphasis mine.

Ah yes the onion. Rich metaphor used throughout literature and culture.

Well it turns out Larry is just wrong. The youngest part of an onion is the inside, and the husk is the oldest part (see wikipedia) so the metaphor is flawed.

Instead, let’s use a cross-section of a tree.

Trees, unlike onions, have their fresh growth at the outer-most ring. The center of a tree is the oldest part, and the big outer ring is the youngest part.

I think a tree works better for Ember anyway, since a tree already has a “core” ;-)

What would be on the rings of Ember’s tree? What kinds of project have we chosen to take on?

Why the change? It turns out software is written by people. And over time, the motivations people have for writing software and being involved in OSS change. The relationships between them change.

My consulting company 201 Created is going to run the Ember Community Survey again this year. The results there will tell us a bit about how our influences are shifting on a large scale.

However I’m pretty up to date on what people on the Ember Core Team are doing these days, and a back-of-the-napkin tally of their employment already shows the change over last February:

More large companies are influencing Ember than last year. Than ever before. And large companies have different needs than many of the smaller businesses that have been major supporters of Ember before now.

Bigger companies have larger audiences of users, which means the need to support a high-quality experience across a more diverse range of devices. And they have organizational challenges that need technology solutions. Using Ember for a team of two developers is very different than using it with a staff of 60 collaborators.

This is visible in the major Ember projects of 2015 and 2016. In 2015, the big items being worked on:

• HTMLBars
• Ember-CLI
• Animation/UX

These features helped developers get started and productive faster. The focus was on developer experience and empowerment of an individual to do really great things with the web.

In 2016 the projects with a lot of effort going into them are:

• Glimmer
• FastBoot
• Engines
• Improved Processes (LTS)

Two of these (Glimmer, FastBoot) are largely performance focused. Engines and LTS releases are tools that help large teams be effective with Ember. The priorities have been nudged.

I don’t think this change is bad, it is a natural and probably cyclic shift. When a company adopts open source, they also accept a mild risk that (unlike software they write themselves) the project is out of their control. Choosing and participating in Ember, a community-maintained project, mitigates the company’s risk. A participant can nudge Ember by sponsoring feature work, open sourcing their own work, hiring community members, or just by talking about what they are doing.

Some specific improvements that large companies are nudging us to pick up and will benefit from:

• Work on Glimmer is ongoing, and we’re working on an improved implementation of the original algorithm. It moves many of Ember’s template features out of Ember and into Glimmer. The implementation will result in better performance on Google’s V8 engine (which is notoriously fickle about polymorphism) and smaller template payloads.
• FastBoot is progressing quickly. We want the story of FastBoot to be that every Ember app is a universal app. This means solving the deployment story, and eventually tackling rehydration.
• Ember Engines are progressing quickly. Engines are routable or mountable sub-applications, installed as an addon. They provide a new way to slice up the organization of a team coding Ember: Instead of along horizontal lines (data layer, UI layer) teams can organize around feature verticals (chat room, dashboard, admin).
• The core team is gearing up for our first official LTS release of Ember. This will increase API stability for addon authors, and bring a slower upgrade cycle (basically twice a year) for teams that need it.

This is growth. Larry said:

Let that be a lesson to those of you who wish to be “inner ringers.” That’s not where the real power is.

And I agree. I think the story of Ember in 2016 is going to be less core.

More bark.

This year we will see a lot of maturity and improvement outside of Ember’s core. Major initiatives like Engines, FastBoot, and Glimmer are already largely happening outside of Ember’s own codebase and API.

The challenge we need to rise to is how to manage this shift. In Tom’s Core Team F2F Post he described the hurdle and some of the tools we want to use. The most important is the empowerment of subteams. The list of subteams in 2015 was pretty short:

• HTMLBars
• Ember-Data
• Ember-CLI

The list in 2016 has already grown:

• Glimmer (perhaps can become official?)
• Ember-Data
• Ember-CLI
• Docs/Guides
• FastBoot
• Ember-CLI Deploy (an independent group)

And I would not be surprised to see it grow further. Official subteams will have increased ownership of the RFC process, a representative on core, and increased autonomy in general.

Ember is growing in new ways, and we’re going to need your help. We’re going to need more bark. Help us grow, and be the bark.

Though these opinions are my own, I’m indebted to @rwjblue and @fivetanley for their feedback on this post.