35. Bringing Open Source to Work

Leah: And one of the things about me that's a little bit different than most people you'll run into in open source is that I don't write much if any code, at least not in terms of my involvement in the open source projects. So, one of the things that was an early idea, not really talked about but in practice pioneered by John Resig on the jQuery project was, this notion of having a functionally diverse core team.

Leah: So, not everybody on your core team had to be an engineer or a docs writer or the traditional things that you think of when you think of an open source project. But that instead you also need people or, I guess in my case person who focused on things like organization and governance and finances and events and logistics. I don't think John has ever really talked about this idea, and he probably hasn't noticed that I talk about it as a thing he came up with. But in practice he came up with it by virtue of allowing it to happen. Right?

Leah: So I was around, and in that day and age had I been around and even wanted to do the work, I maybe would have been allowed to do it, but I certainly wouldn't have been recognized for my contribution. And he, I think just because he's a good guy did and took my areas of expertise seriously, which in turn made the rest of the core team take it seriously. And it slowly evolved into an actual role.

Leah: And so, my journey in open source has been those types of skills in all these projects. I usually get involved at an early stage, because a lot of the early stage things are logistical or project management kinds of tasks, right, or community management kinds of tasks. Hey, I've written this awesome piece of code, how do I get anybody to notice it or care? Okay, now people care, how do I handle the flurry of PRs and various other personnel issues that I need to deal with?

Leah: So, I did that for a long time, strictly for open source projects. Slowly my professional life moved over and I shifted from doing non-profit work to working in marketing, in organization and operations in tech companies. And after doing that a couple of times, I realized that the only difference really between myself and the CEOs of all these various companies was that they had the boldness to stand up and just do it.

Leah: And so the opportunity presented itself where I said, "Okay, I'm going to step up and we're going to do this right now." And so, together with my co-founders I started at Tilde. We just last week had our eight year anniversary, which is pretty tremendous. Basically any day you don't go out of business is tremendous in starting a new company. So, that brings us to today. My background, the background of my co-founder Yehuda, and a lot of the people that we've hired have really shaped the DNA of our company.

Leah: Where at every step along the way we care about open source, we integrate practices that are friendly to open source, we value open source contributions of our team members. And it's been really quite fruitful and I think we owe a lot of our success to our open source strategy.

Jamie: I'm really fascinated by that moment where John had the insight and the foresight to bring you onto the core team in that way. He obviously recognized something in you, and that makes me wonder about when you are in a position of responsibility within an open source project, how do you kind of keep your eye out for people like that in the community, or on the peripheries of the community, or people who maybe even don't realize that they could play that role?

Leah: So, the truth with John is that, I think that his biggest strength in his role as the creator and leader for a long time of this project that got astonishingly successful is that, he just wasn't a very ego-driven person. And it's not to say that all coders are egomaniacs, but he just never seemed susceptible to that invincibility problem, to that I'm an engineer and thus I can do anything. And so, it wasn't a decision to take people seriously for him. It was just like, of course I take everybody seriously, and he's also just nice.

Leah: And so, he treated everybody with respect. And if you showed up and you wanted to do the work, why wouldn't he let you do the work? More work for you meant less work for him. And so I think that first of all, just as a personality type. That is a very useful person to drive a big ship, is somebody who isn't actually all that concerned with themselves and their role and maintaining tight, powerful grips on everything.

Leah: But there's a lot of power in the feeling of having an impact, and it's a feeling that people crave. And so if you just create and highlight opportunities for people to have an impact, a lot of them will actually take those opportunities and become productive and critical members of your community.

Jamie: I think it's quite a powerful thing for people out there looking to make their first contributions in open source. And indeed for people who are transitioning from other careers into technology or stepping into technology for the first time. To know that people leading open source projects are on the lookout for these kind of other skills to bring into things. Whether your skill is copywriting, or graphic design, or the kind of logistical work that has been your bread and butter through your life in open source.

Leah: It's a multifaceted problem. Like, if we as open source projects do a really good job of inviting these people in, the next step in the challenge is going to be getting their employers to realize that their contributions are just as serious and valuable as the contributions of their coders. And that might be really hard actually, because first of all, it already is incredibly hard to get some employers to recognize the value of letting their employees do things on company time, or adjacent to company time, or even if they don't get company time, of just being supportive.

Leah: And it's going to be a little bit harder with functionally different things. Because when you say I'm an event planner, I'm going to help with this conference, that sounds to an employer a lot more like that's consulting work, we should be getting paid for it. Which is a thing that programmers have gotten past with a lot of employers. But, let's solve the problem of getting people interested and then we can tackle the problem of getting their employers to be supportive.

Jamie: On the other side of that coin, I know of employers who are very keen for their employees to get involved in open source projects, for personal and professional development reasons as much as anything else. And I think that can be, even with the best of intentions, that it's not necessarily straightforward to find. You can give someone the time, but actually finding a way to contribute to an open source project that's a good fit for you as an individual, isn't always straightforward and it takes some mentoring from an employer and indeed an employer who has seen that happen successfully several times.

Jamie: From your perspective as your team of people at Tilde, what kind of advice do you give to your team? As to when when they're wanting to go out and do some open source work. What kind of things do you tell them to target?

Leah: So, I'm in a very privileged position in that regard because, myself, Yehuda, we have been involved in these projects for years and years. So, it's not like our employees need to sit down by themselves and brainstorm where I can be useful. It's more like we're proactively constantly bringing them into the projects that we're already working on, and suggesting ideas for other things, or suggesting ideas for projects that maybe I don't even know anything about, that somebody else on the team works on.

Leah: So, networking either with your colleagues or with your bosses on that front can be really really helpful. But you get to know your employees obviously, and you get to know what areas they are experts in and plug and play. Of course it's not always that easy, but you're building their profile in an area that directly benefits your business. So yes, one day they will not work for you anymore and that will be sad. But first of all, do a really good job of keeping them around by continuing to invest in them.

Leah: And second of all, while they are around, you'll be able to benefit and get a return on the investment for everything that you do to help them build their public profile. Like yes, Yehuda is a well known engineer, but when Yehuda worked for NGR it was a tremendous benefit to NGR, and when Yehuda works for Tilde now, it is a tremendous benefit to us because it's circular. It's good for the company, it's good for the person, it's good for the company, and you all sort of scratch each other's backs and enjoy the goodwill that the other one generates.

Jamie: So maybe that's a good segue to talk about the current nature of the relationships between Tilde and Ember and all of the other projects that you're involved in.

Leah: Yeah. People oftentimes ask questions like, what is the relationship between X and Y, because I need to figure out the relationship between my company and my project. And in truth, I really really don't think that there's any prescribed way that is the best for everybody. Which makes it hard to give advice. But basically, all these relationships evolve differently. I think in any of them it is important that the company not be leading a project in anything that is too heavy handed away.

Leah: And I think it is critical that no one project be entirely dependent on one company, because companies go out of business, and companies change priorities. And if everybody at a company is the entirety of the core team of the project, if that company changes priorities, that project dies regardless of how many people internally cared about it. And that's why projects like Angular in phases where they don't have external contributors are worrying, because Google could cancel Angular.

Leah: I think that particular project right now is at a bigger stage. It's less of a concern, but it was a big concern early on. Like in the same way that Google might cancel Google+ or some other product, they are thinking about this open source project as a product. And if they one day told all the engineers that they had assigned to it that they couldn't work on it anymore and stopped sponsoring conferences and took away all the funding, there's a good chance that that project would die.

Leah: But Ember, Tilde supports it tremendously and we have a lot of our employees who are on the core team or work on the project. But to be perfectly frank, if we went belly up tomorrow, it might not even matter at all. It would be sad, but the project would keep going and it's the same thing. LinkedIn is a major supporter of Ember these days, and a lot of Ember's most active community members work at LinkedIn and get employer time to invest in the project. But if LinkedIn tomorrow decided internally Ember's canceled, it wouldn't matter.

Leah: Ember itself would keep going. We have enough people in enough places that the network can't be taken down by any one single point of failure. And that's important when having your company be a supporter of a project. It's similar to that instinct where employers don't want to invest in people. Where employers might feel like, oh, we want to own this entire open source projects so that we can have control over it.

Leah: But that is not a good trade, because full control means you also don't get to take advantage of how an open source project actually should work, which is with contributions from everywhere and ideas from everywhere. And so, I guess one of the central themes is just a lot of the ways to have a successful relationship between a company and an open source project, are counter to the way companies are used to doing things with respect to investment and return and control.

Leah: But if you can give up a little bit in each of those piles, the returns are tremendous, and you have an open source project with the technology that your whole business relies on. That there are people all over the world enhancing and maintaining, and you don't have to do that work. Long term it seems like an obviously correct trade, but it's those short term decisions that will sometimes get companies in trouble, and those short term ROI type calculations that will throw a wrench in this kind of operating.

Jamie: In practical terms then, what are the kinds of things that Tilde works on day to day towards Ember or other things like Rust?

Leah: So we work on lots of different things. Practically our engineers write actual code. Practically I work on planning events for the community. I also work on a whole slew of other things, like dealing with brand-related questions. Can I use the project logo in this way? Can we make a custom Tomster in that way? I deal with a lot of diversity in inclusion efforts, maintaining, updating our code of conduct. There's a laundry list there, but the thing that I do that is the most interesting to me right now, is sort of talent scouting within the community.

Leah: That sort of stuff that we talked about earlier where, I generally have a list on my desk that I maintain of people who aren't very important in our community, but I think should be, and I think could be. And some of those people I met one time at a meetup, and some of those people are really digging in right now into various projects. And that sort of part of what I do has been the most rewarding part for me for a really long time.

Leah: Because there are people now on the core team of the Ember project or in critical roles in the Ember project, where to be clear I don't want to take credit for their success, but I feel really good about the fact that I helped them take those first few steps, and did the easy part of getting them involved, of reminding them that they were welcome and of bringing up to the people who were already there. Like, "Hey, have you met Jessie? Because she's awesome and I think that you'd be a really great contributor in this and this way."

Leah: And again, it's both a functional tool and it's a diversity and inclusion tool. You have to make a manual effort to notice people, and then you have to make a manual effort to bring them in and make sure they have that smooth sailing. And yes, sometimes it can just work magically, and I meet a person and then a month later it turns out they figured it all out on their own. And that's great, but you can't rely on that especially if you want to make sure that your project has diversity in all the ways, and also especially if you want to make sure that even people who are quiet and maybe not that very bold, that that bold can find a path in.

Leah: And that's something that I'm always telling other people to do, as my engineers, the people on the project who are not engineers. It's just sort of keep that in mind and maybe periodically poke and make sure that they know that they're wanted, and walk them, and ask them if there's anything you can do to sort of smooth that path.

Jamie: So we've been talking about the kind of talent management angle. I do want to dig more into kind of til this portfolio of projects beyond open source things. So perhaps let's talk about Skylights a little bit.

Leah: So Skylight is a fun product to work on, but it's also been a really good example of how being involved in open source communities can enhance your product. So, first of all obviously, or maybe this isn't that obvious, but we don't do very much traditional marketing. We don't have an SEO person, we don't spend a ton of money on any kind of marketing. But people know about our product because they know about our people via their open source work and they say, "Oh, Skylight, who works on that? Oh, that person worked on Rails, that person worked on Ember. Let me check it out."

Leah: And so, having an engineering team or in my case a team of anybody, but having a team of people who are involved in open source projects is tremendous marketing for whatever it is you do to actually make money. And it's the kind of goodwill marketing that is really hard or near impossible to purchase or to manufacture. So, the fact that our people work on Skylight and work on open source projects, has had a tremendous impact on our product and on our bottom line.

Leah: But also we're never subject to, oh my gosh, some standards committee changed a thing. We have to rewrite our app or we have to nix all these future ideas on our roadmap or anything like that, because we're in the room making the decisions that impact Skylight. It's not that we decide we're going to build X feature and we go into the room and we say, "Okay everybody, the next priority for the project is this because I need it for Skylight." But it's more that the two get to develop in a very dovetailed way.

Leah: So they really help each other in all sorts of ways. There's nothing or very little in Skylight that we don't have some modicum of control over, which is really hard to say as a company that uses open source projects. Because you pull this off the shelf, you pull that off, you get that project. And sometimes the projects just die because they're not maintained. And sometimes the projects pivot because people change their mind about what they wanted it to do or any such thing.

Leah: That's not a very big risk for us because we're in the rooms, we know what's coming, we can advocate for our use case and we can plan responsibly.

Jamie: For listeners who haven't used Skylight or don't know what it is. Do you want to give the 10,000 foot view?

Leah: I was avoiding it kind of on purpose.

Jamie: I thought that might've been the case.

Leah: I am so not in the weeds on it right now, that I worry that I wouldn't do it justice. But Skylight is a Rails profiling tool that allows you to find the problem points in your application, dig into them, figure out what might be the issue and fix it. It gives you a very friendly view of each request and what might be going wrong. And I say friendly in a very purposeful way, because the reason we started Skylight is because people would log into their APM or whatever various performance and profiling tool they would use, and they would be made to feel like idiots.

Leah: It's very data heavy. So, it can be made to feel incredibly scary. But there's no reason that it should be and there's no reason that it needs to be. And part of what we want to do at Skylight or part of what we are doing is, to make it friendly and easy in a way that, oh, I have a spare half an hour in my day, let me just go dig in and find something that I could optimize or fix or improve. Which is not going to happen if logging in is like 10,000 graphs, you just can't even find your bearing.

Leah: And you just kind of feel like, I thought I was an engineer, I thought I knew what was happening, but then I look at this and I just don't even know what it's telling me. So, our strength in large part comes from our really solid and simple design. We work hard to make it one of those products that is deceptively simple, where you might look in and think, oh, it's just doing a few of these things it's not very intimidating, but in fact there's a lot of information packed in there. You just get to it in a manner that is friendly and approachable and airy, right?

Leah: It's bright. It doesn't feel like the approach that a lot of products like this will take. Which is, let's make it all dark and look like the Matrix and make you feel like you're a super duper basement hacker and you're doing cool things. Because yes, that might make a small segment of the population feel cool, but it makes an even bigger segment of the population feel like I can't possibly do that. So, we built Skylight to tackle that problem, and it's probably seven years old right now and it's going really well.

Leah: It doesn't look dramatically different than it did seven years ago, and it is incredibly more feature full and detailed, and I consider that to be one of our greatest accomplishments. Is keeping it simple and keeping it feeling good even all the while adding features and functionality.

Jamie: I'll say as well that Skylight is kind of uniquely attuned to surfacing performance problems, performance bottlenecks in Rails apps. And I think clearly part of that is because of the nature of the relationship. That's Yehuda and everyone else, you and Yehuda and everyone else had with the Rails project, knowing Rails intimately, having worked on it, and then being able to parlay that knowledge into building a product with just a perfect fit for companies and individuals working with Rails.

Leah: A hundred percent, and that's a tremendous advantage. And some of the ways that we approached building it from the ground up are techniques that are not really accessible to a lot of our competitors. And the only reason they were accessible to us is because our engineers were in the room when Rails was making the decisions about, what to expose and how to expose it, and which APIs to craft. So people kind of missed the boat on a lot of that, and we both were in the room helping make those decisions and had tremendous foresight about what was coming next or why this other dream feature may never happen.

Leah: And that really allowed us to build a strong product that takes upmost advantage of Rails, of the technology itself, right? Like we can get as deep as somebody can potentially get trying to analyze Rails code, because we know exactly how Rails works, and why it works that way, and how it's going to work next week, and how it worked last year.

Jamie: Yeah, and down to Ruby as well. And that sort of leads me onto a question disguised as just me making a point which is that, getting involved in higher level open source projects, does tend to, if you get involved enough, lead to the platform beneath them. So for example, being so involved with Ember and having lots of users with serious needs, with serious applications that need to stay running, means that Ember then has a serious stake in TC39 in the web standards process and as a result of that, Yehuda sits on the TC39 committee and is deeply involved with how JavaScript evolves?

Jamie: And that seems like an interesting strategic angle as well. Although, in relation to Tilde, that to me seems like a really serious investment of somebody's time from the business. How do you balance that kind of side of all this?

Leah: The truth is, it is a serious investment. And as the business decision maker, I do sometimes have doubts. It has always paid off, but it's just plain expensive. And in the beginning of our tenure as a company, I personally worked really hard to get sponsorship and funding from other companies to do some of those things, or from other projects to do some of those things. Sort of like, "Hey, we have these engineers who work here, who are really talented and really invested in the success of this project that your company is also really invested in the success of. But we're too small a company to be able to afford to fly them around seven times a year to do this, or, we can't afford the membership into the standards organization.

Leah: But I think we're aligned on a lot of the same technical things that we want to accomplish. So how do you feel about helping subsidize our participation there?" I'm realizing as I'm talking about this now that, this is like a reveal, I've never told this to anybody. But there's nothing wrong with it, right? Why not? And some companies can employ people who can do a good job at these standards bodies and meetings, and some companies just don't happen to have the good fortune of having hired the people who can do best in these environments.

Leah: But they can help support it in lots of different ways. So, if you don't have somebody on your team who is the right person to send to a standards body, maybe the answer is to provide funding for some other person who doesn't work for you to go there, because you're roughly technically aligned and they will probably advocate for the same things that you care about. I want to be very careful not to travel into government, political lobbying type of things.

Leah: And I suspect there's a reality where that could be a thing, but programming is not nearly that dramatic. So it's more like, I care about this kind of web standards. You care about this kind of web standards. I'm not dictating what you say in the room, but I think it will serve me if you are in the room so I can help you get there. So, now thankfully we're successful enough that we can pair a way for a lot of these organizations, but for a long time we weren't, and we were able to be there on the strength of our network and of our engineers.

Jamie: So, we've talked about the relationship an open source project has with its contributors and around its users. We've talked about the relationship that a business has with the open source projects it depends upon, and open source projects that might be great things for employees to get involved with. Jamie: Well, there's a lot more I could ask you about events and conferences, but maybe we'll save that for another podcast. I really want the audience to take away from this, this notion that people like you within open source communities are playing this talent scout role and actively evolving the communities to make them more inclusive over time, and making new inroads for people with all different kinds of skills and perspectives and backgrounds. Are there any takeaways that you have that we haven't covered or haven't covered explicitly?

Leah: One important parting thought is that, even with all of the strides that the industry has taken to get better at making everybody feel like they're welcome and they have a place, there's of course negativity out there. There are of course less than ideal experiences, and I just want to tell people that the good ones exist. And if you meet somebody who's not very nice, find other people. Open source itself is worth being involved in and being invested in.

Leah: And I work really hard to make the communities that I'm involved in espouse the sorts of things that I believe in, and embody a really welcoming environment. But if you run into that one jerk, or if you run into a project that isn't as good at focusing on that, don't write off open source and walk away. Find a project that's better and find your home and settle in, and you can be a person who is not a jerk. You can be the experience that the person behind you in line has so that they maybe don't have to go through something negative at all.

Leah: And when I do a podcast like this in five years, I don't even want to need to say anything like that, right? Everybody's just going to be magical and have figured out how to play nice with each other. But don't let the naysayers get you down. There's tremendous opportunity. There are so many good people. There are so many people in the world right now who I consider friends and good friends, who I invite to my baby showers and things like that, who I just never would have met outside of open source.

Leah: And it's just a side perk. Again I said earlier, it's hard to make friends as an adult, you have to do the homework, but think of open source as another social network where you can meet people who care about the things that you care about and prioritize the things that you are invested in, and you can welcome them into your lives and really have a richer, full, experience existing because of open source and the people who make it what it is.

Jamie: Well, on that note, I think that's a good place to end. Thank you so much Leah for joining us, and thank you to everybody at home for listening.

Leah: Thank you.