Open Source Evangelism Before it Was Cool with Sarah Novotny

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist 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: This episode is brought to you in part by our friends at FireHydrant where they want to help you master the mayhem. What does that mean? Well, they’re an incident management platform founded by SREs who couldn’t find the tools they wanted, so they built one. Sounds easy enough. No one’s ever tried that before. Except they’re good at it. Their platform allows teams to create consistency for the entire incident response lifecycle so that your team can focus on fighting fires faster. From alert handoff to retrospectives and everything in between, things like, you know, tracking, communicating, reporting: all the stuff no one cares about. FireHydrant will automate processes for you, so you can focus on resolution. Visit firehydrant.io to get your team started today, and tell them I sent you because I love watching people wince in pain.

Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if launching new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.

Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by—oh boy. Well, I'm joined by Sarah Novotny is probably the best way to frame it, but describing what you do takes a bit of work. Sarah, welcome to the show.

Sarah: Thank you, Corey. It's great to be on the show. And yes, not everyone quite gets the threads that run through my career.

Corey: Right. Even if I want to completely ignore everything that you are, and do, et cetera historically, and only focus on the current stuff, I have options to choose from. You are the open-source wonk in Azure’s Office of the CTO. So, you are a Microsoft employee. You are also on the boards of directors for both the Linux Foundation and Node.js.

Sarah: Actually, the Node.js Foundation has now been folded into the OpenJS foundation. So, that was a big merger between Node.js and the JSF—the JS Foundation.

Corey: Given that, honestly, my biggest challenge with JavaScript is pronouncing it—I keep biasing for ‘YavaScript,’ I am not going to dive into most of that today. So, unfortunately, we only have 20 years of your expertise in the open-source world and now, effectively, setting free and open-source software strategy at Microsoft to delve into. So, you know, only that.

Sarah: Just a bit.

Corey: [laugh]. My word. So, at a very high level, the open-source strategy is now being driven from Microsoft's Office of the CTO apparently. Which is a nice departure from 20 years ago when it was clearly driven by their legal department. So, I have had a bunch of guests on previously, from Microsoft who've talked about ‘the new Microsoft’ and the way that they're pivoting to the point where that is now kind of old news. It's exciting. It's great. It's seeing a level of participation that I am honestly shocked to have seen over the past decade or so. My question for you is—and this is possibly dumb, possibly not—why does Microsoft care about open-source at all?

Sarah: There's actually a really simple answer to it. And it's because customers care. In the same way that AWS tries to put the customer perspective first, Microsoft is always focused on the customer and how the customer is interacting. And if customers want open-source to be able to run in Azure, or inside, or in formation with other Microsoft tools, then you need to be able to work in that composable manner. The industry has changed in the last 20 years. 

You've mentioned the historical aspect of this in that 20 years ago, we didn't have nearly the broad industry expertise that we do today, and we were primarily sold vertically integrated stacks by some particular vendor that knew way more about their thing than we ever could in an organization. And so that is changing. There are more and more opinions from the technical staff and teams that have grown up in infrastructure and grown up in technology. And so it's much harder to sell a vertically integrated stack. And so if that's the case, then your customers want Microsoft software to work with all sorts of other things. And you meet your customers where they are, or you risk losing them.

Corey: So I'm not always one to drag the compare and contrast to competition stories here, but something that I think has been pretty clear in the open-source space is there's so much whining about AWS offering a competing service to open-source projects—which just so happened to have a VC backed company behind them, but it's unfair to point that out—whereas Azure does not, to my understanding, get virtually any of that pushback. And it's not because you folks aren't offering things that are open-source aligned. Why is that?

Sarah: We have been spending a lot of effort making sure that we are working in the communities and then also with different companies in an ecosystem to showcase their work as well. So, we have several partner-run services on top of Azure that are run by the open-source company that is best known for the open-source project. So, for example, we have an Azure Databricks service, we have Azure Arrow, Azure Red Hat OpenShift, which is run by Red Hat engineers. And, I mean, we have several more of these because there’s—I think there's an Elastic service, and there's a bunch of services from HashiCorp that are happening. So, it is a matter of trying to work with the community, as opposed to seeing yourself as merely a beneficiary of the community. You have to be willing to put in the work in the communities and in the projects to be able to garner that ability to work with them to build a service.

Corey: Well, to be clear, no one out there has ever accused any of the large cloud providers of being good at naming services, so we're going to just skip past a lot of that snark. And instead, I do—

Sarah: Wait, but why? You don't understand; half of my internal open-source escalations around the names of things. 

Corey: Oh, it's also, truth be told—I don't want to necessarily shatter my own myth—it is way harder to name a service well than it is to make fun of a crappy name. So, I do have some sympathy for folks, but in the interest of full disclosure, I don't want to crap on the merit of a service very often because then you wind up with the engineers who built it feeling really bad. Whereas no one spent months, and months, and months naming Azure Data Box, and if they did, maybe they should feel bad about it. So there’s—I understand that the direction that this stuff goes in, but at some point, you just need to call things out as being badly named.

Sarah: [laugh]. Trust me, we do a fair number of that internally, even before some of them get out.

Corey: Oh, if anyone ever wants to leak me stuff—everyone’s like, “What can I leak you if I really hate my employer?” The honest answer: the proposed names for services that never saw the light of day. That's the thing I want to see. I don't want to see big customer lists or your internal P&L. No, no, no, I want to see the names that were considered too bad to put into public because I would have a field day with it. 

Sarah: [laugh]. I bet you would. Oh, I bet you would. And that's actually a really interesting differentiation, for you to not want to mock or derive a service because of the engineers, but the name, the naming is still hard, and there's still lots of people who work on it and think about it, but not in the way one might if, say, it was a firstborn child or something.

Corey: Right. It's understood, I think, in marketing organizations, that naming is a series of trade-offs and compromises. Engineering is too, but that's not broadly understood in the general market. And it's easy to wind up taking umbrage from an engineering perspective, in a way that doesn't seem to happen when we're talking about naming, by and large. There are always going to be exceptions. 

And there are times the service and or the name both absolutely suck to the point where saying otherwise is borderline malpractice, but it's not necessarily something that is going to rub people the wrong way in quite the same direction. Or at least I don't get the letters about naming that I do about insulting engineering teams.

Sarah: [laugh]. Okay.s, good to know. Perhaps that's an audience thing for you, too. Maybe there are fewer marketing people who are listening to your podcast.

Corey: Yeah, the sad thing is, is I looked up one day and discovered I'd become a marketing person myself, and now I don't recognize myself. But speaking of not recognizing things, what is the story with Microsoft—of all companies—having an employee who is also a board member for the Linux Foundation? That’s one of those oil and water stories if you've been asleep for the last decade. But first, is that on some level considered to be a conflict of interest?

Sarah: It is absolutely not a conflict of interest. And in fact, I represent Microsoft on the Linux Foundation Board. So, I am in Microsoft’s seat on that. We've had a seat on the Linux Foundation Board—we Microsoft—for almost four years now. And when John Gossman actually finally said, “No, we need to do this,”s and a lot the Platinum membership, and participated, and was the first board member for Microsoft there, when he arrived at the Linux Foundation Board meeting the first time, he actually had people clapping and super excited that Microsoft had joined. So it's a complete shift from 20 years ago when I was living here in Seattle, and would not even have considered if a recruiter from Microsoft called me. It's completely different now.

Corey: It really is. And again, I used to be a Windows admin very briefly and got out of it, just because I couldn't stand aspects of what I had to do to run Microsoft stack; went to Linux around 2006 and never went back. And looking back, everything I predicted about hating Microsoft—oh, they're going to be awful in Cloud; they're going to wind up crushing Linux; like the GitHub acquisition, everyone was extremely skeptical about it. Looking at it now, and I think that if you're still beating that war drum, you're kind of a relic, I've got to say. It's very clear that the things that the general open-source community feared did not come to pass full stop. And to be very honest with you, I really question whether any company including Microsoft has the kind of long game to wind up submerging the evil for 30 years.

Sarah: Very few people are that good at strategy.

Corey: Or are, frankly, that driven by spite. I'm one of them, but not too many others.

Sarah: Okay, note to self: don't get Corey mad at me.

Corey: Exactly. So, as I look now, across the open-source landscape, everyone who is doing open-source projects, by and large, has them living on GitHub, it's the de facto place for things to be. And an awful lot of folks who, unlike me, don't have 20 years of muscle memory built up in VI are reaching for an editor, it's going to be Microsoft Visual Studio Code. And that's the early developer ecosystem play that really seems to be paying dividends for Microsoft across the board. I maintain on some level when there winds up being a click the button to seamlessly deploy this thing to Azure, like Heroku used to be but then got stalled somewhere along the way, if done right, that becomes something transformative across the entire cloud landscape. And I like it because if nothing else, it makes the developer experience better. It should not be hard to get started in this world, the way that it once was.

Sarah: Or in many cases still is.

Corey: Oh, when I look at how to write code, a lot of the intro level tutorials in a lot of places it starts off with, first here's a chapter on learning VI. Why? Why on earth would you subject people to that? I get it 20 years ago, but now that's not really necessary in any meaningful way. It's the wrong direction; it feels like gatekeeping, and—

Sarah: It is gatekeeping.

Corey: —it's awful. It's making it harder for people to get into this rather than easier. First, you have to learn some weird-ass ASCII text editor is not a viable strategy for making what you're doing inclusive and welcoming.

Sarah: Yeah, it's been really interesting to watch some of the longer-standing open-source projects, understand and engage with newer developers and learn from them. And then also, some different projects struggle to bring in new recruits because they don't have the empathy for that world being changed.

Corey: Oh, yeah, “I had to suffer, so other people going through it should suffer as well.” This idea runs counter to the philosophy of ‘send the elevator back down.’ You had to struggle and fight to get to where you are? Great. Shouldn't you want the next person coming up to not have to do all of that? We all stand on the shoulders of giants. None of us know how to work punch cards these days. Let's extend that philosophy.

Sarah: Yeah, it's interesting because you brought up gatekeeping. In the same way, you really want to have a positive-sum game out of all of this work because if we do work well across the clouds, and if we were ever magically to have good interoperability between them, then you end up seeing a way that the customers are so much more successful, and the pie is big enough for all of us. This is the thing: the total addressable market of Cloud is not small, and we do not have to look at this in terms of if I gain one customer, you lose one customer. We can entirely look at it as building the best infrastructure for the customers who need them and then setting up the support that they need to make all of this work well together. It's the same way that—well, I guess I can't say utilities at this point because I was going to say it’s the same way we eventually moved toward electricity as a utility. But at some point, we see—at least in California—the electric utility not taking care have their systems here as well as they should have. So, maybe that's a bad example.

Corey: No, but there is something to be said for the idea of utilities, which is, whenever I turn the faucet on or flip a light switch, I don't sit here questioning whether it's going to work or not. Now, I have some IoT light switches, so maybe I shouldn't question that a bit more than I do. But by and large, there's a level of dependability that is required for folks to consider something a utility. By and large, cloud providers are getting a lot closer to that than anything else once were.

Sarah: Yeah. But with utility comes regulation and that has always been a thing that the cloud providers have been more concerned about, broadly speaking. And regulation and oversight does make it harder to cut corners and go fast, but it also may make for a much more stable infrastructure and a much more interoperable and less monopolistic looking space.

Corey: This episode is sponsored in part by our friends at New Relic. If you’re like most environments, you probably have an incredibly complicated architecture, which means that monitoring it is going to take a dozen different tools. And then we get into the advanced stuff. We all have been there and know that pain, or will learn it shortly, and New Relic wants to change that. They’ve designed everything you need in one platform with pricing that’s simple and straightforward, and that means no more counting hosts. You also can get one user and a hundred gigabytes a month, totally free. To learn more, visit newrelic.com. Observability made simple.

Corey: There's so much that could be done in order to make things even easier, but you need to get the fundamentals right first. You have to not wonder if the virtual machines are going to boot when you tell them to; you have to not wonder whether the storage is going to lose your data due to a weird disk issue. And in a lot of ways, those problems from the early days of Cloud don't really exist in the same way. Now, people are wondering what's possible when you don't have to think about that general baseline level of work that anything needs, and instead you can have your staff start to focus on things that are much more aligned with the actual business problem they're trying to solve.

Sarah: Yeah. Take away the effort that is commoditized. I will always need a server-ish thing that can do compute. Maybe we could be serverless; it could be a VM; it could be a container, but I will need some compute, and I will need some storage probably to put data somewhere. And then how do you interop all of these different things across the different clouds, and how do you do this across the different needs, and use this cloud for the workloads that they are best optimized for and that cloud for the workloads that they're best optimized for. 

And just basically hand empowerment back to customers to choose what's right for them as opposed to trying to tell them that they need to buy something to fix a problem from my company or someone else's company instead of saying, “Where are you and what are you doing right now? We need to make sure this works on our systems as well as it can.”

Corey: So, if you want to wind up getting effectively dragged for positions that you didn't intend to make, there are a few better ways to do that than to sit down for an interview with The Register. They're snarky, they're sarcastic. I'm a big fan of them and have been for many years, but you sort of know what you're getting into when that happens. In August of last year, you sat down and had an interview with them, and the headline, which I will quote verbatim, “Relying on plain-text email is a ‘barrier to entry’ for kernel development, says Linux Foundation board member.” Now, tell me more about that, please. Because it’s certainly provocative.

Sarah: It is provocative. There is work happening inside the Linux community, like, looking at ways that our workflow may have new entry points that are more modern, as opposed to the strict model that they use currently, which is their entire workflow is patches through diffs in email, which is super important for the high velocity that the Linux kernel changes have and the size and breadth of that community. And it's limiting to say this is how you need to engage with this project because not as many people today read their mail through a client that can do just straight plain text for real; it's tough actually. And there's lots of opportunity for these larger, longer-standing communities to reach out and look to growing new contributors and new leaders within that community. And that's the only way that these projects will live on another 10 or 20 years. 

Or they will have to be sort of wound down and we will have to look toward the new versions, the new operating system that might happen, or the new web server, or container orchestration system, or whatever. If we're not managing and maintaining these open-source projects and working very hard to bring in new views, bring in new people, and to set them up for succession when succession needs to happen, is incredibly important. We saw a challenge with that with the Python community when Guido Rossum ended up saying, “I’m going to step down,” and there had not been a good setup, particularly, for succession there. And so that community struggled for a while. They seem to be doing better again.

Corey: Yeah, there's an awful lot that companies and organizations can do to make things easier. And once upon a time, plaintext email was the way that these things—

Sarah: Was the easiest way. Yeah, absolutely.

Corey: Yeah. And I was one of those militant folks when I ran large-scale email systems that, “Oh, it's plaintext email, or it's trash.” HTML? No, I want plaintext email. And guess what? We lost that fight across the board.

Sarah: Yep. I gave up Mutt, finally.

Corey: Yeah, it's hard to get Gmail or Outlook to send plaintext email only out of the box. So it's gone from—to make sure that this is something everyone can understand. Now, it's become a gatekeeping Shibboleth that stands in the way of a lot of people who otherwise would love to contribute. Because let's face it, anyone who's reading email in something that only speaks ASCII text, I'm sorry, you are so far of a corner case that it's almost a vanishing point here. I pay attention to this because I write a large email newsletter and the number of people who complain about the plaintext version, I think I had to the first year and nothing since. It just isn't a thing that realistic people are using these days. Now, yes, you can make an argument that the deep geeks who are Linux kernel developers should know enough to do that. Sure—

Sarah: Absolutely.

Corey: I can accept that, but why? What is the actual upside value here?

Sarah: Yeah. There is no big benefit in making them spend the first hour or three hours of whatever they're trying to do in an open-source project where most of the time people are offering their time or offering their time as a tiny slice of what they do for their day job, and they then spend a bunch of time just faffing about and trying to figure out how to get something submitted to a mailing list without looking like they don't know what they're doing. And I guarantee that anyone who has already had any little drag on their career—so pretty much every underrepresented minority out there—is not going to be as comfortable trying to go to something like a mailing list, where they know that it's a hard audience, and try to submit something on their first try and get it right and/or know that if they don't get it right that their first interaction will be a, “Resend your patch. Can't read this,” kind of thing or, “Patch doesn't apply smoothly,” or something.

Corey: Yeah. That was the obnoxious part about a lot of open-source communities back when I helped to run the freenode IRC network. It was incredibly off-putting to have someone go to all the effort of building a patch, making sure that it works on their end, to fix a pain that they had—all on a volunteer basis, may I point out—and then being told, “You didn't format your patch correctly.” Or not even being told how, just, “This isn't in the appropriate format. Read the docs.” And it was, “Why am I helping you people? You're thoroughly unpleasant and I'd rather go somewhere else where I get more of an emotional high from helping.”

Sarah: Yeah. It's actually one of the things we have found most in the Kubernetes community that's most responded to, and most reported, and most talked about is that the community is really open and friendly, and tries to encourage people, and takes on a, “Wow, you look like you're struggling. Let me help,” kind of approach as opposed to an RTFM.

Corey: Yeah. It's incredibly off-putting, too. On some level that's why people started paying more attention—to be direct—to Ubuntu than they did Debian because the response they got from the community when they got stuck—and let's face it, everyone gets stuck somewhere, especially in the early days—was such worlds apart. “Go read the manual,” without any indication of what manual they should read—turns out there's a lot of documentation—what exactly are they're getting stuck on? And people spend more time castigating folks for not asking the question properly than they did actually trying to help people. 

Sure, these are all volunteers. No one owed anyone any particular level of support, but Ubuntu’s entire community from day one was aimed at making this accessible to people who were not experts in it, and that alone changed the entire way that it was perceived. And it's why an awful lot of listeners know what Ubuntu is but will have to do a bit of quick googling to understand what Debian is.

Sarah: Mm-hm. And the fact that Debian is the upstream from Ubuntu is lost on every—many. Not everyone.

Corey: Oh, sure. But this also is turning into what the world is doing where originally, what distro I use, what operating system I used, were big, contentious issues. Today, I don't have to care about that. I mean, a few people do in very specific roles and that's their entire world. But I don't care necessarily, as things move up the stack, what operating system it's using, whether it's in a container or a serverless function, I just care that there's an API I can bounce something off of, and I get what I want in return from that API. 

And it's going to continue to go beyond that down the road, I'm sure. But this stuff is all slipped below the surface of awareness. And the folks who haven't evolved with it feel like relics, to be very honest with you. Not in their focus—higher up the stack. I mean, people working on these things is important, but folks who are convinced that this is all that they'll need to know, where they aren't evolving their skill set, it's sad to see.

Sarah: Yeah. We touched a little bit on gatekeeping, and I think we are in a very much a generational shift, and it might even be the second generational shift within tech in my career time. I'm sure there have been many more since computers began. But there's a point in every career where you kind of get to the top end of an intermediate-level tech person, and you're the one person who knows how to fix this thing, and you're the go to person. And everybody sort of loves that feeling of being the hero, and always being pulled in to fix something for someone, and being the only person who knows or understands it. 

But in a world where we're trying to empower people to use good technology to make good decisions and improve the world, we need to make sure that we are opening technology up for everyone who is coming behind us with more documentation, more philosophical writing, more entry points for people to start, more ways that have guided the directional paths so that people can learn more, and not do the othering that used to happen in the network engineers not talking to the systems engineers because network engineering is so much more critical than systems engineering, and all of the weird silos we had made. So, I actually find this fascinating to watch as these generations change that we know we have this full-stack developer concept now. And it's full-stack in today's world because full-stack no longer means having to rack the hardware and actually talk to the person who was giving you your ISDN circuit or whatever technology you were trying to connect at the time. But from ethernet all the way up to somebody interacting with it used to be a lot more difficult because you'd have to have expertise as opposed to an API, as you mentioned.

Corey: So, the last thing I want to really talk to you about, aligned with this is, if you look across the landscape, there's an awful lot of people who are defining themselves by the technology, or the stack, or the project that they work with. And I get it. I started my career as a large-scale email systems administrator. And it became pretty clear after a year of that, that there was a consolidation happening in the email space and that this was not going to be a long term niche that would have rendered me infinitely employable. And my choice was either learn something else to focus on, or double down and try and deny the reality of what's happening in front of me. 

And it's a hard choice, I'm not denying that at all. But open-source seems particularly tied to this. When I went onto freenode somewhat recently and showed up at a few of the old channels I used to haunt a decade ago, a lot of the same people are still there giving the same advice with the same tone. The only difference is, a lot fewer people are asking the questions now. 

Sarah: Mm-hm. Yeah.

Corey: So, from that perspective, what's the future of open-source? 

Sarah: Oh, the future of open-source still is hearty. I actually think it's a grand space ahead of us. I do think that it is going to look very different than open-source of 20 years ago. We've had companies decide to make concerted, organized strategies. This is the work I do and making sure that they are developing in a way and working with the communities and customers that keep them on track to not capture our customers and keep them through lock-in. 

We really want to see—and open-source is a great way to allow this—is to open up the cloud communities and the cloud infrastructures to be able to be what the customers need, not what the companies need. And I think that—focusing on the customer—is going to be, and has been proven to be the growth win. If you can work with your customers, get them what they need, and then also occasionally show them a thing that they didn't know they needed, and that they can jump forward technologically. I go back a lot to the Ford quote of, “If I asked my customers what they wanted, they would have wanted faster horses.” And so I do think that there is a lot of need for big technology companies to be looking at what the sea changes are, what the paradigm shifts are. 

But I think people need to be answering and offering what their customers need, while then also teasing out the future in there. But open-source specifically, lots of great opportunity, lots of great collaboration across the industry, and lots of practice in all of the very large companies that are trying to work in open-source now. Practice to get it right, practice to be helpful and hopeful and harmless in the communities, and help grow them to be the successes that they need to be, independent of any product may need to be built.

Corey: That's, I think, a terrific place to leave it. If people want to hear more about what you have to say, where can they find you?

Sarah: They can find me on Twitter, and I am just @sarahnovotny. I have a webpage but it mostly is for people who want bios and headshots. Mostly Twitter; Twitter's probably the best place to find me. 

Corey: Excellent. We will of course, as always, leave links in the [show notes 00:31:45]. Thank you so much for taking the time to speak with me today. I appreciate it.

Sarah: Yeah, you're most welcome, Corey. It's been fun and it's been fun to meet you for the first time. Clearly, we have to have more nerdy conversations.

Corey: Oh, yes, I'm a treasure and a joy, simultaneously.

Sarah: It's true. It's true, it's true.

Corey: Sarah Novotny, open-source wonk. Azure’s Office of the CTO as well as the member of the boards of directors at the Linux Foundation, Node.js-turned-OpenJS, et cetera, et cetera. And I'm Cloud Economist Corey Quinn. 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 and a comment telling me what I got wrong, written only in ASCII text.

Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com, or wherever fine snark is sold.

This has been a HumblePod production. Stay humble.