NOEL: Hello and welcome to Episode 28 of the Tech Done Right podcast, Table XI’s podcast about building better software, careers, companies, and communities. I’m Noel Rappin. After you listen to the episode, you can join the conversation with us. You can follow us on Twitter @tech_done_right. You can get notifications of new episodes and tell us what you think. You can also leave comments about the episode on our website at TechDoneRight.io where you can also see our full catalog of past episodes. We’re really curious about what you like and don’t like and who you’d like to hear us discuss in future episodes, so please let us know. Also, if you want to help other people find the show, leaving us a review on Apple Podcasts is a great way to do that. Thanks. Today in the show, we're talking to Nell Shamrell-Harrington. Nell's a Software Development Engineer at Chef who focuses on the Habitat open source product. We're going to talk about open source and the difference between how you run an open source project that people get paid for versus a purely volunteer project. We'll have some tips for maintainers and potential contributors to open source, and Nell's going to talk about the open source projects she worked on during the 2016 campaign. Nell's a very thoughtful and community minded developer and I'm really glad that I got the chance to talk to her for the show. So, here I am with Nell. Nell, would you like to introduce yourself to everybody? NELL: Hello everyone, I'm Nell Shamrell-Harrington. I'm a Senior Developer at Chef. I'm also CTO of Operation Code which is a non-profit dedicated to helping veterans get into software engineering careers. Both of those involve a ton of open source governance work, the really technical deep down nitty-gritty of open source governance. And I'm looking forward to talking about that today. NOEL: Cool. Maybe we'll also talk about working with veterans because we do a little bit of work with Code Platoon which is a bootcamp for veterans in Chicago. So, tell me about your history with open source. What projects have you worked on and what projects do you govern? NELL: There's been three big open source verticals, I guess if you will, in my development career. I started off like everyone does - submitting documentation corrections. I think it was a Ruby wrapper for MailChimp called Gibbon which was my very first open source contribution. Sounds like you're familiar with it? NOEL: Yes. NELL: Awesome! And then I didn’t really get involved in the governance of open source until I moved to Chef. Part of my job was not just coding our open source projects but also managing contributions from outside contributors, managing the road map, making sure everything flows, et cetera. The other two main verticals - one is Operation Code itself. In Operation Code, we have several open source projects mainly geared around tools to help us communicate and also to manage the general Operation Code website. And what's interesting about these ones is they're not so much products that are distributed, though people are welcome to distribute them and iterate them if they want to but they are teaching tools. All the veterans who come into Operation Code, our dream is to have everyone open a pull request within their first couple of weeks. I haven’t quite achieved that dream yet but we're working on it and what’s going to allow us to do that is having a really smooth on-boarding process and ability for someone to get their contribution in and get it tested and then have it reviewed as soon as possible and merged in. NOEL: You're talking about open source governance here and that covers a wide, wide range of stuff from small one-person maintainer projects to projects that come out of Chef that are managed within a company that’s providing open source. What are some of the issues that you see or the things that people don’t realize about running an open source project like that? NELL: A lot of your time will be answering issues and I don’t just mean bug reports by that, I also mean feature requests. The hardest part of a bug report often is reproducing whatever error someone says they're seeing. I cannot tell you how many times I've had someone open up an issue and it shows this doesn’t work, which doesn’t tell me a whole lot. So, something we do with Test Kitchen is any time someone opens up a GitHub issue, there's a template that auto-fills in the GitHub issue form that asks you what operating system are you running this on, what versions of Ruby, all these other different parts of it are you running. And that’s to make it easier for the maintainers whether it's just one maintainer looking at it or several, to really isolate where the issue is and be able to reproduce it and then either code a fix themselves or guide whoever opened the issues through fixing it and sometimes it's their first open source contribution. NOEL: On that project, is that a team of people working as maintainers? NELL: One person is the core maintainer of it. That's Seth, his last name is escaping me at the moment, but his Twitter handle is @cheeseplus. Then there's a few other maintainers who work at Chef and then there's a couple who are in our community, as well, who kind of rotate in and out. NOEL: It's sort of a hybrid Chef and a community project. NELL: It very much is. I'd say almost all of the Chef open source projects are hybrid community and internal Chef projects as well. NOEL: From Chef's perspective, what's the advantage of having that kind of hybrid -- or what's the advantage of providing these tools as open source and then what's the advantage of having sort of community governance of them? NELL: You can go into commercial standpoints. We want to make it very easy for someone to try a Chef product first to be able to set it up on their own infrastructure as quickly as possible, even start developing on it if they want to. And that is what gets their interests and brings them into the whole Chef ecosystem which is quite extensive. From a technical standpoint, having the entire community reviewing the code, it can be painful sometimes but it makes a much better product. And it really helps members of our community who want to add in a certain feature, usually a smaller feature, it's not on Chef's roadmap, but what we do is we mark it as 'help wanted'. And then anyone who's looking to get started in open source or wants to contribute to one of the projects can add that feature in themselves, if they wish. So, it increases engagement, I'd say, as the overall reason for having these open source projects, not just on a marketing level but also on a really technical engineer to engineer level. NOEL: It builds up sort of your ecosystem of the tooling ecosystem, I suppose, to reach tools that might not be, as you said, on Chef's roadmap. NELL: Exactly. The FreeBSD adaptations for Chef projects came from Aaron Kalin. We had never considered that someone might want to use some of them with FreeBSD but he did the work to bring it in and we've seen that ecosystem start to grow as a result. NOEL: Has there ever been any sort of conflict between the community's goals and Chef's goals? NELL: There are and that has been a source of pain in the past. One of the ways we've dealt with that is every week, we have -- it used to be in IRC but it's in Slack now -- a community meeting that anyone can come to. And what we discuss in that meeting are RFCs or Reasons for Changes. This can be changes to Chef products, it can be changes to the workflow, the way people use those products. We want to let the community have a say in what we do as much as possible. NOEL: I really like it when large scale open source projects have a change management system in place. It's something that as a Rails developer really sense the lack of in Rails which I think overall actually Rails engages with its community, the Rails Core engages, which is similarly a corporate-community hybrid that engages with its community pretty well but changes just come. NELL: The best part about it is I used to work on the Supermarket project which was a Rails application through Chef. It happens with any project. The same questions tend to come up over and over again when you make a major decision every few months. Having an RFC where you can see it's all written down the discussion the community had and the reasons why we decided what we decided, it's so useful to be able to send that link to someone who has questions rather than having to rehash the entire thing again and again and again. It saves a lot of time and energy. NOEL: It occurs to me that I've been assuming that everybody out there knows what Chef is and that’s probably poor hosting on my part. NELL: Well, that has nothing to do with food. We can start there... NOEL: No! Although we use a lot of food metaphor in the… NELL: Yeah. I'm frequently asked by the TSA when I'm flying with my Chef sweatshirt what restaurant I work at. NOEL: So, I'm sorry. Can you briefly explain what Chef's role in the universe is? NELL: Sure. Chef is a product or project that allows you to create a template for what you want your infrastructure to look like, whether that’s on AWS, DigitalOcean, Google Cloud, et cetera. And you can have one template that can roll out to thousands of servers potentially, though most people I'd say use it in the hundreds. And then when you want to make a change to all of those servers, you can make that change in one place in the template, it's called a cookbook, and it will automatically propagate out to the entire fleet. NOEL: We use it in the single digits of servers. NELL: Oh, it's still good. We love anyone who uses it. NOEL: Which is less than the hundreds. Yeah, it lets you treat your infrastructure as though it was code and you can check it in the source control and do all kinds of cool stuff. With that, what kinds of things, you said BSD support, what kinds of things are the offshoots of that that are part of the community? NELL: In offshoot products, we had -- this came originally through an acquisition but it's very much a community driven project now is what's called Chef Compliance. And what that is, is it's like Chef that it scans your infrastructure. But what it does is it scans them for vulnerabilities, like certain ports being open. And you can also create templates, we call them InSpec Profiles. InSpec is the testing language that we use for them. And you can have a standard template for HIPAA compliance, PCI compliance, whatever have you. And our community has really been taking a large role in creating lots of different templates for all sorts of security restrictions that are out there. NOEL: Just to fill in because I feel like I should. HIPAA is privacy requirements from health care. PCI is security requirements for payment gateways. NELL: Yup. And then there's alphabet soup of lots and lots of different acronyms for other requirements. NOEL: Yeah, gosh. I have worked on a little bit of both of those. It's good to have a tool to offload some of that to. With these projects -- I'm sorry -- you're working on managing some specific projects? NELL: Right. Habitat is the main one I work on right now. NOEL: In the projects that you are governing, is that a solo position that you're in or are you working with a team of people who all have various levels of control over the tool? What's that like on a day to day basis? NELL: I'm working with a team of people. Thank goodness for how big the Habitat project is which is a lot like the Chef product, but it focuses on application automation. If you're interested, check out habitat.sh. It's a little out of scope to explain the entire thing right now. But yeah, there's a group of us who do our work in the public. We have a public Slack. There's only one private channel in it which, for the most part, we only use for video call links because doing open video call link on anything public is a recipe for disaster which we found out before. What we want to do is capture the discussions there, both in the product decisions Chef makes internally about Habitat -- We had those in public as much as possible -- and the product decisions that are driven by our community of users and contributors. NOEL: So, the governance of this and the work on this is sort of your day to day job? NELL: It's true. I'd say the hardest part is keeping a consistent development environment that someone can get started up with very quickly. I mean, you have a little more leeway when you have people being paid to work on open source projects, to have there be some difficulty with the dev environment. But when you're trying to bring in volunteers from the community or from outside of Chef, in our case, they really need to have the ability to get coding and contributing as quickly as possible. Because volunteer engagement -- I mean, it is fleeting and that’s understandable. People have different priorities be it paid work, family, et cetera. But I'd say that’s been the main challenge of almost every project I've worked on which is making it so people can contribute very easily. NOEL: I think most people, especially coming to a new project, are trying to solve their specific problem. NELL: That’s true. NOEL: So, what kinds of things do you do to make that onboard experience easy for people who want to contribute -- not just people who want to -- you said you had a template for people who want to contribute issues. What kinds of things do you do for people that want to contribute code? NELL: There's two big ones. With Habitat, we do have a docker development environment that you can use for small changes. I used it when I was just first getting started out with Habitat. But if you get to the point you have to compile the entire Habitat code base, then you want to do it in a pure virtual machine. But the docker environment is there for people to get started with really quickly. Another project I worked on, I worked with an organization called DevProgress which was affiliated with the Hillary Clinton campaign back in 2016, and we were writing applications for use by the campaign. And we created Vagrant environments for anyone to get a fully working environment with all the required dependencies installed into it and be able to get into that coding and contributing as fast as possible. NOEL: What kind of applications are you writing in that project? NELL: Two big ones. One was Drive the Vote. It was a way for anyone who needed a ride to the polls. It didn’t matter who you were voting for, we didn’t ask that. But anyone who needed it could request one in our web application and it would match them up with a volunteer who had signed up earlier to drive, and then it would connect them via text message. So, anyone who wants a ride to the polls could get one. And then the other one was Hillary BNB which was based off of a project called Bernie BNB by the Bernie Sanders campaign, basically allowing campaign volunteers to find housing when they want to volunteer outside of their hometown or home state. What's really cool about that one was I found out in January, that one was forked and reused by the Women's March on Washington. NOEL: Oh, neat. NELL: Yeah, that was the highlight of my open source career, seeing your work be used and be reused like that. It's such a high. NOEL: That’s kind of the goal. So, for something like that, how do those projects get started? NELL: We had a core group of people involved in DevProgress itself. So, DevProgress was an umbrella over several open source projects. Then they worked with people, affiliated with the campaign proper to pitch ideas for projects and then decided which ones will return the most value in the shortest amount of time. Because working on a campaign, I tell people it's the tightest deadlines, tightest budgets and highest stakes you'll ever work with. So we really had to be lean and emphasize on getting the most value very, very quickly which is somewhat unusual for open source projects. NOEL: Yeah, I was going to say that that is an unusual open source governance situation because in most cases, an open source project is not working towards a deadline. In that case, does the open source primarily mean we have a set group of contributors but our code is public, rather than sort of taking in contributions? NELL: For the most part, the way it functions is we had a set of core contributors where our code was public but we welcomed contributions from anyone involved in it. We had to really police the GitHub issues for that one, though, because people on the internet get not nice. NOEL: Yeah, our people on the internet. NELL: Exactly. But the real beauty, as I mentioned, is because we open source those projects so early, other people, other campaigns or movements or whoever have been able to fork them and adapt them. NOEL: Where are those online, where you can tell people to find them if they're interested? NELL: Head on over to http://github.com/devprogress and you'll be able to see several of the projects that we worked on. NOEL: Did you interact with the internal IT team for the campaign at all or is it basically separate? NELL: It was pretty separate. There's some law reasons for that but we had some key people who would interface with key people on the campaign. But there's only one or two people, it wasn’t the day to day volunteers too much. NOEL: Yeah, I would guess that’s another situation where you're dealing with campaigns where you can very quickly and not realize that you're running up against legal issues. NELL: Right. Voter data, oh my God! The laws on that are different from state to state which makes it pretty difficult to deal with. So, we tried to avoid taking actual voter data as much as possible. NOEL: Yes, I'm trying to imagine what that legal framework would be like based on my own experience with like financial issues. I imagine it's a huge tangle. NELL: We had an attorney who was awesome. And if your attorney tells you not to do something, just don’t do it. NOEL: That is really good developer advice. NELL: Yeah, if the attorney says 'no', don’t. NOEL: Have an attorney you trust. NELL: Exactly. NOEL: So, how long did you work on these projects? NELL: That one, I worked on for about six months. NOEL: I'm actually really interested in the intersection. I know a couple of people who worked and I haven’t really had the chance to talk to them, but I know a couple of people who worked on the web side of the Clinton campaign. I'm just really interested about the aspect of this as an open source project and sort of as a developer social movement, I guess. Where do you see that going, that kind of energy or developer momentum? NELL: I think it's going to continue. One of the main goals of open sourcing all of our apps, and the Bernie Sanders campaign also did a great deal of open source work as well, is to have that be usable by other campaigns who may not have the big financial package to start with that normally your campaign would have a whole bunch of money when they start or hopefully do, hire lots of developers, or pay for these really expensive software as service systems to get started. Having the projects be open source and having anyone able to fork it, edit it, run it on whatever they want to run it on, it lowers the financial barrier for getting started which I guess was one of the goals of the free/open source software movement in the beginning, now that I think about it. NOEL: It's been a tremendous success in developer tools overall. I talk about this because some I'm old and cranky but when I became a developer, you paid for programming languages and you paid for developer environments. NELL: I got started with C# and Visual Studio ten years ago. NOEL: Yeah, I'm older than that. But even C# and stuff, although they are technically closed source projects, I guess they did have paid compilers. NELL: That is true, yeah. NOEL: Professionally, my first professional experience was with Lotus Notes and ColdFusion, both of which were fairly expensive developer environments like a $4,000 a seat developer environment or something like that. And the existence of open source as a thing not only does it lower the barrier to allowing anybody to get started but it gives you so much code to look at. When I was learning to code as a kid in Basic, source code was a rumor. You knew it existed for things but it was something you never actually got the chance to see. NELL: It’s in the back of those programming magazines. NOEL: Exactly, yeah. I might have learned to code from the back of programming magazines years ago. And it's pretty amazing that all of this exists now in what seems like defiance of the rules of economics in a delightful way. NELL: We're disrupting, as the buzzword happy people like to say. NOEL: Yeah, but disrupting, I don’t know. Yes, it is and certainly disruption was a lot of a goal for the people who started open source as a movement. It's disruption in a way that has brought people into the ecosystem and not disruption in a way that’s trying to cut people out of an ecosystem, if that makes sense. NELL: Right. Someone asked me recently, "Do you think closed source or open source software is more secure?" And my answer actually was open source. And the reason for that is I feel much more confident about the security of my code. I mean, obviously I'm going to test it and use things like Chef Compliance and such to verify it. But if I have potentially hundreds of people looking at it, even if they're not using it or contributing to it, I'm much more confident that a weird vulnerability is going to be found rather than having one person working on it and just having it exist somewhere. NOEL: We see right now as we record this, the Meltdown and Spectre Bugs had just been announced and Linux seems to be patching itself much faster than Windows, for example. I think that that’s true, certainly true of a popular open source project. I think that sometimes the one off open source projects. When I was starting my career as a web developer and we were on ColdFusion and then Java, and I was trying to get us to move to Python. NELL: You should write a book about that. NOEL: It's a very, very short book because we never actually transitioned. And one of the reasons is I worked at a very small web development... we would call it web consulting firm now but that term really was not something they had thought themselves as. The owner of the company basically was like, "If we’re using Python and something goes wrong, who do we sue?" NELL: Oh, that’s a good point. NOEL: I guess I see the point but that seems so opposite from what I was hoping to get out of the developer tools I was using, like having somebody to blame for my problems is not very high on my list of tool chain issues at the time. NELL: A key point there is there's a difference between security and reliability, and liability as in who's legally responsible. And that is a gray area with open source projects often which makes a lot of enterprises very uncomfortable. NOEL: Even the legality of the open source licenses has never really been challenged. NELL: Yeah. I don’t think anyone wants to be the first. NOEL: Yeah, that doesn’t sound like fun. But yeah, I don’t have a long story there. I argued with them for a while about trying to get us to use Python and eventually quit and got a new job, for a lot of reasons not just that. But seeing the free tools, especially in the web development world, seeing the free tools coming and seeing the purveyors of commercial tools being utterly clueless as to what was going to happen to them very, very quickly was an interesting time. Do you find being a sort of public open source developer to be more satisfying than being a, for lack of a better word, a closed source developer? NELL: For me personally, yes. You have to be comfortable with your work being criticized publicly. I think that’s the key difference between someone who's going to be a good open source developer versus a better closed source developer. But the thing is my coding techniques and such are only better as a result of all that public feedback and public criticism, as long as it's constructive criticism. NOEL: Was it hard for you to get to a place where you were criticized, like where your code was being critiqued in public? NELL: Right before I started my job with Chef which is the first time I'd be working on open source paid full time, I put on Twitter that I was nervous because if I got something wrong, the entire world would see that I got it wrong. And someone, I can't remember who it was, but they immediately responded on Twitter with, "Yes, the entire world might see that something went wrong, but the entire world is also there to help." And I've seen that play out again and again. It's weird, it's not the traditional stereotypical coding job, but I do find it immensely rewarding. I've done this a few times, sat down with someone and guided them through making their first open source contribution and seeing the way their eyes kind of light up when they get the git commands in their fingers and then see their work get reviewed, merged and be live somewhere at a project that hundreds or thousands of people might use. It's a wonderful feeling of human connection through technology and code. NOEL: I think that’s really interesting how this has played out where even open source which is this tremendously small-d democratic coding resource that there's still this perceived gap for new developers, like, "I could never contribute." And it's great that you're helping people get over that because there's nothing magical necessarily about the difference between contributing to an open source and not contributing. There's no skill test that they make you pass. NELL: When someone's looking to first get started, the advice I often give them is that yes there are a lot of jerks in the internet, as we mentioned before. But a way to find a project that looks like it's more friendly to our people who are just starting is to take a look at the issues and see if any of them are marked with a label like beginner friendly or first contribution friendly or something like that because that shows the current maintainers and contributors have at least thought about how they will bring a newer person into the project. And those are often much more supportive. If you open your pull request and it's not exactly what they're looking for, but they're willing to work with you to get it to what they're looking for. It's pretty phenomenal. NOEL: It's also worth looking at a couple of issue and pull request threads to see just like how combative the environment winds up getting. That’s a situation that’s improved somewhat over the last couple of years as maintainers have become aware of what is helpful in getting new contributors which is really what the project needs to do to sustain itself. NELL: I think what's helped a lot with that is the emphasis on having a defined code of conduct for your project or community or whatever it is because it forces you -- I mean, someone once said to me, "The jerks don’t read code of conducts." And this is true. It may not prevent something from happening but a fire drill does not necessarily prevent a fire from happening in a building but it makes sure you have a plan if something does. So, it's forcing people to plan ahead and if they do get a bad actor or someone is just being a jerk, they have a plan in place for dealing with it. It forces you to think about it beforehand so people can respond to it much quicker. NOEL: I think that's completely true. When people say the bad actors aren’t going to read the code of conduct, that is not all that far from saying an argument that we don’t need laws because bad guys don’t listen to laws. So, what's something about open source governance that’s harder than it looks? NELL: The biggest challenge is when a pull request comes in, deciding whether it adds value to the project and should be merged in, or whether it does not add value to the project and figuring out how to say no to it in a way that’s still supportive both to the person who submitted the pull request and respectful to the work they put into it. NOEL: I see different projects have sort of different stances on this like some projects are very opinionated in terms of what the tool is trying to do and specifically what the tool is not trying to do. How do you feel about that in the context of the projects that you're working on? NELL: We do keep that in mind. When I worked on Supermarket, the whole point of Supermarket which was a Chef project was to be a community fostering tool that there's a public version and a private version that companies could use on their own infrastructure. We had someone ask us to make it so you only could allow certain users to see certain things on it. And that, after much discussion, we decided no, that’s not where we're going to take the project because the whole point of it is for it to be this community fostering and sharing tool. NOEL: In your experience, how do people respond to the 'I'm sorry, this is not what this tool is for' kind of message? NELL: In one instance which is a negative instance, someone threatened to fork our code, which they're entitled to do, and set up their own version of Supermarket and then tell people to use theirs and not ours. But we talked them down. NOEL: There was a time when that was like the nuclear bomb of open source projects and that would be the death of a project if somebody forked it and I feel like the ecosystem has gotten big enough now that that’s not as big a deal as it used to be. NELL: Very much so. The hardest is when I receive a pull request and it's clear someone has put a ton of work into it. But they didn’t ask me or the other maintainers about it first and it's ultimately not something we want to add to the project, or not the direction we wanted to go in. NOEL: A really good tip there is to ask the maintainers before you put it in a large amount of work into a project. NELL: What I consider a large amount of work to put into a project without asking is a hundred lines of non-test code. If you have more than a hundred lines of non-test code, you really should talk to maintainers first just to make sure it fits with where they're taking the project. NOEL: Again, different projects have a lot of different ways to respond to that. Projects really do just want functionality and don’t have the kind of boundaries that other projects do. Or sometimes, you want to be something that you’ve legitimately not thought of that you’ve realized you need until somebody comes by and says, "Hey, I'm doing this." NELL: For some projects, when you receive a code review, there's a lot of opinions about how something should be done. It's good to discuss that at least, but for me at least when I'm reviewing a pull request and it is something that provides values to the project, the two big things I'm looking for is one, is the code maintainable and two, is there anything unsafe in it. By unsafe, I mean not just security issues but would make it more difficult for someone else to take this code and work with it. If it checks out on both of those questions, I often don’t go too deep into how I would do something differently. I respect that person's work. If it doesn’t violate the style guides or whatever, which every project should have, by the way. NOEL: You should have a style guide if for no other reason than it prevents you from arguing over style. NELL: It's ridiculous. If they do it a little differently than me but there's no safety problems with it and doesn’t violate anything, that’s okay. That’s the nature of an open source project. People are going to do things differently than I do. But if it still works and doesn’t provide any danger, I'm fine merging that in. NOEL: It's worth it to remember that at its best, open source projects like these are community projects. It's a curator and not an owner, is that the good way to put it? NELL: That is. And speaking of style guides or automated checks, my favorite thing for an open source project to do is have automated tests that get run automatically. With Supermarket, we had hooked up to Travis CI. So as soon as anyone opened a pull request, it would automatically run all the tests on that pull request using Travis CI and immediately return back whether they passed or failed which meant whoever was opening the pull request before a maintainer even saw it, could get some feedback as to the quality of the pull request and be able to fix it really, really quickly. NOEL: What's one thing that a contributor can do or a common mistake you see contributors make and what's one thing that you think a maintainer can do to improve the way that a project runs? NELL: The number one mistake I see is not reading the contributing guide. But the number one mistake maintainers make is not making the contributing guide really, really visible. Like that’s something I will put at the top of the Read Me or pretty darn close to the top of the Read Me for anyone who comes to my projects place on GitHub. NOEL: The kind of things in that that includes the style guide and it includes the kind of testing that you are looking for and the kind of documentation that you're expecting, and those sort of issues. NELL: And any special needs of the project itself, like they might handle things differently from other projects. And putting in the contributing guide, I think, is the way to ensure the least amount of friction when someone wants to contribute. NOEL: Yeah, what versions of languages and combinations you need to support, that kind of stuff. Even on small projects, even on very small projects, it's worth having something like that just to think about, like what does this project officially support and what do we not support. Again, because that also certain bug combinations you can say, "Hey look, we don’t support that. We’re not going to fix it." NELL: The most challenging bugs are when -- the most challenging ones to communicate about is when someone opens a bug and it's not an issue with my project but it's an issue with an upstream project on my project. I see that happen a lot. And a good way to handle that is to convey to the person to open the issue. Like this is an issue with this upstream project, make sure you report it to the upstream project, number one. And number two, here's their current status, I'll keep you updated. Once a day or so, I'll check the upstream project, see if the problem has been fixed and then convey that to whoever opened the issue. The key thing to remember is -- you'll see some projects just close those issues kind of saying, "Not my problem." But if the problem manifests in your project, it is your problem even if it's something that’s upstream to your project. NOEL: People going to look at your project for guidance on what to do or whether there's a problem. There's a really good talk at RubyConf this year from Sam Phippen about RSpec bug that was actually Rails bug and how RSpec handles that from a contribution and then from a maintainers standpoint. NELL: That’s awesome. I will definitely have to go and check that video out. NOEL: One of the things about the projects that you're working on for Chef is that it is part of your day job. You're paid to do it. Do you have any things that you might want to suggest for our open source maintainers who are not being paid for it, in terms of how to keep those projects sustainable? NELL: Sustainability is the keyword there. Before I worked at Chef, this was a few jobs ago, I was at one point doing my day job, doing a lot of open source stuff on top of it and then doing a lot of speaking on top of that. And I kept pushing, pushing, pushing. And what happened was my wife came into the bathroom one morning to find me collapsed on the floor. And I was having symptoms of a heart attack. It wasn’t actually a physical heart attack. She did take me to the doctor and we got it checked out but it was a panic attack that manifested like a heart attack. When I told some people about this, I found out that kind of reaction is pretty common. Maybe not common but it's not that unusual in the technical world because we are under such high pressure not only in our own jobs but to be doing side projects, to be doing things on top of our current day jobs. NOEL: I've certainly heard other maintainers talk about that kind of level of stress in their maintenance jobs. NELL: What's helped me with that is, for me, it's more intuitive to budget money than it is to budget time. I'm not sure exactly why, maybe it's my upbringing, but it's easier for me to think about the value of things in terms of dollars. So, I think about what rate I would charge someone if I were being paid to do whatever the project is and then I just keep that value in mind. So let's say, I would charge $100 an hour. If I give 8 hours to a project in a week, that's about $800 worth of time that I've given to this project. And it forces me to think through budgeting, "Is it worth this dollar amount spending it here versus spending it here." And it made it a little easier for me, at least. NOEL: Yeah. I hope you're not having panic attacks. That sounds terrible. NELL: No. I'm doing much better now. Thank you. NOEL: Please don’t do that. NELL: It was a wake-up call. My spouse sat me down that night and said, "You need to do something different." That’s the joy of having a strong supportive spouse is to tell you when you're being stupid, basically. NOEL: That sounds very helpful. Well, it's been really great to get the chance to talk to you, Nell. I'm really glad we got the chance to sit down and talk about this. Where can people reach you online and learn about the things you're working on? NELL: Sure. You can check me out at NellShamrell.com which has a lot of the projects I work on and links to videos from different talks I've done, including the one how Noel and I met. I think it was Ancient City Ruby, it has nothing to do with Russia, and it was Test Driven Development: A Love Story. And then you can find me on Twitter at @nellshamrell. I'm pretty active on there. NOEL: Nell was the first person, I believe, to quote me to me -- no actually, that one you quoted me and somebody told me about it. NELL: That’s right. I think it was on Twitter. NOEL: And Nell also became a fantastic reviewer of Rails Test Prescriptions, tremendously useful. NELL: Thank you. NOEL: And you should also check out Nell recently did a talk at Windy City Rails that was only slightly derailed by a terrifying AV problem but she handled it with style and grace. NELL: Thank you. The funny thing is someone asked me the night before, "What is your biggest fear as a speaker?" And I said, "The projector going out." And that’s exactly what happened. NOEL: It's a good thing you didn’t say like Godzilla smashing the venue. NELL: Oh, God! Godzilla plus Chicago does sound terrifying. NOEL: Thanks for being on the show, Nell. NELL: Thank you so much for having me. Everyone, have a Wonderful New Year! NOEL: Tech Done Right is a production of Table XI and is hosted by me, Noel Rappin. I'm @NoelRap on Twitter and Table XI is @TableXI. The podcast is edited by Mandy Moore. You can reach her on Twitter @TheRubyRep. Tech Done Right can be found at TechDoneRight.io or wherever you get your podcasts. You can send us feedback or ideas on Twitter at @tech_done_right. Table XI is a UX design and software development company in Chicago with a 15-year history of building websites, mobile applications, and custom digital experiences for everyone from startups to storied brands. Find us at TableXI.com where you can learn more about working with us or working for us. We have several positions open as I record this. We'll be back in a couple of weeks.