Subscribe
Share
Share
Embed
Since 1996, Tiffany Farriss has been one of the driving forces behind Palantir.net, an open-source powered web design and development firm she co-owns and currently serves as CEO. From 2009 to 2017, she also sat on the Board of Directors of Drupal, a popular open-source content management system. Prior to that, Tiffany held similar advisory roles at AIGA Chicago and Northwestern Student Holdings.
Join Corey and Tiffany as they discuss how to build stronger open source communities; Tolkien, Snow Crash, and Ender’s Game; why companies have several different levels of obligations for giving back to open source projects; why it’s hard for companies that build products on top of open-source tools to be incentivized to give back; the history of Drupal; Usenet and rise of Eternal September; Slack vs. IRC and losing the open-source mentality; succession planning in open source projects; and more.
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Transcript
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 sponsored by AWS Solutions, which is the exact opposite of AWS Problems. AWS Solutions are vetted technical reference implementations that are designed to help you solve common problems and big faster. They themselves are free, though occasionally some of the products they stand up are not. But it's a great way to click a button, wind up receiving a technical solution that's implemented that ideally solves a problem you have. Visit snark.cloud/awssolutions. Again, that is snark.cloud/awssolutions. And my thanks to AWS for their generous sponsorship of this episode.
And this episode is sponsored by InfluxData. Influx is most well known for InfluxDB, which is a time series database 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 offerings 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 Farriss. 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.
Tiffany: Thank you so much for having me, Corey.
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?
Tiffany: We're firmly against putting children in cages.
Corey: That is a bold, political stance in this day and age. So given that you are not the monster that Thiel built, what does Palantir.net do?
Tiffany: 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 state and federal government.
Corey: 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's been around for 23 years.
Tiffany: We're very proud of that. Yes. 23 years. Well, and the name is a throwback, right? So for those Tolkien fans out there, 23 years ago, if you think back, it was all about the information super highway and when my founder, George DeMet kind of named the company, he thought that was a terrible metaphor and that 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.
Corey: Yeah. We've turned into 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.
Tiffany: I think if you go back and read some Neal Stephenson, I think there were some people who really did anticipate it. 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.
Corey: So on a happier note, on a happier story, 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 awhile 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?
Tiffany: I think it has been such an amazing journey. I think that the cloud has opened up a lot of opportunities for open-source. But, at its very core, the GNU 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 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.
Corey: And that's sort of the interesting question that sort of ties all of this together to some extent. 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.
Tiffany: Correct. Yes. 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 that the better off we're going to be.
Corey: And you talk about self-interest from a perspective of doing what's effectively what is best for a company. And 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?
Tiffany: 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 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 participating 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 Word processor, 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 hosting providers, cloud hosting providers, in making a lot of what 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.
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.
Corey: 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 in 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.
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?
Tiffany: Yes, you have.
Corey: So the interesting thing there, there's still is people that are claiming that today, for example as we record it, we think of this as October 23rd, 2019. But through the lens of Eternal September, it is now September 9,549th, 1993, because this is the September that never ends.
Tiffany: Painful thought.
Corey: 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 changed the culture. And that's been 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 item, you'd need to spend hundreds or thousands of dollars on collocated 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 even a direct relationship between that barrier lowering in open-source, as well?
Tiffany: 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, Dries Buytaert had founded the Drupal Project from his dorm room in Belgium and was hosting it and open-sourced it, and 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 and so he creates the Drupal Association.
And over the years, the Drupal associated 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, Subversion, 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 SVN. 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 SVN, right? 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 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 Eternal September where how did Usenet responded? Well, I mean in my experience and again, I'm kind of revealing my age at this point, but 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 expectation 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 successful 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.
Ad: I’ve 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 InfluxData. InfluxData 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.
Corey: 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 is new to it, how easy it is for them to get started. One of the things that started my entire rampage on this was Jordan Cecil. The guy who wrote Logstash Networks 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 via 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 FreeNote 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.
Tiffany: 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, right? 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.
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 around. But I think what 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 then needs of not only where they are now, but where they'll be in three, five, 10 years. Particularly with respect to succession planning.
Corey: 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 out lives 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 any more, 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.
Tiffany: Yeah. And I think coming from the Drupal community, I am still a defender of the BDFL. Benevolent dictator for life. And what I think that in our case and 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 the 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. I mean, that is certainly a huge expense. It's been a super power of Drupal's for awhile, 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 um, 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 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 how are you onboarding people? What is your obligation to someone who hasn't built the karma yet in your community?
Corey: 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 fool 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 ... 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 sounded 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.
Tiffany: 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, 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 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 welcomed, 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 meet ups 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 ... I think 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 multiculture environment. And if we look at how this has been handled most maturely, so far you look to corporate America, right?
And so and what you find is that most of them move from a monoculture to a multiculture 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 have ... 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 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 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 that they start to work together.
Corey: One of the ... 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, out of 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 just broken, and they reached out and talked to me about this. But it was such a welcome 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 shortsightedness that goes into driving newcomers away.
Tiffany: 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 ... 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, right? I think that's a ... 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 asking to play, 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 they are a consortium of companies really backing it and working together to create 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 is 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 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 onboard 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 having more people reviewing their code. That certainly was our experience, why we went to open-source, was that 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, it's 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 to take care of it. If your open-source community doesn't have the equivalent of a community HR or community working group, you may run into some issues as a result.
Corey: 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.
Tiffany: 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 always been there find that sense of belonging and help them understand 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, 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 undermine it if you only had folks who shared the 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 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.
Corey: 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 get your thoughts on these and other matters, where can they find you?
Tiffany: I'm on Twitter at @farriss, F-A-R-R-I-S-S. You can also see things that I blog about and usually come through the @palantir handled. P-A-L-A-N-T-I-R.
Corey: Yes. Official motto, no, not that one.
Tiffany: That's right! This is not the Palantir you were looking for.
Corey: Indeed! Thank you so much for your time. I appreciate it.
Tiffany: Thank you so much Corey. I enjoyed it.
Corey: Tiffany Farriss, 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 start review on iTunes. If you've hated this episode, please leave us a five start review on iTunes.
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.
Announcer: This has been a HumblePod Production. Stay humble.