Episode Summary
Episode Show Notes & Transcript
- Open Source Stories: https://www.opensourcestories.org
Corey: It seems like there is a new security breach every day. Are you confident that an old SSH key, or a shared admin account, isn’t going to come back and bite you? If not, check out Teleport. Teleport is the easiest, most secure way to access all of your infrastructure. The open source Teleport Access Plane consolidates everything you need for secure access to your Linux and Windows servers—and I assure you there is no third option there. Kubernetes clusters, databases, and internal applications like AWS Management Console, Yankins, GitLab, Grafana, Jupyter Notebooks, and more. Teleport’s unique approach is not only more secure, it also improves developer productivity. To learn more visit: goteleport.com. And not, that is not me telling you to go away, it is: goteleport.com.
Corey: This episode is sponsored in part by our friends at Redis, the company behind the incredibly popular open source database that is not the bind DNS server. If you’re tired of managing open source Redis on your own, or you’re using one of the vanilla cloud caching services, these folks have you covered with the go to manage Redis service for global caching and primary database capabilities; Redis Enterprise. To learn more and deploy not only a cache but a single operational data platform for one Redis experience, visit redis.com/hero. Thats r-e-d-i-s.com/hero. And my thanks to my friends at Redis for sponsoring my ridiculous non-sense.
Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. My guest today is someone I have been very politely badgering to come on the show for a while, ever since I saw her speak a couple years ago in the Before Times, at Monktoberfest. As I’ve said before, anytime the RedMonk folks are involved in something, it is something you probably want to be involved in. That is my new guiding star philosophy when it comes to conferences, Twitter threads, opinions, breakfast cereals, you name it. Please welcome Julia Ferraioli, the co-founder of Open Source Stories, Julia, thank you for joining me today.
Julia: Thank you for having me. And I definitely agree on the RedMonk side of things. They are fantastic folk.
Corey: They’re a small company, which is sort of interesting to me from a perspective of just how outsized their impact on this entire industry is. But it’s, I’ve had as many of them as they will let me have on the show. They are welcome to come back whatever they want, just because they—every single one of them, though they’re very different from one another, make everyone around them better with their presence. And that’s just a hard thing to see. I didn’t mean to turn this into a love letter to RedMonk, but here we are.
Julia: I don’t mind it. They have the ability to amplify the goodness that they see, anything from their survey designs to just how they interact online. It’s wonderful to see.
Corey: Speaking of amplifications, you are the co-founder of Open Source Stories, the idea of telling the—to my understanding—the stories behind open source. Like this is sort of like—what is it, Behind the Music, only in this case it’s Behind the Code? I mean, how do you envision this?
Julia: Oh, I like that framing. So, Open Source Stories is a project that myself and Amanda Casari founded not that terribly long ago because when we were doing research about how to model open source and open source ecosystems, we realized that a lot of the research papers that have been published about open source are pulled mostly from GitHub Archive, which is this repository of GitHub data. It could be the actual Git commit history as well as the activity streams from GitHub as well, but that doesn’t capture a lot of the nuances behind open source, things like the narratives, how communities interact, where communication is happening, et cetera. All of these things can happen outside of the hosting platform. So, we launched this project to help tell these stories of the people and events and scenarios behind the open source projects that really power our industry.
Corey: I’m going to get letters for this one, I’m sure of it, but I’ve been involved in the open source ecosystem for a while and I’ve noticed that there’s been a recurring theme among various projects, particularly the more passionate folks working on them, where they talk an awful lot but they aren’t very good at telling stories at the same time. And nowhere is this more evident than when we look at what passes for a lot of these projects’ documentation. One of the transformative talks that I went to was Jordan Sissel’s years and years ago, at the Southern California Linux Expo. And it was a talk about LogStash, which doesn’t actually matter because the part that he’d said that really resonated with me, that his whole theme of his talk was around, was if a new user has a bad time, it’s a bug. And the idea that, “Oh, you didn’t read the documentation properly.”
When about I started working with Linux, in some IRC chat rooms, the standard response to someone asked for help was to assume that they’re an idiot, begin immediately accosting them with RTFM, for Read the Frickin’ Manual, and then look for ways that you could turn this back around on them and make it their fault. And I looked at this and at the time, it’s like, “Wow, these are people that are mean to other people,” and I was a small, angry teenager; it’s like, “This is my jam. Here I am.” And yeah, many decades later, I’m looking at this and I feel a sense of shame because that’s not the energy I want to put into the world. A lot of those communities have evolved and grown and what used to be the area and arena for hobbyists is now powering trillion-dollar companies.
Julia: Absolutely. I like the whole, “If the user has a bad experience, that’s a bug,” because it absolutely is. And I feel like a lot of these projects haven’t invested nearly as much into the user experience as they have into polishing the code. And the attitude that that kind of perpetuates throughout the project about how you treat your users, it’s pervasive and it really sets up the types of features that you develop, the contributors that you encouraged to commit to the project, and it just creates a—to put it minorly—less than welcoming environment for users, contributors, maintainers alike. And we don’t really need that sort of hostility, especially when we’re talking about projects that underpin the foundations, in some cases, of the internet.
Corey: When we look at what open source is, I mean, I shortcut to thinking in terms of the context through which I’ve always approached it, which was generally code, or in my sad, particular story, back in the olden days on good freenode, when that was where a lot of this discourse happened, I was network staff and helping a bunch of different communities get channels set up through a Byzantine process. Because of course there was a Byzantine process; it was an open source community, and if there’s one thing we love in open source, it is pretending to be lawyers when we’re not. And we’re sort of cargo-culting what we think process and procedure often look like. So yeah, there was a bunch of nonsensical paperwork happening there, but it was mostly about helping folks collaborate and communicate. But I’ve first and foremost, think in terms of code and in terms of community. What is open source to you?
Julia: Well, I entered open source in the Sourceforge days, when all you had to do was go and download some code from the internet and hit the right download button, make sure not to hit one of the extraneous ones. And all you need for that is for the code to be under the right license. And to an extent that’s what’s true today for open source. At the heart of it, this minimum criteria for what constitutes open source is, “Okay, does it comply with the open source definition that the Open Source Initiative puts forth?” Now, I understand that not everybody necessarily agrees with the Open Source definition, but it’s useful as a shortcut for how we think about the basic requirements. But what I find when people are talking about open source online is that they have these very different models. You’ll hear from people that, “Okay, well, if it doesn’t have a standard governance model, it’s not really open source.”
Corey: The ‘No True Scotsman’ argument.
Julia: Yeah. So, I find that we’ve got these different expectations for what open source is, and that leads to us talking past each other or discounting different types of open source when what we really need to do is come up with better language, a better vocabulary, for how to talk about these things. So, for example, I used to work in developer relations, and in developer relations one of the big things that you do is release sample code. Now, oftentimes, I’m not looking for that sample code to be picked up by a bunch of different developers and incorporated as a library into their project—
Corey: [laugh]. Well, that’s your error in that case because congratulations, that’s running in production at a bank somewhere, now.
Julia: Oh, I know. And that has definitely happened with my code, and I’m ashamed to say that. [laugh]. But generally speaking, you’re not looking to build a huge community around sample code, right?
Corey: You say that, but that again, Stack Overflow, it was—
Julia: Okay.
Corey: —[unintelligible 00:09:22] done rather well. So, there’s that.
Julia: Well yes, that is true, but when you release code on Stack Overflow, or GitHub, or in a Jest, or just on your blog, the thing that allows the bank to come in and incorporate that into their own application, or to even just learn from it, is the fact that it is open source. Now, it doesn’t have a lot of the things that a community like Python or Kubernetes has, but it is still open source; it just has a different purpose than those communities and those ecosystems.
Corey: So, I think it is challenging right now to talk about open source as if it were the same type of thing that it was back in the ’90s, and the naughts—and even the teens—where it’s a bunch of, more or less either hobbyists or people are perceived to be hobbyists. Sure, an awful lot of them are making commits from their redhat.com email address, but okay. And some of these people are increasingly being paid to work places, but then you see almost—I don’t necessarily agree with the framing of The New York Times article by Daisuke Wakabayashi—who’s a previous guest on the show—of Amazon strip-mining open source, but they definitely are in there—and other companies as well—are sort of appropriating it, or subverting it, or turning it into something that it was not previously, for lack of a better term. What’s your take on that?
Julia: Oh, that’s a hard one. From a fundamentals perspective, that is absolutely within their rights under the definition of open source, and in some cases, the spirit of open source as well.
Corey: Oh, and I would argue with someone who said that they should be constrained from doing this as far as a matter of legalities, or rights, or ridiculous Looney Tunes license changes.
Julia: Well, there are definitely folks who are trying to make that the case.
Corey: Yeah. Oh, yeah. I’m on the position of, they’re within their rights to do it, but it’s time for a good old fashioned public shunning as a result.
Julia: I’m not sure I agree. I think that it is a natural consequence of how open source has gained in popularity and, in some cases, it’s a testament to open source’s success. Now, does it pose some serious challenges for the open source community and open source ecosystem? Absolutely because this is a new way of using open source that was unanticipated, and in fact, could be characterized as a Black Swan event in [open source-ware 00:12:18].
Corey: The fundamental attribution error that I see, back at the very beginning, was that what we wrote the software, therefore, we are the best in the world at running it, therefore, if there’s going to be a managed service, clearly ours will be the best. Amazon’s core strength has apparently been operational excellence as they like to call it; my position on that is a little bit less of tying into the mystery, a little bit more of they’re really fast and getting paged and fixing things in a hurry before customers notice. So okay, great, but it’s column A, column B, whatever. The bigger concern I have with Amazon as its product strategy is, “Yes.” If it were just a way to run EC2 instances or virtual machines, then sure, that’s great.
And every open source project should, on some level, see some validation of its market through a lens of, “Oh, we’re getting some competition. That’s great.” The challenge I see is that in the line of competitors, Amazon is at or near the front all the time on basically everything. And it’s if they would pick a lane to stay in, great.
Google is a good example of this. There are things that Google very strongly considers in its wheelhouse, but for other things, they partner with the open source-based company in question to create a managed service partner offering and that’s great. Amazon pulls a, “Nope. We’re just going to build this out as first-party. The end.”
And they compete with everyone, including themselves on almost every axis. And that’s where it just gets into a, “Leave some oxygen for the rest of us.” I mean, it feels like they lie awake at night worrying that someone who isn’t them somehow making money somewhere. That is, I think, on some level, more of the Black Swan event than someone else deciding that they can host a particular open source project more effectively. But that’s where I stand. And again, this is just me as an enthusiastic and obnoxious observer. You’re operating in this space. What do you think? That’s the important part of the story.
Julia: Well, I mean, you definitely have a point, Amazon—or AWS, maybe not necessarily Amazon—takes on different technologies far and wide, so they’re not limiting themselves to a space. But that said, I think it comes down less to what is possible with open source and what is okay under the guise of open source, and what is good for the open source ecosystem. And when you fork a project, you do have to understand that you are bifurcating the open source ecosystem. And that can lead to sustainability problems down the road. So, I think the jury is still out on whether forking a project, running it as a managed service—as Amazon is doing with some of the open source projects—if that’s going to come back to bite them just from a developer community standpoint because you’re going to have people committing to one or the other, but possibly not both.
Corey: I think this is why Amazon—I know, they’re very annoyed by their perception in the open source ecosystem, but you take a look at other large tech companies, and almost all of them have a few notable open source projects that started life there. For example, we have—I think Cassandra came out of Facebook, but don’t quote me on that; Kubernetes came out of Google, a fact for which they steadfastly refused to apologize, so far; and so on, and so forth. But Amazon’s open source initiatives have been, “We’ve open sourced this thing that is basically only used at Amazon.” Or, my personal favorite, we’ve put all of our documentation up on GitHub so that you can write a corrections to it yourself from the community, which I’m hearing as, “Please, volunteer for a $1.6 trillion company so that they don’t have to improve their documentation by hiring expensive people internally.”
You can sort of guess my position on that. It seems like they have not launched anything that has a deep heart within Amazon that is broadly adopted outside of their walls. My question for you is, do you believe that having that level of adoption externally is required for a healthy open source project?
Julia: Again, I think it goes back to the goals of why you’re open-sourcing something. I don’t believe that it’s necessarily required for the open source project to be quality and be usable, but if your goal is adoption or if your goal is to get ideas and best practices out there, then yeah, you do need that engagement by the broader community, you do need the contributors. But there are a lot of cases where open-sourcing technology is more for the validation, rather than the adoption of the tech. So, it really depends.
Corey: I’d say the most cynical reason I’ve seen to open source things comes from Netflix, where they have a recurring pattern of open-sourcing something, there are two or three commits, and then it basically sits there unattended. What I firmly believe is happening is that a senior engineer at Netflix is working on the thing and they’re about to change jobs, so they open source the project so that they can change jobs and then pick up where they left off with an internal fork, I view it as a game of, basically, they’re passing themselves a football as they run across the street. And people laugh when I say that, but I’ve also had people over drinks say, “You are closer than you might think, sometimes.” Which on some level is terrifying. Feels like life is imitating art, but here we go.
Julia: That definitely happens, and I have seen it [laugh] as well. People want to essentially use open source to exfiltrate IP.
Corey: Yeah. Only doing it legitimate way as opposed to the, “Please don’t—hope they don’t find that USB stick I’ve hidden in my sock on my last day.”
Julia: Yes. And this is why open source offices have a challenging job in helping facilitate the release of open source software. So, it is hard to ascertain when that is happening.
Corey: Yeah, no company is ever going to have a big statement that is going to be anything other than, honestly, marketing speak when it comes time to explain why they’re doing a certain thing. It’s, “Oh, yeah, we’re open-sourcing this so we don’t get sued in three years by this other company that might prove to be a competitive threat.” Or, “We’re open-sourcing this as a hiring and recruiting technique.” I mean, I would argue, it wasn’t open source, but one of the best approaches that I’ve seen from that perspective came out of Google, I’m firmly convinced to this day that App Engine was run not by their SRE team, but by their recruiting arm, “Because if you can build a great app on App Engine, well, this is, kind of like, how we think about things inside of Google; come and work here,” either via acqui-hiring or a just outright interview funnel. Maybe that’s too cynical, too, but again, that leads to the question of is it really open source when it has these deep ties to specific platforms?
Here’s an open source tool that presumes you’re running on top of AWS. Well, great, sure it’s built by the community and anyone can access these things, but without paying per second to a cloud provider, probably the referenced cloud provider they’re developing this against, it’s not going to get very far. So, it’s a nuanced argument, and there are shades of that nuance to every aspect of it. And if there’s one thing that Twitter is terrible at is capturing nuance in 280 characters. And even in the, “All right, this is my nuanced take on open source in this thread, I will tweet, one of 5,712.” Great. That’s not really the forum for that either. And people lose sight of nuance. It’s a sticky, delicate thing, and it feels like a lot of the open source community has been enthusiastically agreeing with each other—sometimes violently so—but they’re not sharing a common language in which to do it.
Julia: Yeah. And in terms of the purposes of open source projects, it is okay for them to have different ones as long as they’re telegraphing those purposes to their users and the people who are looking at the projects for their own use. But whether it’s open source? I think it’s okay for that to be the baseline and then build out the vocabulary of the types of projects that you want from there, based on those expectations. Yes, this particular technology only works with this cloud provider. That’s open source that facilitates and accelerates development with that cloud provider.
Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And—let me be clear here—it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free, no asterisk. Start now. Visit snark.cloud/oci-free that's snark.cloud/oci-free.
Corey: I always try and stay away from explicit value judgments on a lot of these things because it’s nuanced, and no one who doesn’t work at Facebook wakes up expecting to do terrible things today. We’re all trying to do the best we can with the constraints are operating within. The challenge is that when you’re at a company like an AWS, or a Google, or a Microsoft, or one of these giant companies, the same pressures that the rest of the quote-unquote “mere mortals” in ecosystem have to contend with are very different. But talking to people who work at these big companies, they have meetings and review processes that here at my twelve-person company, I don’t even have to consider.
Easy example of that: Never once have I put something out into the world and had a single discussion about is this going to get us in trouble with respect to antitrust? That has never been on my radar as far as things I have to care about. Even at my previous job at a highly regulated financial company, where you could argue that they are approaching monopoly status in some areas of the market organically, with passive investing being what it is, great, their open source discussions were always much more aligned with what licenses are we willing to accept legal risk for using internally? Because there are things that are—like IP is why we have a business in many respects, so anything that touches that theoretically means we’d have to disclose how the entire system, how the rest of it works, is not allowed to be used here. And there are reviews and processes and compliance requirements for that.
I get that concern, and at a certain point of scale, you’re negligent if you don’t have a function that looks at it through that lens. But I look back to the early days of just puttering around with, “I want to do a thing and I found this project somewhere that people are excited about,” in the pre-GitHub days, I can download it off as Sourceforge or whatnot and I can make it work. And but it doesn’t do this one thing I want to do, “Hey, the code’s available. Can I fix it myself? Absolutely not. I’m crap at writing code. But I can talk to people and piece it together from wisdom that they offer.” And it turns into something awful until finally it gets enough traction that someone who knows what they’re doing looks at it and refactors and it makes it good.
And that’s the open source community I recognize and that I see from my early developmental period. I don’t recognize what we see in ecosystem today through that same lens of, “Okay, go online. Be nice to people”—well, that’s new—“See how this thing works. And oh, if I’m having a problem, I’m probably not the only person who’s having a problem like this.” You have to get really good at using Google more than you do at writing code in some respects. But at that point, it’s almost entirely a copy-and-paste, except that’s not technical enough for the open source world. So instead, we have to learn the 500 arcane subcommands to Git in order to get it out there. But it works. Ish.
Julia: I think that community is still out there. I really do. I think that it is harder to find and it’s not necessarily where you might tend to look, but those projects are still there. They’re still running. They might be a little less high-profile than a lot of the ones that are getting a lot of attention right now, but they are still there.
Corey: On some level, it feels like the blame for this lies—at least partially—at the feat of Slack and its success because it used to be that you had IRC, that was how folks communicated. And I remember the early days of that and things like Jabber or internal servers, grea—or internal IRC servers at companies—great, you’d have engineering all talking on that, and oh, you want to have someone in finance or marketing join that thing? Yeah, the short answer is, that won’t be happening. But you can try and delude yourself and set it up with a special client and the rest.
Slack removed all of that friction, but it’s balkanized to the point where every once in a while, I have to go through and remove a bunch of Slack channels slash workspaces slash whatever we’re calling them this week from my desktop client because it’s basically eating all the RAM like it’s trying to be Google Chrome. And then it’s great, but there’s no universal federated thing the way that there was with IRC where I just pop in a different channel for a different project. And IRC is still there and it comes back to life whenever Slack takes an outage. And then Slack gets fixed, it sort of bleeds off again. But I don’t want to be in 500 different Slack workspaces, one for every open source project that I’m using, and there’s no coherent sense of identity and community anymore the way there once was. And I feel like I’m old man yelling at the passing of time at this. But you’re right, open source to me was always much more about community than it was about code.
Julia: Yeah, and I think that we do not talk about the impact of tools for open source that we use. Because you’re right; with IRC, it was unified. You could pretty much guarantee that projects of a certain size were present there. And with Slack, you have to sign up for yet another account, not quite yet sure why I can’t find the right channels that I need to join in Slack. So, there’s a lot of navigation and a lot of prerequisite knowledge that you need to have in order to be productive.
And then you’ve got other tools being used for communication by other communities like, I believe Gitter is a major one as well. Then you have to make sure that you’re up-to-date with all of these different interfaces, Discord, everything. And the sociological implication of that shouldn’t be underestimated. What are you going to do if you find a project that uses a communication tool that you just really don’t want to use or don’t want to sign up for yet another account? Maybe you pass on by and you find one that works within your existing set of tools. There aren’t a lack of open source projects to join right now. You can be choosy. And we don’t yet know what the impact is of that.
Corey: It’s challenging. There’s no good answer that I found that solves all of these things. It’s become so balkanized, on some level, that every project out there that I see—and there are some small ones that are incredibly foundational to, basically, civilization as we know it, but it’s not working right because it’s you have to figure out where they are and what the community norms are because they change from project to project, and there are so many different things. And, like, you can go into NPM and install some relatively trivial thing that does command-line string processing, or whatnot, and it installs 40 different dependencies. And there’s a problem and you want to figure out exactly how that works, and et cetera, et cetera, et cetera.
Julia: Absolutely. With NPM specifically, or Node specifically, it is interesting that the development model kind of encourages this obscurity, an obfuscation of a functionality. So, it is hard to go in, debug an issue, go to the specific community, understand how they work, contribute a patch, just to fix something that is, you know, five levels up. It gets confusing for developers. It can contribute to longer-term bugs that we see propagate throughout the system. It is not an easy problem to solve, and I have a lot of sympathy for newcomers to the open source ecosystem because it is so hard to navigate. And I think that’s an as yet unsolved problem that we need to address.
Corey: So, what was it that inspired you to create Open Source Stories? I mean, I love the direction you’re taking this in; I love the way you’re thinking about [audio break 00:29:38]. Where did it come from? What started this?
Julia: Well, when Amanda and I were going back and doing research around—you know, aside from the code for an open source project, where are the different entry points? Where are the different interaction points between projects, ecosystems, and the industry? And we did a couple of interviews, just very organic interviews, with some subject matter experts in Node, in Python, in Go. And there was a point where we stopped—or at least I stopped taking notes because I was just so fascinated by the narrative that our interviewee was putting forth and was talking about. And what we wanted was for it to not just be this meeting between a few people, we wanted to be able to share that with anyone. And so one of the things that really inspired us was StoryCorps, which allows you to record, much like we’re doing today, 40 minutes worth of interactions between one to three people.
Corey: Oh, we’re going to cut it down to five minutes at most. Like, one question; one answer. Boom, we’re done.
Julia: [laugh].
Corey: I kid, I kid.
Julia: But it’s really about facilitating the sharing of knowledge and sharing of these oral histories. Because as you’re doing research into interactions in specific open source communities, you’ll get articles, you’ll get changelogs, all of that good stuff, but you won’t get the nuance that we’ve been talking about over the course of this podcast. You lose the story behind the story, right? How are decisions made? How are people thinking about the interactions with their users? What are the turning points for a project? What are those conversations between the maintainers that changed the entire game?
Those are the sorts of stories that we’re hoping to capture because they’re important for history, for knowledge sharing, for learning from our past, and making decisions for the future. And so that’s really what we wanted to capture. And we wanted to capture the narratives behind the people that don’t necessarily show up in the codebase, too: Talking about the designers, the product managers, the marketers behind open source that make it successful. Because there’s so much more than code.
Corey: Oh, my God, yes. It’s… how do I put this politely without getting letters? Well, I guess I’ll take a stab at it and see how it plays out. I look at so much of the brilliant code that has been written, and the documentation is abhorrent, and the design of the site, and the icon, and the interface, it looks like a joke that I put on Twitter trying to be funny. It’s, the code is important, don’t get me wrong, but there’s so much more to it than that.
And we see this in the industry, too, where companies have gone out of business, trying to get their codebase just right. It’s, yeah, you can launch code that is really, really bad, but if you have product-market fit, it is survivable. I’ve heard stories in the early days of Twitter that we saw the fail whale all the time because it was an abhorrent monstrosity, to the point it became a running joke. But it turns out, when you hit product-market fit, you can afford really good engineers to come in and fix a lot of that stuff. That stuff is more important than the quality of the code, and that is something that I think that we have a collective industry-wide delusion about. And it’s a blind spot for us.
Julia: Yeah. I think we get wrapped up in the cleverness of the tech, and I’ve fallen prey to this, too. I get so involved in how I’m solving the problem and forget about the actual problem that I’m trying to solve, right? It’s not necessarily about the how, but about the what. And without your fantastic tech writers, designers, usability experts, your open source project is going to be your open source project. It’s not going to necessarily get that wide adoption, if that is indeed your goal for the technology that you’re releasing.
So, it really is about making sure that as we’re launching and working on these open source projects and ecosystems, that we are inviting people to the table that have these other unique skills that goes beyond that code and speaks to what makes the project different and unique.
Corey: I really want to say how much I appreciate your taking the time to talk to me about this. If people want to get involved themselves, how do they do that? Because I have a hard time accepting that you’re doing something called Open Source Stories that eschews community involvement.
Julia: Yeah. So, we absolutely would love more folks to get involved. I have been primarily the person working on the site, so we can always use contributors to the site itself, but we also want more storytellers and facilitators. And so if you go to opensourcestories.org, we’ve got a page specifically designed to facilitate contributions. So, check that out, and we look forward to hearing from anyone who wants to participate.
Corey: And we will, of course, include links to that in the show notes. Thank you so much for taking the time to speak with me today. I really appreciate it.
Julia: Thanks for having me.
Corey: Julia Ferraioli, co-founder of Open Source Stories. I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment, calling me a fool because I did not bother to RTFM first.
Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.
Announcer: This has been a HumblePod production. Stay humble.
Transcript
Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.
Corey: It seems like there is a new security breach every day. Are you confident that an old SSH key, or a shared admin account, isn’t going to come back and bite you? If not, check out Teleport. Teleport is the easiest, most secure way to access all of your infrastructure. The open source Teleport Access Plane consolidates everything you need for secure access to your Linux and Windows servers—and I assure you there is no third option there. Kubernetes clusters, databases, and internal applications like AWS Management Console, Yankins, GitLab, Grafana, Jupyter Notebooks, and more. Teleport’s unique approach is not only more secure, it also improves developer productivity. To learn more visit: goteleport.com. And not, that is not me telling you to go away, it is: goteleport.com.
Corey: This episode is sponsored in part by our friends at Redis, the company behind the incredibly popular open source database that is not the bind DNS server. If you’re tired of managing open source Redis on your own, or you’re using one of the vanilla cloud caching services, these folks have you covered with the go to manage Redis service for global caching and primary database capabilities; Redis Enterprise. Set up a meeting with a Redis expert during re:Invent, and you’ll not only learn how you can become a Redis hero, but also have a chance to win some fun and exciting prizes. To learn more and deploy not only a cache but a single operational data platform for one Redis experience, visit redis.com/hero. Thats r-e-d-i-s.com/hero. And my thanks to my friends at Redis for sponsoring my ridiculous non-sense.
Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. My guest today is someone I have been very politely badgering to come on the show for a while, ever since I saw her speak a couple years ago in the Before Times, at Monktoberfest. As I’ve said before, anytime the RedMonk folks are involved in something, it is something you probably want to be involved in. That is my new guiding star philosophy when it comes to conferences, Twitter threads, opinions, breakfast cereals, you name it. Please welcome Julia Ferraioli, the co-founder of Open Source Stories, Julia, thank you for joining me today.
Julia: Thank you for having me. And I definitely agree on the RedMonk side of things. They are fantastic folk.
Corey: They’re a small company, which is sort of interesting to me from a perspective of just how outsized their impact on this entire industry is. But it’s, I’ve had as many of them as they will let me have on the show. They are welcome to come back whatever they want, just because they—every single one of them, though they’re very different from one another, make everyone around them better with their presence. And that’s just a hard thing to see. I didn’t mean to turn this into a love letter to RedMonk, but here we are.
Julia: I don’t mind it. They have the ability to amplify the goodness that they see, anything from their survey designs to just how they interact online. It’s wonderful to see.
Corey: Speaking of amplifications, you are the co-founder of Open Source Stories, the idea of telling the—to my understanding—the stories behind open source. Like this is sort of like—what is it, Behind the Music, only in this case it’s Behind the Code? I mean, how do you envision this?
Julia: Oh, I like that framing. So, Open Source Stories is a project that myself and Amanda Casari founded not that terribly long ago because when we were doing research about how to model open source and open source ecosystems, we realized that a lot of the research papers that have been published about open source are pulled mostly from GitHub Archive, which is this repository of GitHub data. It could be the actual Git commit history as well as the activity streams from GitHub as well, but that doesn’t capture a lot of the nuances behind open source, things like the narratives, how communities interact, where communication is happening, et cetera. All of these things can happen outside of the hosting platform. So, we launched this project to help tell these stories of the people and events and scenarios behind the open source projects that really power our industry.
Corey: I’m going to get letters for this one, I’m sure of it, but I’ve been involved in the open source ecosystem for a while and I’ve noticed that there’s been a recurring theme among various projects, particularly the more passionate folks working on them, where they talk an awful lot but they aren’t very good at telling stories at the same time. And nowhere is this more evident than when we look at what passes for a lot of these projects’ documentation. One of the transformative talks that I went to was Jordan Sissel’s years and years ago, at the Southern California Linux Expo. And it was a talk about LogStash, which doesn’t actually matter because the part that he’d said that really resonated with me, that his whole theme of his talk was around, was if a new user has a bad time, it’s a bug. And the idea that, “Oh, you didn’t read the documentation properly.”
When about I started working with Linux, in some IRC chat rooms, the standard response to someone asked for help was to assume that they’re an idiot, begin immediately accosting them with RTFM, for Read the Frickin’ Manual, and then look for ways that you could turn this back around on them and make it their fault. And I looked at this and at the time, it’s like, “Wow, these are people that are mean to other people,” and I was a small, angry teenager; it’s like, “This is my jam. Here I am.” And yeah, many decades later, I’m looking at this and I feel a sense of shame because that’s not the energy I want to put into the world. A lot of those communities have evolved and grown and what used to be the area and arena for hobbyists is now powering trillion-dollar companies.
Julia: Absolutely. I like the whole, “If the user has a bad experience, that’s a bug,” because it absolutely is. And I feel like a lot of these projects haven’t invested nearly as much into the user experience as they have into polishing the code. And the attitude that that kind of perpetuates throughout the project about how you treat your users, it’s pervasive and it really sets up the types of features that you develop, the contributors that you encouraged to commit to the project, and it just creates a—to put it minorly—less than welcoming environment for users, contributors, maintainers alike. And we don’t really need that sort of hostility, especially when we’re talking about projects that underpin the foundations, in some cases, of the internet.
Corey: When we look at what open source is, I mean, I shortcut to thinking in terms of the context through which I’ve always approached it, which was generally code, or in my sad, particular story, back in the olden days on good freenode, when that was where a lot of this discourse happened, I was network staff and helping a bunch of different communities get channels set up through a Byzantine process. Because of course there was a Byzantine process; it was an open source community, and if there’s one thing we love in open source, it is pretending to be lawyers when we’re not. And we’re sort of cargo-culting what we think process and procedure often look like. So yeah, there was a bunch of nonsensical paperwork happening there, but it was mostly about helping folks collaborate and communicate. But I’ve first and foremost, think in terms of code and in terms of community. What is open source to you?
Julia: Well, I entered open source in the Sourceforge days, when all you had to do was go and download some code from the internet and hit the right download button, make sure not to hit one of the extraneous ones. And all you need for that is for the code to be under the right license. And to an extent that’s what’s true today for open source. At the heart of it, this minimum criteria for what constitutes open source is, “Okay, does it comply with the open source definition that the Open Source Initiative puts forth?” Now, I understand that not everybody necessarily agrees with the Open Source definition, but it’s useful as a shortcut for how we think about the basic requirements. But what I find when people are talking about open source online is that they have these very different models. You’ll hear from people that, “Okay, well, if it doesn’t have a standard governance model, it’s not really open source.”
Corey: The ‘No True Scotsman’ argument.
Julia: Yeah. So, I find that we’ve got these different expectations for what open source is, and that leads to us talking past each other or discounting different types of open source when what we really need to do is come up with better language, a better vocabulary, for how to talk about these things. So, for example, I used to work in developer relations, and in developer relations one of the big things that you do is release sample code. Now, oftentimes, I’m not looking for that sample code to be picked up by a bunch of different developers and incorporated as a library into their project—
Corey: [laugh]. Well, that’s your error in that case because congratulations, that’s running in production at a bank somewhere, now.
Julia: Oh, I know. And that has definitely happened with my code, and I’m ashamed to say that. [laugh]. But generally speaking, you’re not looking to build a huge community around sample code, right?
Corey: You say that, but that again, Stack Overflow, it was—
Julia: Okay.
Corey: —[unintelligible 00:09:22] done rather well. So, there’s that.
Julia: Well yes, that is true, but when you release code on Stack Overflow, or GitHub, or in a Jest, or just on your blog, the thing that allows the bank to come in and incorporate that into their own application, or to even just learn from it, is the fact that it is open source. Now, it doesn’t have a lot of the things that a community like Python or Kubernetes has, but it is still open source; it just has a different purpose than those communities and those ecosystems.
Corey: So, I think it is challenging right now to talk about open source as if it were the same type of thing that it was back in the ’90s, and the naughts—and even the teens—where it’s a bunch of, more or less either hobbyists or people are perceived to be hobbyists. Sure, an awful lot of them are making commits from their redhat.com email address, but okay. And some of these people are increasingly being paid to work places, but then you see almost—I don’t necessarily agree with the framing of The New York Times article by Daisuke Wakabayashi—who’s a previous guest on the show—of Amazon strip-mining open source, but they definitely are in there—and other companies as well—are sort of appropriating it, or subverting it, or turning it into something that it was not previously, for lack of a better term. What’s your take on that?
Julia: Oh, that’s a hard one. From a fundamentals perspective, that is absolutely within their rights under the definition of open source, and in some cases, the spirit of open source as well.
Corey: Oh, and I would argue with someone who said that they should be constrained from doing this as far as a matter of legalities, or rights, or ridiculous Looney Tunes license changes.
Julia: Well, there are definitely folks who are trying to make that the case.
Corey: Yeah. Oh, yeah. I’m on the position of, they’re within their rights to do it, but it’s time for a good old fashioned public shunning as a result.
Julia: I’m not sure I agree. I think that it is a natural consequence of how open source has gained in popularity and, in some cases, it’s a testament to open source’s success. Now, does it pose some serious challenges for the open source community and open source ecosystem? Absolutely because this is a new way of using open source that was unanticipated, and in fact, could be characterized as a Black Swan event in [open source-ware 00:12:18].
Corey: The fundamental attribution error that I see, back at the very beginning, was that what we wrote the software, therefore, we are the best in the world at running it, therefore, if there’s going to be a managed service, clearly ours will be the best. Amazon’s core strength has apparently been operational excellence as they like to call it; my position on that is a little bit less of tying into the mystery, a little bit more of they’re really fast and getting paged and fixing things in a hurry before customers notice. So okay, great, but it’s column A, column B, whatever. The bigger concern I have with Amazon as its product strategy is, “Yes.” If it were just a way to run EC2 instances or virtual machines, then sure, that’s great.
And every open source project should, on some level, see some validation of its market through a lens of, “Oh, we’re getting some competition. That’s great.” The challenge I see is that in the line of competitors, Amazon is at or near the front all the time on basically everything. And it’s if they would pick a lane to stay in, great.
Google is a good example of this. There are things that Google very strongly considers in its wheelhouse, but for other things, they partner with the open source-based company in question to create a managed service partner offering and that’s great. Amazon pulls a, “Nope. We’re just going to build this out as first-party. The end.”
And they compete with everyone, including themselves on almost every axis. And that’s where it just gets into a, “Leave some oxygen for the rest of us.” I mean, it feels like they lie awake at night worrying that someone who isn’t them somehow making money somewhere. That is, I think, on some level, more of the Black Swan event than someone else deciding that they can host a particular open source project more effectively. But that’s where I stand. And again, this is just me as an enthusiastic and obnoxious observer. You’re operating in this space. What do you think? That’s the important part of the story.
Julia: Well, I mean, you definitely have a point, Amazon—or AWS, maybe not necessarily Amazon—takes on different technologies far and wide, so they’re not limiting themselves to a space. But that said, I think it comes down less to what is possible with open source and what is okay under the guise of open source, and what is good for the open source ecosystem. And when you fork a project, you do have to understand that you are bifurcating the open source ecosystem. And that can lead to sustainability problems down the road. So, I think the jury is still out on whether forking a project, running it as a managed service—as Amazon is doing with some of the open source projects—if that’s going to come back to bite them just from a developer community standpoint because you’re going to have people committing to one or the other, but possibly not both.
Corey: I think this is why Amazon—I know, they’re very annoyed by their perception in the open source ecosystem, but you take a look at other large tech companies, and almost all of them have a few notable open source projects that started life there. For example, we have—I think Cassandra came out of Facebook, but don’t quote me on that; Kubernetes came out of Google, a fact for which they steadfastly refused to apologize, so far; and so on, and so forth. But Amazon’s open source initiatives have been, “We’ve open sourced this thing that is basically only used at Amazon.” Or, my personal favorite, we’ve put all of our documentation up on GitHub so that you can write a corrections to it yourself from the community, which I’m hearing as, “Please, volunteer for a $1.6 trillion company so that they don’t have to improve their documentation by hiring expensive people internally.”
You can sort of guess my position on that. It seems like they have not launched anything that has a deep heart within Amazon that is broadly adopted outside of their walls. My question for you is, do you believe that having that level of adoption externally is required for a healthy open source project?
Julia: Again, I think it goes back to the goals of why you’re open-sourcing something. I don’t believe that it’s necessarily required for the open source project to be quality and be usable, but if your goal is adoption or if your goal is to get ideas and best practices out there, then yeah, you do need that engagement by the broader community, you do need the contributors. But there are a lot of cases where open-sourcing technology is more for the validation, rather than the adoption of the tech. So, it really depends.
Corey: I’d say the most cynical reason I’ve seen to open source things comes from Netflix, where they have a recurring pattern of open-sourcing something, there are two or three commits, and then it basically sits there unattended. What I firmly believe is happening is that a senior engineer at Netflix is working on the thing and they’re about to change jobs, so they open source the project so that they can change jobs and then pick up where they left off with an internal fork, I view it as a game of, basically, they’re passing themselves a football as they run across the street. And people laugh when I say that, but I’ve also had people over drinks say, “You are closer than you might think, sometimes.” Which on some level is terrifying. Feels like life is imitating art, but here we go.
Julia: That definitely happens, and I have seen it [laugh] as well. People want to essentially use open source to exfiltrate IP.
Corey: Yeah. Only doing it legitimate way as opposed to the, “Please don’t—hope they don’t find that USB stick I’ve hidden in my sock on my last day.”
Julia: Yes. And this is why open source offices have a challenging job in helping facilitate the release of open source software. So, it is hard to ascertain when that is happening.
Corey: Yeah, no company is ever going to have a big statement that is going to be anything other than, honestly, marketing speak when it comes time to explain why they’re doing a certain thing. It’s, “Oh, yeah, we’re open-sourcing this so we don’t get sued in three years by this other company that might prove to be a competitive threat.” Or, “We’re open-sourcing this as a hiring and recruiting technique.” I mean, I would argue, it wasn’t open source, but one of the best approaches that I’ve seen from that perspective came out of Google, I’m firmly convinced to this day that App Engine was run not by their SRE team, but by their recruiting arm, “Because if you can build a great app on App Engine, well, this is, kind of like, how we think about things inside of Google; come and work here,” either via acqui-hiring or a just outright interview funnel. Maybe that’s too cynical, too, but again, that leads to the question of is it really open source when it has these deep ties to specific platforms?
Here’s an open source tool that presumes you’re running on top of AWS. Well, great, sure it’s built by the community and anyone can access these things, but without paying per second to a cloud provider, probably the referenced cloud provider they’re developing this against, it’s not going to get very far. So, it’s a nuanced argument, and there are shades of that nuance to every aspect of it. And if there’s one thing that Twitter is terrible at is capturing nuance in 280 characters. And even in the, “All right, this is my nuanced take on open source in this thread, I will tweet, one of 5,712.” Great. That’s not really the forum for that either. And people lose sight of nuance. It’s a sticky, delicate thing, and it feels like a lot of the open source community has been enthusiastically agreeing with each other—sometimes violently so—but they’re not sharing a common language in which to do it.
Julia: Yeah. And in terms of the purposes of open source projects, it is okay for them to have different ones as long as they’re telegraphing those purposes to their users and the people who are looking at the projects for their own use. But whether it’s open source? I think it’s okay for that to be the baseline and then build out the vocabulary of the types of projects that you want from there, based on those expectations. Yes, this particular technology only works with this cloud provider. That’s open source that facilitates and accelerates development with that cloud provider.
Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And—let me be clear here—it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free, no asterisk. Start now. Visit snark.cloud/oci-free that's snark.cloud/oci-free.
Corey: I always try and stay away from explicit value judgments on a lot of these things because it’s nuanced, and no one who doesn’t work at Facebook wakes up expecting to do terrible things today. We’re all trying to do the best we can with the constraints are operating within. The challenge is that when you’re at a company like an AWS, or a Google, or a Microsoft, or one of these giant companies, the same pressures that the rest of the quote-unquote “mere mortals” in ecosystem have to contend with are very different. But talking to people who work at these big companies, they have meetings and review processes that here at my twelve-person company, I don’t even have to consider.
Easy example of that: Never once have I put something out into the world and had a single discussion about is this going to get us in trouble with respect to antitrust? That has never been on my radar as far as things I have to care about. Even at my previous job at a highly regulated financial company, where you could argue that they are approaching monopoly status in some areas of the market organically, with passive investing being what it is, great, their open source discussions were always much more aligned with what licenses are we willing to accept legal risk for using internally? Because there are things that are—like IP is why we have a business in many respects, so anything that touches that theoretically means we’d have to disclose how the entire system, how the rest of it works, is not allowed to be used here. And there are reviews and processes and compliance requirements for that.
I get that concern, and at a certain point of scale, you’re negligent if you don’t have a function that looks at it through that lens. But I look back to the early days of just puttering around with, “I want to do a thing and I found this project somewhere that people are excited about,” in the pre-GitHub days, I can download it off as Sourceforge or whatnot and I can make it work. And but it doesn’t do this one thing I want to do, “Hey, the code’s available. Can I fix it myself? Absolutely not. I’m crap at writing code. But I can talk to people and piece it together from wisdom that they offer.” And it turns into something awful until finally it gets enough traction that someone who knows what they’re doing looks at it and refactors and it makes it good.
And that’s the open source community I recognize and that I see from my early developmental period. I don’t recognize what we see in ecosystem today through that same lens of, “Okay, go online. Be nice to people”—well, that’s new—“See how this thing works. And oh, if I’m having a problem, I’m probably not the only person who’s having a problem like this.” You have to get really good at using Google more than you do at writing code in some respects. But at that point, it’s almost entirely a copy-and-paste, except that’s not technical enough for the open source world. So instead, we have to learn the 500 arcane subcommands to Git in order to get it out there. But it works. Ish.
Julia: I think that community is still out there. I really do. I think that it is harder to find and it’s not necessarily where you might tend to look, but those projects are still there. They’re still running. They might be a little less high-profile than a lot of the ones that are getting a lot of attention right now, but they are still there.
Corey: On some level, it feels like the blame for this lies—at least partially—at the feat of Slack and its success because it used to be that you had IRC, that was how folks communicated. And I remember the early days of that and things like Jabber or internal servers, grea—or internal IRC servers at companies—great, you’d have engineering all talking on that, and oh, you want to have someone in finance or marketing join that thing? Yeah, the short answer is, that won’t be happening. But you can try and delude yourself and set it up with a special client and the rest.
Slack removed all of that friction, but it’s balkanized to the point where every once in a while, I have to go through and remove a bunch of Slack channels slash workspaces slash whatever we’re calling them this week from my desktop client because it’s basically eating all the RAM like it’s trying to be Google Chrome. And then it’s great, but there’s no universal federated thing the way that there was with IRC where I just pop in a different channel for a different project. And IRC is still there and it comes back to life whenever Slack takes an outage. And then Slack gets fixed, it sort of bleeds off again. But I don’t want to be in 500 different Slack workspaces, one for every open source project that I’m using, and there’s no coherent sense of identity and community anymore the way there once was. And I feel like I’m old man yelling at the passing of time at this. But you’re right, open source to me was always much more about community than it was about code.
Julia: Yeah, and I think that we do not talk about the impact of tools for open source that we use. Because you’re right; with IRC, it was unified. You could pretty much guarantee that projects of a certain size were present there. And with Slack, you have to sign up for yet another account, not quite yet sure why I can’t find the right channels that I need to join in Slack. So, there’s a lot of navigation and a lot of prerequisite knowledge that you need to have in order to be productive.
And then you’ve got other tools being used for communication by other communities like, I believe Gitter is a major one as well. Then you have to make sure that you’re up-to-date with all of these different interfaces, Discord, everything. And the sociological implication of that shouldn’t be underestimated. What are you going to do if you find a project that uses a communication tool that you just really don’t want to use or don’t want to sign up for yet another account? Maybe you pass on by and you find one that works within your existing set of tools. There aren’t a lack of open source projects to join right now. You can be choosy. And we don’t yet know what the impact is of that.
Corey: It’s challenging. There’s no good answer that I found that solves all of these things. It’s become so balkanized, on some level, that every project out there that I see—and there are some small ones that are incredibly foundational to, basically, civilization as we know it, but it’s not working right because it’s you have to figure out where they are and what the community norms are because they change from project to project, and there are so many different things. And, like, you can go into NPM and install some relatively trivial thing that does command-line string processing, or whatnot, and it installs 40 different dependencies. And there’s a problem and you want to figure out exactly how that works, and et cetera, et cetera, et cetera.
Julia: Absolutely. With NPM specifically, or Node specifically, it is interesting that the development model kind of encourages this obscurity, an obfuscation of a functionality. So, it is hard to go in, debug an issue, go to the specific community, understand how they work, contribute a patch, just to fix something that is, you know, five levels up. It gets confusing for developers. It can contribute to longer-term bugs that we see propagate throughout the system. It is not an easy problem to solve, and I have a lot of sympathy for newcomers to the open source ecosystem because it is so hard to navigate. And I think that’s an as yet unsolved problem that we need to address.
Corey: So, what was it that inspired you to create Open Source Stories? I mean, I love the direction you’re taking this in; I love the way you’re thinking about [audio break 00:29:38]. Where did it come from? What started this?
Julia: Well, when Amanda and I were going back and doing research around—you know, aside from the code for an open source project, where are the different entry points? Where are the different interaction points between projects, ecosystems, and the industry? And we did a couple of interviews, just very organic interviews, with some subject matter experts in Node, in Python, in Go. And there was a point where we stopped—or at least I stopped taking notes because I was just so fascinated by the narrative that our interviewee was putting forth and was talking about. And what we wanted was for it to not just be this meeting between a few people, we wanted to be able to share that with anyone. And so one of the things that really inspired us was StoryCorps, which allows you to record, much like we’re doing today, 40 minutes worth of interactions between one to three people.
Corey: Oh, we’re going to cut it down to five minutes at most. Like, one question; one answer. Boom, we’re done.
Julia: [laugh].
Corey: I kid, I kid.
Julia: But it’s really about facilitating the sharing of knowledge and sharing of these oral histories. Because as you’re doing research into interactions in specific open source communities, you’ll get articles, you’ll get changelogs, all of that good stuff, but you won’t get the nuance that we’ve been talking about over the course of this podcast. You lose the story behind the story, right? How are decisions made? How are people thinking about the interactions with their users? What are the turning points for a project? What are those conversations between the maintainers that changed the entire game?
Those are the sorts of stories that we’re hoping to capture because they’re important for history, for knowledge sharing, for learning from our past, and making decisions for the future. And so that’s really what we wanted to capture. And we wanted to capture the narratives behind the people that don’t necessarily show up in the codebase, too: Talking about the designers, the product managers, the marketers behind open source that make it successful. Because there’s so much more than code.
Corey: Oh, my God, yes. It’s… how do I put this politely without getting letters? Well, I guess I’ll take a stab at it and see how it plays out. I look at so much of the brilliant code that has been written, and the documentation is abhorrent, and the design of the site, and the icon, and the interface, it looks like a joke that I put on Twitter trying to be funny. It’s, the code is important, don’t get me wrong, but there’s so much more to it than that.
And we see this in the industry, too, where companies have gone out of business, trying to get their codebase just right. It’s, yeah, you can launch code that is really, really bad, but if you have product-market fit, it is survivable. I’ve heard stories in the early days of Twitter that we saw the fail whale all the time because it was an abhorrent monstrosity, to the point it became a running joke. But it turns out, when you hit product-market fit, you can afford really good engineers to come in and fix a lot of that stuff. That stuff is more important than the quality of the code, and that is something that I think that we have a collective industry-wide delusion about. And it’s a blind spot for us.
Julia: Yeah. I think we get wrapped up in the cleverness of the tech, and I’ve fallen prey to this, too. I get so involved in how I’m solving the problem and forget about the actual problem that I’m trying to solve, right? It’s not necessarily about the how, but about the what. And without your fantastic tech writers, designers, usability experts, your open source project is going to be your open source project. It’s not going to necessarily get that wide adoption, if that is indeed your goal for the technology that you’re releasing.
So, it really is about making sure that as we’re launching and working on these open source projects and ecosystems, that we are inviting people to the table that have these other unique skills that goes beyond that code and speaks to what makes the project different and unique.
Corey: I really want to say how much I appreciate your taking the time to talk to me about this. If people want to get involved themselves, how do they do that? Because I have a hard time accepting that you’re doing something called Open Source Stories that eschews community involvement.
Julia: Yeah. So, we absolutely would love more folks to get involved. I have been primarily the person working on the site, so we can always use contributors to the site itself, but we also want more storytellers and facilitators. And so if you go to opensourcestories.org, we’ve got a page specifically designed to facilitate contributions. So, check that out, and we look forward to hearing from anyone who wants to participate.
Corey: And we will, of course, include links to that in the show notes. Thank you so much for taking the time to speak with me today. I really appreciate it.
Julia: Thanks for having me.
Corey: Julia Ferraioli, co-founder of Open Source Stories. I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment, calling me a fool because I did not bother to RTFM first.
Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.
Announcer: This has been a HumblePod production. Stay humble.
