 everyone, and thanks for having me. My name is Jamie. This is my face on the internet. I work for a company called With Associates in London. We are 11 people making websites and apps. They paid for me to come last year. They paid for me to come again this year, and I would not be up on the stage without them. In my spare time, I co-organize Ember London. We've not quite reached the dizzy heights of NYC just yet, but we're growing. We have over 600 members on meetup.com. We run two events per month, one meetup and one hacker hours-inspired project night. We've recorded 42 talks, which have been seen over 11,000 times on Vimeo, and we couldn't have done any of that without the generosity of our speakers and our sponsors, and some of you are here today. I want you to know that we love you very, very much. So that's enough about me and enough about London. I want to talk briefly about last year's conference. I got a show of hands who was here last year. Nice. Is it just me or do these guys organize the best conferences in the world? So last year, mine started on the off-beat. My Airbnb cancelled the night before I was due to fly, and I put the call out to the community, and obviously they had my back. I spent the first night staying with Matt and Corey in what became the big hacker house, and I spent the rest of the time staying with Thomas and Emily Reynolds up in North Portland. You might know Thomas as the creator of middleman. And everywhere I went in the city, it felt like the spirit of Emma was alive. If you were walking up Burnside this time last year, you would have seen this billboard. This is a piece by a Portland artist called Maudoud Yang, and it was made with an Ember app called 2B. So two of 2B's developers were in town last year for the conference, and I got to explore the city with them as they went around trying to meet their users. People like Maudoud, and this guy Juan, aka Cool Skull. He's an artist, MC, chip thrash, empresario, and designer of extraordinary garments with an Ember app. Yeah, I do not skateboard. So as I said, everywhere I went, it felt like this, like creativity and imagination and emberiness was everywhere in the city. And as I sat in PDX waiting for my flight home, I opened up 2B and tried to capture some of that energy in a crude collage. And that's what this talk is about. How did a tech community come to be this vibrant? And how can we keep it growing in that same spirit? So to preface this, I think there's a tendency and open source to focus on the code and to assume that the community spontaneously comes about in support of it. I think that misses the big story. A community like this takes as much design and engineering as any software project. And to illustrate that, I want to look at the design and engineering of this community from five different angles. Angle number one, the Tomster. So this is the original sketch of the Tomster. It was early 2012 and mjs.com was being redesigned to become a real grown-up website. Patrick Gibson then working for Tilda was looking for illustrations to lend a bit of character to the three blocks of copy on the homepage. He found and commissioned Lindsay Wilson. And shortly thereafter, Tomster appeared. Now, at this point, he wasn't a mascot, he wasn't a logo. He was just an illustration to convey these ideas of developer ergonomics, productivity, and friendly APIs. For the purposes of this talk, I want to slim that down to just productivity and friendliness. So we all liked Don to him. And pretty soon, he was out in the world representing bug reporting, works in progress, Ember camp for the first conference, and our build channels and our train release cycle. Looking at this today, it seems obvious that we would communicate our build process this way. But recall that it's inspired by Chrome's release cycle. And the pages that explain that look like this. And this. And now, don't get me wrong, the copy on these sites does a really good job of explaining what the purpose is. But I want you to imagine yourself as a newcomer to the framework, newcomer to the platform. Looking at this, ask yourself, would you think this is for me? And that's crucial because the whole point of our beta releases is that we want people of all experience levels trying them in their apps. And we depend upon their feedback to know if there are bugs, and more importantly, if the API is understandable. The friendlier we make this process, the better our chances of getting that crucial feedback. Ember also has roles to play in our real-life interactions in workshops and podcasts and meetups. So this is NYC, Salt Lake City, Munich, and London. And in case you didn't know this already, there is a system in place for you to affordably commission and license a Tomster for your city. So many who have spoken in the past about good defaults. So this is the idea that a framework should make doing the right thing feel better than doing the wrong thing. And I think this sort of principle can be applied to our discourse as well. And Tomster helps with it. I asked him if he could make it easier for the core team. And she said if you have a brand and or a mascot that correctly emotes something specific, it makes it easier for people in the leadership roles to then actually meet those ideals. So if the things we say on stage, the way we behave, jibes with the friendly geeky hamster in glasses, we've done something wrong. He also allows us to compose together perhaps conflicting concepts. Another quote from Lea. Our tagline is the framework for ambitious apps. And it's actually really hard to juxtapose friendliness and ambition next to each other. They're not two things that you would normally package up. So ambition is a loaded statement. It comes with baggage. If you use ambition wrong, you conjure up this guy. But there's a really easy way to defuse this. This is venture capital Tomster when we get funding. So never. He's like a smiley or as a friend of mine calls it a safety wink. We can use him to punctuate those potentially loaded statements and make sure that productivity and friendliness are always part of those conversations. How has he been so useful in so many different contexts? I think part of it is his fundamental versatility and accountability. I asked Lindsay about this and she said when you create characters, you pick things that are iconic but also adaptable. Tomster wasn't overly done and he could embody what a developer is. He doesn't have a lot of distinct features but just enough to say, okay, this is for me. So I have a programming analogy for you. It's a bit tenuous but stick with me. So consider promises. Promises are an abstraction that encapsulate the complexity of eventual values and using them allows us to talk about other things knowing that asynchronicity is taken care of. You can think of Tomster in a similar way. He is an abstraction which encapsulates the values of productivity and friendliness and allows us to talk about other things knowing that those two values are part of the conversation. In other words, he's a tool. Angle number two, language. This is also a tool. It's a powerful one but it's a perilous one. Words stick and if we pick the wrong words, they'll haunt us but if we pick the right ones, they enable new conversations. I spoke to Tom about this and he said when you're operating at the edge of something, often times one of the biggest hindrances to making progress is not having a shared vocabulary. We like to help ourselves frame our thinking by trying to coin terminology. You'll see this throughout the project. Almost any time a new idea is introduced, there will be a catchphrase to encapsulate it. Things like stability without stagnation, data down, actions up, functionally diverse core team and glimmer. So these are pithy statements but they also give us terse, unambiguous ways to talk about all the mirrored ways that plays out across these projects. So our community guidelines, I'm relatively rare in having these, these are constructed from other words from the Mozilla, Twitter and Ubuntu communities and you take a statement like be open and that's an ambiguous way to talk about all the mirrored ways that plays out across these projects. But the fact that we can share values with those other communities is fundamental and hinges upon having the vocabulary to describe them. Here's an anecdote from London. So we were discussing running hacker hours and Joe List pointed us in the direction of this series of tweets. So this one doesn't bother me too much. Like overzealous border officers, I think we can work around that. But this one really gave us pause. So hack, like ambition is a loaded term that comes with baggage, Joe's suggestion was to reframe things using the more innocuous project nights. But as it turned out, that reframing and that new vocabulary opened the doors to other ways to talk about what they were. So Mike organized the call. I'm not sure if he came up with this on his own or pinched it but bring your own project became a really nice way to describe what our events were all about. So this idea of language and vocabulary takes on a more practical tone when we talk about documentation. I spoke to Trek about this and said documentation at a very high level is essentially defining public API. There have been several cases where attempts to document either EMMA or related libraries have turned into public API changes. If something is difficult to explain, it probably means we're exposing the wrong primitives. And this goes just as much for defining the public API of a software framework as it does something like community guidelines or codes of conduct. If we can't explain how we expect people to behave, then maybe we've not thought it through hard enough. Angle number three, user interface. So how much to open source projects really need websites? Like what won't a read me do the job? This is the read me for rimrath which is a library for removing files. It's two functions. A read me kind of is all you need for this. This is the one for chalk. So chalk puts a nice API on anti color codes. It's a little bit longer. I think it spends some of the time thanking people but still more or less communicates what you need to know. This is RSVP. Just does promises, right? It turns out explaining promises is quite involved. And this is browserify. It just glues modules together, right? Well, it turns out that's pretty difficult to explain concisely too. So, of course, browserify does not depend upon a read me alone. They have browserify.org. So this leads you to the happy path and sends you on your way and then gives you jump off points for when you've learned enough and feel confident enough to continue. But it does something else. It introduces the visual language of the authors. This playful, inscrutable comic style tells you something about the tastes of the authors and about how they design their APIs. And this is important because it means once you've used one of Substack's libraries, you'll recognize that taste in other places and it will make it easier for you to pick up another library. You see this in Yehuda's work as well. The websites of things like Bundler and Thor and Handelbars and Cargo have a consistent visual language that's a clue that the same consistent design ideas are present in the libraries that these things document. And also, if you've had success using one of these libraries before, you'll see this visual language and know that this is something you can trust. This is a quote from Matt Ruby's designer. And this is the quote that kind of brought the idea of developer happiness to the conversation. But I think the crucial statement is this last line. I consider a programming language as a user interface. So it should follow the principles of a user interface. And I think you can expand this outwards. If you consider a programming language as a user interface, then you can also consider the documentation user interface and the community user interface as well. And if you have that in mind, you can design the best possible community. So I love this recent example. Our community pages were recently redesigned and more better calls to action were put in place. We made it easier to find meetups. One of the really interesting things about this is because we already had an established visual language, it made it easier for lots of people to contribute to this redesign. This is literally all the pull requests that went into landing this. So user interfaces are tools and the visual language we use is a tool as well. This is a quote from my good friend Casper. He's talking about building products. But you can use that same mental model when it comes to building the community. Angle 4 is hackability. So this quote I absolutely love, this is from Stefan. An open project has that mud on the floor from the construction workers. You don't mind walking in again with your boots on. It has to feel hackable. Parts have to be accessible. And really what I think this is is about showing, like I think all open projects are intrinsically hackable, but it's about showing people that they are. You don't want something that feels too done, too hermetically sealed. When I spoke to Yehuda he said it's really important that the feeling you get when you're an active contributor is pretty close to the feeling of being a core contributor, minus the cases where an executive decision has to be made. And again it's about communicating that to people. Like we have this in place, but people need to know. Alex put this nicely, he said Ember has a philosophy that there's nothing really set about the technology. It's more the idea there should be conventions around solving these problems. I want to take you back to this quote from Lindsay about the Tomster. He wasn't overly done and he could embody what a developer is. This idea that you don't make every decision for everybody and demonstrate that there are still choices to be made and still things to contribute to. This plays out in Meetup, so something we like to do is make sure that if someone's come up with a suggestion from the previous month, we make a point of saying that we've implemented it in the following month's Meetup. Angle 5 is roles. So last year in the opening keynote, Yehuda and Tom drew our attention to the functionally diverse core team and pointed out that there are many specialisms equally as valuable as someone writing the code. I'd like to extend this out to the community as a whole. I think there are all sorts of specialised roles you can play and this isn't to say that this needs to be your niche. It's just that when you approach the project and you want to contribute, you know that there are all sorts of things you can do that play out. So document here is an interesting one. I think we sort of consider documentation as an easy place to get started. But I consider it the metaphor I have is like a co-driver or a running mate. So implementing something like glimmer is an exhausting mental process and I think oftentimes you get to the end of implementing something like that and don't have the energy to then put it into words, put it into pros and describe it to people. But if you've got a running mate who can be helping you tackle those challenges and also translating them at the same time, that's a huge benefit to everybody. We have some wonderful mentors in this community. People like Ember Sherpa do amazing things and help people get started. One thing I think is really interesting about being a mentor is it's actually a really short hop from being a student to being a mentor and often the people who just cracked the nut for whom the penny has just dropped will make the best mentors because they understand that context of being new. There are some people in the Ember London community who seem to have limitless time and energy to go out and try new libraries and they'll often come up to me obsessed with FRP or obsessed with something new and shiny that they found and I think it can be tempting sometimes to feel a little bit cynical towards these things. But a better strategy I think is to encourage these people and say go out there explore these new ideas and then come back and tell us what you think is valuable. Bear in mind our longer term goals but do come back and tell us, come back and know that we're going to listen to whatever you have to say and we may just implement those ideas. More important than almost everything is the critic oh hey Ryan if it weren't for Ryan Florence pointing out our flaws we might not have glimmer today he really ignited a fire to prove him wrong and I love this tweet from him like his discourse on Twitter can be antagonistic but it's done so much good so actually round of applause for Ryan Florence so the point is there are loads of roles that people can play inside and outside the community and the more clearly we define them the more we give them names the more people will know what they can do, how they can play their part and it doesn't have to be just submitting pull requests I say just submitting pull requests is huge so in conclusion we've looked through the design and engineering aspects of all these five things and really my point is to consider community building as a design and engineering challenge another nice quote from Trek the value of a framework is not the source code the value is really the patterns and the understanding that people got working through what the problems were to put this another way the code is a snapshot of the best ideas in our community at a given point in time but the ideas really live with the people they live in all of us and what we're trying to do is create the best possible home for good ideas and also the most receptive to new ideas when I first started writing this talk I had this idea that community design and API design were somehow similar, were somehow symmetrical but the conclusion I've come to is that they're actually the same thing the code is like the kernel at the center but then this act of designing something that works well for everybody expands outwards through documentation, through websites into the community, into events like this but it's the same analytical process all the way through so thank you