A black swan event refers “to unexpected events of large magnitude and consequence which then play a dominant role in history”. With open source ecosystems increasing in complexity and growth as sociotechnical systems, we must examine how often these events are happening and if they are truly unexpected. This talk explores a series of events in open source history, some of which came as a surprise to users of the open source project and industry as a whole, had a wide and long-lasting impact on technology, or was inappropriately rationalized after the fact with the benefit of hindsight.

Transcript

So if we haven’t established it already, we are beyond thrilled to be with you all today, so thank you all for coming. We also want to let you know that should you work better with slides and speaker notes than looking at a screen, you can check those out at bit.ly/breaking-the-internet.
>> I am short. OK. So welcome to Remember When We Broke the Internet? Do you remember? It was just like a few seconds ago.
So we’re not going to talk about how Amanda and myself have personally broken the internet because we’re going to talk about that over dinner or drinks or something like like that, but we’re going to talk about sometime when open source or something very much like it has broken the internet, and that’s not nearly as straightforward as the news articles and retrospectives and press releases would have you believe, because it’s interconnected. It’s a complex sociotechnical system that we’re going to be looking at and seeing how it intersects with open source. So what you are going to see here in this talk might amuse you or it might severely embarrass us, and quite frankly I’m OK with either outcome. So take that for what you will.
>> No shame.
>> No shame. So I’m Julia I’ve been working in or around open source for a while and I am basically your standard multi-tool when it comes to open source. I just do what needs to be done, and then I go home and sleep.
So —
>> And I’m Amanda, I’m fortunate that my work recently most focuses on understanding nuances of open source, where it works, where it needs support, and where all the things that are holding up the internet in the back room that might be supported by things that were not intended to be that way. So before we jump into story time, Julia and I always like to start our talks off on level-setting of foundational concepts to make sure we’re all on the same page.
>> So this is really dry and I’m sorry
[laughter]
>> So most of us have this mental model of what open source might be, and in your own head, but there are strict criteria that must be fulfilled for something to be considered open source.
So here we go. In order to be open source, code’s got to be there, you have to be able to access it, you have to be able to edit it and distribute it.
But it also cannot be specific to a technology and it has to protect the integrity of the author’s intellectual property. Open source does not mean that there are no intellectual property rights here. And you also have to include the license, this is a part that a lot of people ignore, unfortunately and there are things it can’t do in order to be open source. Can’t discriminate against people fields or use. That means you can’t protect from industries that you don’t like from using your software. So that’s the dry part.
>> We feel like that’s super-important to mention this, as well, because Julia and I use “open source” to describe a group of people or a community.
>> Yeah, yeah, so OK. We will do a very brief introduction into complexity theory.
And that’s the conceptual framework which defines complex systems, so complexity theory states that while complex systems are unpredictable, they are constrained by order generating rules. So a complex system has components that interact in multiple ways, following local rules, and there’s no unifying rule to define all interactions.
However, the emergent sum is still greater than the sum of its parts.
>> So now we have a special kind of complex system. It’s a sociotechnical system. You have noticed that some of those shapes have turned into people.
You can’t separate out the people, the social from the technical aspects of an organization. They’re really tightly linked. Without the people, it doesn’t work. So we need to ensure that when we think about these systems, that we account for the interactions between our society as complex structures, and the behaviors of us, the people who live within them. So what does this have to do with open source?
>> Well, so if we examine the evolution, as well as the individual layers of open source, we can see that they have components that interact, they have components that interact in multiple ways, they follow local rulings, there’s no unifying rule to define all actions, and the emergent system — and sister — is greater than the sum of its parts. So we can confidently say that open source is a complex system.
>> We have to keep in mind that it is a sociotechnical system. We cannot remove how we, as humans, interact with ourselves — I talk to myself all the time, each other, and the technical systems without really reducing the problem space to the point of meaninglessness. This is most important when disruptions in the system happen that fundamentally change the ecosystem.
>> So we’re going to talk about some of these today. Specifically here we are talking about a disruption to an ecosystem that we would call a black swan event. Black swan events ultimately disrupt the status quo, cause systemic change, and seem inevitable in hindsight, which is my favorite part. So we’d like to focus with you today on specific evidence in the history of open source which highlight the complex specific nature of our ecosystem.
>> So in order to really understand some of these black swan events, we have to look at them in their historical context.
Who here works in open source?
>> Or near it?
>> Or near it. OK. If you’ve worked in open source for maybe like, what, three days?
>> Yeah, 72 hours.
>> You probably have stories about how it used to be when you started?
[laughter]
>> And if we look back further as we try to do in open source science and open source archeology, which is — we do a lot of that. We see how open source has changed over time, as well as where an evolution happens through a disruption of norms.
> Oh, wait, oh, so … So since we’re be talking about norms, this is super-important, right? We have to explain context. We want to understand how things changed, why they changed, people say they should be able to see that. And normally we show this through a timeline. There’s a great project that Julia is working on right now that’s trying to collect all those timelines and we talked about that before. But I think we should use a different format for this nice group of people, because we’re in person?
>> I know, it’s special.
>> It is special. So what do you say?
>> Well, I think we could make that work, yeah, what do you think we should do?
>> How about a song?
>> We have great acoustics.
>> Yeah, it sounds pretty good in here.
>> Wait, is that a cat playing a piano?
>> It is!
>> Wait, let me rephrase that. Is that a cat head on top of Billy Joel playing a piano?
>> It is!
>> Oh, that sounds awesome, let’s do it.
>> Awesome, OK. So this is an audience participation talk.
[laughter]
>> So we will be singing the lyrics, which you will see and we’re going to ask for your help on the chorus, which will also be up up there. So if you know the tune, please sing along, if you don’t know the tune, still sing along.
>> We might do that, too.
>> So notable even vents in open source sociotechnical …: Are
Wait! We gotta go back. OK, sorry, don’t hant to hurt you in this talk. We’re going to go back to 1988. So in 1988, there were about 60,000 computers connected together to form the public internet. And so there were an increasing number of industry networks, all selling the power of connection in the workplace, but a majority of these computers at the time were still government or academic systems. And so the Morris worm or The Worm, because it is so popular it gets to hold that title. Maybe infamous, famous, we can use a lot of thesaurus words there. But it was created inadvertently released by Robert Tappan Morris who was a student at Cornell. But released it inadvertently — starred, as part of a research project examining internet systems and how their open protocols could be exploited, right? Makes sense, you want to be able to test things out in real time. But so it worked much quicker than Morris expected and exploit exploiting multiple browser vulnerabilities and so there’s many notable firsts in this event, that plus being the first computer worm to be distributed through the internet. Morris was also the first Nell any conviction in the US under the 1986 computer fraud and abuse about act.
> This kind of goes back to the whole there are rules created because of people’s action conversation.
>> Yes, my actions are kind but not hurting anyone, yes, exactly, rules happen that we didn’t predict. So what does this event matter to open source and how is it a black swan event? So using our magical glasses hindsight … this event happened in November of 1988 and that was just months before GPL and Linux were released for the first time so we can’t ignore human interests, community expectations and social trust that existed at the time of those releases which were fundamentally impacted by the Morris worm. The reaction to and recovery of the Morris worm demonstrated the — Morris quickly worked to move fixes to the worm onto multiple mailing lists and sysadmins worked to prevent things from being impacted further.
There’s a pivot in security regulation in international laws at this time, we didn’t want all systems to look anymore, so super-homogeneity was seen as consistency, now it was seen as a risk.
>> This was also in the best interests of the burgeoning tech industry at the time, right, so it actually played very well into that strategy.
>> Right. Right. But excitingly, now back to the song. So it’s time for the chorus. Everyone who knows: Please join in.
>> “We didn’t start the fire it was always burning since the world’s been turning! We didn’t start the fire, no we didn’t light it, but we try to fight it! Jazz, Ruby, Murphy versus Libby. Open source gets a name. CVEs ain’t cheap: ASF … … …”

> Wait!
[laughter]
>> OK. So it’s 2014. And 2014 was a very interesting year. And that was because of this one. This is one of my favorite examples, when talking about open source, as a complex sociotechnical ecosystem.
Heartbleed first came on the scene in 2012, actually, but was only publicly disclosed about two years later, in 2014 and who has this kind of visceral reaction to seeing this? I still have a visceral reaction to seeing this and I’m still talking about it. So let’s talk about Heartbleed. What was it? Essentially it made user-entered data vulnerable to being captured by malicious third parties. With that data, bad actors could impersonate users, compromising even more information and security. This was bad. This was bad for trust in online systems, it was bad for trust in open source, etc. And because of the internet makeup at the time, it affected, at a minimum, 66% of the internet.
Kind of back to some homogeneity issue.
>> I wish they had learned, because that’s happened a couple of times since. It’s not the last. So Heartbleed was very high profile at the time, and it drew attention to the fact that while open source is a global ecosystem, it’s got global participants, it is a rich area, and it’s distributed, but the maintainership isn’t necessarily. Very few people beforehand realized that OpenSSL was maintained by effectively one person at the time.
> Effectively.
>> Effectively. So some articles will tell you two, but effectively one.
And it was maintained entirely on a volunteer basis.
And one of the great arguments in favor of open source, of which we are fans is that many eyes make all bugs shallow.
>> Not a fan of that one.
>> Right, yeah, yeah. But the fact of the matter is that a maintainer’s time is limited. One of my projects says I’m perpetually oversubscribed, so, you know, I have no time, either. In OpenSSLs days case the maintainer didn’t enough time that their day job that they needed to pay their bills and all that good stuff, to mitigate Heartbleed and this required companies paying for the core maintainer to take time off to work full time on OpenSSL and it increased interest in open source sustainability, supply chain analysis, and tooling.
Even more companies that relied upon open source, otherwise known as all of them, saw sponsored development and open source contributions as an investment in their own stability and reliability and resiliency.
>> We learned a lot from OpenSSL, but — serious part over? Back to the song.
>> Chorus time.
>> Again, sing along!
>> “We didn’t start the fire …”
∂∂∂
>> Wait, OK, now we’ve got to stop. It could be a measure of open source’s success, but also, yeah —
>> All right, so it’s now 2016, left-pad is the name of a package in the NPM registry, which is commonly referred to how the event is referred to. So in 2016, there’s a trademark disagreement over an NPM package name, specifically not left-pad. And when it was filed with the registry, this trademark disagreement, which was then and still remains privately held, NPM sided with the trademark holder. So in response the maintainer of left-pad and other packages deleted all of his NPM packages including left-pad and this showed how left-pad had become a transitive dependencies for many other packages, so because of the way NPM references dependence, it crashed many popular websites and services.
But in response, NPM restored a version of that unpublished package without the maintainer’s consent. So we’re going to get into some asterisks and parts here where we’re going to talk about things. But I do want to mention this had notable impacts both in open source and the node which NPM system is a part of specifically. So we do have to say that unpublishing code and releases was perfectly legal under open source terms and licensure, we’ve heard of the phrase free to fork but when it refers to the fact that licenses outline shareability or not and attribution or not, there’s licenses that exist around all of these different concepts. Most notably here, this event put a bright spotlight on the Node.js philosophy, about how things are linked together, about usability, about what you do versus what you just grab from someone else to do, and this was at a time that like there was a decreased awareness of dependency complexity. This really heightened that up. Julia talked about supply chains a few years before this, but this really brought in more discussion about how we were thinking about these complex transparency pieces, but so we got another glimpse of increasing costs and maintaining burnout. Open source contractualism. There’s additional scrutiny placed around privately run package maintainers, which still is an open question.
Whoops, sorry … OK, let’s get started again, because I like this song best.
>> OK: (… singing)
>> You have to stop again. You have to stop again.
>> So what are we stopping?
>> I mean it’s 2018, but it’s kind of now, so —
>> Yeah, yeah, yeah, OK, so this is why we had the very, very dry intro to what is open source.
>> Right, right.
>> So we get into some controversial territory, which is my favorite type of territory. It’s time for everyone’s favorite technical topic: The legal side of open source!
So we’ve done a great job, like, really A+ job of convincing people of the value of open source, got companies using it, they’re using it more than ever before. Go us!
But the pendulum may have swung a bit far. And what was once an expression of freedom, counterculture, and a bit of subversion, became part of a business model.
Companies developed open source software with the goal of monetizing it.
Additionally, it was around the same time that the next big thing, called the Cloud, offered companies a way to not have to be in the datacenter business anymore. Which is great. Allowed small businesses to act like big ones.
It gave them greater flexibility, and the ability to focus on their core differentiation. Instead of optimizing for things that they didn’t really care about as much. So service centerings found the opportunity to further take the load off of their customers by offering to run some of these open source projects as managed services.
The consequence of this is that it effectively cut out the companies who developed the software, from the equation.
And then that meant that they missed out on the profits that they anticipated through their investment.
So they explored other options, and in some cases, switched away from open source models altogether.
>> From that very specific definition.
>> From that very specific definition.
>> Of open source, right.
>> Mm-hm. So that is a dramatic oversimplification of the issue. And I have personal opinions on this matter, which are not uncontroversial themselves.
But the long and short of an analysis will show that the Cloud providers did exactly what open source allows them to do, H. Were they monetizing open source? yes. Had others done this before them? Also, yes.
Was it the same way that a proprietary product uses open source?
Well, no the necessarily. We had shifted in part due to this whole cloud business, towards developer productivity. So developers were now the target audience instead of what was traditionally known as the end user, and so this is kind of novel for folks, but it had a tremendous impact on open source and the open source ecosystem. We saw, and still see, a muddying of the open source waters with the introduction of terms like open core, and source available, as companies try to keep their reputations as open source companies without being fully open source.
>> By that definition.
>> By that definition.
>> OK. This is the last chorus, the last one coming up. So y’all did great on the first one. The second one, I gotta say your energy was a little lower, and that’s fine, but we would really like you to bring it all out for the final chorus, that way you have all the energy up for the next speakers, so please bring it all together. Let’s try one more time!
>> We didn’t start the fire! It was always burning since the world’s been turning … We didn’t start the fire, but when we are gone, it will still burn on and on and on and on and on … … whoo!
[applause]
>> So just like the song, we could go on and on and on mostly because the internet keeps breaking.
>> And people keep doing things creatively to express themselves and be part of the community and doesn’t always match with what was previously existing.
>> We always push the bounds.
>> Yeah, motivations.
>> That are fundamental challenges which exist in the larger open source ecosystem, which will accelerating black swan events.
> So I think as a part of this, too, we don’t want to talk about the things that are sad or hard, but also when we think about complex systems, we think about motivations perturbations.
>> So part of the open source ethos is transparency, but for some reason we primarily focus on code. The rest of how open source operates is oftentimes lost to walled gardens, off-the-record chats, and an overindexing on source control as the only source of truth that matters. We need to bring transparency more into open source, bring it into the aspects of open source that are still in the dark. We need to explore the ways that open source needs to evolve in order to reduce the frequency of these black swan events. Transparency is not a core tenet of open source anymore, but it should be.
>> Right, and so glue work is the phrase created by Tanya Reilly to explain the difference between a project that succeeds versus one that fails. There remains a focus on certain forms of contributions. Even with the binary categorization of code versus non-code work which you’ll hear me frequently rail against, feature work and advancing new versions of a package are given more visibility than the glue work which enables our entire ecosystem. So glue work is not visible as an essential part of open source, but it should be.
>> So one of those things that nobody wants to talk about. The history of open source, like most histories, are told from one perspective, and that hampers our ability to both reason about how events have come to pass, as well as it influences our technology decisions in the future.
Open source has a cult of personality problem, and that contributes to problems in sustainability, reliability, and the overall longevity of our ecosystem. So we need to shine lights on these missing or untold narratives, including the glue work that makes open source go. This may seem at odds with calling out the cult of personality problem, but they’re two sides of the same coin and imbalance of these two stories leads to some work being undervalued and flashy work being overvalued. It’s a sustainability, reliability, and longevity problem. Narratives are not complete, but they should be.
So we didn’t light this fire, but we’re staying to fight it, and we hope that you do too. Thank you!
[applause]