 morning. Let's roll. My name is Justin. A fun fact, I get paid by the tweet. So if you follow me on Twitter and say hello, I'd love that. Or if you want to drop me a long form line, you can reach me hello at testdouble.com. Open source is good, right? Companies working with competitors, other companies on common tools, and then turning around and sharing that for free. Startups, now they can stand on the shoulders of giants and build great new things with just adding a little code on top. Companies that couldn't exist otherwise. And then never before in the history of the universe has an individual that's not state sponsored or company sponsored been able to just do a little work of their own and then literally change how the world works. But is open source good really? I mean, companies love consuming open source, but if you ever want to share an upstream patch, much less open source library, they suddenly are very stingy and skeptical of this open source thing. And then a lot of startups keep falling into the same trap of hoovering up all of this free stuff without understanding how it works and building maintainability nightmares right as they get successful. They can't add new features anymore. And most of the maintainers I know are pretty burnt out, right? Like, they don't like the fact that they're doing something for fun and they're free time, companies are running on that stuff and then expecting customer support, you know, on nights and weekends. So today my goal is just to bring to light a handful of issues affecting open source. And my only objective here is to encourage you to do the same thing. Because maybe if we can start to build a broader awareness of some of the systemic issues in open source, we can start to have ideas of how to fix them. And then maybe somebody will come along, start to create new creative solutions for those things and then we can, you know, start to live and realize the promise of true openness, whatever that means. And then we're done. But again, today, very little minor, just looking at a handful of things. Topics, such as dependencies. Pulling back the curtain a little bit to show what it's like to be a maintainer. Issues of trust, adoption, security. And then some deep thoughts about how we interact with each other as humans, as well as where I think the future is heading. I like to start off with term definition, the word ideology. Most of us think of the word ideology as like a political subscription or affiliation, what you believe. But I like this definition more. They do not know it, what they are doing it. Ideology as the negative space that's driving our actions without us even realizing it. It's a quote from a dude named Karl Marx. Open source fans are a bunch of hippies so I figured I'd start with a Marx quote. That comes from the book Capital. And Capital is an interesting book because as a work it sits at the intersection between philosophy and economics. I think it's an interesting subject to start with today because so does open source, right? We share all this code altruistically as if to earn karma from people we don't know. And yet there's all these companies out there making a bucketloads of money off of open source and every company that even doesn't contribute open source needs it to get by. So thinking of capital and traditional economies I want to look, chart the march of progress of economics. In the beginning, everything was shitty. Everyone was just trying to get by, survival day to day. But then as groups of people started to form, specialization emerged. You could go to one market for your veggies and another person for your meats and through efficiency is this opened the door to the development of human culture. Recreation and art emerged. Industrialization further optimized this because now we could go to one place and get all kinds of goods. The internet totally inverted that. So now from my bed on my iPad I can order things from anywhere in the world and have it all shipped to my door. This is progress. But where does it lead us? You know this year there were rumors that Amazon is actually using big data to predict what they're going to buy before you click one click and they're actually shipping it to distribution centers near you in advance so that they can send it to you the same day or the next day. And some people are starting to ask questions like is this march of progress actually somehow taking away something about that's been core to the human experience? So it's an unintended consequence. Another example of unintended consequences in the like progress of economics, food ink, right? This documentary was a big hit and look at that aggressive tagline. You'll never look at it again or the same way. But I think it would be more honest if that said for like at least a month. Because we can't change these. These are systemic issues. When you chart progress over time there's a natural accretion of awfulness. It just mounts up until it gets to a point where we all freak out about it. And when we freak out about it we think we're going to fix this, right? But we can't just turn on a dime. Nothing stops this strain. It's going to keep on getting worse before it gets better and maybe we can rein it into current panic levels layer. Speaking of awfulness, let's chart the same march of progress about all of the tools that we use to suck in new dependencies from the open source world. So charting open source is progress over time. In the beginning there was just files out there on the internet. And so if I wanted to like build a system and pull in some open source I'd have to go find it first, download it, and then literally like check it into my version control, depend on it. And then logically it kind of continued on as part of my application. If it broke I had to fix it. And that was a guard against pulling in too much because I didn't understand it. And it was just more and more for me to maintain. Make files and common build system tools emerged as a great way to depend on stuff logically. So now I could build an application and depend on something like libxml. And it could be built on each of the systems that needed to be able to compile. But it existed as a separate entity. I could upgrade it separately and I could view it as apart from my application code. Java and its jar files were another great innovation because now instead of having all these build systems configured appropriately a single compiled byte code could be distributed and then run anywhere. So with Java I could literally go to a website, download a jar, put it on my class path and it would work. And this was so convenient that it actually opened the door to those same sites saying oh and by the way we depend on this third thing. That's what we call a transitive dependency. And what that allowed was really all of these libraries that we depend on to become small, more focused. And even you know when you think of transitive dependencies like Apache Commons emerged as almost an alternative language stack within a language ecosystem. It was extremely novel. Ruby you guys have done great work making this even easier with Ruby gems and bundler. Now when I'm writing my gem file I only say the things that I explicitly depend on and those transitive dependencies are discovered for me and their version resolution is handled for me automatically without me even knowing. And I can have arbitrarily deep dependency graphs only really thinking about the stuff that I directly depend on. NPM has just taken this a step further because the Node.js runtime doesn't require it allows you to load the same library multiple times in a single process which means I declare my dependencies and then it just naively sucks up all the dependencies of my dependencies and so on and so forth to these gigantic trees and it gets really broad and really deep. Up to the point where a very common thing for a Node.js library to run into is support ticket saying hey I can't install this because it's literally longer than the Windows Max file path limit of 256 characters. Wish that was a joke. This march of progress is optimizing for convenience. Getting somewhere more quickly. It's short term progress and it's available to us for the low low price of long term fragility. The comedian Louis CK talked about this recently. It's true everything that makes you happy is going to end at some point and nothing good ends well. It's like if you buy a puppy you're bringing it home to your family saying hey look everyone we're all going to cry soon look at what I brought home. I brought home us crying in a few years. Here we go. Count down to sorrow with a puppy Our community's Louis CK a guy named Gary he told me to build a small but non-trivial Rails app. An empty app will have 50 gems but yours will end up with 75 to 100. Now go away for six months come back update all your dependencies. Your app no longer works. I know from experience in the Ruby community that this is true. But it's easy to start a Jekyll blog. It's easy to install SaaS. It's easy to generate a Rails app. It's always easy right now never in a year. The reason I think is that when somebody asks us what our application is we think of the code that we write as being our application even though upon inspection all of us would agree that our app is really the full stack of everything that we ship into production. It's never been easier to ship something to production but the things that we're shipping to production have never been more complex. I'm guilty of this all the time. I say oh it's a Rails app because it conveys a lot of information all at once. I never think to say oh when Rails depends on Thor this very specific I don't even notice that. I didn't even know it until I made that slide. Even though 272 gems can no longer be installed in the same project because of version resolution complex. So Bundler it hides some of this from us. I think it could actually promote some of this information. It could tell us hey we just installed 10 direct dependencies and that conferred 43 transitive ones. Or I could say the version specifiers and all those gems preclude the installation of 1,300 other gems out of our ecosystem of 88,000. It could tell us hey and by the way if you were to run Bundle update right now it would be unable to update 5 gems to their latest version. I'd love to know that proactively. Of course if you're an NPM, a Node.js fan you might point out haha, version resolution doesn't affect NPM and you're right. But there's other issues. I can depend directly like so let's pretend orange triangle is a dependency. I might directly depend on version C of it. One of my dependencies might depend on version B and one of its dependencies might depend on version A all at the same time. This is all well and good until I start to think about it. What if I call my triangle and it gives me back a domain model object at version C's library understanding and I foolishly admittedly I pass that into my dependency who passes that into version B of the same dependency. As a library author did I think about that when I was writing the library that that was possible? Probably not. So is it going to blow up or is it going to blow up? The answer is nobody knows. And that's not great for understanding the software that we're building. Another issue is that as a library author I can specify the exact version that I want of something but I can't control the specification underneath. So if orange triangle depends on a very loose specifier of like red square for example at version star which means that the users install time they're just going to get the latest and greatest version. Things could potentially break. In fact one day we just started to get issues that every new installation was failing and we hadn't changed anything for like a month. What had happened was one of our direct dependencies broke because it had too loose of a version specifier on something else and so there was a breaking API change and then to fix it we realized that because the maintainer was out to lunch we actually had to fork that dependency and then specify explicitly I want version D the last compatible version of this thing and then push up a new version of lineman to NPM and now we're saddled with the maintenance and ownership of this NPM module that we don't understand that we'll never look at that if there's a security thing or whatever we're just it's just baggage now. Here's a video that the team took in me that weekend I feel like that a lot. So we all understand that the code that we write for applications is the code that we need and the code that we depend on directly is there for convenience to help us get started and so I think that's why I think a lot of people have been lampooning the phrase full stack developer this year because nobody knows everything that they're shipping anymore. So this makes me long for the good old days sometimes of like make files. Sure they were pretty good. So I think that's why a lot of people don't know what to do. They don't know what to do. They don't know what to do. They don't know what to do. So I think that's why a lot of people are like multi-file developers when we're doing an application like make files. Sure they were painful but maybe that was a healthy pain. 30 years later a lot of these old C projects still build correctly. Now who's confident that when I run npm install on my project 30 years from now it's still going to work. Let's talk a little bit about all these people ruining everything like me open source maintainers. way I envision it is that a maintainer is on Google looking for the thing that they need and then realize, oh, it doesn't exist yet. I'll turn around and go make this thing and work in the open and share it. An early adopter, and slightly less so, might just Google the same thing the next day and then find it. And then their reaction might be, oh, sweet, I found this cool brand new thing. I'm going to go share it on Hacker News and talk about it because it's still hip and underground. It's like finding a cool indie band that you want to share with people. And this starts putting the maintainer up on a pedestal, right? You know, promotes them and they might get stars in their eyes and get excited that people are using their thing. But because they're on that pedestal, other people on Hacker News don't mind at all pointing out, oh, it doesn't do X or Y or Z. And now the maintainer realizes their ego is all wrapped up in the adoption of their tool. But because early adopters are usually just as competent as maintainers at building stuff, maybe they'll send in pull requests that fix those issues. And now the maintainer is really happy again. It's super up and down. The initial release of any new library, new open source stuff is usually just scratching the itch of a person who has a need. So there's going to be rough edges. And early adopters are great because they, as developers, often will send in pull requests or submit issues to help round things out. And what emerges is usually like something that's pretty ready to be consumed by the masses. Maybe you call that a version 1.0 candidate. Or if you're like afraid of the implications of what 1.0 means in semantic versioning like I am, that's your version 08040. So at this point, I'd love for the conversation to happen between maintainers and early adopters. You know, sharing ownership, hey, let's own this thing together so that the early adopter can broaden the contribution base of this project. That typically doesn't happen. I'd even settle for just a maintainer saying, hey, let's make you a committer. That way you get notification of issues and stuff. And early adopter agrees that they'll help sometimes. But because those conversations don't happen at this point, the maintainer may as well be saying, hey, let's never communicate again. Sounds good. Bye forever. And then they're off to the next thing. Because early adopters are always after the new shiny. So why don't maintainers just share control? Well, I think the reason is that they misjudge how much happiness this library is going to bring them. Because up until now, they got to scratch their own itch and build a thing, and that was fun. And then they started to get acknowledgment for it, and that was great. Then they got to version 1, and now they can only imagine the skies of the limit. This thing's going to make me super happy. I'm going to be like DHH, and people are going to start holding conferences after me. Fear not, because late adopters will disabuse them of this happiness. So from the maintainer's perspective, if it scratched their itch initially, version 1 is probably mature enough to do what they need. So they might go a week without any commits or activity. They might go a month. And because they're also like early adopters, some new shiny thing's going to come along, and that might distract them and then whisk them away. And they're off into the next thing. A late adopter sees that, and then their response is usually excitement to say, oh, look, no recent commits. This must be stable. 800 stars. This sounds like a safe bet. Open source, that's free, that's good. And so they're very often, from years old projects, I'll get an email being like, oh, we're so glad we found this, thanks. So maintainers' needs start small, but then we layer them on, round things out. And if we conceive of each library as a thing, and then we layer on top of it what a user needs, what I need out of that library, it's never a perfect fit. There's going to be some things I wish that library did that it doesn't do. And in that gap becomes a negotiation. I have to ask the question, well, do I submit a PR for this? Do I work around it? Do I open an issue and ask them to implement a feature for me? And so a lot of those late adopters, like literally two days later, will come to the project, put a stern look on their face, and then start saying, wait a second, this thing doesn't enterprise my enterprise thing at all. How could they ignore such an obvious and important use case? And so this is where like entitled GitHub issues come from. Missing obvious and important feature, well, you know, our team thought this was a real written and good library, except that it doesn't do this crazy nonsense. And so I try to be polite and I respond like, I didn't know it had to do crazy nonsense. Could you please explain? But instead of a real reason to conversation, all their coworkers just jump in and start plus oneing it. And the implication is that I'm bad and I should feel bad for not doing this stuff for them and having anticipated their needs. So odds are it's a weekend, I'm at the park with my wife, I'm having a beautiful day, and now I'm glued to my phone getting really nervous and feeling inadequate. So I run home real quick and I start working, hacking, hacking, hacking and the stuff. I come back and I'm like, Hey guys, I just spent all weekend building this thing. Can somebody please just verify it works? So I can close out the issue. And now what happens at this step? I never hear from them again. And now I have a sad because I just did all this work for free for strangers that they didn't appreciate that they might not ever use. And now I'm saddled with it forever. And I'm gonna have to work around that little edge case in my code going forward and make the thing that I love less maintainable. So this is how the, you know, projects tend to bring me less happiness as a maintainer over time to the point where I hate most of my projects after they're three years old or more. So late adopters, you know, because these well rounded version one things do the happy path well enough late adopters typically are when they're asking for something they're asking for more niche features than early adopters. This leads a lot of people in our community to assume that late adopters make better customers than users. And that's why you see things like donate buttons, people talking about dual licensing, GPL plus commercial pro feature add-on packs that they can pay for maybe paid support contracts or consulting hours. All of this I think kind of misses the point because it's a motivation impedance mismatch here. People are building open source out of intrinsic motivation and drive that they have and money isn't going to solve that problem. And so if you want an open source library to do something and the other person doesn't just throwing money out isn't going to make them any more motivated to do it necessarily. I would much rather if culturally we all got in the habit of letting maintainers feel free to say no. I feel like a jerk when I say no I can't do this feature for free for you. But even now like when I ask for a pull request or something like that what I really want to say often is like I don't think that this is a good idea for the curation of this library long term I'm sorry. And I feel like a total asshole when I say stuff like that. But I think that we'd be all a lot healthier if we were a little bit less entitled when we opened an issue we were more complimentary and asking for advice on how they might approach the same problem instead of assuming that the library needs more code in it. Trolls are a totally different category of people who make us unhappy. Obviously they spit out hate sometimes threats whatever it is we know that the effect that they have on other people is they make them want to give up and walk away. And so remember maintainers they're not rock stars. But because of the asymmetry right like a lot of famous maintainers have 15,000 followers on Twitter we assume that they have their stuff together and we might even understand like well if they got that many followers there's probably a couple of trolls in the room but it's not that big of a deal. But because the asymmetric nature of communication we don't see the fact if those trolls are the overwhelming majority of who's interacting with them on the internet. And they have an outsized impact on a lot of open source developer psyche. So when the maintainer quits we're all like whoa that's weird that's what happened I didn't see any of that. Seth Varga recently left the chef project he was a great contributor did a lot of awesome stuff but just a handful of trolls in the community were able to sap all the joy that he had from that project. Further making us sad and so maintainers at this point this is where I often see the cries for help saying hey I'm burnt out can somebody please help me maintain this thing that has all these features that nobody wants anymore. Hello anybody and at this point no one's there right the late the early adopters who might have helped you know are long gone at this point and this is exactly how a lot of projects stagnate and die. But even well maintained projects up until you know by maintainers who do all the things right no maintainer lasts forever big invisible one this year was TJ Holloway Chuck left no JS for go and in the process he handed off a lot of his like infinity billion npm modules to other maintainers but he actually sold express JS to strong loop even though he wasn't the primary maintainer on anymore and he didn't tell any of the maintainers so it's really easy to screw this up why of course you know beloved in our community he left and he had every right to close down all of the stuff and leave and because he was highly visible we all had forks of his stuff and we're able to put it all back together again but that's not true of most maintainers so I like to think like what if there was an application for this that recognize that it's very human very natural for people to leave and stop contributing at a certain point and I think it would be need to be able to broaden the base of people are contributing so like what if I had a service where I could authorize Ruby jams and npm and github and it would like aggregate all of my projects and I could actually like explicitly say I need help on this one and here's the type of help that I need that way when somebody goes and logs in there's like a dashboard where they can see all the projects that they use that have asked for help in specific ways and then a call to action to say yes I'll offer to do that that's a lot strikes me is way more successful than just sending off an email in the dark to a maintainer being like I like your thing can I help you the reason that I did this talk today the reason that I thought to put it together was because our our our friend and beloved colleague Jim Wyrick passed away and when Jim died I thought a lot of things and it was very hard on me but one of the things I thought about was like he's got this tremendous legacy and I want to see if I can help in particular I have a favorite gem of his is our spec given and I wanted to see if I could go about helping adopt it and that process was very complex and difficult and I made me realize that when people go to their lawyer to do a state planning very few people ask like well what's going to happen to my github repositories when I die and even if they had the law hasn't really caught up to technology and it never will but maybe we can work around this so an application like this that already has all of our authorizations could effectively serve as a dead man's switch that is like if you fall off the pedal the train stops so maybe I could list beneficiaries like Todd and Brandon and after you know I go absent for a certain amount of time maybe it sends me little tickler emails every month and if I go away for 60 days it knows to add Todd and Brandon as owners on all of the projects that I that I've authorized it to I by the way I like to come up with a name for a thing before I build the thing I'm not going to build this but I like to call it somebody please make this dot IO really somebody please make this I would be very appreciative so that's all that's just about dependencies that are like you know binary dependencies or runtime dependencies that we package with our applications what about all these cloud services that we use right this slide is a slide of services that are going to shut down someday next slide can any centralized service probably written volunteer on on less money you know the if the corporate ones are all going to shut down what about the the purportedly open ones and can they be truly open like a maximally open system is rife for abuse but if you make it too curated then it could exclude people and limit the amount of contribution and I ask this of course because almost all open source infrastructure is entirely centralized out of convenience right because the march of progress just wants to make easier and easier to adopt stuff it's a hard question to answer how do we decentralize this you know a lot of people in the room contribute to ruby gems and I think they do great work and I think they're underappreciated but what if ruby gems were to disappear how many businesses with that effect do the businesses relying on ruby gems realize that as liability what if npm were to fail and lose a month of backups how many things would no longer be able to install and work I ask the question because I want to know like what would a decentralized dependency service maybe look like we have bit torrent apparently right we have cryptography it seems like the sort of thing that we'd be able to figure out without having a single point of failure speaking of single points of failure one of my favorite things to do is wait until the next time GitHub goes down because people freak out on Twitter and then they make the kind of snarky joke of like well you know it's distributed so why do you guys care because I can still work locally and in fact I can SSH to my buddy and we can still collaborate good thing that's all we use GitHub for right it's not like we use GitHub to pull down our dependencies or we use GitHub to test all of our code or we use services that get that depend on GitHub to analyze all of our code we even have most of the continuous delivery services that ship our code also depend on GitHub being up and even if you finish your work your next issue is in GitHub issues because that runs on GitHub and you can't find the next thing to do because now it was also co-opted all of our project management so how can we connect numerous services to our code which is admittedly the source of record the thing that everyone's going to want to integrate with but still avoiding that single point of failure well fortunately Git is very fast and very portable and it seems to me like a distributed transport layer or mechanism that would let these people hook into it without having a single company needing to be up for everything that we do to work seems possible somebody please build this let's talk about trust so open source requires adoption obviously it's optimized for it and in order to adopt something people have to trust it's good now there's explicit trust which is the dependencies that we directly depend on but there's also implicit trust the stuff that they depend on we just sort of trust that the people we trust are trusting the right people etc it's a big web but as a maintainer how do I get people to trust me and use my thing the answer of course is marketing let's look at marketing over time in open source so consider linus twervold 1991 announcement of linux he did it on the minix mailing list here it is and look at it got a few paragraphs but no catchy name he makes a self-deprecating remark in the first line and then he goes totally off message and talks about how to work on his niche particular hard drive this is bad marketing linux if it were announced today this thing runs most of the servers in the world it wouldn't even make the front page of hacker news if it came out today I think that's reason for pause a decade later the the ant project for Java this is trying to get into a lot of big corporate environments that don't trust open source look at all the things they had to do they had a fancy logo look at all this website stuff they had a mission statement and then of course the apache they had a foundation affiliation to try to confer trust but the more dependencies that were hoovering up over time the less we less time we have to vet them and so nowadays the standard github markdown read me is expected and here you know you expect a quick catchy intro a whole bunch of real easy steps to get started and then some mostly green badges up at the top to tell you things are working and it's gotten even further because now there's all these corporate backed sponsored projects this one is a yeoman where a diverse group of engineers are building a rocket with gradients and an authoritative tagline and they even have like a one liner install with a wizard that walks you through how to generate a thousand different types of projects it's a bad idea separate talk everything in open sources optimized for adoption it's the natural selective pressure that we're under as maintainers you know so we have all these like rock stars people in the community we look up to you like when Aaron Patterson releases a new gem I trust Aaron I know he's you know good at programming codes and so I trust that his gems are gonna work I could look at how many stars or how many forks a project has I could look at how much activity there is how many open issues I can see how many times that projects been downloaded now even though 90% of those are Travis see I downloading them over and over again my lizard brain tells me it's still important semantic versioning we went like 40 years without any sort of like you know like proper formal way of versioning software but why did we need one now the answer is we have so little time to like that our dependencies that we need to know at a glance like is this ready for use or is this safe to update and who's got time to vet transitive dependencies nobody the more people that you explicitly trust the more people you don't even realize that you're trusting I encourage everyone to recognize to that all these projects are marketing to you like I write open source and I want people to use it because I love it and I'm passionate about I want you to engage with my brand and use my stuff but I hope that you have ahead of discernment on and you realize that every new thing you pull in it adds complexity to what you're doing and more stuff can fail speaking of failures let's talk about security I actually have been for a long time a believer that you can do worse than security through obscurity you could have a whole bunch of stuff up in the open and nobody working to secure it cross the free software foundation point out well open source code is accessible to everyone right the cathedral in the bizarre argument of like many eyes and shallow bugs but that's only technically true people have to read the code for that to be true so who reads the source code first of all there's the people who claim to read the source code and then there's tiny minority of them who actually do there's people who fork projects but so few people who fork do anything there's the people with commit rights but then the actual committers are usually only a handful of that there's people who send a pull request but only a handful of pull requests or anything more than just drive by single tactical things and then there's the people who are hunting for exploits this is the only community where a hundred percent of them you can rely on reading the code so in absolute terms an uncomfortable proportion of people reading the source code are actually out to exploit it bash is a computer program it's in everything and the internet of things all those things run bash like your smart fridge etc so it's kind of unfortunate that bash had a terribly big security exploit because a lot of those things are not upgradable and patchable somebody went and looked at that code and what they saw was shocked to them it was global variables everywhere there was all these void methods that took no arguments basically that means that all that method could possibly do is A nothing or B muck with global state and then here's the vulnerable function I'll give you a second if this looks like nonsense to you I agree let's just read we're going to read a line of open source as a group this is the beginning of a for loop and I look at this and I'm a ruby so I don't spend a lot of time with for loops but I look at this I'm like why does that called string index why are they doing assignment in the second thing instead of a Boolean operation why are they incrementing in the second clause instead of the third clause surely they did that for a reason I think because I would write that like this and so I always trust I always assume that the person who wrote some other codes as smart or smarter than me so clearly they must have done that for a reason until I can prove that they didn't and so the amount of cognitive depletion that occurs as I read this method was so great I only got like halfway through it so the free software foundation who maintains bash says the solution is not proprietary software the solution is to put energy and resources into auditing and improving free programs and I think that's a pretty agreeable thing so who here wants to audit the quality of code that literally everybody depends on none of you right why is that it's because as a as a library becomes more popular the importance that we audit that it works and that it's safe and that it's secure goes way up but our motivation at an individual level to audit it goes way down if I use a gem and only three people are using it I'm probably not going to trust that it works so I'm going to read the source code but if I'm using bash I'm not going to think I should probably read this I'm going to assume somebody else did the downside is that everyone else is assuming the same thing and no one's actually reading it this is an example of tragedy of the commons and in this case this is an example that it's it's nobody's problem until it becomes everybody's problem and at that point it's too late so my hope is there's this recent group together I think the companies can solve this by investing because they have the money and if they collaborate you know the to-do group is an example that they came together they want they want to form some norms about open source governance one of the things I hope they look into is sharing notes when they're auditing the security of stuff working together to patch exploits I don't know if that's one of their goals but I think that's probably where the solution lies if you work in a smaller company it's your responsibility I think it used to be the case that we were trying to get open source into the door at wherever we worked and so we didn't want to say anything negative about it but now everyone needs open source and I think it's our responsibility to tell our bosses that open source is not a free lunch it's not some altruistic thing to make sure that it's working right it's a massive source of potential liability and it's worth vetting it out I want to share some thoughts about our interactions as people as well as where I think the future is heading so unfortunately all of these stick figures that I drew painstakingly were a lie because what they intimate is that open source is a thing that happens between people face to face in human interaction but it's not like that how we actually communicate is email github issues twitter almost all of it is just asynchronous text you know we're all no more than an avatar a username some emoji now and then and text on a screen that means that when you get riled up about open source no one can hear you scream I'm screaming all the time and none of you ever come to say hi and that's a big part of the problem Evie had a tweet recently I liked a lot she said it's effed up that a lot of modern discourse is optimized for whoever has the fewest feelings in the most free time who would design that system us apparently so when there's uncertainty ambiguity or disagreement in a team and if that leads to simmering disdain is email the right use the right communication channel probably not I think that it makes more sense to escalate to a higher fidelity form of communication so if there's ambiguity maybe real time text makes sense I could clear things up if you're having a voice conversation you can emote and empathize with the other person if you're making somebody cry you can see it on a video chat and if all else fails you can always meet up in person and there's something about human biology that when two people get in a room they tend to walk out with some kind of compromise and that doesn't seem to be true on Twitter I don't know why also the strategy can be great troll repellent right trolls get their power through anonymity and the perceived lack of consequences for their action but if you level up the fidelity of the communication and the discourse that means that their anonymity is also going to a road and they lose that and so when you like if somebody's trolling you're like alright cool let's have a hang out suddenly they go away so what I'd love to do is like make opting into these higher forms of communication easier so if I'm in a GitHub thread I'd love a button that would open a new chat in Gitter which is a tool for chatting on GitHub or build a live example in place like through JS bin or schedule a pairing session with screen hero or air pair or hop onto my nitrous IO box right in place I think anything to encourage us to have those more real communications the better I also want to think about where the future is heading because I showed a graph that it's going to get worse so on that graph I said no okay we're here and you know it's going to get worse before it gets better so what does this look like and I was stewing on this while Gogarucco was happening and I was thinking like if we extrapolate from our current culture of dependence where would that take us and I didn't come up with a lot of great answers but then I saw this tweet Yehuda was giving a talk about the Rust programming language and he says Rust enables a whole new generation of high level programmers us to write systems level code and my initial reaction was ehh these were the huge pyramid of stuff we don't understand that's scary but as I explored it and started working on this I actually realized I'm okay with this there actually might be some benefits to this and let's talk about those so if you think of innovation over time low level system innovations happened before high level ones naturally you need low level systems before you can have high level ones and then they crept up in the last 20 years most of this open source innovation that we've experienced has happened in high level programming languages now only very recently have we started reinvesting in low level systems like Go and Rust but today's like open source dependency culture really is steeped in a lot of assumptions about high level code and so the question is if we were just a cargo call that down to low level systems engineering how would that translate how would it work when I think of my systems programming friends they tend to be very conservative and cautious and that's because there are a mix of isolated from innovation and just curmudgens put it in slightly nicer way that means that there's a certain amount of accidental or incidental cautiousness a certain amount of intentional learned cautiousness and maybe I can learn from that cautiousness too embedded in real time failures have very grave consequences in some cases and that's probably where that cautiousness comes from so if you think of a high level system what's the worst that could possibly happen healthcare.gov starts failing and people can't get their insurance that's really bad that's like 60 night lines in a row of drama for our nation so let's take the same technology and put it in charge of this thing and see how that works right like low level systems there's way more rigor required in terms of fault tolerance because people can literally die if you don't get it right my systems friends have a different perspective on dependencies than we do they view adopting a dependency as outsourcing our understanding of how to do something that means that like if we have an application responsibility that orange blob over there and some particular dependency we can view that dependency as solving part of our application's problems for us we still know what like what it's doing and why but we might not know how and that represents what I call understanding debt understanding debt is typically paid down by iterating any dependency we have we learn about it through usage and through changing you know how it works and what it's what we need to work around and what's not great about it but if iterative releases aren't possible then you shouldn't outsource that understanding like if we think of high level systems versus low level systems a high level system is highly centralized might only run one instance low level systems tend to be built fabricated shipped and then they're out the door high level systems have very short life spans typically low level systems might have to live and be rated for very long periods of time high level systems usually have a full staff maintaining the thing for its entire life but low level systems might just have a support chain high level systems usually have way more than enough overhead in terms of memory and CPU in order to like you know absorb the impact of some inefficient dependencies but low level systems have very hard and real caps high level systems are highly connected we have all these tools to automatically deploy patches and new stuff but low level systems might have intermittent connectivity or no ability to be patched at all so clearly we've made it very easy to iterate high level systems but at this point it's still very hard to iterate low level ones so these concerns require that systems engineers have a deeper up front understanding of what they're building if you consider like if we were to graph out the depth of understanding necessary to be successful in a high level web app versus say like a low level plane control like a landing gear or something you only really need to know how browsers work HTTP a little bit of JavaScript the request response lifecycle but you might need to know a lot up front about how planes work and everything that can go wrong and everything that you're going to be plugged into and you need to count for that on day zero so this traditional like you know we write a handful of little tiny domain objects on top of this mountain of open source stuff that we don't understand that might be an appropriate level of depth for a high level app but if we were to simply cargo call that over to a low level system there's this danger zone in the middle right of stuff that we don't understand and it's inappropriate and might put us at risk and so systems engineers have a couple of options they could either build more richer deeper domain stuff or they can go through a process of qualifying those tools and literally rigorously proving that they work this reflection caused me to realize that modern tooling is just a product of high level web development you know if we look at this chart again this represents just today's perspective on how dependencies work and if we were to do the same thing at low level rather than worry about cargo culting ruining systems code I'm pretty sure they're going to still make sure that stuff works maybe together collectively we can have a new and broader perspective on what is currently our culture of dependence in fact I'm hopeful now that systems innovations you know bringing the same convenience that we have in open source to low level systems they might reciprocate some cautiousness desperately needed cautiousness as well as emphasize the importance of understanding the things that we're shipping so we covered a lot of ground in these four areas today but I want to part with the message that I think that the open source world can be a lot better and there's a lot of room to improve and it's all actionable and most of it's fixable you know companies I think that we need to do our job of convincing companies that they have a responsibility to be contributing back and to be auditing the security of stuff I think startups you know need to be cautioned that there's no such thing as building a real app in a weekend and being done maybe that means that like they should invest the time in understanding the things that they're standing on top of or if they have to get out the door in 30 or 60 days or whatever understanding that you probably want to throw away version one when you go back to rebuild version two after you've validated it after you've been successful I like to call this the slow code movement individual maintainers I think that they can learn a human lesson from this that is aggressively try to pull in new owners and contributors as early as possible while there's still excitement to do that and then I think we can solve with tools make it easier for people who want to participate and get involved in open source make it very explicit and invite them as opposed to just waiting for them to work up the courage to email somebody so once again my name is Justin you know please say hello where I come from test double we're an agency of really terrific software developers and so if your company needs developers and some help please let me know and I'd love for our great people to work with your great people like everyone else we're hiring too so feel free just to drop a line join at test double I'd love to chat with you during a break today and if you're too shy for that and you just want a free sticker I got stickers too and most importantly I just want to thank you all for your time and thank the organizers for having me I'm really really humbled and privileged to be here thanks