Screaming in the Cloud - Building Strong Open Source Communities in the Cloud Era with Tiffany Farriss

Episode Date: November 20, 2019

About Tiffany FarrissTiffany is the CEO and co-owner of Palantir.net. Along with George DeMet, she provides the vision and values for Palantir. She has over 20 years of internet consulting and development experience and extensive experience providing information architecture and usability consulting for a wide variety of clients. Tiffany has a BA in Mathematics from Northwestern University, where she focused on mathematical modeling and human-computer interaction, and was a member of the Drupal Association Board from 2009–2017.Links ReferencedSponsors AWS SolutionsInflux DataTwitter: @farrissLinkedIn URL: www.linkedin.com/in/tiffanyfarrissCompany site: Palantir.net

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. They themselves are free, though occasionally some of the products they stand up are not, but it's a great way to click button, wind up receiving a technical solution that's implemented that ideally solves a problem you have. Visit snark.cloud slash aws solutions. Again, that is snark.cloud slash aws solutions. And my thanks to AWS for their generous sponsorship of this episode. And this episode is sponsored by Influx Data. Influx is most well known for InfluxDB, which is a time series database that you use if you need a time series database.

Think Amazon Timestream, except actually available for sale and has paying customers. To check out what they're doing, both with their SaaS offering as well as their on-premise offerings that you can use yourself because they're open source, visit influxdata.com. My thanks to them for sponsoring this ridiculous podcast. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Tiffany Ferris, the CEO and co-owner of Palantir.net, also known as No, Not That Palantir. Tiffany, thanks for joining me and welcome to the show. Thank you so much for having me, Corey.

Of course. So given that you do work for a company called Palantir, I think we have to first open with the question, I will be torn to pieces if I don't ask, where exactly does your company stand on putting children in cages? We're firmly against putting children in cages. That is a bold political stance in this day and age. So given that you are not the monster that Teal built, what does Palantir.net do? We are a digital consultancy that uses open source tools to help solve our clients' problems. We work primarily with nonprofits, institutional nonprofits like higher education and healthcare, as well as,

you know, state and federal government. It's easy to sit here and say, well, that's sort of a derivative name. Why would you name your company after an existing company that already exists until you realize that your company has been around for 23 years. We're very proud of that. Yes, 23 years. Well, and the name is a throwback, right? So for those Tolkien fans out there, you know, 23 years ago, if you think back, it was all about the information superhighway. And when my founder, George DeMatte, he kind of named the company, he thought, you know, that was a terrible metaphor. And that really really the promise and the potential of both the web and the internet was as a nodal communication device. So thinking about it as more of the network of palantiri that existed in each of the cities of the realm was a much better way to approach it.

Yeah, we've turned it to something of a dystopian future where it has much more ominous overtones than it did. I don't think looking back to the late 90s that any of us saw the Internet and culture surrounding it evolving the way that it has. It never occurred to me that it would be a commonplace day-to-day thing that everyone knew about and that it would have dramatic social implications. I think if you go back and read some Neil Stevenson, I think there were some people who really did anticipate it. You know, I think Snow Crash kind of got some hints of it. And even Ender's Game had a lot of overtones of the kind of discourse and disinformation potential in the Internet. So I think there were people, there were harbingers out there, but I certainly didn't see it coming like this. So on a happier note, on a happier stories,

I suppose, let's talk a little bit about things that are, I guess, more cloud adjacent than talking directly about the cloud itself. Something you've been interested in for a while and talking about in different fora have been sort of the issues that cloud has created for open source, especially recently with some of the moves Amazon and others have made. And the open source ecosystem goes back far beyond cloud was ever a thing. And watching the evolution of that ecosystem has been fascinating from both the inside and the outside. Where do you stand on it? I think it has been such an amazing journey, right? I think that the cloud has opened up a lot of opportunities for open source. But at its very core, the new public license, the GPL, is fundamentally a distribution license. And I think that the cloud introduced the possibility of creating software for others, but not distributing it. And I think that the cloud introduced the possibility of creating software for others,

but not distributing it. And I think that we're still wrestling for that soul of open source in that context. What does it mean that you can take open source, create derivative works on it, that you sell to others, and then not have to contribute back to the community, whatever innovations you've added to it. I think that's the interesting challenge of our time. And that's sort of the interesting question that sort of ties all of this together to some extent, is at what point is someone obligated to give back to an open source project? I mean, in an absolutist term, by reading of the license, you're not. There's no requirement that you give back other than if you make changes to the source code,

you're required to make those changes available and republish it for some but not all licenses. But there's never been an obligation of, oh, if you take this and turn it into a product, then you're obligated to buy a different tier of licensing. Or the new licenses that do speak to that are definitionally not open source as determined by the OSI. Correct. Yes. You know, I think that there are several different levels of obligation. You have your ethical obligation. You then have a self-interested obligation. And I'm far more interested

in talking about the self-interest side. I'm a bigger believer in carrots than sticks. And I think when we start going down the ethical path, it tends to feel like you're bashing people. And I've had the best success in trying to align the interests of the open source communities that we work with at large with the interests of the ecosystem that relies on them and really making sure that there's sharp relief about the alignment between what the business interests are and what the community's interests are. And I think we've done a fairly good job of that in Drupal so far, but I think all communities are somewhat vulnerable to this. And the sooner that open source communities take seriously how they influence their own economies, essentially, I think the better off we're going to be.

And you talk about self-interest from a perspective of doing what's effectively what is best for a company. So the question naturally arises, if I'm an Amazon or another large cloud provider, how is contributing back to open source in my self-interest in a direct sense? I think for those hosting providers that choose to offer as part of their suite open source products, either there's two different levels, right?

There's the open source on which their cloud platforms are built, and then there are the services that they may provide as kind of turnkey services or self-start services. And I think those are two different sets of incentives and alignments that are possible. For those companies that have built their product, their cloud product on open source, I think it's a little bit harder to be able to find the incentive because you do have

the question of competitive advantage in that way. And I think it falls to each of the providers to be able to decide how much of that bespoke software do they want to carry? It's a question of technical debt. It's a question of what advantages you gain by giving that back to the community versus your assessment of what potential harms you may have if your direct competitors were to also enjoy those advantages. And a lot of that comes down to the culture of the open source project as well and how they enforce the norms and what that particular project sees as its bar for participation and first class citizenship. Then you have the case of the cloud providers that provide kind of self-service where they make it so that you can install WordPress or install Drupal in a very easy way.

And I think we've seen perhaps better traction, at least in the communities that I'm closest to, with those cloud hosting providers in making a lot of the contributions that they make back to the community. And so I think that becomes a little bit easier because it's not about the product itself. It's really more adjacent. And the better a cloud provider's reputation in certain communities, the more likely they are to win business. So that's what I mean when I talk about the communities need to think carefully and they need to be quite thoughtful about what level of influence they have over the economies within their own communities

and what are the incentives that they have to offer and what are the benefits that all of the companies in the ecosystem could realize and really find those pockets of the win-win. One of the things that I think that hasn't really been discussed much, and I'd like to maybe go into that a bit with you now, is one of the, I guess, powerful aspects of cloud

has been that it's been lowering the barrier to entry. And that's a challenge that not just computing, but also the open source movement have been struggling with for a long time. What's the easiest way to get someone on board? In my own case, I'm a terrible developer, as you can tell by looking at any code I've ever put on GitHub for anything. So my involvement was, for the better part of a decade, I was network staff on Freenode, helping to provide a sense of fostering community in an IRC world.

But even then, getting someone onto IRC in the first place was challenging and difficult and finicky and required a certain level of technical know-how that until you figured that out, you weren't in a position to ask for further help. So a similar example that I think you mentioned to me at one point was eternal September, back on the Usenet days, where every year when September hit, Usenet,

an old school, I guess, message board, for lack of a better term, roll with me on that one, would get a whole bunch of new users coming in as they went to university and had access to this in a way that you didn't when you were a home user. So it took time over the course of September into October for the newcomers to understand the netiquette, for lack of a better term, the way you behave, the way you comport yourself. And then one year AOL hooked up all of their users onto Usenet, and that was known as the start of eternal September. Have I gotten the story mostly right? Yes, you have so the interesting thing there there's still people that are claiming that today for example as we record it we think of

this as october 23rd 2019 but in the through the lens of eternal september it is now september 9 549th 1993 because this is the september that never ends painful getting on exactly and that was an example of the internet culture having to adjust having to adapt to a new normal suddenly people who would never have had access to these things did and indelibly change the culture and that's viewed as a sort of condescending way of approaching it but cloud has done the same thing too once upon a time in order to spin up a company or any random idea, you'd need to spend hundreds or thousands of dollars on co-located equipment, on getting a whole bunch of things bolted together. And now it's an API call or a button click away. The barriers to entry have dramatically been lowered

in terms of cloud as well. Do you think that there's, I guess, an alignment or that there's been a, even a direct relationship between that barrier, that barrier lowering in open source as well? Absolutely. I think that's what we experience in our open source communities all the time. If you think back about how the Drupal Association was created, you know, Dries Beiter had founded the Drupal project from his dorm room in Belgium and was hosting it and open sourced it, and other people started to use it. And then at some point, the servers melted down, and so he put out a call for help.

And so they needed to buy more actual physical servers. So donations poured in from everywhere. He ends up with tens of thousands of dollars for the purposes of supporting this open source project, this little nascent open source project. He needs somewhere to put it so that he doesn't end up getting all the taxes himself on it. So he creates the Drupal Association.

And over the years, the Drupal Association was tasked with really supporting the Drupal community primarily through the maintenance of Drupal.org. We had physical actual servers that hosted Drupal, that hosted the SVN code repository that we used. And even that started to create, I think, a barrier for people to participate in it. You had to learn SPN.

It wasn't as accessible. You had to be able to run your own local environments. You had to be able to set those up. And as we have enjoyed the benefit of all of the cloud providers, you could spin up a Drupal site with a cloud provider really through clicking buttons now. So it's very, very different from the days of IRC and SBN. We have GitHub.

We have Slack. And so there are people who can really stumble quite into the Drupal Slack. And again, they don't know really what's expected of them. And I love that term netiquette, but I think as we look more broadly at open source, it's really a question of citizenship. It's a question of, you know, what is expected of me? What can I expect from you? And what can we expect collectively from this environment that we're in?

And so I think that's one of the places where we have this opportunity now to look back at something like, you know, Eternal September, where, you know, how did Usenet respond to that? Well, I mean, in my experience, and again, I'm kind of revealing my age at this point, but, you know, there were a lot more community managers, community moderators who kind of got involved and for better and for worse at different times. And it started to create, the expectations started to shift based on what they could do and how they could extend it. And I think that that's what we need to reckon with in open source as well, is that the barriers to using open source have dropped significantly. And we have an opportunity to think differently about how we might impact the barriers to contributing back to open source. All of these cloud services make it easier in some ways to contribute. But we need to create those incentives. We need to create those expectations. We need to create the mechanisms by which people who are newer

and who maybe are not indoctrinated in the culture, who maybe got there because the open source product is the best product, not necessarily because it's the best open source product, which I think is quite honestly a victory for open source. But we have to recognize that these folks need to be successfully onboarded, not just into adoption, but through adoption into the contribution journey, moving them along the engagement ladder within open source to really embed the sustainability that we need. I frequently said that multi-cloud is a stupid best practice. And I stand by that. However, if your customers are in multiple clouds and you're a platform,

you probably want to be where your customers are unless you enjoy turning down money. An example of that is Influx Data. Influx Data are the manufacturers of InfluxDB, a time series database that you'll use if you need a time series database. Check them out at influxdb.com. I think that there's also been a shift in many open source projects, or at least as I like to think of them, the successful ones, where you take a look at the projects that have thrived

and the projects that have not. Largely, there's going to be a difference as far as how easy it is for someone who's new to it to get, is it for them to get started. One of the, one of the things that started my entire like rampage on this was Jordan Sissel, the guy who wrote Logstash now works over at Elastic. I saw a conference talk that he gave very early on in my speaking career. And one of the comments he made was that if a new user has a bad time, it's a bug. And every successful project that I'm engaged with these days is following right along in its footsteps. I mean, I wouldn't consider it code, but I have a bit of an open source project these days. I'm the community lead for the Open Guide to AWS.

It's a giant markdown document that lives in a GitHub repository. That's the 10,000 tips and tricks that you or I would trade with one another over drinks, be that be it coffee or tea or whatnot, where one of us is getting started with AWS and the other was giving insight and guidance into how it works. And now it has over 25,000 stars on GitHub. So you know it's good. 185 contributors. There's a Slack team tied to it now with 9,000 people in it. It's the largest Slack team that I'm aware of for the AWS universe. But notice that it is a Slack team. It's not a channel on Freenode because the world has moved on

because IRC was never friendly and welcoming. We've now gone to this balkanized environment, which, by the way, I think that Slack is terrible for this because it does not offer anything approaching full-text history, any sort of controls or whatnot for open-source projects. I would love to pay them,

but the last time I did the numbers on active users, it would cost me over $60,000 a year. I'll pay hundreds, but not thousands for that. And that's something where I think we're losing something from the old school open source mentality and methodology.

But as a counterpoint, if we had an IRC channel instead, we wouldn't have 9,000 people in there. We'd have maybe 90. Right. That's right. I think that this is another case where open source is a victim of its own success. As we make the tools easier to use, we really struggle and find the edges of what is sustainable by the old models. We need to align the interests of all parties involved, the open source communities themselves, the users, the contributors, the companies

that build successful businesses on and around open source, we need to make it really easy to get these on-ramps to connect the time, the talent, and the treasure to the areas of greatest need. Right now, I think we often settle in the places of the least friction. And there's nothing wrong with that. That's not a judgment statement.

Slack is a place of low friction. But as you know, there are limitations to it. It's not going to be sustainable for an open source community to invest in a commercial license to be able to have the full text history of it. And so we lose things all the time by not rolling our own. But I think the flip side of it is that all of these tools have accelerated that adoption and accelerated the community's ability to really focus in on what it is they do best. So in some ways it's helped us all get off the island a little bit.

But I think that there are some strategies. There are certainly some tactics that open source communities need to be thinking about right now, about how to meet the needs of not only where they are now, but where they'll be in three, five, ten years, particularly with respect to succession planning. Yes. And that's something that I think people don't take seriously enough.

We take a look at tech and how rapidly it moves. So things you'd have to generally care about in other ecosystems and other spaces is how do you build something that outlives me? Whereas the idea of me writing code today that someone is still using five years from now is horrifying. And my lifetime

planning extends beyond a five-year time horizon. Ergo, I will always be around as long as this code needs to be maintained. So I don't really need to worry about who's going to take it over once I'm dead and gone. That isn't really accurate or fair anymore, but that's the mentality people are approaching this with. This benevolent dictator for life nonsense that we see in some projects suffers from exactly this failure mode. Yeah, and I think, you know, coming from the Drupal community,

I am still a defender of the BDFL, but the benevolent dictator for life. And what I think that in our case, in the Drupal community's case, Dries has done really well is he started to build a team of people around him and to start to distribute decision making, right? I mean, this is really where open source projects move from just doing Agile to starting to be Agile. And I think that's the next place where we're going to start to see improvements and even at scale, even at the scale

of a project like Drupal. But I also think that this succession planning is threatened in some ways by the impermanence of the cloud. It's both freeing because you don't have to worry about maintaining project issue queues like Drupal does. That is certainly a huge expense. It's been a superpower of Drupal's for a while, the way that they manage their issue queues and the way they manage contribution, I think really allowed our project to be very,

very successful five years ago. But at the same time, maintaining that, the level of technical debt that we also have to support just around the periphery of our project is a significant drain on resources or a significant use of our resources. That said, moving the hosting of Drupal.org into the cloud away from the servers has been a good thing. But I do worry about the ancillary services that we use, like Slack, because it is so impermanent by design that we lose that kind of institutional knowledge, which was always, I think, a bit tenuous anyway in open source.

Those who were there remember, and they have a bit of a long memory, but it used to be able to be passed down from person to person. The culture of open source was really a very personal one. And I think that the cloud has enabled open source to scale so fast and projects to blow up so quickly that that culture doesn't necessarily have a chance

to catch hold and spread in the way that it used to. So we need to adapt the ways that we do this, and it's going to involve some change management, some new thinking around, you know, what it means to operate at this kind of scale, even beyond the questions that arise, because you have the distribution and the licensing questions. I think there are just even bigger questions posed by the cloud in terms of, you know, how are you onboarding people? What is your obligation to someone who hasn't built the karma yet in your community? And that was part of the challenge I had with a number of open source communities.

Every project seemed to have a slightly different vibe to it. But there were several that, well, I'll name it. Debian was a good one back in the day where I would ask a question and the answer was that I should shut my full mouth and read the freaking documentation before asking any further stupid questions and educate myself first. The lesson I took from this was don't use Debian. Instead, go in any other direction here. And again, not to steer this into the weeds necessarily, but that's the experience that I had. I found it incredibly off-putting. And I am a cishet white dude in tech.

The entire open source ecosystem feels like, and along with the rest of society, was built to cater to my precise demographic, obviously, because we're better than everyone else. Please. The point is, if I found this off-putting, I cannot imagine what it would be like for someone who didn't look and sound like me. And that was terrifying and horrifying,

and it was not in any way, shape, or form inclusive. And that is where so many open-source communities have fallen. Others have stepped up and absolutely thrived as they wind up instituting a don't be an asshole policy. I think it's absolutely key to make sure for the success of open source, both as a culture and a community, but also as a product and a project, you know, to be able to invite more people in. We need it for adoption, but we also need it for innovation. I mean, the research is incredibly clear that diverse teams create the most successful projects and products. But then it does create this question, right? Open source really did start as a monoculture and your experience is not uncommon. You were part of the dominant culture, and yet it still could be, you know, a very, it could be a very hostile place, right? And I think that the projects that ended up being more successful from an inclusion perspective are the ones that, at least initially,

in my experience, they were by accident. I mean, I think that there were women and people of color who got involved with those communities and either because the people that they interacted with were very welcoming, as in the case of Drupal, you have WebChick, Angie Byron, who was just out there welcoming everyone for whoever they were and wasn't shy about who she was and what she brought to the table very, very early on in Drupal, that representation mattered. And so when you started to get pockets of people who felt welcome, who felt landed in a community, it continued to spread. And that's what we see.

We see that in companies, but we also see that in open source as well. I think what I've always found really interesting is this notion that in a lot of the projects that are online only, as opposed to those that have an IRL component, whether it's through meetups or through conferences, you do see the opportunity for those who have non-gendered handles to be successful. And I think that that was very interesting. That was very freeing to some folks. And as that became accepted, I think those are the communities that we saw who embraced that diversity as one of their core values.

But it takes a tremendous amount of work to do the community management as you shift from this originally kind of, as you noted, white male cis monoculture where, yeah, there was some diversion but everybody was fundamentally the same and you kind of had a baseline assumption of what the norms were going to be

and how you were going to be treated over to a truly multicultural environment. And if we look at how this has been handled most maturely so far, you look to corporate America, right? And so what you find is that most of them move from a monoculture to a multicultural through a compliance phase, right? And this is where I see a lot of

open source projects right now. They are, with varying degrees of success, struggling with what community governance actually means and the ways in which that governance should be structured, should be supported, and as well as tasked with accommodating, supporting, and encouraging diversity, equity, and inclusion. But that phase is really essential. And I think the more that open source projects can lean on each other, not only for experience, but also for literal support. I would love to see communities get together and serve on each other's appeal boards for their community working groups or whatever the analog is in their community. Because there's a lot of expertise that is being built. And there are a lot of successful experiments going on in different projects that could really catch on if they were amplified.

And so there's a lot of opportunity for knowledge sharing. There's a lot of opportunity for literal bodies and experience to be shared between the open source projects as we all navigate through this kind of compliance phase where the leadership has bought in that, you know, it is important that we make this an inclusive and welcoming space, but you may have little microcultures within your community that aren't yet there or are afraid about what that means or afraid that they might inadvertently say something wrong. And so I think the more we are able to provide community governance structures to support that, the better it's able to provide community governance structures to support that, the better it's going to be, right? I mean, I think it's really a question around helping communities understand that mistakes are going to happen, but that all mistakes are recoverable if you approach

it with honesty and openness. So creating that kind of a structure, particularly at scale, is daunting. And it's a place where I see a certain economy of scale for the projects if they start to work together. Even if you take a step back for a second and go back to a pure self-interested perspective, assume that even back in the days when you had someone showing up and your first insult when they asked a dumb question was to insult them. What, that's going into a pure self-interest, what is the shortest path to get effectively that person who knows nothing and contributes nothing into someone who is actively contributing to the code base, to the environment, to the community? And if you drive people off, the short answer is they won't.

They're going to go find somewhere else to be. An early formative experience for me was I was, I think, developer number 15 behind SaltStack. And I am about as good at Python as you probably would suspect I am from this conversation. But they merged every pull request that I put in. Sure, 10 minutes later, there was another pull request from one of the founders of the project,

immediately fixing all the things I'd just broken. And they reached out and talked to me about this, but it was such a welcoming environment that, oh my God, I can do this. And I couldn't do it, but I thought that I could. And over time, I became able to do it because I wasn't driven off for not being good enough yet. From that perspective alone, I became a champion of the project. I would talk about it to people constantly. And thankfully for

everyone involved, I stopped contributing a lot of code to it. But instead, I started contributing in other ways and being a bit of a cheerleader for it. That's value to a community for an open source project that lives or dies based upon what people think about it. I just don't understand the short-sightedness that goes into driving newcomers away. You know, what you're describing is a learning culture. It's a culture where anyone, regardless of where they are on their journey, is welcome and that it's a mistake-making place, right?

I mean, that's one of the brilliant innovations of the pull request opportunity, you know, this kind the pull request opportunity. This kind of pull request culture, I think, if you look at it from that perspective, you can allow people to both make mistakes and feel like they have this contribution and then show them what that mistake is and show them how you correct it. I think it makes such a difference to people. And I think it's crucial, especially as we acknowledge that unlike maybe 20 years ago or 25 years ago when we had a lot of hobbyists and enthusiasts

who were playing around with open source, the folks who are asked to work with open source now are probably doing it for their jobs. And so the environment itself, whereas it used to kind of have this almost extracurricular feel to it, is largely professionalized. And certainly we see this in the third generation of open source projects. They were really born to serve a need,

either because they have a corporate sponsorship or that there is a consortium of companies really backing it and working together to create it and put it out there. And I think that's another key piece to consider, is that the element of choice and agency in working with open source has changed incredibly now and that evolution changes the dynamic around contribution. People will do what they need to do for work and that can be consumption. If you have to use open source because it is the right tool or there was a strategic

decision, great, you're going to do that. But the real question is how are you going to take that person who maybe is required to do it for work and either get them to have contribution policies back from those companies themselves, get some time to contribute patches back, whether they're incremental or more major. Either way, I think a lot of that depends on how folks are treated. Because a company, I can't ask someone on my team to work in a toxic environment. We have a code of conduct that we expect when folks are working at my company. and I can't ask them to go somewhere where they would receive lesser treatment.

So I think that starts to create that pressure because I can ask somebody to use something. Anybody can go to a website and download it, whatever tool it is. Go to GitHub, get the code you need, and then just use it. That's really where the opportunity costs really starts to stack up

when open source communities don't create this kind of welcoming on-ramp to take that person who is doing it professionally because it's a part of their job and really get them indoctrinated and on board with the expectations of the community and to be that evangelist within their own companies for why it matters, how their company will benefit, how the team themselves will benefit from, you know, having more people reviewing their code. You know, that certainly was our experience. Why we went to open source was that, you know, Drupal had more people on the security team than I had in my company. So I knew that my efforts to develop my own CMS were going to be swamped. And if I put those efforts toward Drupal and really helping Drupal succeed in the areas where our own CMS had succeeded, we were all going to be better for it. But I was also going to gain the things that they did much better than we did, whether it was security team review or whatever that was.

So I think acknowledgement of the fact that open source has professionalized and is now a routine part of people's jobs is something I'd like to see more folks talking about and why that matters when we start to look at some of the toxicity that can happen in communities and how that is handled. If it happened within your company, HR would be expected to step in and take care of it. But if your open source community doesn't have the equivalent of a community HR or community working group, you may run into some issues, right, as a result. It really comes down to being inclusive. It leads to better outcomes for everyone on all

sides of the table. I just don't understand how there are people on the other side of this particular issue. I try to approach it from a position of compassion and really what is driving that. And I work from a place of positive intent that it's not about excluding people as much as it is the fear of being excluded. Particularly if you've been part of the dominant in-group for a long time, it's important to you. Open source is incredibly important to folks who've been involved in the community for a long time or certainly some newcomers who just find their place and feel like they belong. And I think if you've ever had a place where you belong and you are going through what you feel is an existential threat where

by including people who don't look like you, that you feel like your place is at risk, I can understand why you'd get concerned. I also think that it's incumbent on those who are working on DEI, diversity, equity, and inclusion initiatives to help folks who have, you know, that there is such a systemic and institutional conditioning that we are all subject to, that everyone, everyone is going to make a mistake. Everyone is going to, at some point, you know, just be transgressive unintentionally, right? And accepting that position, like, you know what? I might say something sexist or I might say something racist,

but what matters is how I recover from that and how I make it right. And modeling that in your community, that it's not about perfection. It's not about everybody coming from the same point of view. In fact, that would's not about perfection. It's not about, you know, it's not about everybody coming from the same point of view. In fact, that would undermine it, right? If you only had folks who shared, you know, my way of thinking or my ideology, it's not about that at all. But it is about making sure that it is a safe place, that our open source communities are places where I can come and I can be curious about what those around

me have to contribute. And they will be generous about sharing their knowledge with me. And likewise, I will be generous about sharing what I bring to the table for them. That's how we create an environment of safety, right, for everybody. And there's never been a perfect place and there has never been a perfect person. There's not a person among us who has not made a mistake in dealing with anybody. And so I think that the more we talk about that and the more we create systems that help call people in when their behavior isn't meeting the accepted norms, if they're not understanding how we do it here, give them that opportunity to reflect on it, give them a space to be able to process it, give them a space to be able to change if they want to.

If they don't want to, then yeah, okay, you can choose to leave, but it is fundamentally your choice. It's not about having to be perfect to stay. It's about understanding and buying into the norms that my presence here can't make someone else's presence invalidated or erased or just unwelcome. I think that's something that needs to be internalized by people a lot more than it currently is. I want to thank you for taking the time to speak with me today. If people want to find more about what you have to say and your thoughts on these and other matters, where can they find you? I'm on Twitter at at Ferris, F-A-R-R-I-S-S.

You can also see things that I blog about and usually come through the at Palantir handle, P-A-L-A-N-T-I-R. Yes, official motto, no, not that one. That's right. This is not the Palantir you were looking for. Indeed. Thank you so much for your time.

I appreciate it. Thank you so much, Corey. I enjoyed it. Tiffany Ferris, CEO and co-owner of Palantir.net. I'm Corey Quinn. This is Screaming in the Cloud. If you've enjoyed this episode, please leave us a five-star review on iTunes. If you've hated this episode, please leave us a five-star review on iTunes. at screaminginthecloud.com or wherever Fine Snark is sold. This has been a HumblePod production. Stay humble.