The Frontside Podcast

Robert Jackson: @rwjblue | rwjblue.com

Show Notes:

Resources:

Transcript:

CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 75. My name is Charles Lowell, a developer here at The Frontside and your podcast host-in-training. This is a little bit of a diamond anniversary episode, I guess -- #75 -- so it's going to be good. With me today is Jeffrey Cherewaty. Hello, Jeffrey.

JEFFREY: Hey.

CHARLES: To celebrate our 75th diamond jubilee, we have with us a very special guest who I like to refer to as the Eye of Sauron when it comes to bugs in the Ember community. Mr Robert Jackson, who is a person over at LinkedIn, who does what he think is best. Hello, Robert.

ROBERT: Nice. Howdy, howdy. It's great to be here. Thanks for having me back.

CHARLES: Today, we're going to talk about many things but chief amongst them is going to be BabelJS and the conversation around tooling in the JavaScript community because we've come from a point where, I want to say in 2012 where it wasn't really a thing or the build stuff was like an incidental thing but it mostly was just, maybe compressing your files and maybe doing a little bit of finger printing or what have you, to now pretty much build tooling, rules and everything around us. The amount of software around the deployment of your software is a huge amount. Would you say that's fair? We’ve come a long way.

ROBERT: I think, for sure that we, at this point, have a whole tower of Babel going on, with all the things that we're doing. We have a ton of tools at our disposal today that I wish that I had years ago. I think that, unfortunately the law of nice things is that as you get better things, you realize the things that you don't have still. It's like an ever-increasing distance to the Promised Land, if you will. But I think that where we are today is massively night and day better than where we've ever been before. We can do so many things like code mods and transpilation and prod debug style, all sorts of things. For the most part, in the Ember community at least, we try to make that as much like a default out of the box experience as possible.

CHARLES: Just to talk about that land before time, now Ember was one of the first frameworks to really embrace transpilation but also using Babel as the primary tool. What was that experience like? What changes that we have to make in order to hit that?

ROBERT: I think, the Ember itself, the framework itself which is still shrouded in the final global's output which folks used, was one of the first major things to use ES6 modules and at that point, it was before Babel was even like a concept, as far as I know, we started using Traceur. Then we also used the Squarehead written in model transpiler as well and we use [inaudible] for a while and it was great.

As we continue to press on this path, we realized that we wanted nice things in our apps too. We wanted modules. At the time, we're using Ember app kits. This is pre-dates Ember CLI using Ember app kit and the way we got modules was either via [inaudible] pipeline which was a Ruby thing in Ember side or just like some Grunt pre-compilation which roughly just ensured that the modules were evaluated in the right order and people generally actually wrote global style code and just assumed the concatenation order worked. That is super not great. It made for some really gnarly interdependencies that was hard to untangle, I suppose.

CHARLES: When did Babel come in that conversation?

ROBERT: Shortly after we started doing Ember app kit. This was like a project that Stef Penner started. We started doing ES6 modules specifically. At that time we were using Grunt for that and we did modules. I think we used squares ES6 modules transpiler. Then shortly after we started working on Ember CLI itself, like the tool named Ember CLI that you know today, we migrated to a tool called Esperanto from Square's transpiler. Then that was deprecated and we started using Babel.

We have made many hops along the way. I think when we originally introduced Babel into the Ember CLI app pipeline, it was an optional dependency because it was actually quite slow to run Babel across a decent-sized app. It was many orders of magnitude slower with Babel than without. Some folks wanted to optionally opt in to using Babel. That was probably sometime in 2015 so over the years, we slowly started migrating the codebase so that at this point, a Babel is totally required part of Ember CLI built pipeline and we will warn you or something if you don't have.

It started out as basically an optional dependency and then we worked along to add multiple caching layers, which is also for neutrality sometimes if you get it wrong and sort of speed up like the cross-restart caches and also, we could remove the performance penalty of the build side of using Babel and just like have nice things and unlike the ES latest version of JavaScript in our apps.

CHARLES: It sounds exhausting but thank you for jumping on to the JavaScript fatigue grenade. The number of technologies you just listed through, there is a lot going on in the frontlines.

ROBERT: I don't know that we've always done a great job of this but hopefully, the idea is that we should insulate most Ember users from having to make all these sources themselves. Ideally, we are doing internal things. We expose specific public APIs and in most Ember apps, it could upgrade from amongst these, from Squares transpiler to Esperanto then to Babel, mostly seamlessly. You just drop this thing in or do that thing, just basically add a package to your package JSON and it should work. That's the idea. Hopefully, no one else had to deal with quite the level of shenanigans that I was talking about. Hopefully, there's only a handful of people that remember all the names that I already listed.

CHARLES: I remember them happening but you're right, we were relatively insulated from all of that. I think the hardest part was making the mental leap from global-oriented code over to modular code where every symbol has to be important before you can use it and bridging that chasm, I think was the work that the majority of developers had to do. It was no small task but clearly, it was worth.

I guess the question is obviously, there's a lot of benefits to using ES6 modules but there's other things, because it's a full transpiler, you've got a lot of features like the modules that you can either take or you can leave. How do you decide which ones to turn on by default versus leave off?

ROBERT: The way that Babel itself internally did this in version five of Babel is quite different than what Babel 6 does. In Babel 5, they roughly took the mindset of, "We'll just transpile everything that is past stage two," which is the way they rate things are, like stage two is ready for browser implementing. Stage three is roughly finished and you can consider it stable. By default, Babel in the Babel 5 version era was just trying to transpile everything and you could opt in to special experimental things. Maybe like spread operator or decorators or something like that. That's how Babel 5 works.

Now, on Babel 6, which is the migration we just underwent in Ember community, going from Babel 5 to Babel 6 was a huge leap for us because it turns the whole thing on its head and basically, makes it that each and every transformation you want to use, you have to opt in to manually by adding a plugin. They also add a presets and things like that.

CHARLES: So literally, every transpilation you want to --?

ROBERT: Yeah, exactly. It was a quite huge shift and that's also why it took us so long to upgrade from five to six.

CHARLES: Was the upgrade again pretty transparent for the end user?

ROBERT: If you weren't using experimental features like decorators for example, the upgrade was roughly like yarn, upgrade Ember CLI Babel, done. That was basically the upgrade. Now, there are people that got bit by specific bugs or specific things where maybe they had a custom plugin that they were using. For Babel 5, they would have to upgrade that also.

But by and large, the default out of the box Ember app generated by Ember CLI 2.4, we tested all the way back to 2.4 and make sure that version number CLI Babel worked and for all the versions and hops between 2.4 and 2.13, which is when we finally released it.

CHARLES: About turning this on the head, why was that decision made to make every single transpilation opt in?

ROBERT: I didn't have to see the table at that time with the Babel folks. I'm not quite sure exactly why it was done. All I can say is that the main reason, as I understand it, had to do with plugin ordering and making that you had the ability to much easier opt in and out. For example, the way we migrated to Babel 6 in Ember Land was by using Babel preset in, which is a preset maintained by the Babel folks that essentially takes a list of targets, similar conceptually to auto-prefixer or something and says --

CHARLES: What is auto-prefixer?

ROBERT: Oh, sorry. Auto-prefixer is a thing that will post-process your CSS and add the random browser prefixes based on the list of browsers that you support. In Babel world, this basically means we give Babel preset in and the list of browsers. You might say, IE11+. You might say latest two Chromes, latest two Safari, latest two Edge or something. Firefox too.

You give us this array of what you support and double preset uses an internal database that's also the same thing that powers like, CanIUse.com and it just decides, "What do I need to transpile to target these specific browsers." For example, if you only support browsers that natively support like Promise or something, you might not need to polyfill, for example. That's just a crude example but another one, like arrow functions or classes.

CHARLES: I actually noticed this yesterday because I was on the BabelJS site and I remember, it used to be when you would type something in that left pane, your ES6, it would always generate this really nasty thing that boiled down to prototype code where you're manually adding methods and stuff to prototypes, sometimes using to find property and what have you. But I noticed yesterday, I would enter in a class and it would just be a class over on the right. It didn't touch the code at all. It just passed it through. Is that because the preset environment is now the one that they're using to do the transpilation on the demo site, basically is set to the level of browsers that understand class constructs?

ROBERT: Yes. If you can forgive IE11 for a moment, which some of us can, some of us can't, all of the evergreen browsers plus Safari, which I don't think is evergreen, all support class and error functions, they all support a huge swath of ES6, out of the box, by default. If you're only have to support like Edge, Chrome, Firefox and Safari -- maybe Opera, I don't know -- then you can like transpile way less stuff. You can use native classes and the Bebel JS repl, lets you choose what to transpile back to. I don't remember if they're specifically using Babel preset in or not but that's basically the idea, which where you're getting at.

CHARLES: Does that make it faster, because it has to do less work?

ROBERT: It does less work, for sure but also in the browsers, for example with Chrome when they were doing the TurboFan migration which is like the internal JavaScript VM that just migrated to in Chrome 59. When they were doing that migration, they were basically only adding optimizations to the new syntax. They stopped working, modifying, changing, optimizations for ES5 stock code or only really adding things like to optimize ES6 stuff.

The class for example is much smaller by bytes than the prototypal version. It also provide some additional guarantees like you have to call super, for example and things like that. Then in addition, it's just better optimized or has the potential to be better optimized in the browsers than the ES5 version because they can make specific assumptions about the patterns you can follow.

JEFFREY: These are all big architectural decisions that changed how Babel works. How do these changes the workflow for somebody working with Ember CLI, that doesn't have anything particularly custom going on?

ROBERT: Again, the workflow should basically not have changed in any way. A default out of the box Ember CLI app from version, I think Ember CLI 2.12 used a Babel 5 and then, 2.13 started using Babel 6 for the blueprint. Anybody could upgrade add-ons, for example. It can upgrade to Babel 6.

As soon as they were ready and the reason for this was because each layer in the Ember CLI app pipeline is responsible for transpiling its own code that it owns. This is how, for example we were able to upgrade to Babel 6 in a minor version bump because it was essentially opt in only. Again, each add-on, for example got to say, "I will use Babel 6," and then their add-on works and do their tests and all that stuff. But by and large, a normal app should only have to upgrade the one Ember CLI Babel package and then any Babel plugins you might be using and that's it. There shouldn't be any other special shenanigans or hoop jumping that you have to do.

CHARLES: Do you have any, even anecdata, surrounding how much savings you get in terms of payload size?

ROBERT: The problem is that Ember itself still supports IE9, which doesn't have any features of the good things. Also, Uglify has significant problems with ES6 code. We're still struggling through the woods of getting a good set of targets built up. The default set of targets that we include for new Ember app still includes IE9 because that's what Ember supports so in your new Ember app, you would have to edit the config/targets file and just configure how you'd like it. Basically like last two Chrome, last two Firefox, last two Edge --

CHARLES: Let me stop you there because I think you just mentioned something that is of key interest. When you said 'config targets,' does that mean that every Ember application comes with a stock set of targets that's changeable?

ROBERT: Yep, exactly. I wrote a blog post about this, actually at RWJBlue.com. It talks about the targets and how this was introduced and how it works. The default stock set of targets is also listed in there and I have a bunch of tips and tricks about how you can have local development, say on latest Chrome. You can have native generators. You can accept through your Ember-concurrency things and that have to see the wacky regenerator like switch statement. I talked a lot about that in this blog post.

Basically, the config/targets file that is generated by default Ember app today has some list. I think it has four things in it but it includes IE9, that is the oldest thing. It's like the tent-pole, if you will. But if you drop that out, then it's roughly evergreen browsers only and you can target classes and arrow functions and all sorts of stuff, have that actually emitted.

CHARLES: Wow. That's incredible to be able to do that. I know that certainly when it comes to debugging, it is so frustrating to see the mangled concatenated code.

ROBERT: Yes, exactly. The thing that just blew my mind when I first got this working was just being able to step into an async function and just step over, step in as appropriate without having to jump to weird [inaudible] land or weird backburner code, like run loop code. It just works and no regenerator, no extra polyfills. The Promised Land is gorgeous. I don't know however you get there but it is beautiful over there.

CHARLES: Yeah, although I have a question. This has been something that I know has been a challenge when it comes to working, especially people who are beginners. Having the code at runtime, not be in the same form as it is when you're developing it can be a wide cognitive gap that you have to straddle as a developer. Supposedly, source maps are there to help us with that. But I've noticed source maps don't always work and they feel a little bit fragile like if something's not configured quite right, then the whole source map chain breaks down in your back to looking at mangled code and you're like, "I'm not totally free from ES5 because I have to understand how it's compiled down."

A similar situation would be like back in Ruby code or some other language, having to still understand how it'd map down or be able to read out as assembly, even though I don't think it's quite that bad but you still have to hold that mental model and you have to understand what a prototype is. Is there any way to address that? What’s the deal there, I guess? I know that's a really open-ended question but --

ROBERT: Yes. A few things. I totally agree with you. I think that there's a number of angles and I'll try to list them but I probably do a horrible job in meandering the woods for a little while so just ring me in when you're ready. But basically, I think there's a few things. First of all, I don't think I remember a time in JavaScript space where you ever actually had the thing you're talking about, where you saw the code you developed and actually ran it in production. For me personally, since I've been involved, we've always done modification, which broke that.

Unless you're running minified code locally, you're already out of that zone. Even if you have no Babel, you have no other transpilation, you're almost certainly going to minify. That's already a problem, a chink-in-the-armor of doing both things. Minifying locally during dev is theoretically fine. It's just going to make your life very miserable but it should work technically. There's ways in Ember CLI to do that out of the box like you just set a flag but generally, that's already a thing.

I think, source maps are massively brittle, as you mentioned. It's just slightly wrong thing and when you have a file of like a thousand lines, just having something be a few characters off is quite bad by the time you get to the end. You can easily have a debugger in a place and you think you're stopped at one section but you hover over the symbols or something and they don't show what you expect. Or you're just not in the function you thought you were or something like that.

A great example of this is if you've ever put a debugger in Ember-Twiddle.com and put a debugger in app code in a Twiddle, you'll get a breakpoint and the role that's highlighted is not a debugger line and it's like really [inaudible] so you know that you stop the debugger but because Twiddle does all of the compilation client side in the browser with Babel, then it like evals it essentially, the source maps are totally wacky and you have this exact situation that you're talking about, where it's like I don't know how to reason about what is happening.

CHARLES: You just have to use the console.

ROBERT: In that case, you have to use a console. I think the most common thing for me to see or to tell people is to disable source maps. If you have a thing where you believe source maps might be right or might be wrong, easiest thing to do is disable source maps, refresh and then you're looking at what's actually being evaluated but that's a super sucky answer. That's roughly like, "I have this caching problem. I will just don't cache things." That's not a great answer. You should just fix the bugs.

The issue is that the bugs lie at the feet of, literally every tool in the space. It's really hard. For example, if you Babel before Uglify, are you supposed to give Uglify the input source maps? The answer is yes but Uglify oftentimes doesn't handle input source maps properly so it won't do the right thing. Then there's tools like Sorcery that is essentially a thing that have each step, only do their own source maps from raw code to Babel and then from the Babel-transpired code to minified code and then you give all those source maps to Sorcery and it try to stitch them back together and make them work. That's a really neat tool.

CHARLES: That sounds amazing. It really sounds like the only real solution.

ROBERT: That's the only solution to solve the threading through of all the source maps thing and it actually works quite well. Unfortunately, the problem with that is now you have to track the order of all the things and that's all actually non-trivial. Especially in Ember CLI app or any app of any significant size where you have thousands of files and you're transpiling them, you have to basically keep track of the source and then you concat stages independently. We don't have a good mechanism like back channel, if you will to keep track during the pipeline of what the order of operations are and how to stitch all the source maps back together properly.

But I totally agree that this is not a wonderful place to be and we just need to spend more time to focus. We basically need to do two things. We need to say, "We all agree this is unacceptable and we actually have to be willing to invest time to fix it. It's just too easy to uncheck little check boxes in source maps and move on about my day and it would be better if we just dug in and dealt with it like we would any other bug.

CHARLES: Yeah, I think it's hardest because this one in particular, it hits beginners way harder than everybody else because they don't necessarily have the transpiler mental model.

ROBERT: Well, the other thing is like with lots of things, if it only sporadically works or only sporadically breaks, you just completely destroys any trust you might have had with the thing. Basically, if you test suite mostly passed, how well are you going to feel about deploying? It's like, "It passes eight out of 10 times, it's probably okay." That's not the kind of confidence that you want with these tests. It's the same sort of thing.

If your default answer is, "Well, maybe the bugs [inaudible]. Let me uncheck the thing and refresh." You either should just never use source maps or you should just like fix the damn problem. Figure it out and fix it. The issue is that almost never is the thing I'm trying to work on relate to source maps. The thing I'm trying to work on is some other bug in some other system and I'm like, "Oh, damn," and I just want to beat this out. You end up getting like three yak shaves deep and at some point, you have to declare yak shaving bankruptcy and give up. [inaudible], ah yes. Good. Well, I'm absorbing that one. That's great.

CHARLES: That's called yak overflow.

ROBERT: The thing is if we can only harness the yaks and convince them to build things for us. That could be amazing.

CHARLES: Yeah, each layer is a yak frame. There are could be some burden. If in terms of allocating your developer resources, if you could track the number of the yaks that were required to accomplish each task, you could say this is a really high value yak to kill or to shave, I guess.

ROBERT: We don't kill them, come on. They got to carry our stuff.

CHARLES: Yeah, the land of the future, the Promised Land is wrapped and it's built with [inaudible]. Anyway, moving on. We have a question from Twitter, from one Rob DeLuca. He wants to know about what's going on with Ember decorators and ES6 classes. When are those going to make an appearance in Ember?

ROBERT: Ember decorators is an add-on that I authored roughly forever ago, it seems like but not quite. There's been a lot of work on it lately to update it, to work nicer with Babel 6. We also added support for classes. There's a whole bunch of work going on in the Babel space to update things to the latest spec of decorators. Back when I originally wrote the add-on, this was in the stage one version of decorators spec and a massive amount of things change in the spec around what was allowed, what wasn't allowed. It doesn't change a ton on the user facing side so the way you invoke a decorator was like [inaudible] or something. It's roughly the same. But the internals of how that transpiled, what syntax is allowed and not allowed, that all went through a lot of changes.

CHARLES: Didn't they used to decorate things more than just classes and methods?

ROBERT: Confirmed. Yeah, exactly.

CHARLES: I actually was kind of disappointed that they walked back from that.

ROBERT: I agree, actually. It is slightly unfortunate that you can't decorate like a POJO, for example today or with the current spec. The thing to remember is that it's really important that TC39 take the most conservative approach and iterate forward, especially with this massively shifting technology. Decorators are a big change in the way you think about things. Same as class properties and private fields and all of these things that are coming out of TC39 these days. If we started too broad, I fear we do painted in like a giant corner. Also, as a side, the syntax of decorators is nice but if you just wanted decorate a function, you could just wrap the function and a calling function. It's not that complicated.

CHARLES: Right but that's the same thing. That's just what a decorator is, right?

ROBERT: Except in classes. In classes, it's actually not possible to do that. In classes, the class body, you cannot say, "foo: Ember computed and pass a function." You actually have to have the concise methods syntax. For plain functions, you can easily just wrap it. For classes, you don't have a choice.

CHARLES: Or you have to do what Ember object does, which is just take a hash and then construct the methods by hand.

ROBERT: Yes. Unfortunately, if you do that, then you can't use getters and setters. If you do that, because when you define like 'get space' first name or something, you actually define a getter on that hash, that POJO and Ember object will just eagerly evaluate it when it goes to instantiate your instance. That is definitely not what you wanted. There's all sorts of landmines in there and there definitely are dragons, I promise.

The good news is, I think we're going to a really good place, the Ember decorators add-on was recently renamed for Ember computed decorators and now offers decorators for action. We've had computed and observer and on for quite a while. I think service inject, like control inject but don't do that and things like that. Those all exist as decorators.

Now, there's a nice API doc site link from the ReadMe and most of these things work nicely. The wonderful thing is that you can basically use class syntax today with many objects in Ember Land without using 'Ember object.extend.' You can do like 'class foo extends Ember object' and most things work really nicely. There's a handful of edge cases that we need to sand down and fix and deal with but it's a really, really exciting path. Basically, just like embracing real JavaScript syntax, now that we have good class system and we can start shying away from some of the bizarreness of the Ember object model.

CHARLES: Even though the thrust is towards using ES6 classes, under the hood is it still going to be instantiating in Ember object?

ROBERT: The nice thing is that Ember object itself actually just embraces ES5 and you can already imagine like a regular class foo extends bar, already can extend from anything that is a prototype type class as well. Internally, Ember itself like Ember object or Ember component or Ember service or all those things, are basically just prototypal classes so extending from them works exactly the same like normal function foo set prototypes and stuff like that. It's exactly the same as the prototypal version in ES5.

There are some edge cases, some things that we added on top like things like mixins for example, which are kind of gnarly and the resulting JavaScript class system does not have mixin. Well, it doesn't have mixins in the way that we think of them in Ember but you can easily imagine writing a mixin decorator or something that does the work, either assigning the properties from the host objects or just making a chain of extending classes. You actually are real super in those. All of that is quite possible.

There's an open issue on Ember decorators repo that someone opened just yesterday or two days ago about adding a mixin decorator. Personally, I would prefer to hold off landing that because I want to see how far we can take normal class syntax, like normal class stuff. I think that the next thing that we'll probably need is an RFC in Ember Land to officially embrace using regular classes for these things and explore all the edge cases and stuff that were sort of ferreting out in the add-on.

CHARLES: If you have regular classes. Then you can use regular mixins, like the JavaScript functions like mixins.

ROBERT: You should totally be able to do that but I just don't think that we should support Ember.mixin, basically is what I'm saying.

CHARLES: Yeah. I don't think I've ever written a mixin that I didn't come to regret later.

ROBERT: I tend to agree. I would like to ban creation of all new mixins.

CHARLES: Yeah. Anyway. That's a whole another can of worms.

ROBERT: That's another topic. Yes, exactly.

CHARLES: Behind the scenes, we're getting in Ember object essentially, a new Ember object that extends this class, if I understand it correctly that is generated and decorated but it's an ES6 class and then behind the scenes, you get an Ember object that extends it. One of the things that I think is another big challenge is because Ember objects are not regular POJOs, they're really hard to inspect in the debugger. Computer properties are kind of no-go when you use log into the console. Are they going to clean up a little bit of that?

ROBERT: There's a few things. First of all, being able to use plain class syntax means that we can use real getters trivially for the things that we don't need. Some of the magic that Ember computed is doing for us, it's not magic but still it can waive internals. There's use cases that people use computed for, which is roughly that, "I want to lazily do a thing," which isn't really the point of computed but sometimes people don't want to eagerly do. They only want to create some array or something if instantiated, for example. Then they rely on the fact that the computed is cache or [inaudible].

It's massively trivial to do that yourself in just a getter and if you do that, then you can use the normal JavaScript dev tools to just inspect the object. You only need some magical thing that knows how to called Ember.get to retrieve the instance value. The answer is roughly that it unlocks those things but it doesn't provide them by default. As of the thing that Ember decorators add-on does today, it's really just creating a regular computed property on the instance but I think, once we embrace classes, once using classes is public API in Ember Land, from the Ember project it says, "Yes, this is the thing that you should do," then we start updating guides and stuff. There will be an RFC for that once we get there. Then we can start figuring out, "How do we make the Ember.get requirement to go away?"

When you do that, you're talking about moving to real getters and if we move to real getters, then all of your normal debug tooling will just work out of the box. I think that's the path but I think there's many stepping stones, if you will. We're going to try to rule it out in small chunks over time so that it's not too hard to digest and we can slowly iterate the way we teach folks the guides and things like that. We have a lot of things to move forward at the same time.

CHARLES: Yeah, I know another thing too is being able to see the actual name of the class in the dev tooling when you're trying to track down memory leaks, when you're logging into the console. Being able to see that if you're using ES6 class say, I've got a class named 'person,' today when you log out of the console, it just says class. Or if you see it in, if you're looking at a heap snapshot, it just says class. But hopefully, we can get to a point where it'll say, 'person,' or it'll say, 'car,' or it will say, 'dog.'

ROBERT: I think that specifically will require some of the target stuff that I was mentioning because it's only going to work when you're actually using classes. I think we're close to the point where many apps already don't have support IE11. As it continues to age out, more and more users drop away and we can start embracing evergreen-only style browsers. Then when we're there, then like it basically everybody supports class. Basically all of them support arrows and async away and all sorts of nice things.

CHARLES: Actually, I think in that particular case, if it's a function, even though it transpiles the class down to a constructor function, the browser will still recognize it because that's something I noticed today when I'm using POJOs and when I'm using Ember objects. The reason it's called class because literally, you say var class when Ember creates the constructor.

ROBERT: But the reason for that is in Ember, in the raw source, it is using the class keyword. It's actually using class but we transpile it down because Ember targets IE9, which transpiles down to wacky-land basically. Once we can use targets, then we can basically remove the extra layer so you're actually using classes, even at the depths of the internals. We would basically not set a variable. It has to be a named class, basically.

CHARLES: You're right. You have to give a name to the class because right now, it's basically because the variable name, it literally is var capital class. That's the name of the class gets in the runtime. There's a lot to look forward to. It's always a dangerous thing to ask people, when can we expect this? I don't want to put any pressure but when do you see these things rolling out? Don’t you love how you always preface a question with, "No, I don't want to put pressure on you, but I'm going to put pressure on you?"

ROBERT: I'll give the stock answer that I always give which is, "You will get it when it is ready and you will be happy about it." But that last bit was more for my kids actually but anyway, I realized that I'm on record here. I think that a good window for this is something like the six-month horizon. Maybe slightly longer. It's hard to say exactly. Like I said, we have to do an RFC. There's a small amount of work has to happen in the Ember internals to unlock a few of the things that the RFC needs to say but the Ember core team has talked about this pretty extensively. We're all generally, obviously want to do the thing. The question is exactly, "How far we go?" And my personal perspective is that we should do small steps like unlocking small parts at a time.

For example, we can go to class syntax and say that it's public API to implement a constructor function, instead of init for example, and say exactly what the semantics are on that and we can do that roughly independently of actually officially embracing specific set of decorators. The decorators are fine to live in add-on space for a period of time. As we mature and figure out which ones are good, which ones do we want, what do we not want, that kind of stuff. I'm a strong advocate of doing the smallest amount of things possible to unlock the feature, unlock the things and then we can iterate forward as we go along.

We're working on updating the guides and making things more idiomatic in API docs. There is a massive amount of literature that exists between the API docs and the guides that will have to be rethought, not always rewritten but we have to make sure that what it's saying is the actual idiomatic 'right thing,' like embraces the language. From my perspective, I think it's very, very important. It's a huge priority because I think, right now one of the things that I hear from folks is the custom object model makes Ember feel like a dinosaur.

Partially because we had to create all of these things before any of these exist in the language. Our dedication to supporting backwards compatibility is really important. We haven't just dropped support for all things. We need to chart a nice path that lets everyone sort of meander forward and upgrade their apps and no one gets stuck on a cliff. I think that's really important to do and do slowly over time in a consistent way.

CHARLES: I think that thoughtfulness is the key to the castle. You aren't just throwing away backwards compatibility and thinking about what is the migration path for everybody. People lose that as being way more valuable than having the hottest thing in your hands and unfortunately, only being burned by that, can make you perceive it.

ROBERT: Yeah, exactly. I think people just going on the hide factor or the shiny factors. It's easy to forget that this shiny thing wasn't so shiny a year ago or two years ago and if you had written something a year ago or two years ago, you would have basically been totally screwed. It's easy to forget those things because you're sucked into this like the JavaScript fatigue thing, like you're sucked into this like, "Oh, there's a shiny thing. Now, I want that."

I think we just need to do a better job of telegraphing our emotions like where we're going, like talking about the direction in a more overall road map-y way in Ember. It's clear, why can't I use classes today or one of the edge cases or things like that. Hopefully, in the next little while, we'll get that RFC up and we can start talking about these things in earnest.

Right now, with the Ember decorators add-on, you can look at the API docs of that. But basically with that add-on, you can totally use regular class syntax today for the vast majority of things that you'd want to do an app. You could do class extend service or something and it works just fine in vast majority of things work.

Again, we have edge case like things in component space, for example like attribute linings are very hard or tag name. Those are less trivial, basically because in Ember, actually binding is essentially a concatenated list of all the attributes that we're going to bind to and there's no concept of that in the normal JavaScript space. I believe we should be able to do this with a decorator but also, if we get to the Promised Land of having Glimmer components and whatnot, it may not matter anyways because that whole thing of actual bindings and tag name and class name bindings and class names and classes, all of those properties go away and we can just use normal Handlebars syntax, which is going to be great.

I link to them along but I wrote two blog posts about things that were doing in Ember CLI Babel. The first one is targets. The second was about debug code stripping. If you feel like basically, have a certain deprecations in an add-on or app code, it automatically stripped the same way the Ember does. But those are the kinds of things that are unlocked by having shared Babel tooling and stuff.

CHARLES: Thank you so much, Robert for coming and talking with us. The amount of knowledge about JavaScript and just everything in general contained in your head is just so massive. I feel rich just having gotten to experience a little bit of it in the past 45 minutes or so. Thank you so much. You're going to be talking, I understand at EmberCamp London.

ROBERT: Yep, that's next week on the 11th. That is coming up quick.

CHARLES: All right. Everybody, look for that. We'll link to that in the show notes. Also, there's a lot of extra stuff that we didn't have time to talk about, specifically around this topic that Robert's written about on his blog so be sure to check out those links below. See you around.

Anissa Willyard: @team_giveback | GiveBack2Schools

Show Notes:

Resources:

Boston: Peace of Mind Lyrics

Transcript:

CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 74. My name is Charles Lowell, a developer here at The Frontside and your podcast host-in-training. With me from The Frontside also is Ginger Whalen, our head of business development. Today, I'm actually excited about this episode, I'm excited about every episode but I'm excited about this one in particular because we're going to get to see something from the other side of the coin.

Our listeners are on the implementation side and sometimes, when it comes to starting up a business or being a founder, the driver and the implementer are met in one person but more often, and I think in a more healthy way, they're split between multiple people serving multiple roles. Today, we're going to interview somebody who is a serial entrepreneur, who is currently a founder at a business that we came very, very close to working with. Please welcome, Anissa Willyard to the show.

Hello, Anissa.

ANISSA: Hello Charles. Thank you so much and thanks to The Frontside Team and Ginger. You guys are an incredible team and I really enjoy having the opportunity to be able to be here today so thanks so much.

CHARLES: No problem. You're currently a founder at GiveBack2Schools, which is going to be launching soon.

ANISSA: Yes, that is correct. Our goal is to launch in July 19th. We've kind of pushed it back a little just to make sure we get through the holidays and make sure that i's are dotted, t's are crossed and now, we are locked and loaded. The official date right now is the 19th and we're really excited to launch in Olathe, Kansas.

CHARLES: Fantastic. We're going to actually talk a lot about that later on but first of all, there's obviously a large backstory for how you came to be doing what it is that you're doing today. I wanted to kind of delve into that a little bit.

ANISSA: First of all, I think right now, we all live in such interesting times that I believe by having a business with a mission is actually is going to allow us as individuals to create such a positive change. The change that we create will actually feel us through as founders or as anybody who decides to move forward to start any kind of company. I do believe there was a quote that I live by. It’s one by Zig Ziglar and it says, "It's not where you start but where you finish."

To kind of take you through that journey, my hope today is that I give everybody hope, that if I can make a difference, that somebody else can too and that will give them and inspire one person to take that action to make that difference. I look back on everything in my life and kind of where I was in my journey, as far as the why. The why behind what I did. I sat down throughout my day and I broke it up into three different parts. In the first part is kind of called, 'the grownup phase.' That's where you go to school and you come through college and then your middle years where you're out, you're fighting for that career and you really are starting to climb that corporate ladder if that's the road that you decided to go down or raise families or whatever that is.

Then the last part where it brings you to that moment, where you question yourself, "When this is all done, did I really make a difference? Am I leaving behind and making a better place here?" That all brings me through, like you said, "Where did it all come from and everything?" From my days with Mary Kay Cosmetics, back when I thought for sure, I was going to be an oncologist and then went out, that's with Mary Kay where I had the honor and the privilege to be trained by the woman herself back, growing up in the Pacific Northwest and having a great role model that just inspired me and be enabled at the right age of 22 years old to have earned a free car. My father thought that was just crazy, that I would sell lipstick so I might as well move on and pursue the corporate dream.

Now today, to come full circle and think when it's all over, where am I heading? It kind of in a roundabout way who I was and from working in advertising, to marketing, to implementation, the jack-of-all trades and probably the master of none when it's all said and done.

CHARLES: When you say you came to this moment where you had this time of reflection of saying, "Is this the legacy that I want to leave behind?" What is that when you start thinking about the things that you want to leave both to your family and to the world, maybe even long after you're gone? When did that happen and how long did that take and what was the end result of that? What path did that set you on?

ANISSA: It's so interesting that you asked. The next part that probably I would share was hopefully I can make a future and take you down that path. I grew up in a very small town in the Pacific Northwest. The population was under 500. My mom actually passed away when I was in the fifth grade and my father was a logger, a timber faller, a real blue collar gentleman. My father knew how to work but he never really had an idea how to raise two small daughters from [inaudible]. He was by far no means a perfect man. He would leave us girls sometimes home alone and he only had a sixth grade education.

Some of the defining moment since I look back and had time to reflect is my mom actually, when she passed away, my father was illiterate at that time. I was actually responsible for filling out the paperwork. The name Lyn spelled with a 'Y', not an 'I', my mom's, to this day, even on headstone, it's spelled wrong but it's a reminder that it's really not where you start, it's where you finish. But my mom was a great inspiration in my life. She told me every day, "Someday you're going to be somebody," and I didn't really know who that person was and she had battle with cancer.

She was always encouraging and she always taught us girls to have no fear. Even I can share stories about that but then, if I looked back in my life, even though my mom wasn't around and my father was gone all the time, there was a long consistent thing I had in my life and that was school. It really allowed me to dream. School was something I looked forward to every day because they help me escape the reality that I still lived it. There was music and sports and outdoor school fun activities, the opportunity to learn and grow. My family life was so different. If I would have went to college they wouldn't have cared, nor if I would have been that home. It didn't really matter because there wasn't really a purpose.

As I was decided to want to move out and went on to climb that corporate ladder, it always felt like there was something missing. I continue to rise to the top and of course, you work hard and you make your money but there was always that missing gap. I found myself in so many ways following in my father's footsteps: great worker, tons of awards, he traveled all the time and never around. For several years, I guess I question myself, "Is this really what it's all cracked up to be in."

I don't know if anybody here that listens and have never heard of the music group, 'Boston.' While I enjoy classic rock and I don't know if you've ever heard the lyrics of Peace of Mind and I guess, I'll just open that up because that's not necessarily from my generation but a generation that's older than I am. But it just came on the radio one day and it made me take that pause.

CHARLES: You know, I don't know the song out of hand but maybe I can look it up and sing it as the outro music for the podcast.

[Laughter]

CHARLES: I don't give any opportunities to sing on a podcast but when I do, I [inaudible] that.

ANISSA: I would so love to hear it and sometimes, just a few lyrics have really resonated with me as I recall that moment because with my childhood, a lot of people may think, "Oh, my gosh. That poor girl..." I actually had a great childhood. I got to use my imagination and become creative and create something that most people never got to create in their mind. But the few of the lyrics -- just to share with you -- actually did define that moment.

It was about five years ago and here is how just a few of them go. It says, "If you're feeling somewhat low about the dues you've been paying, you want to run but somehow, you're just not sure if you should run or stay. You just can't decide on which way to go. I understand about indecision and I don't care if I get left behind. People are always living in competition and all I want is peace of mind." I thought, "Oh, isn't that true? Well then, they kept going."

They kept going to the next part and I thought, "Really, is this happening to me?" I'm driving down the road and I feel like this artist too was way before my time is talking to me and just going, "Seriously?" Then it said, "As you're climbing to the top of the company ladder, I hope it doesn't take too long because there'll come a day that it won't matter and that they you'll be gone." And I thought, "Oh, my gosh," and it just hit me like a ton of bricks and I thought, "You know what? Time to make a difference."

I remember catching an airplane, flying home that evening and coming home to my husband and saying, "Guess what, baby? I'm going to do it," and that was the defining moment.

GINGER: That is so great tip in such a powerful moment like that and those lyrics, isn't that the human condition? We all have encountered that indecision and questioning our purpose or our impact at one time or another and to be able to make a change and then develop this company, launch this company, hatch this idea and we'd love to hear how you then transition into this purpose-driven, mission-driven, cause-driven company. It's very powerful.

ANISSA: Thank you. When you decide to do something, like I said that was five years ago, where I made that decision, and then you jump back and you go, "Well, how am I going to do this?" Okay, I have a great idea and I am going to make a difference but then you start to look at this whole picture and this is almost like an elephant sitting there in front of you, "How am I going to eat this?"

Really, the next part I call and it's something that I coined to myself is called the PPG. I needed a plan, I needed people and I needed to go. That's really what I live by, was that PPG. The point on when I first started, I knew what the end game was. I thought I have a mission, I have a plan but where do you go? You start writing down all these ideas, I don't know if you guys are like me, I am a left brain, right brain person. One minute I'm analyzing something, next minute I'm trying to create it so I can go back and forth in the same sentence. I'm an oxymoron and I can really create a lot of chaos within my own world really fast where you start to doubt yourself when you think should I move forward.

Even though you make that decision, it's like, "I'm going to cut off all options. I'm going to do it." When I first started, I didn't have all the answers to achieve the end game. You know, right now sitting where we are and everything that we do and all the different people we've spoken with, I don't know if you'll ever have all the answers. You just have to follow the heart.

GINGER: If there's the cause that you find that mean something to you and mean something to your history. You said school was really important for you growing up as an escape in your safe place. How do you find people that will enlist or support or participate in that same cause? How did you find your people?

ANISSA: The really interesting is that two of my partners and I have worked together in a different role in a different capacity for almost 15 years. What's really interesting about it is certain people gravitate together in so many ways. One of them was actually a teacher and a coach but there wasn't really any money to be made in that at that point in time so they ended up going into sales. The other one actually had the marketing background, single mom, raised three daughters, put them school as the pomp squad, head person and then my last partner is actually a former superintendent of schools. It's weird how we were all pointed in the same direction.

To have that, I'm more of an outsider. I always say, they're more of a pedigree. I'm more of a mutt that kind of take care of me along the way. But they had similar backgrounds, similar heart and similar care. When she started to collaborate and share ideas, it just grew. I remember back in school where one of the founder says, "I was the child that maybe had to have that free lunch and sat alone," then you hear different ideas and then you put their friends in the room and you start talking with different coaches because they know a lot of coaches and activity director. It's just grows, Ginger like you wouldn't believe in. You get more excited and more ideas flow.

I do think how we all came together and how we have all worked in different capacities made a big difference but that synergy of opening it up and being able to talk openly and freely about ideas, really is what grew this to where it is today.

GINGER: The partnership is just so strong because you all have the same sense of purpose or you want to make an impact in the same area. Imagine it's really gratifying and you're really connected to your partner in ways that are unique.

ANISSA: Right. It's funny because we've really have this saying, "No idea is a bad idea," and I am so glad they have those ideas for me because I'm the one who brings up the off the wall ideas and the thoughts and they encourage it every day. I think to have that synergy to pull that together has been priceless.

GINGER: How would you recommend other small businesses if they're not built on a cause or built on a mission but they'd like to choose behind a certain mission. How do you say that you could go by choosing that, if they didn't all come from that background or come from that cause throughout their life?

ANISSA: That's a great question. I do think that once you sit down and you get real still, which is not always easy. We have a 27-year old and we have an 11-year old daughter. To really sit still and to get close to yourself and go, "Where am I today?" If there is something that just really bugs me or something out there that is broken or if there's something that if I could fix it would make a difference, I know I'm speaking for myself. I can't solve all the world's problems but if I can make a difference in one or make a difference in one person's life, that they can leave this Earth just looking back, knowing it made a difference. What do you have to lose?

A lot of times people think, "Oh, if I do a mission-driven business, I may not make money. I may not be for-profit," or, "What about this? What about that?" Put all of that aside for a minute and just start taking your old sticky notes and writing it down. This actually got even deeper with us. Our daughter play soccer at a real high level. She plays for a select team here in Austin, Texas. At one time, I even questioned myself, "Am I doing the right thing?" I thought, "You know what? I'm going to really get in the saddle to point myself right in those shoes of what our children go through and everything else again."

They were doing that fundraising mission to give scholarships to children for balls and to be able to play soccer and I told our daughter and I said, "This isn't necessarily what our business is going to do but it has similar path and I asked that we go out and we try and make a difference and see what it takes and what it does." Once you make that decision, it will grow many legs no matter what it is. Just keep going with it and keep trying new things and keep experimenting. Eventually, your vision will be so clear that no matter what you woke up, this is it.

GINGER: Yeah, I love it. It usually does start with one individual with the really strong passion. Also, I agree that it used to be saved for non-profit organization or some philanthropic organization or religious organization but now, corporation is for-profit, public-private, even governmental agencies and they now have a mission and they're seeing for something. I think employees these days demand it too. They really want to make a greater impact, even then just locally, not even one with global compact. They also want to stand for something collectively and going for some purpose.

ANISSA: I so agree. People are changing the world by changing our ecosystem in business. It sounds so cliché. It really does. I remember the first time I heard someone actually state that, I laughed. I thought, "Ecosystem in business? What?" That has to be somebody is in a cool buzzword today. Then when you start to define how it all works together, the cliché actually means something and it starts to take a life of its own. Just like you are stating in business today, people demand more. They want to be part of something. People supporting what they helped create.

It sounds like such a simple statement but in then encompasses some of the most difficult problem leaders today face. You have to always ask yourself, "Am I solving a problem?" But solving the problem will have an effect and it's just one of those, "What effects will I have?" I believe in my life, if we use such as fundraising, I always look back and think of how much cookie dough between the oldest selling and the youngest selling and all of that and I laugh and I'm thinking, "If all the cookie dough we buy, if I would have actually eaten it all, I would be a cookie today," so I am solving a problem, you know? I don't need no more cookie dough at my house.

CHARLES: I think it's an important point though, any time there is a need and a great need, if you can make it exponentially easier for people to fulfill that need, then there's absolutely a business there and there's absolutely a mutually beneficial relationship that can be developed where it's okay to say, "You know what? I'm going to charge some money for this service," but the net effect is going to be everybody gets to participate and this thing is going to make things better.

ANISSA: I so agree. You guys may find this funny but I believe podcast is something that make a difference in people's lives too. I really enjoy running. I run between five to seven miles a day and there's not a day that I don't turn on something that I listened to or I dive into. I do think the sharing out there today has made the difference. Just by you guys doing your podcast or simple things like that, it does bring that unity together in so many ways.

GINGER: But we do hope to inspire and we are inspired by doing this, definitely.

ANISSA: Oh, I can only imagine, definitely. But back to a little bit about people do help support what they help create. I think when you can define a problem, I know sometimes that does get deep and sometimes you may think it's shallow and sometimes when you start writing it down, you don't really know what the real deep problem is. You just start with a lot of different parts. You may go through days that you think, "Does this really matter at all?" Really does it?

But deep down inside, that's your fuel. That's your passion that keeps you going. It also may take some time. When I first started out back years ago after my mom passed away with breast cancer, I thought, "I'm going to be an oncologist," so as I was going to college and everything, I realized that I really don't enjoy draw on your blood and dealing with all of that. I thought, I am more of that people person than I am sitting there. Even though they have a life and passion and I learned so much from that experience, my mom used to have a great, great saying and she used to always say, "Anissa, there's a lot of dead folks on this Earth. Don’t be one. They're living but they're dead. Don’t be one."

That never came to me until many years later in life what she really meant. She meant live life with passion and go for it and never look back and I thought, "There is some to that saying, just don't walk around like a zombie. Be someone." That was when you bring it back, to define that problem like I started with, you may not even know what your problem is but you know that deep down inside. You're not excited to wake up. You're not excited to get busy at something because you're not being fulfilled and you know that somehow you did not make that difference.

GINGER: Yeah, I think that's the bottom, like figure out what you want to stand for, figure out how to make an impact besides yourself and beside your community, more than global level and get behind it, get passionate about it. You keep doing that. You listen to your message. You listen to your mom.

ANISSA: I did. I did. There are so many times I didn't listen to my mom and I don't know if it turned out good or bad because I've made a lot of mistakes.

GINGER: We all have.

ANISSA: Right. You know what, if you take that forward, you just challenge that problem from every angle. Who do I need to help solve this problem? Do you need your merchants, your consumers? Who is the [inaudible]? You may think there's a problem but they may not even know they have a problem. You know, sometimes people are in such denial. Others are not a problem and you're thinking, "Oh, you have a problem," but that's kind of where I come from and to do that.

Then when you have a vision and you have people, there will be people who will not support you. They were actually say you are crazy. In that sometimes, people can take that internally and go, "Am I crazy?" Just know that that's a true compliment. If you're not always speak in everybody's language and people think you're in left-field sometimes, that's okay. Don’t worry about that.

The other part is when you start out on your own, you're going to hit roadblocks. Anybody who starts the business will tell you, you are always, always 100% never for sure and willing to change, no matter what as you continue towards your end game. But really, I live a lot of my life by a movie. The movie, my favorite movie of all times is The Wizard of Oz. I really do think it has several meanings to it. It does take a brain like the Scarecrow. If you're not the brains, get somebody who has those brains behind you.

I always knew that when we were going, I needed somebody who has a lot smarter than I was in so many ways. It takes the heart. I've got a great heart and compassion and all of that but it does take that heart. Maybe you are more of the brains. Find somebody with that compassion at heart and it takes courage. I know that your team are there to build what you guys have and to do what you've done. It took a lot of courage. I think anybody today who is in business, I do think the mission sometimes is what get us through when we are in business because without that, there really is no end game.

GINGER: Although all of us are going to start businesses based on a cause or a mission, there's a tons of ways you can get involved doing volunteering. Then you're involved with like-minded individuals chasing some cause, accomplishing something but those lessons can be an individual level, group level, company level. I completely agree.

CHARLES: Yeah and I think it's important too. It's thematic on this podcast of don't go alone. I think we have some very toxic myths out there of the people, this person, kind of founder who locks himself in a room and then they sit there, eating nothing but pizza and Dr Pepper for 48 hours and they emerge with the solution to everything. That's just not how it works. Time and time again you'll see that what really makes a robust, resilient business is exactly like you said: having people who can truly fulfill each one of those roles, the brains, the heart, etcetera and really step into them completely. It's a great point that just can't be repeated enough.

ANISSA: Oh, I agree. I don't know if my family would even be my family if I didn't surround myself with good people. If I lock myself behind closed doors, I may come out crazy, literally. They would not want to be around me.

GINGER: Again, we can all say that at times.

ANISSA: But Charles, to go back on your point, don't take this alone guys. There are people out there that have the different parts that maybe you're missing. I'm telling you, there is strength in numbers. I don't mean numbers like 10 or 20. That's great but when you're really collaborating and getting down in the nights that we worked and the early mornings and the times, we were told basically no. When you're out there fundraising and you're trying to get the money, to go where you need to go, to continue your own way, not everybody is excited about you or what you're doing. You'll have to have those partners to keep you going at every turn because they will make the difference. There are times where it gets really dark and that darkness can be just one more knock or one more call to make it happen. I encourage that spirit together.

CHARLES: Yeah, I think there's also another point that I want to bring to the forth and while we're on the subject of toxic myths, I think we have also this myth and it is prevalent of the idea of startups and people embarking on businesses being very young, basically young men and I think that while young people have a lot of time on their hands, the people that you know and you can cultivate over a lifetime. They are the true asset. You have people with 10, 20, maybe even 30 years under their belts who have developed these networks which are just these -- we're from Austin. I love trees and I love the trees in Austin and one of the things that makes live oak trees, which is a very hardy native tree that survives around here, it goes through periods of sometimes it rains a lot but sometimes we go through five, six years where it doesn't rain a lot.

What happens is these gigantic oak trees have these network of roots that intermesh and intermingle underneath, sometimes 10, 20, 30 feet under the ground. If you have that time in your life and you've spent that time being around extraordinary people, that will come to fruition in terms of you'll be able to grow new trees based on that shared interlocking network and the strength of that network is really a true asset. I think that another message here is that people who are advanced in their careers are almost the opposite of saying that a startup is not an option for you. It's almost like you're going to be better suited for it in many ways.

ANISSA: Oh, I love that analogy. That is such a great analogy. Looking out in my backyard here in Austin, we have oak tree. I'm going to remember that every day. I agree so much. That was probably one of my biggest fears. You look at some of these great companies that are born today and come out and you're thinking, "Gosh, have I missed my prime?" Also, being a woman in business, sometimes I've been the lady in the boardroom. I've been the one that has earned that executive title. To climb that ladder isn't easy but to be a woman in business sometimes, also makes you stop and wonder, "Is anyone going to listen?" I think that the wisdom in business that we have, the so-called bloody knees from falling down and getting back up, the balance back ability, that in order to make those things happen, it was a [inaudible].

I just appreciate the fact that there are other people out there just like me who maybe want to make a difference and don't know where to go. Just realize that there is more than just me out there that has this feeling. You just need to take that chance and make it happen.

GINGER: Or classic rock or classic movies.

ANISSA: Right. No doubt.

CHARLES: We talked about how to organize a business around a mission, I'd like to actually take a moment just a couple of minutes to talk about GiveBack straight on and let you explain because I think it's just a great concept.

ANISSA: It's really funny. A little bit about GiveBack. GiveBack was actually born from an idea of being sick and tired of fundraising, if you can believe that. During the time when I was a child growing up, fundraising really hasn't changed for our educational system. Everything gets cut. I remember looking back and being able to sing songs from The Beatles, Little Submarine and all of those things. Nowadays, you don't have those things anymore. We always get these different, "Oh, got to sell cookie dough, got to sell this."

In our time as a family, I was already at the end of its rope. I'm traveling. My husband's got a great career and our oldest son was actually raised by a full-time live-in nanny. Now, that's not something I'm excited to brag about but it happen. As we had our second child, we were heading down that same road. When it came to fundraising in schools and all of that, I thought how many kids out there don't even get to go to outdoor school. What we did, the concept and the idea was how can people just live and we give. That was really how it was born. From my marketing background, from working with businesses, people want to make a difference. But yet, there's really no trackability on their ROI. Yet, they also need the cost to get new clients in so there is that cost of acquisition, bringing new clients into their business.

Schools need money. In order to keep going for these athletics activities and all of this and how can I tie this together that the consumer can dictate wherever they are in America that they can and maybe someday global, give back to their child soccer or maybe the chess team at the middle school or the high school. Maybe they have three kids so they're not giving up their precious time, their own resources, to go out to a school function night, when it's only Tuesday, service is poor. The restaurant wants to help but it's just not working into our time and who has the time?

I remember the wagon full of cookie dough and taken it door to door and I was thinking, "If we don't get it out, it's going to spoil in our garage because our son had to hit the record and sell the most cookie dough. Yay! Great job. Now, Mommy's got to go deliver it with you." It's eight o'clock at night. We're driving around in the car, knocking on people's door to give them cookie dough. Then what percentage was really going back? That’s kind of what we did. We connected the dots and we brought fundraising or funding of those activities at education and all of that into a way that it would just basically, as we always say, you get to live and let us do the giving.

GINGER: That's great. Then people can really know what kind of impact they're making, how much they're giving back. I think that was the missing piece. People got frustrated in fundraising is it feels kind of good and giving to the cause, I support but what is it really doing and how much is really going back to them? Those were open questions back then.

ANISSA: Right. Believe or not, they're still open today. Here we are going into the Year 2018 and they're still using envelops out there and who knows where that money's going or what percentage went back. You hear about that all the time. You see it firsthand. I agree with you and that was really something as that transparency to be able to show. You know, the school was gone, now what you did and how much went to this activity? Also, it was that full circle transparency and boy, doesn't that make a difference and to be able to let people start to dream again, if we have instruments maybe these kids could actually play them again, versus, "Oh we've got a company [inaudible]. Forget about outdoor school. Let’s just go to more textbooks." It gives us a different way to bring back to our schools.

GINGER: You want to talk about this going national at some point for people that are in the Austin area?

ANISSA: To be honest right now, our end mission was to do what was right. As we soft launch and get out there, yes our goal is to go nationwide. We're looking more towards about the scalability but I would rather under-promise versus over-promise and not deliver. Our goal right now is just to watch for upcoming events. It was hard for me to keep it under wraps for so long. Now, we start to leak it out a little bit.

I think probably the best way to put it is stay tuned and keep your eyes open. That would probably be the best verbiage to use at this point but I thank you guys for your hospitality and allowing me to do that.

CHARLES: Oh, no. It was our pleasure. It was great meeting you. It was great getting to meet other members of your team. You come across folks in the line of work that we do and you all really stood out as folks who knew what they were about and we're on a mission to achieve it. I think it's important for people to hear that that you can do that, really at any point. Thank you so much. Thanks for GiveBack.

ANISSA: Thank you. I just really want to say thank to all of you and I want to wish you a Happy Fourth and safe and good health out there.

We will be back on June 29th with your regularly scheduled podcast!

Happy summer!

<3 The Frontside Gang

Kris Van Houten: @krivaten | krivaten.com | Q2

Show Notes:

Resources:

Kris’ Blog Post Series on Accessibility:

Transcript:

CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 72. My name is Charles Lowell, a developer here at The Frontside and podcast host-in-training. With me today is Wil.

WIL: Hello.

CHARLES: Hey, Wil. Today, we're going to be talking about accessibility in single page applications with Kris Van Houten who is a developer at Q2. Hey, Kris. Thank you for coming on the show. Today, we're going to talk about something that I know a lot of people's minds here and probably elsewhere on the internet, it's a topic that's getting a lot more attention, which is a good thing and that's accessibility. We’re going to explore the niche of accessibility as it applies to single page applications. Now, you're a frontend developer at Q2, what initially got you interested in and passionate about accessibility in general?

KRIS: I honestly feel my path to passion in this area has been a little bit unorthodox in a number of ways. I basically started out in total apathy of this topic and over the last year, it has turned into a genuine interest of mine. About three years ago, I remember listening to an episode of ShopTalk Show with Dave Rupert and Chris Coyier and they kind of went on this large rant about accessibility and why more developers need to be concerned and compassion about it.

Dave Rupert was talking about his contributions to the accessibility project and I'm sitting back and thinking to myself and this is back then, obviously, "Why would anyone who is blind want to use anything that I'm working on." I basically balked at the idea and disregarded it entirely. At that time, I was just getting my feet wet with Ember working on an application with a company here in Cincinnati and we had these conversations about, "I notice that we put this action or a clickable event on a div element, should we not be doing that? Is it that not something that we should be doing?"

I remember sitting back and having this conversation and saying, "The ads been crawled by SEO and Ember isn't yelling at us for doing it. It still works fine so what the heck? Let’s just go with it." Basically, every single app that come into since then has basically adopted that same mindset even before I joined the team so I know it's not just me who is thinking this. A lot of developers that have been exercising the same way of doing their code.

CHARLES: Right, it's the path of least resistance. Everybody’s got a job to do. Everybody’s got features to deliver so that practice can be very easily self-perpetuating, right?

KRIS: Exactly and I think a lot of developers just don't understand the semantic difference between a div or a label or a button or a link and how browsers can actually treat these difference HTML attributes or HTML tags differently because of how assistive technology can utilize them for per person's benefit. That’s where I was a little over a year ago basically.

When I first started at Q2, that first week, I got pulled into a discussion about design patterns which is another passion of mine and somehow, that turned into me joining a group that was to establish to figure out how to tackle the task of making our large app accessible. Basically, we had a company come in, audit our application and we got a big fat F for accessibility so it's something that we said, "We need to start tackling this problem." Being that, I just started at the company that week, I was going to tell them no but internally, I was panicking and saying, "I got to figure out what is this whole accessibility thing is and why it's important."

I started looking for books, articles on the topic and trying to basically flood myself with information. Two things that really transformed my way of thinking was actually a talk given by Nathan Hammond at that Wicked Good Ember in 2015, where he shows an example of building an application without accessibility in mind so basically, doing what I was doing before which is we're adding actions to div tags, we're not really caring about semantic HTML, we're just making the feature or the application work.

But then what he does, which I think is super powerful is he pulled up a colleague of his who is blind and had him try to use the application. He just goes through and you can see the struggle and he's actually vocalizing and talking about where he's [inaudible] with this application. Long story short, Nathan comes back up and makes a few adjustments. DHTML has [inaudible] up again and it's night and day difference just by changing the markup and by dropping in the Ember A11y add-on which helps with focusing the browser in certain areas of the content. He’s able to totally transform how's individuals able to use the app.

For me, that was a super powerful to come in and see that and see someone actually struggle with a website that they were trying to use. I think, [inaudible] where I always saw accessibility was it will only affects people who can't see and I think that's the other area where I've really started to have that paradigm shift was when I realized that this isn't just people who can't see. It’s for people who have motor difficulties, who can't use a mouse and how to use a keyboard instead. People who have various vision issues, whether that's cataracts, colorblindness, glaucoma, dyslexia, some in these effects, not just DHTML but also affects color contrast, the fonts that we're using that impacts every area of application design and development and that's where I started to realize that that was where the paradigm shift happened in my mind where I started thinking to myself we really need to start talking about this more and getting other developers on board in general on this.

CHARLES: It can be intimidating, especially when it feels like on a single page application, your divs have to do more, so to speak in the sense that it feels that your HTML is fatter. It’s not just a thin layer but your HTML is actually part of the UI.

KRIS: Exactly, yeah.

CHARLES: When it comes to having this paradigmatic shift that you're describing, when you're looking at your single page applications, are there any insights into the general structure of the application that you feel like you've gained that are foundational, they kind of transcend accessibility? I guess, what I'm saying is, is there any way that you become like a better developer or been able to recognize foundational patterns because of having these insights surrounding accessibility?

KRIS: I've been working with Ember for about three or four years now, basically since it was still in beta. Over the last several years, I have started to accumulate a lot of knowledge as to how we can utilize Ember to do a lot of the heavy lifting for us. When I started getting more passionate about the area of accessibility, first question that came into my mind are how can we use Ember to do some of the heavy lifting for us. For example, some of the things that I had done was go through and start working on developing a couple of components that basically cover a lot of things that I find ourselves doing [inaudible] a lot. Whether that might be a component to just plain icon on a page or a component to display input on a page.

What we're able to do is using Ember, we can say, "Here's the icon I want to display but if I don't happen to pass in an aria-label attribute, for example. The component will add the 'aria-hidden=true' for me. Being able to really utilize the power of Ember to do some of that stuff for us on the back side of things, I guess you could say it magically.

CHARLES: Let me stop you there for a second and unpack that example. What you're saying is, if I'm going to put an input on the page, if I actually don't assign an ARIA role, it's going to hide it from me?

KRIS: No. I was thinking of an icon components, say if I'm using Font Awesome, for example and I want this with the trash icon so I wrote a component for our specific icon library that we're using. We pass in the icon that we want to display, again that could be the trash icon and we can also pass in an aria-label attribute to add a label to that span that will be read to the user. But if we don't pass that attribute in, the component will automatically add the 'aria-hidden=true' attribute for us so basically it skips over it.

CHARLES: Yes so it won't be just garbage for a screen reader or someone navigating with a keyboard.

WIL: Yeah, otherwise the screen reader tries to read the content of the icon CSS which is just the Unicode.

CHARLES: Right.

KRIS: Yeah. What we really is trying to figure out and what I've spent a lot of my time, especially in writing my blog series on this was while we are using React or Vue or Angular or Ember or whatever, how can we utilize the power of the single page application frameworks to do some of that heavy lifting for us in the background without us needing to explicitly define everything. I'd say, especially when you work on a large team like what I work on currently, we can't expect everybody to be extremely well-versed in the area of accessibility so if we can do some of the work for them and just encourage them to adopt these components in their daily workflow, it does some of the work for us. That’s what we're working on and talking a lot about at Q2 is basically this pattern adoption.

CHARLES: Right so it sounds like to kind of paraphrase, whether you're working in any framework most of them have this concept of components so really leaning hard on that idea to make components at the very granular level aware of their own accessibility. Is that fair to say?

KRIS: Yeah, obviously there's more I'm sure as we go for the conversation about some of the things that I've tackled in this area but long story short, being able to utilize and recognize, you have this extremely powerful JavaScript framework at your disposal to do some of work for you so why not equip to do just that.

CHARLES: Yeah. I guess that falls into my next question, which is there are component level concerns and if there are other component level concerns, I definitely want to hear about them but what immediately leaps to mind is there are also cross-cutting concerns of any single page application, what's the state of your URL and if you're using a router. Some of the content on the page is going to be changing and others isn't like how do you cope with that? What are the cross-cutting concerns of an application that span components and then how do you cope with them?

KRIS: I think one thing that comes to mind as you're talking is the whole area of context switch awareness. If I click a link, if I go from the home page of an application to my profile page, how does a screen reader know that that content has now changed to present this new information to the user? I know what we were able to do was we were able to drop in the focusing out with component that's put out by the Ember accessibility team, which basically whenever we render to an outlet, that's utilizing this focusing outlet component, it will focus the browser to that main area and start presenting that information back to the users.

One area that was at the top of our list as we start tackling accessibility was we need to figure out this whole context switch awareness thing because -- this is back then obviously when we first got started -- back then there was no way for a user to know when the page changed so they would basically be sitting there, waiting for any kind of feedback or whatsoever to be presented back to them and it just wasn't happening.

I would say, managing focus is probably one of the top level concerns when it comes to single page applications because it's a single page application so if you click a link, the page isn't completely refreshing, prompting the screen reader to present the information back to user. That’s one of the key areas that I think of.

CHARLES: What about things like asynchrony because a lot of times, these context switches are not boom-boom, one-two. The content on which you want to focus isn't available yet. Usually, the analog from a visual UI would be a loading spinner or a progress bar. How do you deal with those to say, "Your content is not quite ready. If you're made to wait it's because we want your content to be of the highest quality."

KRIS: Sure, yeah. We were able to drop in the focusing outlet components in our application and it took care of a good chunk of the work but it seems like in our application, we're doing something that might not be as conventional as the rest of the Ember community would like them to be so we might not use the model hook as we should. It’s hard for the page to know when the contents actually ready, when it's been rendered to the DOM to present back to the user. One thing that I'm currently trying to tackle right now, to figure out how we can remedy that problem. I probably say, honestly that's the challenge I'm working on right now. I don't have a solid answer to that one at the moment.

CHARLES: Irrespective of how it plugs into the tool that you're using, what would just be the desired interaction there, regardless of how you make it work?

KRIS: I guess, conceptually what I'd be thinking about is how can we notify the user we're loading content right now and whether that we have an alert box that has the ARIA alerts, basically attributes set on it, that we could pass in new, basically notifications to it to let the user know, "Loading content. Please wait," and then once that content resolves, focus them on that main outlet where the content has been displayed to read that content back to the user. That's how we're trying to think about tackling this issue but we haven't have a time to implement it to see how it's going to work across all the different avenues of application.

CHARLES: I did want to come back at the component level. are there any other ways that you can lean on Ember or lean on React or lean on Vue, if you're using a component or in framework, just talk a little bit more about how you use those to unlock your application and make it more accessible.

KRIS: One thing I can think of is a way that we can enforce better usage of the framework that we're using is one that comes to mind is a component that I worked out in the blog series that I wrote was building a form input component. Especially, when you're trying to write an accessible app, I think about how can we enforce certain patterns when other developers come in later on and want to add a field to a form or use this component somewhere else in the application. What are some ways that we can enforce that they're doing everything, using the component correctly so that way it renders accessible mark up?

What I tinkered around with and we actually just landed in our application is basically a form group component to where we pass in, obviously the value that the input is bound to. But we also pass in a label that is tied to the input and whenever you hit save and the app goes to refresh, if you don't pass the label, there's an assert statement that basically fires up an error into the console and lets you know, "You're trying to use this component, you need to pass into label attribute for the purposes of accessibility and here's the instructions on how to do it."

We've been kind of toying around with this idea of enforcing patterns because again, we have several dozen developers at Q2 that are working on this stuff and they're not all wizards when it comes to accessibility but how can we gradually start getting them to the place where they're adopting these patterns and best practices. I'd say, doing things like that, we are enforcing patterns in the usage of the components as well is really a key. One thing that we implement it in our testing framework is the use of a Deque Labs' aXe engine to basically go through, we can pass it a chunk of HTML and it will give us any suggestions that it has to make that content more accessible. We're using that in our test library right now, in our test build and encouraging developers as they write new components, as they go in and modify components to throw new snippets in to make sure that the content that's being spit out here is accessible and then submit your PR again. Just trying to be more hands on in that way.

CHARLES: So you actually running a GitHub agent or something that's actually in the same vein as your test suite or if you're taking like snapshotting with Percy for doing visual diff so you're actually running a third check, which is an accessibility check?

KRIS: Right now, we were able to land the aXe engine into our test build a couple months back so we're just slowly incrementing that over time. We have a couple challenges in the way of getting Percy implemented but that is in our list of goals to have that running as well. But one thing that I really like about aXe engine in particular is that if your check fails, it refines improvements that you should be making. The nice thing about it is also spits out a link to a page on Deque Labs website. They give an explanation of what have found and basically educates your developers for you.

To me, I think that's huge because again, we can't educate every single developer and expect them to be pros at this but we can utilize tooling like the aXe engine or the [inaudible] Chrome extensions or stuff like that to do some education for us. As we work towards automating this further and further by using the aXe engine in our development side of things or using Percy on the test build as well. See, there's all kinds of stuff you can do but that's where we are right now.

CHARLES: I really like that idea because in comparison with what we talked about at the top of the show, about how there's this path of least resistance that developers will follow quite naturally and quite rationally, which can lead to not accessible applications. It sounds to me like what you're doing is a establishing the same path of least resistance but having that path guide you towards accessible applications and saying, "This path of least resistance thing, it can be an asset or a liability so we might as well make it an asset."

KRIS: Yeah, for sure. We sit down once a week and we talk about whatever challenges we're trying to work through in terms of accessibility. We have a weekly meeting where we sit down and talk about it. I thought one of the key topics to those conversations is how do we get the other developers that are not in these meetings more aware, more informed and more up to speed with this that they care about it, that they're working on it and it's part of their inner dialogue as they're writing out new features that are going to be deployed out to our clients. Lots of challenges there.

CHARLES: Yeah. We’ve talked about some of these problems that you catch, you're actually writing some assertions there on the test build so you'll actually fail if there's certain requirements that aren't met but what are the things that are more intangible? How do those come up in terms of accessibility? What are the things that you can't catch through automated testing?

KRIS: Right now, some of things that we're having a hard time testing which Percy will help once we get that implemented is contrast ratios and stuff like that. That’s one of the key things that comes to mind for me when I think of the things that are a little hard to catch. I think another thing that's hard to catch, especially at the aXe engine and stuff like that, won't necessarily catch is the flow of your dialogue. When I turn on a screen reader and it starts reading back this page and content to me, sure we can make it so that it doesn't read out the icons character code and a lot of stuff. It presents the information we want back to us but I think, having that information presented back to the user in a way that's legible, that makes sense to them is probably one of the bigger challenges that I've been working on a little bit.

One that comes to my mind is like the reading of currencies or numbers. One thing that I found way helpful was Deque put out a very thorough article on how the different screen reader like JAWS, NVDA, Apple's VoiceOver, how they read different types of punctuation, different types of graphics symbols, how they read [inaudible], $123.50, what does a screen reader actually read back to you. That's where I've actually been spending so much of time lately is building on some components that instead of reading back what the streaming will read back by default, which should be, "Dollar sign, one-two-three-five-zero," having actually read back, "One hundred twenty-three dollars and fifty cents," so basically, writing a series of components, I would do some of that, again heavy-lifting force, in that way, our developers don't have to go in and manually add-ons aria-labels obviously.

That's been a nice little challenge where something that's we are working on just testing right now and making sure it works right if there is any downsides to doing this but I want a person using a screen reader or other types of assistive technology to hear the information as I'm thinking about it. When I see $123.50, I'm thinking in my head that's, "One hundred twenty-three dollars and fifty cents," not in single digits one right after the other. Those are things that a lot of the automated software isn't catching. It’s not catching like, "Your grammar is bad," or, "This isn't making any sense to me." It is catching like are you passing in or applying the attributes to HTML elements that you should be. Are you using semantic structure in your headings and stuff like that?" I think that's one of the areas where developer is need to get their hand dirty, turn on the a screen reader or use any array of different voice-over tools to actually listen to the content being present back to them to see how it's presented.

CHARLES: Yeah, it's almost a difference between a syntax error versus a runtime error like we've got a lot tools that can catch the syntax errors and you can put those in and catch where you have something that's malformed but some sentences can be perfectly formed but make no sense and it takes a human set of eyes to make sure if that content is coherent. One of the things that if you're going to ship applications to people, you need to be able to try and measure as closely as possible the environments in which the people will be using your software so you can actually have an accurate measure of whether it works or not.

For example, in the Ember world lately in the stuff that we've been doing with acceptance testing in React, we admit people are going to be using a multiplicity of browsers to access this application so it's very typical to use Testem or use Karma to fire up five different browsers, which if you're using BrowserStack, you can do fifty. You know, people are going to be using IE8.1 on Edge or on a Surface. They’re going to be using Safari. They’re going to be using Chrome and those often surface those issues but I feel like there's no access to the actual screen reader and assistive technologies to be able to make real assertions against those things.

I imagine that it would be cool if there was some way that in Testem or in Karma, you could have one of your browsers be like an assistive browser that you could actually assert, I want to assert that it read it as, "One hundred fifty-three dollars and twenty-five cents," and is that on the horizon? Is that even possible? But it seems like something that we have to shoot for if we actually want to measure that these things are working if we actually want to capture data points.

KRIS: Yeah, I totally agree. If you look at the documentation on W3 for how these different HTML attributes should be treated by the browser or by the assistive technology, long story short is this is not how -- in several cases -- certain screen readers are presenting the information back to you. It’s not how it's treating the content. That’s again, one of the areas I thought was way interesting about that. Deque article on punctuation and typographic symbols, which is like we should expect that this software is operating at this level to present this information back to user in such a way where it understands what the dollar symbol in front of a series of numbers means but it just isn't there yet. There’s still work to be done. I'm hopeful for the day where our screen readers are a lot more powerful in that capacity.

One that makes me a lot more hopeful about that is I don't know if it's just because I've been more interested about this over the last year but it does seem like I'm seeing a lot more people talk about accessibility. I'm seeing Apple putting out videos, talking about the efforts that they're making to make their software more accessible. It does give me hope that there's a lot more visibility on this now. There’s a lot more people fighting for this cause to cause these companies to come back and say, "We're going to put more effort into this. We not just going to make a standard screen reader and ship it and just leave it there for five years and no one was going to touch it," but, "We're going to start making improvements."

One thing that I did notice just over the last couple months even was that out of nowhere, we use Apple VoiceOver in Chrome, which isn't typically how people use it. They typically use it with Safari. But if you use in Chrome, it will actually read back to you as, "One hundred twenty-three dollars and fifty cents." When I came across that, I was kind of dumbfounded but then I was thinking to myself, the vast majority of people who are using screen readers aren't using this browser but that's really interesting that they're doing this now. I dream of that day where we can basically run a series of mark up through in a test or into a function and basically have to spit back, here's how screen readers going to present this back to you. I'm hopeful for that day.

CHARLES: I'm wondering now like why don't major browser vendors, why is this not just a piece of a puzzle that comes when I download Firefox. Firefox has access to my speakers, why isn't there a web standard for how screen readers will treat content? Maybe there's an effort under way.

KRIS: I sure hope so. Looking through documentation, we know how things are supposed to work, how we've agreed that they should work and now basically, we're just waiting for the different browser vendors and Microsoft and Apple to make the updates to their streaming technology as well as JAWS and NVDA. I'm hopeful that these changes come soon. These are improvements to the interface.

CHARLES: Yeah. Any time there's a gap, you can see that's an opportunity for someone --

KRIS: For sure.

CHARLES: -- To write some software that has some real impact. I know certainly, I would love to see some way to roll these things into our automated test suites.

KRIS: Yeah. I searched for it but with no avail and it's a little bit beyond my knowledge of how to build something of that caliber. I hope someone else does it because I don't know how.

[Laughter]

CHARLES: Well, maybe in a year, maybe in two years, maybe in 10, although hopefully a lot sooner than that.

KRIS: Yeah. I would judge that at the speed of things were going right now, I'm optimistic that we're going to have some much better solutions within the next year or two on this field. Especially of how much I'm seeing people talk about it now, how much it's becoming a part of the regular conversation of web development, application development. I'm really optimistic that we're going to see some strides in this area over the next couple years.

CHARLES: Okay. With the time that we have left, I'm going to ask one more question. Kris, there is something that I wanted to ask you, which is let's say that I am a developer who is working on a team that is maybe it's big, maybe it's small. I've got an application or I'm starting an application and I have a desire to make it accessible. How do I establish that path of least resistance? What advice do you have for someone who's just about to take the first step on that journey to make sure that they have the outcome that they're looking for which is the most accessible single page app that they can have?

KRIS: I think it's a great question. I would start out that answer by simply saying to encourage you to be somebody who cares enough to speak up and become an evangelist, become an educator and become an enforcer in your workplace for this work. You don't have to be the most knowledgeable person in the world on the topic. God knows I'm not and I still there were people come to me, asking me, "How do I make this feature, make the guidelines, make it accessible to screen readers," but I'm passionate about this topic and I'm interested in learning as much as I can about those.

Step one, just being an evangelists for it. Be interested in it, care about it. I'd say, the next thing is just learn more about semantic HTML. I would say from a lot of the things that I've been trying to tackle with the application that I'm working on, just simply writing semantic markup takes care about 80% of my challenges. In just understanding what are the different elements, what are the different tags are for and how screen readers and other assistive technology see those things.

To get started, I would say there's beginner, intermediate and advance stuff. I would say go to the accessibility project, which is just A11yProject.com and read through the content there. It’s very entry-level. You can probably read through most of the content within an hour or two and really start to get a grasp as to what level of effort you're looking at in terms of your application. Once you get through that, if you still want to learn more, I'd say go over to Mozilla's developer network -- MDN -- and read through their documentation.

On the topic, there is a little bit more exhaustive but it's still really easy to read and really easy to grasp. Based on a content they have shared there, I'd say more of an advance level is actually go through all the documentation on the W3. It’s a lot more verbose, it covers a lot more of use cases, it has a lot more suggestions and just stuff ready to go over. I'm still working through that information. There's so much of it but I would say that's as a good place to get started with understanding the different attributes, what they're for and just the importance of writing semantic HTML.

I would say some definitely good things to start tinkering with to find some of the low-hanging fruit in your application would be to use some of the assessment tools that are already out there. You have the [inaudible] little JavaScript snippet that you can put in your Chrome favorite's bar or you can use the aXe engine or if you even have an aXe Chrome extension that you could pop up in your application to basically give you report on some of the areas that you should be looking to make some improvements.

I think it's important to view accessibility kind of like how a lot of bloggers view SEO, is that there's always more work to be done, there's always improvements you can make but the key is to take those first steps and start making those improvements. One of the nice things about the accessibility project and there's a couple other websites out there that have some of the lists, they basically have a checklist for you to go down. If you're just getting started with accessibility, they have a checklist of all the first things that you should be covering to get your app started in that realm, to start making those improvements. I know you guys do links in the show notes. I can definitely send you those things to those items to get people started.

Another thing I find myself doing a lot is while we're talking about something in our chat at work in or just go off in the code pin and mock something out in HTML and then see how the screen reader reads our content back to me and then kind of tinker with it and do a little bit of self-discovery in how this all works together. There’s a lot of options out there. I know just threw a lot at your listeners but I'd say, it all starts with being someone who cares about the topic and cares enough to start asking others to care as well.

CHARLES: I think that's a fantastic answer and a great note to end on. But before we go, obviously we will include those things in the show notes but also the other thing that we're going to include is a link that you actually, I understand, have a series of blog posts related to all of the things that you've been talking about, which we'll also include.

KRIS: Awesome. Thanks.

CHARLES: Everybody, go read it. Thank you so much Kris for coming and talking with us about accessibility. I think you're right. It is a topic that's gaining a lot more traction and a lot more mind share in the mainstream that can only be a good thing.

Audrey Eschright: @ameschright | The Recompiler

Show Notes:

Resources:

Open Source Bridge: Enter the coupon code PODCAST to get $50 off a ticket! The conference will be held June 20-23, 2017 at The Eliot Center in downtown Portland, Oregon.

Transcript:

CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode #71. My name is Charles Lowell. I'm a developer here at The Frontside. With me also is Joe LaSala.

JOE: Hello.

CHARLES: Hey, Joe, another developer here at The Frontside. With us today is the publisher of The Recompiler Mag and a long-time open source contributor Audrey Eschright. Welcome Audrey.

AUDREY: Hey!

CHARLES: Thanks for being on the show.

AUDREY: Oh, thank you.

CHARLES: Today, we're going to be talking about open source and in particular, the labor that goes into open source and making that sustainable but before we get into that, I wanted to first talk about your background, both in terms of how you came to be publishing the magazine and also your background on open source, how we're arriving at the subject today.

AUDREY: The magazine, in a lot of ways, I refer to it as a feminist hacker magazine. It holds together a lot of different things that I've worked on over the years so I'm going to jump all the way back to when I first encountered open source and then maybe that will fit together. When I was in high school, I first encountered the internet and the internet that was available to me at that time use things like Gopher. Gopher is a pretty web protocol and it was free software. I didn't really understand that it was free software at that point but I did understand that if I wanted to learn how to write code and the computer that I have access to were things like a bunch of really old PCs like 286's and an old Macintosh.

Then there were commercial compilers for writing code and there were free compilers for writing code. There was a thing called GCC and I knew that it was on university computers and if I got access to those, then I could write code. Then I got to college and write about when open source really started to take off as this concept of how free software comes into business world. I've had that as a background of becoming a programmer and getting involved in things but after college I wasn't really sure that I want to work in technology so I took a break. When I came back, I needed a way to get myself up to date so I started volunteering with this local group called Free Geek that recycles computers.

What they do is they take those computer parts and the ones that are usable, they build them into Linux boxes for people, like Linux desktop boxes. How I got back up and running was learning how to work and volunteering in an organization that was very open source based, like all of the tools that they used are just completely open source.

CHARLES: Was that for budgetary reasons or they didn't want the people to burden the recipients of these computers with any licensing fees or obligations to third parties?

AUDREY: It's budgetary but it's also ideological. The organization was started out of environmental interests. The original folks, they pointed to us this computer monitor that they [inaudible] as the reason that they do this, that the way computer waste is being handled was so unfriendly that you might as well just dump it in the river. They started from there but I think because those kinds of interests of creating something that was really accessible for people are really educational and accessible to lower income patrons has always been a really big part of it. I think that using Linux and using open source tools has been a big part of that.

CHARLES: I think open source is so pervasive, a lot of people forget that in those days, there was a lot of radical thinking behind it, of radical accessibility like it's your basic right to be able to access every layer of your stack. It's a little bit unfortunate that you mentioned GCC that like the GNU, the Free Software Foundation isn't as much part of the conversation as they were back then.

AUDREY: Yeah. I think that as more people come in to, we've shifted through these different generations basically in open source contribution and how it's formulated. The fact that I even default to open source is really interesting because a lot of the values that I referencing are those free software values.

CHARLES: Fast forward to the present...

AUDREY: Part of how I built my skills was by starting open source projects called Calagator. It's a community calendaring platform that makes it very easy to import things from other sources like Facebook. It's interesting, it wasn't our primary thing but it's so big now. We've been doing this for 10 years so a lot of recent change around us. We have a 10-year old [inaudible] app that is still up and running and is now in Rails engine.

CHARLES: Wow. Is this an application that you can run yourself or when you say it's an engine, if I've got a Rails app, I can just drop it into any Rails app?

AUDREY: Yeah, that was a direction we decided to go in a couple of years ago because my experience was that handing people in Rails app and saying, "Go fork it and then go sell it and use it in your community." That's a pretty big technical burden. At least, as an engine, it makes it a little bit more flexible for people to really come in and make some of those changes. We can bootstrap a little bit more for them.

CHARLES: It's always funny to me know how some projects always run off the fork model, like there's a lot of HTML starters or editor starters where the thing is you fork it. I always hate that model because eventually, you ended up having to do this terrible dance with the upstream in order to jump around the changes that are coming through and stuff.

AUDREY: Yeah and that was definitely one of the problems that we would run into. We would make changes to functionality and the frontend and the visual display of it. It was really difficult for people to pick and choose the parts that were useful for them.

CHARLES: Yeah. Okay, so you've got a 10-year old Rails applications/engine, now you are actually running an instance of this engine yourself or just maintaining the open source?

AUDREY: Yeah, there's actually two of them, that I'm in involved with right now. One of them is that Calagator.org. It's a Portland's techs events calendar. That was really our original site and the reason that we created this. The other one just as of a few months ago is PDXActivist.org and that is a way to get a lot of activism and political organizing off of Facebook, basically. That's really our primary target. It's just getting people an alternative to using Facebook for all of their events.

CHARLES: I see. Now, having to maintain an open source project for 10 years, that's a really, really long time.

AUDREY: Yeah.

CHARLES: How big is the community now and how many different users have you seen as you developed this?

AUDREY: Well, it's a little hard to tell. We deliberately don't do a lot of tracking, especially on PDX Activist side. I can tell you that there are a lot of events on both calendars. For the tech events, there are probably five things that you can do on any given day, maybe 10. During design week, they put all that on there too. This has been very consistent over the history of the project. I can also tell you that we've had dozens of contributors.

CHARLES: Yeah, that's more what I meant when I said users. Not necessarily the consumers of the calendar but the consumers of the software that makes the calendar.

AUDREY: It goes without saying that I think that those users are creating events, they are part of that because they help curate content. Like with the wiki, your user base isn't just the people who update MediaWiki. It's that people who really work on the content too. We've had dozens of people. There's a contributor's file that I didn't pull up but we can go and look at it. We made a point of crediting everybody who contributed at Code Sprint, whether or not they check in code. We have a really great documentation over the history of the project about how the different ways that people contributed and who they are.

CHARLES: Yeah. I feel like that's something that often goes missing in projects, especially open source projects that you find on GitHub where there's so many people that are involved in creating software beyond just what you see in the commit history. It's kind of a poor showing of what it was all involved in the whole creative act. Sure, it's an accurate reflection if it's a one-person project who's hacking away on weekends but as your project scales, there's a lot of different stuff going on.

AUDREY: Yeah, definitely. I think the other part that's really interesting for me about this is that I can point to that big contributor pool, people who have come to sprints so they've work on a project. They help define the shape of the project. Then I can tell you that we had a three-person core team for a very long time and then it was down to a two-person core team. Now, I'm not really sure which one of those is in charge. I don't look at GitHub often enough and a couple of the other computers. There isn't a lot of coaching happening anymore. We should have a wish list but there's nothing so urgent that we stop all other work and go back to making this our primary effort.

CHARLES: Of the people on the core team, how many of them are developers?

AUDREY: All of us. All three of us were. We come into with different cross skills. I've done a lot of documentation and mentorship. As of the others, I would say we have one person who were in design or one person who was more apps-oriented. We fill those different layers too.

CHARLES: Of that group of the core contributors, outside that group of core contributors, you said you accumulate a list of all the people who contributed. What's the breakdown in the roles that those people are playing?

AUDREY: You know, it has changed a lot over the course of the project. Early on, we had maybe half of the people were really doing development and the other half were helping. We took a very agile approach like index cards and users story. Maybe half of the people that show up at a given time, we just talk through the feature and do research. We were looking at a lot of integration so what needed to know what would be required to integrate it. We brainstorm a lot of things.

We did in-person Code Sprints every two weeks from the year that we started, at late of January to the end of July. We had this whole set of in-person work that really shape in that. Also a lot of people who weren't necessarily contributing code that had disappeared.

CHARLES: I see, so people who had a vested interest in a particular set of features could show up and voice that interest and be heard, as opposed to what you're having, it just be limited to the people who are writing the actual code.

AUDREY: Yeah and we would ask people to spec it out. Just sit down with somebody and figure out how the feature could work and whether it fit with everything else to what we're doing. I do that research and investigation. Over the years, we've had this come and go in waves. Every so often, we need to go up a Rails version or make certain kinds of major updates so we get people together for that.

We had some different pools of Codeschool students that have come in and really been interested in working on this to get a little bit more development experience, get some experience working with other people, have open source some resume to show off. I've been very enthusiastic about giving people that resume credit that if they need an open source of it so that they could say, "I know how to write with other people," then our projects is very happy to help them with that.

CHARLES: What is the conference that you run?

AUDREY: I am on the committee for Open Source Bridge. It's an annual conference for open source citizens, which is the same people who participate and benefit from open source.

CHARLES: Which is pretty much the planet at this point.

AUDREY: Yeah. It's funny because, I think it's just so interesting who does or doesn't identify themselves as part of that. Anybody using a computer these days is in some way benefiting from open source and could potentially contribute to it and be part of that. It's not just awareness, there are a lot of actual barriers so that, to everyone having a role in it. But the conference I co-founded it with Selena Deckelmann who's at Mozilla now.

We do say over time to ask a lot of questions about how across technologies, open source comes together to build things? How projects work? What kinds of skills are involved? How we become better maintainers by being aware of our users, by communicating better, by being good moderators of online message boards and mailing lists and things like that? We've had a chance to really just look at broad swath of elements that come in.

CHARLES: I think that literally every bullet point that you mentioned, I feel is something that we've come across and it has been a challenge for us, in our efforts to maintain our open source projects. Ours are mostly just libraries. There's very little by way of big, big frameworks or big, big applications. We've got it kind of easy, I would say and we still struggle with those things really understanding our users, understanding how your open source project should run and how it even fits into the bigger ecosystem. Is there a guide out there somewhere like how to how to open source?

AUDREY: You know, I don't know that I've seen a single guide but there is really a lot of good writing and a lot of good conference talks on this topics. Like you said, it's just this broad set of skills and we focus so much on teaching people how to code and maybe teaching people how to code together, to be good contributors together but if you ever to maintain a project, there's leadership involved. There's communication involved.

CHARLES: It seems to me that's the bulk of it, right?

AUDREY: Yeah. I don't know, did you get training on that?

[Laughter]

AUDREY: I just decided to try things. I'm very lucky that I'm mostly made good guesses but there's some really bad ones too where later I look back at it and realized we could have done better.

CHARLES: What are some of this mistakes that open source contributors often make, where they could save themselves a lot of trouble?

AUDREY: I think a big one is thinking about it only in that technical framework. Even just by tools that we use, we tend to force people into contributing solely through GitHub, which means that you've got to understand somethings about the bug tracker and how tickets go and the workflow around that.

CHARLES: Yeah. I've literally looking at a message in our Slack from yesterday where someone on our team who doesn't interact with GitHub said literally, "Someone is going to have to show me how because GitHub is the most confusing thing I have ever logged into."

JOE: I thought about that message today too and yeah, I guess I'm wondering how do you attract those more non-technical skill sets to a project?

AUDREY: It takes a lot of direct mentoring and coaching. You already has some people that are identifying themselves to you if you're having that conversation. I think I've really benefited from looking at who else is like them, who else do they know that might want to get involved and starting conversations that way. Because the biggest projects that I have worked on are these calendars, it does give us so many users that maybe are interested in having more technical involvement.

If I can start looking at who's doing a lot of cleanup on there, who's paying a lot of attention to the content and the structure of the content and structuring information is also a technical skill. But people don't necessarily go from that to thinking, "I can write code," or, "I could submit a ticket and debug that thing and tell you what needs fixing now." But people can get there. We just have to be willing to talk to them about it and willing to look at it from their point of view.

CHARLES: One thing that I dig out of there is that if you're running your open source project solely on GitHub, it's not going to be enough. You're going to be constrained in your growth just by the toolset and the implicit exclusivity of that toolset. What are some tools that you can bring in that are going to be more attractive?

AUDREY: I think mailing list have turnout to be one of the most open-ended things that we've done. People who want to find out a little bit more, sometimes post there but also just having a good webpage, a good info pages or some sort, having your wiki actually talked about some of the less technical aspects of it. Even explaining what your project is for can be really good. You know, you start to make these assumptions like, "If they're going to go and install it, do they know?" Maybe not. I think just looking at it as a broader set of communications.

CHARLES: Right. What seems self-evident to you and maybe someone who shares a lot of context to you is a mystery to someone else. It never hurts to state the obvious. It seems to me you have to be able to use tools that people are familiar with but also part of the leadership is giving people things to do, giving them a way to think about your project or giving them a way to act independently. How do you think about the different roles in an open source project so that you can then elucidate those roles so that someone coming, who is going to look at your website or who's going to be reading your e-mail list is going to be participating in your community in some way and particularly not in a code contribution way, how do you think about the different roles of your open source project so that you can kind of hand that to them? So that they can act independently like, "Here's this thing that you could do. Here's this thing that you could do. Here's this thing that you can do." What is that kind of core set of roles?

CHARLES: We could think about it in terms of the actions that we take. If you go back to our lone weekend coder who put something on GitHub, you're already writing the code, making design decisions about the shape of the code, you are writing about it in some way, even if all you do is update the ReadMe to have two lines of something you're writing. You are managing any bug tickets that come in, any future request so you're doing some project management, some kind of general analysis of that.

They don't necessarily have to be different roles. People implicitly take on the whole thought of that when they start a project. But they can also be split out. I hate to say like, "Give away your least favorite thing," because people sometimes do that, may dump it out there and it never gets handled well because they don't really understand what they're looking for. But it's okay to say, "I am really great at this one thing and I really struggle with this other thing." I bet there's somebody else who is just way better at organizing the stack communication and they can help me with that. If I can tell them what I need it for, maybe they can help with that.

CHARLES: So you have to admit your weaknesses?

AUDREY: Yeah. I think a lot of leadership is that kind of self-analysis: really seeing where you are helping the most, where you're strongest, what things absolutely have to be done with you. I don't know. I'd learned you to be really honest about that. Sometimes, the thing you enjoy doing is not the thing that you have to do because nobody else can. But often barred things that are really not fun for me, turned out to be the thing that nobody else can do.

I just think that you have to spent some time thinking about that and thinking about what you can teach people too. You already have the knowledge of your project and what you're trying to do so I think what you can teach is what your mission is, what your goals are and maybe they can help you to communicate that too.

CHARLES: Yeah, because it seems to me if you actually can very clearly communicate your target, then people can begin to walk towards it independently and that's almost more important than the actual taking the steps. Or the steps needed to be taken but that's something that you can provide.

AUDREY: Yeah, you need that kind of definition regardless in order to make your decision and have your work actually function and the less conscious we are about, the more we tend to get a big pile of something and you go, "Now what? What do we do with that?"

CHARLES: Right. I think it also flushes out if you have a clear target and you have a clear mission, by externalizing it, it makes you reflect on it more and hardens it, if that makes any sense. You have all these ideas bouncing around in your own head about the things that you might want to do or might like to do but once you actually try to express it to people and say, "You know what? We’re going to do this." Then it takes on a reality of its own that is subject to more scrutiny but also subject to the constraints of the real world and that's a good thing. It means that whatever you're going to come up with is going to be more resilient.

AUDREY: Yeah. I think we can be scared about putting that out there. They won't see what you see or they won't like it. Those who disagree with your goals there will go, "You really should have been building an eggplant slicer and not a tomato slicer." Yeah, I don't like tomatoes. But for more definition that we put out there, the clearer we are, the more that the people who want to [inaudible] they can find us. That's why it's so important to do it and not to dodge those kinds of questions.

CHARLES: Yeah, absolutely. Now, I'm wondering so when is this conference that you're running? Is this the first one or is this the second, the third?

AUDREY: Oh, no. We're on our ninth.

CHARLES: You are on your ninth? Oh, my goodness.

AUDREY: Yeah, it's actually just in a few weeks. It's in June, the week of the 20th, I want to say. Tickets are for sale. If you're in Portland, we had a great volunteer program where you put in eight hours over the course of the entire week. You can split out with everyone and you get a free ticket.

CHARLES: Nice. This is the problem with the internet is I'm always finding out things that I wish I'd known 10 years ago. I wish I'd known about this before it actually tried to do any open source. This is the Open Source Bridge so what's a sample of what you guys are going to be talking about?

AUDREY: The thing that we've added this year and it's really exciting is the activism track. We're having a lot more people to talk about what they do as code. In this other way, more of public facing way. We have Nicole Sanchez from GitHub. She's going to talk about diversity inclusion and some of the biggest [inaudible] there. We also had Emily Gorcenski doing another keynote and she talks a lot about data and ethics and has a lot of interesting things to say about how we collect and sort and process information and the impacts of that. We have a couple of workshops that are really great. One on technical interviewing and the personal skills that you need. There is a session on keyboard hacking.

CHARLES: Keyboard hacking? This is in the activism track?

AUDREY: No. This are across all the tracks.

CHARLES: How many different tracks are there?

AUDREY: There's five.

CHARLES: This is a big conference.

AUDREY: Yeah. It is such a great community for me to be a part of. Like I said, the different kinds of projects that people come from and bring into it and the different skills, we'll have people that are everywhere from kernel hackers to working in devops to people that kind of fit, I think what we think of it are more typical like web developer or mobile developer kind of skill set. People who run their projects, folks from Dreamwidth often come and participate and they have a lot of really great things to share because they have such an inclusive focus on how they do their project.

CHARLES: Where was that?

AUDREY: Dreamwidth. It's a LiveJournal spinoff. It's online community journaling website. It's in Perl, which is cool. There aren't as many outward facing things, hiring Perl programmer these days, I think.

CHARLES: It's still a very active Perl project?

AUDREY: Yeah.

CHARLES: Wow. I did Perl a long, long time ago.

AUDREY: I think it's really useful to remember that programming languages never actually die. There is always code.

JOE: There's still plenty of COBOL positions out there.

AUDREY: Yeah. Actually my uncle is a COBOL programmer.

CHARLES: Yeah, I remember it was only some statistic where it was something like five years ago, Java, Eclipse, COBOL is the most popular programming language. The cycles are much larger than we tend to think. Surfing on the beach as we do, not realizing there's a whole ocean generating those waves.

AUDREY: Yeah, I think if you're in a certain kind of technology startup plan, there's always this push to go for the nearest and shiniest on the number of JavaScript frameworks that we've gone through in the last five years. You kind of [inaudible] of all of these things that come before that are still in use. What I really loved about doing devops is that all of this pieces are still in play and there's something to learn from that. If they don't die, you don't get rid of them. You just try to build on them and keep them working usefully.

CHARLES: Right. Man, that's exciting, so you have a very, very huge cross-section of the development community. It sounds like participating in here which is a quality in of itself. That must give you a pretty unique perspective being with that level of cross-discipline. Are there any insights that can only be gleaned by being able to perceive it from that high of a level?

AUDREY: Well, a big one is that we all struggle with governance. We don't really talk outside of just a couple of forms for events that focus on open source maintainers. We don't talk about the governance of projects, like who was in charge and how decisions are made. But it turns out that that has just an enormous impact on what a project can actually do and how it survives. I think I might not have seen that as clearly without having people from so many different angles participating.

CHARLES: I'm just trying to think of keeping it in the area of web frameworks because that's something that I'm familiar with. If we were to compare, say the governance model something like React, which is basically whatever Facebook wants, versus something in the middle like Angular, which is like an explicit governance model but also is heavily influenced by Google, versus something like... I don't know, well something like JavaScript itself, which has an open democratic model but heavily represented by major, major, major companies, versus something like Rust, which is I certainly get the feeling is a very explicit, very democratic model.

All of those seem to have achieved a lot of success and this seemed like a very healthy projects but on the one hand of the spectrum like Rust, you have the super-transparent, super-democratic model and then on the React side, you've got this authoritarian model. That's opaque. How do you reconcile that those are both successful?

AUDREY: I think a lot of what actually determines this stuff is who pays the developers. In both of those cases, meaning projects that present information and decision making differently but there are corporations that pay those developers and that's where the primary source of that code. Because of that, really who pays the developers determines what gets made, what code gets written. In a way, they're both doing some of the same things. They're just not giving you inside into that decision making, in some cases.

CHARLES: The decision making apparatus is there, I guess the thing is this transparency to the user base matter. I would say that the user base of a thing like React dwarfs the actual corpus of decision makers. That doesn't seem to be that that decision making process is opaque.

AUDREY: Well, I might be opening too much of a larger conversation by saying this but if you're familiar with the idea of algorithm transparency, decision making is encoded into things like algorithms and when we can't examine them, then we don't know how that decision was made so we don't know what biases are encoded into it. The same thing happens with code in general. You might say, "Let the outcome of this and this working really great," but there are still biases and preferences that are encoded into that that you don't have insight into.

If they start to ship the project in a certain way, that include some users and excludes others. Even on just purely technical levels, you don't know what. You don't know how they got to that, you don't know if they're going to keep steering in that direction. If you're one of those people that is starting to be excluded, you don't know what you can do about it. I've seen these kinds of governance discussion even happen within Ruby in Rails.

CHARLES: Yeah, it does seem like these political questions come up constantly. I remember an example that leaps to mind is a project that I was involved with was the Jenkins project, which originally was Hudson, which came out of Sun Microsystems. When Oracle bought Sun, they were basically trying to, I want to say there's always three sides to every story but from where I was sitting, they were essentially trying to subvert the project to their own needs and end up being in a fork of the project. Luckily, there was recourse there where because it was open source and because it was mostly maintained by the community and not by the company, they were able to fork it. They changed the name. They changed the logo and that was the end of the story. There was a question of which fork would survive but that was resolved within probably six months.

But Jenkins lived and I think it's better off for it but I guess maybe then a question that you can one kind of stress test that you can put like, "Is it okay to put weight on this technology?" What would happen? Would my community be represented and would I be able to fork this, essentially? Maybe in that sense, React would pass that test. In the sense that it would be reasonable to fork it or something like that. I don't know. I'm just thinking of ways to try and validate if something safe to use.

AUDREY: I think it's really interesting that you commented on the new change and the logo change because those kinds of trademarks are actually the most readily protected of all of the intellectual property in an open source projects. If things are going to go off and become a community project and it's being released under some open source model, often where the corporate control stays over those assets -- the name, the logo, the graphics -- maybe even some of the work [inaudible].

You have to ask if that code is still useful without that infrastructure that they provided. If you take the whole codebase and you walk off and you don't have the same developers and you don't have the same, even hosting resources or whatever, is that code still useful to you? What if you use a bug tracker?

CHARLES: Right, now you own it. What's the cost now of maintaining? And are you going to get a return on that investment?

AUDREY: Yeah. There's been some pretty big open source projects that have struggled with that, especially for end user facing software. Those turned out to be easy things for community to pick up.

CHARLES: Can you provide any examples?

AUDREY: I'm thinking of some of the stuff that happened with Open Office LibreOffice.

CHARLES: Yeah, I remember that.

AUDREY: There's still two different batches of people working on this and from what I understand, a whole lot of intellectual property complications.

CHARLES: Yeah, it's funny how sometimes, it would be interesting to see a case study of all the major forks and the outcomes of what they were. Some I can think of, there was a fork of Ruby gems, for example I think back in 2009 that went off and was mainly, I think was a way of protest. I think some of those concerns were addressed in the main thing so that fork ended up dying, then you got the fork of io.js, which was ended up. There was a fork and then a rejoining with the Node community but I would say it was an effective tool so there was a fork but then it joined. It was a source code fork but it was a political fork. Then you have the Jenkins fork where the fork basically swallowed its ancestor and there's all these fascinating outcomes and then you've got this LibreOffice Open Office where the waters are very murky about what happened with that fork.

AUDREY: I heard people say like, "If you don't like this decision, then just go fork the project."

CHARLES: Because that's easy.

AUDREY: And if one of your major developers does it, then maybe, like you said, they have some leverage and they can make the changes they want to see happen, [inaudible]. But in general, that's a really hard thing to pull off. You've got to be able to take your entire community with you. Part of this is have to be functional and I think people are very rarely actually make that happen.

CHARLES: Right. I feel like that's a dishonest thing to say when people are like, "If you want to go fork it," because really forking the code is the easy part. It's forking the community.

AUDREY: Well, if you do that, then you've got a lot of conflicts. You've got a lot of people's feelings to address. It's not a very simple thing to recover from.

CHARLES: Yeah. Some people do it. We have some good examples of that happening but it doesn't always pan out for the best. How can we make open source more accessible and supportive of contributors? We’ve mentioned a lot of that stuff in terms of how you can support people who are contributing but there might be more to talk about that.

AUDREY: Yeah, we haven't really talked about who gets to participate. We talked about what kinds of things you can do when you see that people are interested but we don't talk about how in order to be a week encoder, you've got to have those weekends free. Certainly, I am right now.

CHARLES: Yeah, neither do I.

AUDREY: You have to have access to a laptop if you want to go to Code Sprints or [inaudible]. Not everybody has that, even people who are programming or your own computer not owned by your employer. That can be really important. You have to have a knowledge of how open source works. I do see fairly often in conferences that focus on a lot in open source, there will be how to become an open source contributor kind of talk. That kind of cultural knowledge is really important because otherwise, you're going to GitHub and you look at it and you say, "What am I supposed to do here? What am I actually supposed to do with this?" It's just a wall of information. There's something about a project on GitHub that creates these entry points for somebody who doesn't know how open source projects work.

CHARLES: Yeah and it's so hard to be able to perceive it from that person's perspective, especially if you're frog-boiled, so to speak in the community. You've been doing this for so long, these things seem self-evident that it takes a computer, it takes the time, it takes knowing where to establish a toehold. These are all non-problems for you but they're insurmountable for someone else.

AUDREY: There's one other aspect of this that we haven't really talked about, which is the friendliness to the kinds of contributors that you have, the diversity of the project versus the homogeneity of the contributors, whether or not you have a code of conduct and you know how to do something with it so that people feel safe and welcome in your environment. There's a lot of people that stay away from open source projects because all they've ever seen is harassment and that behavior.

You can have a counterexample but if you don't have some mechanism for showing that that won't happen in your projects, then there are folks that are never going to submit about. They're never going to make a commit. They're not going to put anything on the wiki.

CHARLES: Why would voluntarily subject myself to, if the only thing on the other end of the phone is pain?

AUDREY: There are plenty of people that decided just to opt out because of that. If open source projects want to see more contribution, you have to be very proactive in dealing with that.

CHARLES: Yeah, I feel like it almost would be nice to have some sort of training. Even if you have a code of conduct on your open source project, I think as you grow it from something that's maybe just one or two people to where there's a larger community, the first time you have a bad actor who shows up and start slinging turds, it's shocking and you're taken aback. But just as the number of people grow in a community, that is going to happen. It's just an unfortunate fact of human nature so not having to react to it, but be prepared for it, I think is something that's extraordinarily valuable. I don't know if there's a guide for that on GitHub or guide for that on anywhere else but I think it would be very useful skill to have.

AUDREY: It's just very funny that you say this because this is actually a training idea.

CHARLES: Oh, really? I promise there was no payment under the table to ask that question.

AUDREY: Yeah. There was some consulting around this and I started a program with a local non-profit called Safety First PDX and what we do is train user group leaders, conference organizers, open source project maintainers on exactly that: what to do with their code of conduct to enforce it and help people feel welcome in their community.

I worked through a really specific examples with people about how you respond, how you have this conversations and what kinds of things you need to do to protect your contributors who are participants and be really firm about what is next in your space.

CHARLES: Absolutely a critical skill for any open source project, for any open source community, for any large accumulation of people.

AUDREY: And GitHub made it very easy to put a code of conduct on your project now but without these kinds of resources, I think what happens is that people get that first incident and they panic because it is scary to tell somebody that their behavior isn't okay. To tell them that they might have to step away from the project or stop doing that or even leave indefinitely, those are really hard things to get started doing. I really enjoy doing the training and getting to walkthrough that to people.

CHARLES: Are you going to be offering that training anytime soon?

AUDREY: We just had one here in Portland last week. We're doing it a quarterly thing but I'm also really open to bringing it elsewhere like a place to host and some sponsorship that they can throw at that and people that want to take this.

CHARLES: That'll be awesome. Maybe we can have you in Austin.

AUDREY: [inaudible].

CHARLES: Thank you, Joe. Thank you, Audrey for coming on the show.

AUDREY: Thanks.

CHARLES: It was really great to talk to you. It's great to talk about your history in open source and the things that you're doing in the community, especially the insights that you have around running sustainable open source projects. Also, thank you for talking to us about Open Source Bridge which is, I understand coming up right around the corner.

If you want you can go to our podcast page and there will be a link to get $50 off if you enter in the discount code 'PODCAST.' That's $50 off of your open source bridge ticket. Be sure to go check it out. That's it for today, from The Frontside. If you're interested in hiring us, we do have availability starting in July so reach out to us. All right, everybody. Take care.