"We're the Together Framework"

I remember the first time I saw Melanie Sumner describe Ember as "the together framework".

It was 2019, and I was sitting in the audience of the Amsterdam Ember meetup for the premiere of Ember: The Documentary. The lights had dimmed, the room quieted down, but my nervous energy refused to settle down.

I knew that I believed that the most important thing about Ember was that we climbed together, but what did the rest of the community think?

The documentary opened with an interview of Tom Dale, giving the basic details of what things looked like back in 2011 when we decided to start Ember together. I nervously bit my nails. I was still worried.

But within a few minutes, the documentary began to show interviews with members of the community. To a person, they talked about the value of community. Around the darkened room, I could see people nodding their heads and smiling. The way that people were talking in the video seemed to feel true to the people gathered in the room. I relaxed and sunk into my seat.

And then it was Melanie's turn to describe Ember. "We're building it together," she said. "We're the together framework, if you want to say that."

Those words, more than anything else in the documentary, made me feel at peace with what we had accomplished. After 8 years of work, we had built a framework around the values of community aspiration and ambition. After 8 years of work, sitting among people who lived thousands of miles from where I lived in Portland, Oregon, I felt at home.

1. Wrapping Up Rails

Let's rewind all the way back to 2009, the year when the Rails and Merb teams started working on Rails 3 in earnest.

You don't need to read the first part of this post ("Together: The Merb Story") before reading this post. However, if you're interested, there's a lot of context about this part of the Ember story there.  

A few months after the Rails and Merb teams agreed that we could do more by working together than apart, DHH gave his annual RailsConf keynote. In that talk, he reflected on the reasons for the success of Rails.

We confessed commonality. We confessed that we're not as special as we like to believe. We confessed that we're not the only ones trying to climb the same mountain."

In a lot of ways, this described how I felt about working together with the Rails core team. Just a few months earlier, I was sure that our perspectives were too different, and that working together made no sense.

Reflecting on my own journey, I realized that I could have failed to become a maintainer of Merb. I could have failed to become a productive member of the Rails core team. Nothing about my story was preordained, and when I started out, it really felt like I didn't belong. I felt alone.

But when Ezra and DHH welcomed me into the frenetic details of the work, I could feel that they thought that I belonged. Not because I proved it to myself with logic—which I could never have done—but because when Ezra and DHH showed that they trusted me to be a part of projects that they had created, they melted away my self-doubt.

My journey, which once would have seemed impossible to me, turned me into a true believer. From that point onward, I would work on projects that aspired to prove that we all do better when we evolve, build and journey together.

I've never been able to stop thinking about how little experience I had when I was thrust into programming. I worry about the next kid like me, starting in 2015 or 2020, who is told that times have changed and that the only path to becoming a programmer is to take months off of work and attend a bootcamp. I could never have done that back in 2005, and there are so many people who could do amazing things in the programming community who can't do it today.

I can't prove it, but I believe deeply that the path I took can still exist for many more people. I believe deeply that the more we focus on communities that climb together, the more opportunities we will create for people to grow into successful developers and even community leaders who can inspire us and lead the way. I believe deeply that when communities have faith in what we can accomplish together, we can build astonishing things.

2. JavaScript in 2010

After I wrapped up my work on Rails 3 in 2010, I knew that I wanted to do something on the front-end. I had learned a lot from serving alongside an incredible core team and community, and I could see that the front-end community didn't yet have a strong champion for the values that drew me to Rails and helped me succeed.

I had no idea what I was doing at the time, but I knew that I liked HTML and CSS more than systems like Cocoa ported to JavaScript. I had already spent a few years on the core team of jQuery, so I had no problem with JavaScript, but I wanted to be part of a front-end community that could bring together incredible programmers and incredible designers of different experience levels and different skills.

I had become convinced that open source communities were lionizing heroic coding skills and ignoring so many other kinds of skills, abilities and aspirations that make real-life communities so vibrant and successful.

I talked about the technical problem with Carl Lerche, who had worked together with me on Bundler and Rails. Over a few lunches, he gave me the kernel of the idea for Handlebars, and I was off to the races. I built and tinkered around with Handlebars, and even released the first version. Through Handlebars, I learned how to build a compiler, and the project was picking up steam. I felt great!

But after getting Handlebars off the ground, I was stuck again. I had a template engine, but I had no idea how to bootstrap a whole front-end framework myself.

I kept thinking about a meetup I had attended a few years earlier, where Francisco Tomalsky demonstrated 280 Slides. 280 Slides was a presentation product that looked like Keynote and ran entirely into the browser. It was implemented in Cappuccino, a new web framework that aimed to bring the power of Cocoa to the web. The big reveal was that the presentation itself was implemented in 280 Slides, not Keynote! I was blown away 🤯.

After the presentation, I went over to Francisco to gush about how impressed I was by their achievement. For days, I couldn't stop thinking about it. Years later, it still left an impression on me.

But thinking about it, I also knew that my journey to web development came through HTML and CSS. I had learned enough HTML by tinkering with FrontPage in college. When I discovered that the work of "web design" wasn't very similar to my experience with print design, I quickly learned enough CSS to do my job. Somehow, I had managed to become a professional web application developer without ever learning something like Cocoa.

It felt wrong to concede that ground. I didn't want the future to be closed off to the kind of person I was back in 2005.

I took a wider look at the front-end ecosystem, and it looked like the state-of-the art really was tools like Cappuccino and SproutCore. It looked like the future of web application development on the front-end was JavaScript abstractions that looked a lot like the daunting desktop toolkits that had once convinced me that I wasn't the right kind of person to be a programmer.

While that was a chief concern, I had another major concern as well. The crown jewel of Cappuccino, an interface builder named Atlas, was slated to be a paid product. And SproutCore, which was a little more open, was an internal Apple product, with internal design documents and a months-long code release process.

It looked like the future wasn't just daunting, it was also controlled by a small handful of people and companies, the exact opposite of the empowerment I had experienced working on Rails.

I began to think that if I wanted a front-end framework accessible to people with a background in HTML and CSS and governed by a community, I was going to have to build a new community from scratch.

There was only one problem. I had no idea how to do that.

3. SproutCore

Then, on July 1, 2010, something changed. Charles Jolley, who had worked on SproutCore at Apple, announced that he was leaving the company to make SproutCore a truly open source project. In his announcement, he emphasized the improvements he hoped to make to the community around SproutCore.

First, SproutCore is now and will always be totally free and open source. I think this business of charging for a commercial license is not an effective way to grow a project. Sure you make a little cash, but at what expense to the community? My goal is to make SproutCore and all of the developer tools that surround it totally free to everyone. All I ask is that you participate in the community somehow to make things a little better for those who come after you.

At a time when the idea of a front-end framework was still in its infancy, this felt like a revolution. I remembered Charles because he had built the build tools for SproutCore, back in 2008, on top of Merb. We'd corresponded a few times, and he had even invited me to speak to Apple engineers about Merb, way back then.

I sat down with Charles and showed him Handlebars, and he loved the idea of building SproutCore applications with HTML templates. It looked like I wouldn't have to start from scratch after all!

In a flash, I was working with Charles at his new company, Strobe, to bring my Handlebars templating engine to SproutCore's view system. I was making progress. It was a great to be collaborating again and I enjoyed the progress we were making.

But it wasn't quite the same as before. The work felt weird.

Charles had left Apple, and the two of us were working together on SproutCore's code, and that felt great. But the bulk of the engineers working on SproutCore and the bulk of SproutCore's users were still at Apple. I spent most of my days worrying about the needs of people I had barely met and didn't understand. At night, I worried about whether I was making the right decision.

4. Meeting Tom Dale

And then I met Tom Dale. Tom was a fresh-faced member of the SproutCore team at Apple who had gone from building a Rails app for his World of Warcraft guild to a member of the SproutCore team at Apple in only a few years.

In a lot of ways, his story mirrored my own. He was another person who had started with a need to put something on the Internet. He had found his way to programming, and ultimately framework development, through HTML and CSS.

Before I met Tom, I had become deeply worried about Apple's ownership of the SproutCore framework. Those worries deepened when I heard Apple's process for "open sourcing" the SproutCore code written by Apple engineers.

Fair warning: make sure you swallow any liquid that you might be drinking... You ready?

Here it is: a person on the SproutCore team had to print the complete diff describing months of work by multiple engineers. That person had to walk it over to a lawyer. Sitting across from the lawyer, they had to work through the diff, explaining to the lawyer what it did.

The distance between how I liked to work on open source software and how Apple liked to work on open source software couldn't be further apart.

I fretted. I worried. I literally stayed up at night trying to imagine how this could even work. I was doing my open source work on Github, while Tom and others were doing work inside of Apple and occasionally coughed it up, like a hairball, into the open source repository. It wasn't really working, and we knew it.

Before long, a particularly thorny technical issue had come up, and we needed an in-person meeting to resolve it. If I recall correctly, Apple had some particular needs around theming, and I didn't want Apple's needs to further complicate an already complicated codebase, especially considering the already-strained way that we were collaborating. I showed up to that first in-person meeting ready for a fight.

After some awkward, perfunctory greetings, we started talking about the problem. We got into the technical details. We used whiteboards and printouts. We got really animated. And just like back in my days of working on Ruby frameworks, the act of working together took over. Just for a moment, the tension between my open source philosophy and Apple's weird process melted away.

I saw, once again, how much small acts of trust could turn an awkward, defensive relationship into the sheer joy of collaboration.

At that moment, I knew two things for sure. First, I wanted to work closely with Tom Dale. Second, I wanted any open source community that I built, going forward, to be rooted in the value of togetherness that I had learned from Merb and Rails.

Fast forward back to 2019. It was Friday night in Amsterdam, and I waiting for Ember.js: The Documentary to roll. After the room went dark, but before the video started to roll, my mind drifted back to 2011, and to the 8 years since.

5. Strengthening Our Community

I felt proud of how far we'd come, but also a twinge of sadness at the ways in which we'd fallen short.

We'd had our ups and downs. Major changes in Ember 1.13 tested the community, and raised real questions about our commitment to our core value of togetherness.

We'd reacted to that mistake by hunkering down and declaring a moratorium on breaking changes until all of us in the community had a chance to recover from what had happened. After a period of rest, we'd gotten back to work, building upward once again.

But while we rested, recovered and rebuilt, the Backbone and Angular era gave way to the React and Vue era.

While React showed the world that unidirectional data flow could improve the way we designed we frameworks, we focused our effort on building a community that could live up to the values we aspired to.

We strengthened our RFC process, the beating heart of Ember's consensus model, to cover decisions that went beyond the code we wrote. RFC #345 proposed that we move the Ember community's official chat to Discord, garnered 164 comments, and proved that our community was up to the task of making big decisions together, even when they had nothing to do with code or APIs.

Even more ambitiously, RFC #425 proposed an update to the Ember website. This RFC showed that we could use our community process to coordinate efforts with a designer, without devolving into free-for-all design-by-committee. Feedback included requests to ensure that the new design was accessible and that we didn't completely lose the iconic Tomster illustration in the name of modern design.

To help addons decide which versions of Ember to support, and to help the community upgrade together, we introduced LTS releases in RFC #56, and made Ember 2.4 the first LTS release.

We also refined our deprecation process. From Ember 2.0 hence, we would only deprecate an API in Ember if we had a new API ready to go, and we could write a clear migration plan that covered the use-cases of the old API. Additionally, when an API is deprecated, it should no longer appear in the main body of the guides. This meant that deprecations would be used to move the community forward together. We could only deprecate an API when we were ready to recommend that all users, from people just starting out with Ember to the most experienced, could write new code using only the new APIs.

During this period, we were innovating on community.

Ember was already ahead of the curve with our RFC process, but we showed that we could manage big changes like the move to Discord or the website redesign through our community process. We showed that a strong community could do project management, and even make traditional command decisions outside of the clutch of a corporate management hierarchy, and without a single BDFL figure.

We worked together to iterate on our development process to make it even more effective at managing upgrades for teams of many different sizes distributed throughout the world.

We had made a good deal of progress on technical issues too. The Glimmer 2 rendering engine, a drop in replacement gave Ember apps competitive rendering speed. We migrated our API surface to JavaScript modules, aligning Ember with the wider ecosystem. Ember CLI got much faster, supported new versions of Babel, and came to work very well on Windows. And on and on.

But when I sat down to watch the Ember documentary in Amsterdam that night, I realized that what really set Ember apart was our emphasis on building the capacity to work together.

Along the way, we had learned that building a project like Ember together goes far beyond writing code together. It means welcoming in people who focus on learning Ember, people who maintain infrastructure, people who run our events, and yes, the people who work on the code in the framework itself.

6. The Ember Documentary

I knew how I felt about the value of Ember, but as the video started to play, I realized that I felt anxious. How would the Ember community describe our values? After 8 years as a framework, how much did we really identify as a framework whose core value was building together?

As I watched the documentary, a wave of gratitude and relief washed over me. People didn't talk about the code or technical details. Instead, everyone who was interviewed talked about the value of togetherness.

The long-lasting value of Ember lives not in its technology or its professionalism. Those things are the implementation details of what we really care about.

We grow as developers together. We design our framework together. We evolve together.

We're the together framework.