NOEL:  Hello and welcome to Episode 16 of the Tech Done Right Podcast, Table XI's podcast about building better software, careers, companies and communities. I'm Noel Rappin. If you like the podcast and would like to encourage us to continue, please follow us on Twitter at @Tech_Done_Right and leave a review on Apple Podcasts. Reviews really do help new listeners find our show. You can also leave comments on our site, TechDoneRight.io and we have a weekly newsletter where you can find interesting stories, podcast, news and some essays for me. You can subscribe to that at TechDoneRight.io/Newsletter. Thanks.

Today on the show, we have Nadia Eghbal. Nadia works at GitHub and is the author of Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure, which is a white paper about Open Source. We talk about open source at a big picture level, how it changed over the last 10 or 15 years. Is it sustainable? What makes it sustainable? Along the way, Nadia reassures me that open source makes sense economically, which was kind of a relief. I hope you enjoy.

Nadia would you introduce yourself to everybody?

NADIA:  Yeah, I'm Nadia. I work on Open Source Initiatives at GitHub and have spent some time writing, thinking and talking about how we build and sustain open source projects.

NOEL:  The first thing I read of yours, I think, was about a year and a half ago, where you wrote a story that got out a lot about the hidden infrastructure of open source and the hidden fragility of it. You came to that through looking for VC funding. Do you want to talk about how you started researching the open source community in general?

NADIA:  I came at it of having left a previous job in venture capital and while I was there being on the funder side, I did a lot of thinking around what do we fund in technology and why do we fund it that way because the predominant source of funding in software, in particular, is still venture capital. When I left those, I was trying to think about what are other things that can't be funded by venture capital because venture requires specific outcomes and what are we missing?

I actually didn't land on open source for a couple of months. I spent some time, just like drawing up a list of all the things I could think of, all the projects I could think of and people and just cold-emailing people and trying to hear their stories, hear about how they were supporting themselves or not. I had to cross a lot of things off that list but I was looking for a coherent thesis and some of things I didn't cross off of that list were open source projects. I had actually thought that they would probably be the least interesting area because everyone always said open source is really well-supported and it just kind of works and people just build it and it's fine.

But when I was talking to specific maintainers about it, I didn't get that story at all. I heard from a lot of people that they were really overwhelmed. I started diving deeper into that. I asked them for references. I asked for other people to talk to and realized that there was a very interesting story around open source and how it wasn't getting supported so I started writing about it.

NOEL:  One of the things, I think that you get at, that is really interesting is how the relationship between open source and the rest of technology changed in the mid-2000s. I've been a professional developer since about 1998 and I've gone all the way from my at first web job they wouldn't let us use open source tools. I wanted to use Python and they wouldn't let me use Python because they didn't know who to sue if something went wrong. I wish I was making that up. I'm not. All the way to having largely a professional career, based on Rails and Ruby and RSpec and all of these great open source tools, what do you think changed in 2006, 2007, 2008 that put the infrastructure under more pressure?

NADIA:  I think we saw more standardized way of how people were building and contributing to and discovering open source. There's GitHub, obviously but before then, there was also SourceForge and also, related resources and tools like Stack Overflow. Before then, you might have had products that are being managed through a random mailing list or you had to just go on their website and download the projects. They were all over the place.

Once you had a central platform where you could jump from project to project, the way you contribute is exactly the same and the version control that you use is exactly the same. The issue tracker is exactly the same. It suddenly becomes a lot easier for people to consume more rapidly. I think that's true for any other kind of content consumption in the past 10 years or so and how that's all been changing.

I actually see a lot of parallels between what happened in open source and what's happened in, let's say social media or videos or blogging or anything else. We're just able to consume content more rapidly but with open source, of course it's not just about passive consumption but it's also about people getting involved in the production. I think that's where we've hit some sort of resource constraints. What I saw, as projects were being used more and more, the number of maintainers was not actually increasing per project so the things got out of whack.

NOEL:  In my own career, I've seen that in a couple of different stages like when I started learning to program open source was not a thing that was accessible. It existed because the UNIX projects and the GNU stuff that all of this is an outgrowth of existed but if you are like a random high school kid with an Apple II in suburban Chicago, you had no access to that at all. To me, this is amazing. This is a tremendous thing that happened that if you learned coding today, you have this tremendous ability to access and just to read code. Source code was mythical when I learned to develop.

NADIA:  It's a good thing, I think.

NOEL:  Yeah, overall, it's an amazing thing. I went through the SourceForge era and the era where you would download a tar file and try to make it and cross your fingers and hope that it worked, which is something that improved dramatically. I think that from my perspective, what happened happen in two stages. There was an early stage in around 2000 where the LAMP stack got popular and then Rails got popular and suddenly, you had the capability for businesses to get built on open source in a way that was orders of magnitude easier than it had been in the past. Then following that, you had GitHub and all sorts of people coming in to fill this social coding need now that there was all of this economic interest around it.

As you say, the person infrastructure, the people running it, that has not scaled in the same way. I know a couple of the people that you quoted in the original article about maintainers getting overwhelmed and I certainly talked to people who are, it's certainly one reason why I have never really run an open source project myself like it seems thankless and painful, where do you see is this going? It seems to me that the current situation is not sustainable so how do you see this changing?

NADIA:  My views on this have evolved over the past two years or so, which is probably a good thing that your views change. When I started, I was really focused on the funding aspects and I still think funding is really important but difficult to get at, before we've established a lot of other stuff in the foundation. I've been thinking more broadly around sustainability and what does it mean for a project to be even be sustainable. It's not necessarily, I think that the maintainer gets paid a salary to work on it full time because there are some maintainers who don't want to work full time on their projects.

NOEL:  Then, it becomes a question of who pays the salary and what are their goals.

NADIA:  Right. I think the question is, for the project perspective, is the project's moving along and developing at the rate that it should, given its importance to the rest of society? Then there's a question of are the maintainers, who are primarily responsible for it, are they happy? If they get from that lens, money's one piece of it. A lot of it is just best practices around both managing the projects and managing the community. I realized that even that was not really a given among open source projects. I noticed that open source community are really siloed so someone who's working in a Ruby ecosystem is not talking to someone working on like Linux kernel.

When you see those people get into a room and talk to each other or talk online to each other, it's really cool because they are facing a lot of similar struggles, regardless of the code that they're writing, the way they're thinking about managing their projects and their communities, is really quite similar and there's lots to learn from each other. I've seen that... before we can even talk on a grandeur scale like how do these things get funded and supported and systemically thought about, it's making sure that people have a common shared understanding of how projects get run, how do they scale, when is it okay to step down, when is it okay to step away and take vacation on a project. The things like that, people aren't even really talking about.

NOEL:  What do you see that the successful projects are doing here, that other projects could learn?

NADIA:  A couple of things and this really depends on this scale or scope of your projects but maintainers can get overwhelmed when they start to feel like they're the ones who have to respond to everything and have to do everything themselves. I think that's a natural feeling, especially, let's say you author the project and then it becomes really popular. At first, you're responding to one or two issues and then suddenly, it's like 100 issues and you just naturally grow into that role.

But where I've seen maintainers be successful is to try from a very early stage, just to push that work off onto the contributors and say, "If you reported this issue and you're also not taking steps to fix it, unfortunately, I don't have time to fix it so I'm going to have to close this," and being okay with that. That's like a really scary thing because people get upset sometimes and you don't do that.

NOEL:  Yeah. My friends who are maintainers often talk about how, as consumers of open source, people often have unreasonable or entitled levels of expectation of what the maintainers are actually going to do. You actually wrote about this a little bit when you were talking about the myth of the bazaar, that we have this feeling that every open source project has a battalion of volunteers making all the bugs shallow. But in fact in most cases, they don't. It's one person working in their spare time.

NADIA:  I think we can aspire to products that can get a lot of contributors. That's awesome. Not every project is going to get that frankly. A lot of them just have, one or two people that work in them full time.

NOEL:  Even very popular and widely used, still come down to only a couple of people who actually writing the code.

NADIA:  And then it's like, "What is that person's constraints." If they do want to work on it, more full time or they want to bring on more resources, then I think that's where you start exploring the path of funding or getting more dedicated support or dedicated maintainers. If they can't or don't want to do that stuff, then honestly if they don't have time to work on the project, then that's the constraint. Their time is the resource constraint so it's getting them comfortable with saying no to things and closing things that they don't want to work on, unless someone else wants to work on them.

NOEL:  Right and there are a lot of cases where money doesn't solve that problem. A lot of these things, the money isn't going to support a full time user and if time is the constraint, then time is still the constraint, even if there's bug bounties or things like that.

NADIA:  I think there's an ideal world I'd like us to aspire towards where projects that are really, really important and where there is a desire to work on it full time. There should be financial resources available for that. I think just figuring out those channels is going to take a long time.

NOEL:  Yeah, we're starting to see things like Ruby Together and Python Software Foundation and... Python Software Foundation has been around for a long time. But it attempts to sort of put some predictable structure behind these really important community infrastructure projects. I see a lot of efforts in that respect that are only intermittently successful, do you see some areas there that are working?

NADIA:  I think much like what happened with, let's say open source development itself and how GitHub helps standardize that behavior, we're going to have to see some sort of standardizing of how things get funded because right now, there's a lot of random successes or outlier successes where someone happened to run a crowdfunding campaign and it worked great or someone happened to get a large corporate donation and that was great. One platform I think has been showing potential for that is Open Collective, which is a platform where projects can be put there. They can start a collective and people can donate to that. Anyone can donate into that, anyone can see that the money gets pulled out.

NOEL:  Where is that being used?

NADIA:  I think, they have 200 open source projects on there. There are a couple of great examples of projects that have managed to raise a lot of money on there but in the end, it still comes down to whether that project has a dedicated evangelist or someone who's dedicated to thinking about fundraising our community. I think that's kind of the lesson for me. It's like projects need to be able to think about those kinds of roles.

NOEL:  Yeah, it seems to me like there's a real danger zone in these projects that a lot of times the original maintainer creates the project to scratch their itch, as the saying goes and because they just like building new stuff. Then as the project matures, the original maintainer is no longer interested because the original maintainers doesn't get out of bed in the morning to work on a mature project. They get out of bed in the morning to work on something brand new but at that point, the project is stable and is building users and building the kind of work that the original maintainer doesn't want to do. At that point, it seems to me like a lot of projects get into trouble.

NADIA:  I think just the work changes. How I would primarily define a maintainer is someone who is starting to take on aspects of work that aren't just writing code. If you're starting to spend more time reviewing other people's code or writing documentation or triaging issues that come in, that's all kind of maintainer type work. I think it's perfectly valid if people start to get involved in projects or start their own projects for very different reasons. It might be because, like you said they're scratching their own itch or they thought it would just be fun to get into open source and build a reputation or whatever that is. Once those benefits max out, you're doing a very different kind of job. I think that that's a time where it's okay to step down or find someone else who enjoys doing that work or just find ways to limit the work that you do so that it's still enjoyable.

NOEL:  I find a lot of projects don't plan for that kind of succession, that eventually it just builds up and builds up and the maintainer just rage quits and somebody hopefully, picks it up.

NADIA:  Some people have made the argument that it seems scary to step away because what if nobody picks it up but then, often somebody does. I think there's too many different kinds of projects and kinds of ecosystems to be able to make that a rule or not but it is interesting for me to think about, what happens if you step away and will the spirit of open source survive and someone else just picks up that project and wants to be involved with it. Maybe, yeah.

NOEL:  There have been a couple of outlier cases in the Ruby community there was, of course, why the lucky stiff who basically pulled all of his projects offline, but many of which, the ones that were important were picked up by other people who grabbed copies of it. We actually have unfortunate cases where the original maintainers have passed away and that actually turns out to be very complicated.

NADIA:  Yeah, it is.

NOEL:  Because there's really no mechanism to it. There's almost no expectation that that's going to happen and it becomes very, very hard for somebody to pick up that project.

NADIA:  Yep. I think that's another argument just for resilience with projects. Even before any situation like that happens, there should be, at least two people with commit access or admin access and thinking about stuff like that is important.

NOEL:  Yeah, but the analogy to software development that I see here sometimes is that a lot of times in software development, what happens is you underbuild at the beginning because it feels like overkill to heavily engineer something that's just starting. I think I see that in a little bit of open source projects too that it seems like crazy to put in all of this personnel infrastructure and then, by the time you realize that you need it, it's too late. You needed to put it in place months ago.

NADIA:  I think it's something that's hard for me coming in as an outsider that from my perspective, I just went out and researched a whole bunch and I was like, "I see the patterns and the things that we could be doing," but that's also really overwhelming. You can't be just like, "Ideally, in a perfect world, you would have all these things set up and all this infrastructure and all these admins and whatever", but in reality, this isn't even probably someone's full time job so how do you take those learnings and then figure out how to incorporate them in ways that don't feel overwhelming?

NOEL:  I mean, my experience in trying to explain open source ecosystem to people who are not developers is that people are amazed that it exists.

NADIA:  I was amazed when I realized how exactly it all worked.

NOEL:  Yeah, I mean, it wasn't exactly a planned system and there's two ways. One of them, I think about the person that I was alluding to in my first job who is just was like, "Who do you sue?" He was a salesperson and a business person and very good at those things. The idea that people would just give away valuable tools for free, I almost want to say, offended him on a deep level, like he was just kind of kept looking for the catch. I do wonder a little bit about on a big picture, economic-level, whether any of this makes sense.

NADIA:  It does actually. Drawing upon my... I'm sure I took some econ class in college or whatever. There a matrix of any consumable good. I'm going to go deep into the econ. You have things that are excludable and non-excludable and then rivalrous and non-rivalrous. A public good is something that is both non-excludable and non-rivalrous which means when other people use it, it doesn't deplete the resource.

NOEL:  Non-excludable?

NADIA:  I think it's non-rivalrous. You can use this piece of software and so can someone else and that doesn't diminish your ability to use it. Then, non-excludable is whether you're able to limit access to it or not. Like air that we breathe, I can't really limit whether you can breathe the air or not.

NOEL:  But software could be excludable or non-excludable depending on how you structure it.

NADIA:  Yes and if you think about this matrix, there is actually an economic place for open source software and how we think about it and how we support it, if you think about it as a public good, that if in theory, at least how it stands right now, it's non-rivalrous and non-excludable and then the question is, "Could you change it so that it becomes excludable and you would charge for access?"

That's never really felt right to me. I think because open source is successful because it's non-excludable. I know some people want to go down that road. One thing that's come up for me is there is a difference between resource constraints in consumption and resource constraints in production. People consuming open source, that is a public good, and I think it's actually quite fine the way it is. The part where, I think maintainers get overwhelmed is where people are coming on the production side and overwhelming them with support requests and issues and bugs and things like that.

NOEL:  Yeah, that makes software a unique good compared to a manufactured goods or the things like traditional economics would think about.

NADIA:  Yeah and I'm realizing actually that people don't really understand how it works so all the research that's been done on this was on, there's a class of information goods like software or let's say music or whatever or books where the good is information. But most of the research that's been done in it was done when they were physical objects. When you had like a CD of software or a CD of music or a physical book, then it's more clear how someone is paying for access. But there isn't a lot of information or research on how do we do that when everything is digital.

NOEL:  Yeah. I don't think economics has completely adjusted to marginal cost of consumption being zero at all.

NADIA:  It's amazing. In my dream world, more people would be experimenting with how do you think about limiting access on the production side. I don't know, I might be crazy but we just sort of assume that anyone should be able to file a bug or anyone should be able to submit a PR. What if they don't? That doesn't violate the definition of open source.

NOEL:  What if you had to be a member?

NADIA:  Yeah. I know that there's scary implications there too.

NOEL:  Sure. Certainly, there are cases that come to mind where there's an open source version of the tool and there's a commercial version of the tool, which has among other things, paid issue support and then the commercial version of this tool supports the open source. It's a tricky model but I've seen it work. A Sidekiq is the one that comes to mind. A lot of the early things that I read about economics and open source talked about the reputational economy, which I don't think really gets at, I mean it gets at it a little but it's not a sustainable basis for building open source. I don't think it really explains, for instance why Facebook open sourcs React. 

NADIA: It's not for reputation.

NOEL: Facebook doesn't need the reputation.

NADIA:  We still don't have great vocabulary for distinguishing all of the different kinds of behavior that happened within open source. I think reputation still plays in for a new contributor or even why someone might open source their own project as an individual. Like you said, a company is going to do it for very different reasons. It's more for, you could say for brand reputation. I think that still plays in sometimes. If it's a project that they're really serious about, then it's trying to achieve market dominance by giving something away.

Then there's a question of why does someone continue to maintain projects, even after the benefit has maxed out and that, I think we don't really understand and that's where I think money can play in more.

NOEL:  Look at Rails, which is the open source project that I spend a tremendous amount of time in the community, 37signals?Basecamp has gotten tremendous value from the open source-ed-ness of Rails. Some of it is reputational, some of it is just that they get a better tool to build with and some of it, I think is that it establishes them as a serious technology company in a way so I guess that's reputational but in a somewhat different way. They don't need it for their business per se anymore to be open source but they still get a tremendous value from it in an intangible way, I think. I don't know, I'm kind of just noodling through that.

NADIA:  I think don't really knows right now, which makes the whole thing very exciting.

NOEL:  If you ask them, they would say that they open sourced it because they felt like they would get tremendous amount of value from it being adopted in the beginning and also because they thought it was the right thing to do like there were tremendous benefits to the community that would come from having a tool like that be available and incidentally, it would have benefits to them that they would have a better tool to develop and if they didn't have to work, depend on their own silo.

NADIA:  It continues to be an asset to them even now.

NOEL:  It seems to. They certainly support it and to some extent, support the community that has grown up around it. 

You started this project, in part to try to explain to non-developers what the state of the developer ecosystem was. Do you feel that part has paid off? Do you feel like there's an increased awareness in the non-developer part of this ecosystem about the importance of open source and how it needs to be supported?

NADIA:  Not as much as I expected when I started. I think that's okay because I realized, even among developers there still wasn't a shared awareness or understanding both people who are contribute to open source but then also like people who consume it, like non-open source developers.

NOEL:  What did you find in the developer community as being the misperceptions?

NADIA:  There are a lot of people who are excited... if you mention open source to developers, pretty much everyone is going to go, "It's so great. I use open source software all the time." There's a positive glow or feeling about open source but a lot of people use it and don't always realize what's going on under the hood. There is a lot of room for effort of even just companies and developers that use open source but don't participate in the production, to understand what's going on behind the scenes and just create a little bit more awareness and empathy for that. Hopefully, offering up resources, which we're seeing some of.

NOEL:  I think that the software thing, I have a note here in my questions note and I'm not completely sure I got it from but I'm going to try anyway. There's a concept in software development that was described as "worse is better". It was originally coined to describe why the C family of languages beat the Lisp family of languages for developer share. The idea was that the Lisp languages were so good, so easy to build up your own code, there was no real incentive to share code because it was easy enough to build your own.

Whereas, the C family, the open source community developed there in part -- I'm paraphrasing an argument made by somebody who smarter than I am so that's always dangerous -- but in the C community, where it was harder because C was a lower level language, there was more of an incentive to build up these shared libraries and ultimately, those shared libraries had a strong community building incentive that made those tools, even though the individual languages weren't as powerful, over time the tools became more powerful.

I was wondering as the open source languages and tools get better, if there's a danger, or how that might apply to the open source ecosystem as the sharing tools get better and better, whether there's any kind of effect that you see or have thought about in terms of that, minimizing the amount of sharing between ecosystems or between projects?

NADIA:  Interesting. I think "better" is a pretty subjective term. I can't imagine a world in which people just say, "We're done" and kind of walk away. If you look at the history of software development, it's more that we give people tools to think more and more abstractly about code and what they can do with it so they just become smarter and do more interesting things with it. I think that's actually a good thing and we're not going to ever tap that out.

We are seeing more fragmentation and I think, that speaks more to tools becoming more flexible and because it's easier to tweak little things here and there and then have your own version of whatever it is exactly that you wanted. I think this is like evolution of any creative segment. You just see more people riffing off each other's work, building things that may not get big but are good enough for them. I think that's all a good thing.

NOEL:  As an individual tool like Rails or React gets better, the changes you need to customize them become smaller and there's less incentive to share though?

NADIA:  Yeah, well they might share them but there's just so many... The analogy I'll just go back to when YouTube first came out. There were probably 10 insanely popular videos that we all knew about and could think of. Those are the ones that went totally viral and became part of our culture. Now, there's so many viral videos on YouTube that someone might have seen something that had 20 million views or whatever, that I've never even heard of, just because there's room for more and more people to be successful without being the most dominant technology.

I think people will continue to open source their stuff just because there's still personal reputational benefits to that, but you might find that you have like a thousand people who are excited about it and that's good enough for you or there might be something that a lot of people are using but I've never heard of or whatever.

NOEL:  So you start to have a discovery problem too?

NADIA:  Yeah. I don't even know if it's a bad thing. It becomes a bad thing when for each of those situations, if the demand is too great on that individual creator and we're not talking about how do you support this level of scale and consumption.

NOEL:  One thing I see in the JavaScript community, where I do think there is a discovery problem with a lot of tools being created to solve, basically the same problem and a lot of churn. I do think that in that community, it sometimes acts to the detriment of the community as a whole because people there's not as much incentive to try something new, if you think it's just going to get replaced six months later by the next thing. It seems to incentivize less long term planning, in a way that's hard.

NADIA:  Yeah and I think that's a problem even outside of software that all content is becoming disposable. I don't know how anyone's going to solve it yet but I definitely see that.

NOEL:  Ask me about technical book sales sometimes. Speaking of things that have gone destroyed by open source.

NADIA:  Yeah.

NOEL:  Another thing that I want to talk about, one of the issues that the community has is diversity, the community of open source contributors not being representative of the community of developers as a whole and sometimes being, either difficult to break in for new people, especially new people who do not match the stereotype of an open source developer, or sometimes outright hostile. How do you see that changing? Is improving that also one of the things that you're looking at in the work that you're doing?

NADIA:  Yes, in terms of how it affects sustainability of our projects overall. I will say that, although there is still a lot of behavioral problems at open source, it's a lot better than what it was 10 or 15 years ago.

NOEL:  Absolutely. There's no question about it.

NADIA:  I just think people forget that. People are getting a lot nicer because there is more accountability and visibility than there was.

NOEL:  I think that the GitHub effect of a common location has an effect on that because you can actually see the stuff that was often on weird mailing lists in the past --

NADIA:  Right, like do we want to go back to that? That's not to minimize all the things that are happening right now. There's a couple aspects to me. One is, I think there is... people come into products and there isn't a lot of context on either end for the person. Someone might come in, let's say a maintainer might see a thousand issues and they know how they want someone to behave or what they might expect. If someone comes in and it's their first issue they've ever opened, they might say something that sounds rude or not understand how things work. It leads to a lot of friction on both sides.

I think it's really hard to be, for either side, to be civil when they don't always have context on each other. I think bringing in different types of skills and different types of people is really, really important for building a project out as more than just a codebase. Over and over and over again, this is just like a broken record. I just hear projects constantly saying, "We don't just want code contributions. Please write documentation. Please help answer questions for people on Stack Overflow." That's going to require different kinds of skills than someone who just wants to come and write code. That's why, I think it's more than anything else, I think that's why it's really important to make sure that projects are welcoming to new people and give them a chance to get involved in the way that they want to get involved.

NOEL:  We often tell new developers that documentation fixes are the quickest way to break in to an open source project, especially if you're a new developer and you notice something in the set up or something that somebody else might not have noticed. But that can be vary, very much by project. Some projects are very welcoming to it and others are not.

NADIA:  Yeah.

NOEL:  What would you recommend that a project do? What do you see successful projects doing in that respect?

NADIA:  In terms of getting people?

NOEL:  Yeah, getting onboarding, I guess.

NADIA:  A couple of things. One is just making sure that the project's documentation is also welcoming. By the time someone has, let's say opened an issue or asked a question for the first time, there are probably 100 other people who might have landed on the projects and decided it wasn't for them and left. There's also the question of how do you capture all those people who you may never even see. I think that's really important than just making things seem friendly, welcoming and allowing people to self-serve a bit.

Then when someone does interact on a project for the first time, having somebody respond quickly is really, really important. I know that's also really difficult. It's kind of a chicken and egg problem but not hearing back from someone is probably one of the big reasons why someone will just leave or the question becomes stale and they move on. I think finding that balance between getting people to do the work themselves but then also being able to help them and not having them feel like they're overwhelmed. Being able to navigate that balance is important.

NOEL:  What change would you most like to see in the next four or five years in the open source ecosystem?

NADIA:  Oh, men. Four or five years? It could do so much in four or five years. I think from the project side, what would make me really happy is better tooling for maintainers to manage their workflow and all the things that are required to run a successful project. That's more of, I guess an automation thing. A shared understanding of best practices among projects and having people continue to recognize and encourage that in each other. That's within projects.

On a broader scale, I would love to just see companies, government, foundations, people with financial resources, understand that this is a problem and commit financial and human resources to supporting open source and not to take it for granted that it's going to be there forever.

NOEL:  Yeah, ideally that happens before we have the first real disaster that happens because somebody removed a critical project.

NADIA:  Yeah, too late.

NOEL:  Thank you so much for being on the show and where can people reach you if they want to learn more about things that you've writing about and talking about?

NADIA:  I guess, Twitter is probably the easiest. My handle is @nayafia.

NOEL:  And all of your writings on Medium are tied to your name, correct?

NADIA:  Yep.

NOEL:  Great. Nadia, it's been really great. I really enjoyed this conversation and thank you for being on the show.

NADIA:  Likewise. Thanks for having me.

NOEL:  Tech Done Right is a production of Table XI and it's hosted by me, Noel Rappin. You can find Table XI on Twitter at @TableXI and you can find me at @NoelRap. The show is edited by Mandy Moore and you can reach her on Twitter at @TheRubyRep. Tech Done Right can be found at TechDoneRight.io. This episode should be findable at TechDoneRight.io/16 or you can download it via whatever tool you use to listen to podcasts, which you probably know since you're listening to a podcast right now. Please send us feedback or ideas on Twitter at @Tech_Done_Right or you can subscribe to our weekly newsletter at TechDoneRight.io/Newsletter.

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 and we do have a couple of developer positions open as I record this. We'll be back in a couple of weeks with the next episode of Tech Done Right.