Skip to main content

📣 Submit your proposal: OpenSSF Community Day Korea

Tag

Podcast

What’s in the SOSS? Podcast #23 – Kusari’s Michael Lieberman Talks GUAC, SLSA and Securing the Open Source Supply Chain

By Podcast

Summary

CRob is joined by Michael Lieberman, CTO and co-founder of Kusari, about the importance of supply chain security in the open source ecosystem. They discuss Michael’s journey in open source, his contributions to projects like SLSA and GUAC and the future of supply chain security.

Conversation Highlights

  • 01:56 – Michael explains how he got into open source
  • 04:10 – The challenges of being a startup within the open source ecosystem
  • 05:38 – Michael digs into his participation with SLSA and GUAC
  • 09:13 – How maintainers can address SBOMs with GUAC
  • 10:56 – Michael’s predictions for supply chain security and dependency management
  • 14:26 – Michael answers CRob’s rapid-fire questions
  • 15:32 – Advice for those entering the cybersecurity or open source development spaces
  • 17:50 – Michael’s call to action

Transcript

Michael Lieberman soundbite (00:01)
I think for the downstream consumers, it’s one thing to do the security. It’s another thing to have folks who are consuming the software know, yes, I feel confident that they’re actually doing the right things because I’m getting signed in an atttested documentation that I can tie back to the maintainers.

CRob (00:18)
Hello, everybody. I’m CRob. I do security stuff on the internet, amongst other things, and I also am a community member and chief security architect for the Open Source Security Foundation. And one of the amazing things I get to do is host “What’s in the SOSS?” podcast, where I talk to interesting people, whether they’re developers or leaders, policy people in and around the open source software ecosystem.

And today we have a pretty cool treat, my friend Michael Lieberman from Kusari. I’ve had the chance to work with Michael for a couple of years within the OpenSSF, and we’re going to talk today about supply chain security and other topics. But before we do that, Michael, why don’t you introduce yourself to the audience?

Michael Lieberman (01:07)
Sure. Yeah. So I’m Michael Lieberman, and I’m CTO and co-founder of a startup called Kusari, focused in supply chain security, but also very much focused in building and using open source.

And in addition to that, I also wear multiple hats in the community as a CNCF TAG security lead, which is the technical advisory group for security for the CNCF as the name sort of suggests.

And then in addition to that in the OpenSSF, I’m a maintainer of some projects like GUAC and SLSA. And in addition to that, I’m also a TAC member and a governing board member.

CRob (01:47)
Now that we’ve got the today story for Michael told, could you maybe share with us, what’s your open source origin story?

Michael Lieberman (01:56)
Sure, so I’ve been using open source obviously, like, since college, you maybe even before that, actually, I remember learning my first programming language, was a very early version of Python. And you know, that was kind of my first introduction, I think, to open source. But as far as, like, my career is gone, using open source for a really long time, occasionally opening up an issue on whether it was prior to GitHub, you know, into some mailing list or that sort of thing.

More recently, when I was…got into the banking world, I was working at a big hedge fund called Bridgewater for a while where we were doing a lot in open source, but we were starting to become more open and contributing back, especially given that we were so security focused. We wanted to make sure that certain things we had seen would get addressed upstream.

And so that involved a lot of stuff on that end. And then as time sort of progressed, would say around the time of the pandemic started getting a lot more involved in, in open source, where I first was a regular member of the financial services end user working group, which is part of the CNCF or at least for the CNCF, I should say. And then eventually I became one of the chairs of that.

Folks in that group are very interested in security. And that’s how I got introduced to TAG Security, where I started working on the Supply Chain Integrity white paper that they had sort of best practices paper, I should say, that they wrote up and I contributed to. And then eventually the Secure Software Factory Reference Architecture, which I helped lead. But as part of this whole thing, there was a relatively new group called the OpenSSF, or Open Source Security Foundation.

And that’s kind of…how I got introduced there, because obviously CNCF, TAGv Security, security, that’s very much focused purely on cloud native, but then you had OpenSSF, which was focused more broadly just on open source security, and that’s kind of how I got introduced there.

CRob (03:54)
That’s pretty cool. And you’re unique in regards to some of our other guests in that you are leader of a startup. Can you maybe describe a little bit for the audience, what’s it like being a startup within this amazing open source ecosystem?

Michael Lieberman (04:10)
It can be very challenging to kind of get some signal above the noise, especially when you don’t have like…when I worked at the big banks, it was very easy to say, “Hey, I work at Big Bank X, you should listen to me,” compared to when you work at a startup and you’re like, “Well, I’m a founder of a startup. You should listen to me.” But I think the thing there is you sort of live and die by your contributions.

So when folks see that you are a good contributor to the community, that you are coming in with your expertise, but also trying to understand other things, and also just trying to do the chopping wood sort of work. It’s not just about, yes, I’ve worked on that for years and this is how it should be done. It should be also, hey, this is how it should be done. And let me show you, let me sit down and actually write down some of the documentation or let me work on a tool or open up a PR to show you how that sort of thing would work.

So it’s a little bit of everything and I will say it’s kind of hard to not get drowned out sometimes by just how much is going on. But with that said, I will say if you put in the time and effort, it can be very rewarding.

CRob (05:18)
But let’s talk about some of your contributions that I know you still, in addition to running your company and being involved in all these different organizations, you’re an active developer and participant in a couple of our biggest initiatives within the foundation, SLSA and GUAC. Could you maybe talk a little bit about SLSA first, and then let’s dive into dependencies with GUAC.

Michael Lieberman (05:38)
Sure. So my introduction to SLSA was kind of a funny one where I saw an article about this new set of practices that had been contributed to the OpenSSF by Google. And I immediately asked the question of like, what’s going on here? What is this thing? And everybody else said, “We just released it today. Like, give us a second!” But I got involved very early on because it seemed like, wow, this is actually hitting something that was not being hit prior, right?

A lot of other best practices that are out there were hitting like how to secure a thing, but not how do you prove that the data that says you are securing the thing is actually accurate? That’s really what SLSA is hitting, especially in the build process right now. So I got involved very, very early on. I became part of the steering committee.

And then as sort of things evolved, I became sort of an actual maintainer of the spec itself, where I contribute both to the content of the spec, as well as reviewing stuff and making sure that things line up with other pieces of the spec. So that’s kind of how I got involved with SLSA.

And then as part of some of that work, right, that was back when I was still working at the banks. And as I kind of continued on, it was very clear that when we look at software bill of materials or SBOMs and a lot of this other data like SLSA that’s like the information that’s coming out of SLSA there is not a lot to make sense of it. And what things do make sense of it often look at each of those things as a in a vacuum? So it looks at a SLSA attestation in a vacuum or an SBOM in a vacuum and so there was something that was missing there.

And after myself and my co-founders decided to create a startup, we quickly realized that maybe we should start working on a tool to start addressing stuff in that space. And a few of the other folks in the space — like Professor Santiago Torres from Purdue University, as well as some folks from Google, like Brandon Lum and Mihai, who also is a big contributor in OpenSSF — we all sort of kind of came together and we realized like, oh, we all want to build this thing.

And so why, given that we were all working together in some capacity in the open source already, we said, as opposed to all of us creating different tools and yada, yada, why don’t we all come together and build something? And so that’s kind of was the genesis of GUAC and GUAC became this tool and it’s now part of the OpenSSF. At the time, we had sort of created it outside of the OpenSSF, but once it kind of reached that critical mass, we decided to contribute it to the OpenSSF.

And for folks who are not super familiar, it’s essentially a way to analyze lots of SBOMs, lots of SLSA attestations, other supply chain metadata, enrich it with information like vulnerability data from open source databases like OSV, or to figure out license risk information from APIs like Clearly Defined, and all sorts of other stuff. And so it’s trying to help answer the questions of what is in your supply chain? What should you be worried about? Where’s the next Log4j? Where does that live? And what does it impact? Is it impacting one of my applications or all of my applications? So it’s really a graph of understanding everything that’s in your software.

CRob (09:03)
So this sounds really valuable to downstream consumers. How would like an open source maintainer or developer leverage an SBOM or GUAC? Would that be useful to them?

Michael Lieberman (09:13)
Sure, yeah. So it depends. So the way that we currently have it set up, and it’s evolving, is

GUAC right now has a good answer for when you have lots of SBOM. So for the end stream consumer, but also in addition to that, we’re having conversations, for example, with the Kubernetes ecosystem and some other ecosystems that their project actually consists of lots and lots of lots of different pieces.

And for them, one SBOM is not enough because they have hundreds potentially of sub-projects that they need to keep track of. And some of the questions they ask are, did I update this logging library in one Go project or did I update in all of them? And do I have a situation where this sub-project is using a completely different framework than this other one and that’s introducing just general risks to the project.

So that’s kind of where some maintainers are kind of coming at it from as well. But there are plans actually as of recently, we had some discussions to actually start working on some additional tools and integrating with additional tools like Protobom, like bomctl, that are also OpenSSF projects to also help answer the question of what happens when I have one or five SBOMs as opposed to when I have 500 or 5,000 SBOMs. And there’s a big gap right now between I have one and I have 5,000 and we’re looking to try and help bridge that gap with some of the upcoming work in the new year.

CRob (10:44)
Very nice. Speaking of upcoming work, you’ve been in this space for a while. What do you see coming down the road in the next few years around supply chain security or dependency management?

Michael Lieberman (10:56)
Sure. What I see is a lot more of the open source distributors, so like your Pi PI, your Maven Central’s, integrating a lot more of this stuff like SBOMs and SLSA into the ecosystem and I know a lot of them are already in the works for doing this. But I think for the downstream consumers, right, but it’s one thing to do the security, it’s another thing to have folks who are consuming the software know, yes, I feel confident that they were that they’re actually doing the right things because I’m getting signed in attested documentation that I can tie back to the maintainers and You know unless the maintainers are completely lying to me, in which case, well, now they can’t be trusted and yada, yada, there’s potentially public repercussions or whatever for those individuals, like there’s clearly incentive to do this.

And so what I see is finally folks looking at not just how to produce all of this stuff, but how to consume it to answer questions and address risk, which then I think will introduce what is really needed right now, which is a feedback loop of people are producing SBOMs, some of them are gonna be more accurate than others. But I think through analysis tools, whether it is GUAC or any other thing that’s out there, right, Like there’s OSV scanner and there’s a bunch of other, things, we’ll start to see that folks will find gaps in those SBOMs, in those SLSA statements, in the supply chain metadata and realize that it needs to be updated. That data will be updated or enriched and will be generating better SLSA and SBOMs in the future. That’s, I think, one big thing.

The second big thing I think we’ll see, which is maybe, maybe a bit more, I don’t want to sound myopic or anything like that, but I do think especially in the AI space in the next, whether it’s next year or the next couple of years, we will see something akin to a Log4j in that space where a lot of folks will be relying maybe either on a data set that everybody thought was good, but it turns out it’s been polluted in some way, poisoned in some way. Or a model itself that a lot of things rely on that has some critical vulnerability, whether it’s purposefully injected with some sort of malicious behavior, or if it’s just, hey, we realize that the way we train this led it to be potentially exploited in a particular way to get it to make certain decisions that we don’t want to allow.

I think we’ll see that in the future because it’s hard enough to track dependencies and understand your supply chain when you’re talking about software and software consists of code. But when you’re talking about AI models that are trained on terabytes or more of data here, it can be very difficult to know like, where does that needle live of this thing has somehow polluted the overall model?

CRob (14:02)
That’s really interesting food for thought. We’ll keep an eye on that as we go into the future.

But let’s move on to the rapid fire part of our talk. So I got a couple quick and easy questions. I just want the first thought that comes into your head. First question, mild or spicy food?

Michael Lieberman (14:26)
Spicy.

CRob (14:30)
Nice. I also love me some spicy food. Text editor, Vi or Emacs?

Michael Lieberman (14:38)
Vi, Vi.

CRob (14:41)
(Laughter) All right, well that’s not the most contentious question we’re going to have. But Vi, I also love me some Vi. What’s your favorite adult beverage?

Michael Lieberman (14:51)
Ooh, whiskey.

CRob (14:53)
Whiskey, very good. Very safe answer. Now the most controversial question. Tabs or spaces?

Michael Lieberman (15:01)
(Sighs) Spaces.

CRob (15:06)
Awesome. And then finally, what’s your favorite open source mascot?

Michael Lieberman (15:11)
You know, for as much as I love the goose, I will say I’m a big fan of Tag Security’s TrashPanda raccoon mascot.

CRob (15:20)
Very nice. That’s a good one. So as we close out, do you have any kind of words of advice for someone that’s getting into the cybersecurity or open source development space?

Michael Lieberman (15:32)
Sure, yeah. The advice I always give is just get involved, right? Just get started. And it doesn’t matter where you get started. And to be clear, I was the same way where I’d be scared to, you know, I’d be like, I think I found a bug in a potential piece of software. Should I bother them with this? I could be wrong. It’s like, obviously do your due diligence. Like don’t just come in and immediately start saying, hey, I found this thing.

And obviously, everybody is, everybody’s wrong and I’m right. It’s more like, well, I look through the documentation, I look to see if there was any open issues about a thing, I didn’t see it, I opened up an issue, right? And then when it comes to the open source community generally, or just cybersecurity community in general, just, I think the big thing is ask questions, introduce yourself. Folks wanna help, right? Because even if we were all like, I wanna say like, most of us are pretty nice in the community. You know, yes, we can get a little annoyed at things and yada yada, but most of us are pretty nice.

And what I say is even if we weren’t nice, it’s in our best interest to get help here because it’s…there’s so much stuff that needs to get done. And so just come in, introduce yourself and so on. There’s also like, you know, for folks who are, who think that they need lots of expensive training on a lot of this, you know, you don’t, at least especially when you’re starting.

There is a lot of free stuff out there. There’s, for example, the Linux Foundation has a ton of great free resources, like from a training perspective for cybersecurity. But in addition to that there’s also all sorts of other like, you know, charities as well. Like if you’re somebody who is from an underrepresented group or, or struggles financially that, you know, can help get you a leg up as well.

But, in addition to that, think the big thing is it just keeps going back to introduce yourself to the community because we can help point you in the right direction. There’s a lot of folks who will help mentor and help you out in whatever way you need, whether it’s pointing you in the direction of a great training course or helping mentor directly or even just pointing you to here’s a good book you should read that I think helped me out.

CRob (17:42)
That’s awesome advice. Thank you. And finally, do you have a call to action for our listeners, something you’d like to see them do?

Michael Lieberman (17:50)
Sure. First, I’ll talk a little bit more broadly and then I’ll go more specific. But I think more broadly again, especially for folks who are end users who work at end users, like, you know, your, your big banks, I know having worked at big banks for years and years and years, you can feel disincentivized to participate in the open source community. Push for this because as folks who will be listening to this will are inevitably aware, right, banks are using tons of open source.

A lot of the challenges they have is not being able to contribute back, not being able to work with the community to address issues. Push on your organizations to be more involved while highlighting the actual risks there of if we don’t get involved, this costs us more money because there’s a whole community that’s looking to help and help fix this. And so we need to need to be involved to kind of get our voices heard.

And then in addition to that, just generally, right? Like, be more involved in the open source community, be more involved in the security community, especially if you’re a security engineer, it’s much easier to be involved in open source just from like, hey, I created this really cool tool that has this new feature and this new feature could make us all lots of money. You know, security is not often seen as the thing that makes everybody a ton of money. So it can sometimes be like, yeah, yeah, yeah, yeah, we’ll work on that later. No, no. If you don’t take care of security, could potentially lose a lot of money. You could lose customer data. You could ruin your reputation, the reputation of others and cause serious damage. So more involved in the cybersecurity community is super important.

And then a bit more specific, a bit more self-serving, come join the GUAC community. We’re always looking for more contributors. We’re trying to find more end users, you know, one of our big challenges has been, turns out, you know, a lot of enterprises actually do use GUAC or have been making POCs of GUAC, but a lot of those large enterprises don’t come to the community, for example. And we’ll hear through the grapevine, such and such as using GUAC and they’re running into a bug. It’s like, well, we can’t fix it if we don’t know about it. So, so come join, come participate.

And again, as I mentioned earlier, contributions are not purely, like, I wrote, you know, a thousand lines of code for this new feature. It can just be open up an issue, fix a typo in our documentation. It can be helping write notes in the community meetings, right? Anything is helpful and appreciated.

CRob (20:19)
That’s awesome. Thank you very much, Michael. Appreciate your contributions to the community and thank you for joining us today.

Michael Lieberman (20:26)
Yep! Thank you for having me.

Announcer (20:28)
Like what you’re hearing? Be sure to subscribe to “What’s in the SOSS?” on Spotify, Apple Podcasts, AntennaPod, Pocket Casts, or wherever you get your podcasts. There’s a lot going on with the OpenSSF and many ways to stay on top of it all.

Check out the newsletter for open source news, upcoming events and other happenings. Go to openssf.org slash newsletter to subscribe. Connect with us on LinkedIn for the most up to date OpenSSF news and insight. And be a part of the OpenSSF community at openssf.org slash get involved. Thanks for listening, and we’ll talk to you next time on “What’s in the SOSS?”

What’s in the SOSS? Podcast #22 – Sovereign Tech Agency’s Tara Tarakiyee and Funding Important Open Source Projects

By Podcast

Summary

In this episode, CRob talks to Tara Tarakiyee, FOSS technologist at the Sovereign Tech Agency, which supports the development, improvement and maintenance of open digital infrastructure. The Sovereign Tech Agency’s goal is to sustainably strengthen the open source ecosystem, focusing on security, resilience, technological diversity and the people behind the code.

Conversation Highlights

  • 01:42 – Why the Sovereign Tech Fund became the Sovereign Tech Agency
  • 03:59 – The ways the Sovereign Tech Agency supports open source infrastructure initiatives
  • 04:42 – The four criteria for Sovereign Tech Agency funding: prevalence, relevance, vulnerability and public interest
  • 06:51 – Sovereign Tech Agency success stories
  • 09:09 Plans for the Sovereign Tech Agency in 2025
  • 11:54 – Tara answers CRob’s rapid-fire questions
  • 13:54 – Advice to those entering open source development or security field
  • 14:55 – Tara’s call to action for listeners

Transcript

Tara Tarakiyee soundbite (00:01)
You can actually hear the relief when we’re talking to maintainers about how can we sort of get this kickstarted? How can we get the ball rolling? Hopefully those maintainers can also show the benefits of investing in security, investing in resilience to people that depend on their software and get them to invest in it as well.

CRob (00:17)
Hello everybody, I’m CRob. I do security stuff on the internet. I’m a community leader and I’m also the chief architect within the Open Source Security Foundation. One of the coolest things I get to do as part of this role is to host “What’s in the SOSS?” podcast, where I talk to interesting people, maintainers, leaders and folks involved with upstream open source security and open source supply chain security.

Today, we have a real treat. We have Tara from the Sovereign Tech Agency, and they are here to talk about the amazing work within the upstream community for the last several years. So maybe could you introduce yourself and explain a little bit about the organization you’re working with?

Tara Tarakiyee (01:00)
Thank you. I work with the Sovereign Tech Agency. We are a GC that’s funded by the German government, specifically through the Ministry of Economy and Climate to essentially strengthen the open source ecosystem, which is our mission. And we do that by investing in the components of our open digital infrastructure that are, I’m sure as you know, like maintained by very few people, but relied upon by millions and millions, what we call the roads and bridges of our digital world.

CRob (01:33)
I like that. That’s nice phrasing. As I mentioned, you all went through a little bit of a rebranding recently. Could you maybe talk about the change for us?

Tara Tarakiyee (01:42)
Yeah. So we had the whole concept that was developed by our co-founders, Fiona Krakenbürger and Adriana Groh to provide like an investment fund to support this critical infrastructure. And that was sort of like our first, let’s say, vehicle of support for projects. But essentially, what we’re trying to do is meet the community where they are, providing what they need. And we know that, sure, investments are good, but support for something as complex as our post-request instruction needs to come in different forms and factors.

So since then, we’ve also introduced two other programs, what was called the Bug Resilience Program, which is now called the Sovereign Tech Resilience, as part of the rebrand, and also our Sovereign Tech Fellowship. We provide services. We work with the vendors in this space who have experience with vulnerability management, with reducing technical debt, with doing code reviews and providing audits, and also with setting up and running bug bounty programs. And we provide those vulnerability management services. to open source projects indirectly. So we pay for it, but the services go to the open source project.

And with the fellowships, we are looking for maintainers who are key people in their communities who support several projects that for them, like, it wouldn’t make sense to apply it through something like the Sovereign Tech Fund. Usually what we do with the Sovereign Tech Fund is these service agreements that are sort of like deliverable based.

With the fellowship, we’re providing like a different way of providing support for maintainers through our fellowship where we support maintainers who are key in their communities by providing either with a board contract or with a six-month fellowship, three-month fellowship.

Those are sort of the sort of a bundle of services that we’re providing and under the banner of the Sovereign Tech Agency. We all have the same mission. We’re still doing the same things. It’s just the name, name change was just to reflect that there’s like a big house now where all these different programs live in.

CRob (03:47)
Makes a lot of sense. Could you maybe just share a little about how the agency kind of executes on this mission? How does someone become aware of these programs and how does someone take advantage of them to participate?

Tara Tarakiyee (03:59)
For the fellowship, we issued a call on our website. Currently, the call is closed for this year as we sort of review through the application that came in. For the Sovereign Tech Fund, we are still accepting ongoing applications on our website. So if you go to sovereign dot tech, you will find our website, and there you can navigate to the apply section where you can learn about our criteria, what we look for in critical infrastructure, open source, and from there it will take you to our application platform.

CRob (04:32)
If one of the programs is open, are there any kind of limits on who can qualify to participate? Does it have to be an EU citizen or can it be anywhere from around the world?

Tara Tarakiyee (04:42)
Anyone in the world can apply as long as you’re maintaining open source critical infrastructure. The way we, it’s hard to define something as open source critical infrastructure, you know? So for us, we take four criteria. So we look at sort of the relevance of your open source project. Is it used in different places, in many places, by many people?

We also look at…sorry, that was prevalence…then relevance, is it used in particular sectors that are particularly important? Like it could be not be used by many people, but if it’s using like the energy sector or aviation or something that’s, like, highly critical, then that’s another factor that of balances that out.

And then we look at vulnerability. So, I mean, it’s not a nice question, but like what would happen if your software component would disappear tomorrow? Would like people panic? Like that’s probably a good sign that it’s infrastructure. But also we balanced the question out also by looking at different aspects of like, why is this not receiving funding?

Because I think that’s a fundamental thing for us. Like we exist to support infrastructure because in general, like those are things that are hard to fund. It’s something, it’s a resource that everyone depends upon, but very few people contribute to. And that’s, that’s sort of like our niche. So that’s also something we look at in vulnerability.

And finally, we do an evaluation, like, is this a software that’s in the public interest? So is it being used in applications where it’s generally good for society? So, based on our evaluation of these four criteria and also look at the activities, like is it more maintenance activities or generally like you want to develop new features? Would you occasionally fund or invest in new features? But that’s only when there’s like a strong sort of public interest argument for it and no one else would fund it. In general, we mostly focus on improving the maintainability and security of those critical software components.

CRob (06:35)
Thinking back, you all have been operating, whether it’s the fund or the agency, for a little over two years. And thinking back over that, are there any particularly interesting success stories or where you felt that the fund or the agency made a real difference?

Tara Tarakiyee (06:51)
I mean, it’s generally nice just to hear the feedback from the different projects. It’s hard for me to name, like, one particular example or pick a favorite. In general, think like, when I look back and see like projects where they struggled for a long time to get the people that depend on them interested in security. Even though, like, it’s a critical dependency for, like, many companies and stuff, but nobody wants to fund like a security team.

People would rather fund new features and, which just like sort of exacerbates the problem. Like it just creates more pressure on the maintainer and creates more technical debt and more potential for things to go wrong. You can actually hear the relief when we’re talking to maintainers about, yeah, like we’re interested in your security plans. Like how can you sort of get this kickstarted? How can we get maybe those other people also interested? Cause again, like it’s such a big lift sometimes and with some software that we can’t do it all on our own.

So we try getting the ball rolling and then hopefully those maintainers can also show the benefits of investing in security, investing in resilience to the people that depend on their software and get them to invest in it as well. I’m also very proud of our investments in, for example, Fortran, where it’s a technology that’s still very important. Like people hear about it and think like, remember it like maybe from their university days or reading about it on Wikipedia, but it’s still there. It’s still lots of code written in it.

I think Fortran developers deserve the ammenities that modern day developers have, like a good package manager having the developer tooling. So I was very proud of our investment there because, again, like, also considering the state of the world right now, Fortran is very vital in climate modeling and us understanding the world around us. So it’s a very critical time for investment in such technology.

CRob (08:50)
Excellent. Yeah, the older languages deserve the same love that the newer ones do. I totally agree. Getting out your crystal ball, it’s towards the end of 2024 here. What’s in the future for the Sovereign Tech Agency in your programs for next year? Any big plans or anything you’re very excited about to get to work on next year?

Tara Tarakiyee (09:09)
So for work, we learned a lot from the past two years. So I think now it’s time for us to also start exploring ways of bringing in more people into the field of open source. I think, like, a common concern is looking at open source technology, like, there are very few maintainers and not so many are able to come in. Like there’s a high barrier for entry. So maybe I think looking at ways of opening up the field and getting more people, because I mean, the door is open, but that doesn’t mean that people automatically come in. Like, people need help to be able to get into open source.

And also we work with some very complicated projects because their infrastructure, because they’re written in sometimes like high-performance languages that are harder to get into. So I don’t want to compare, but like it’s not maybe as easy as, like, web development where sometimes the languages are a bit more accessible and there are already like a plethora of resources existing to help people get into them.

So I think just getting more people through the door, getting more, let’s say communities that don’t have access to the resources to become open source developers, helping get to the door, get them to becoming the maintainers of the future, I would say, is, would be something I would be very interested in working on or a problem to tackle.

With open source, it’s important to consider that interoperability needs standards because that’s how you create sort of like a healthy technology ecosystem. Because you don’t want like sort of a monoculture where like one software becomes a dominant thing and then that just creates lots of issues. So you want to have a variety of implementations around the standard to solve a particular problem. That just creates healthier software.

I think exploring how maintainers interact with standards bodies that exist. Also, you have increasing regulation and standardization coming from governments. And finally, I think there are some not official standard bodies, but bodies that help certain technologies communities or programming languages sort of improve their work that the maintainers know about these, but most people don’t. And I think getting more involved in sort of supporting the work that happens there to create better specifications, move technologies forward and get more maintainers involved in the conversations about the technologies that they’re developing at standard bodies will be another area of interest for us.

CRob (11:42)
Very nice. Yeah, that’s an interesting vision. A docket of things that I think we’ll probably be working on together next year. Well, let’s move on to the rapid-fire part of the interview.

(Musical sound effect: Rapid fire, rapid fire!)

All right, I have a couple quick questions. I want you to just answer right off the top of your head. Spicy or mild food?

Tara Tarakiyee: (12:06)
Spicy, but I have a limit.

(Sound effect: Ooh, that’s spicy!)

CRob (12:12)
Excellent. From your perspective, what’s your favorite open source mascot?

Tara Tarakiyee (12:17)
Oh, I mean, have to give it to Penguin, like Linux Penguin.

CRob (12:22)
Tux! Very nice!

Tara Tarakiyee (12:24)
I do sometimes get jealous of the FreeBSD devil, because it’s slightly cooler.

CRob (12:28)
Absolutely! Thinking back on your career with interacting with open source, what was your first open source project you remember using?

Tara Tarakiyee (12:37)
I mean, the first one I actively used knowing it was open source was Firefox. I wa a big part of the Firefox community early on in university. So I think how I got my start into open source advocacy was by organizing. I think, back then we were throwing these Firefox launch parties in Jordan. And from there, I got into Linux.

CRob (13:02)
That’s awesome. Well, thank you for sharing. As we wind down, do you have any advice that you would want to share to either someone entering the open source development or security field or is currently a maintainer?

Tara Tarakiyee (13:15)
I think it’s important for people to start listening more to maintainers. From my experience, like for the past two years working with maintainers, they know what they want, know where the problems are. There are people who really care about all these critical pieces of infrastructure that we depend upon, and they do have a good sense of what the problems are.

It’s just that I think not that many people listen to them that someone who really cares about software development in a way that’s… I compare it a bit to being an artisan where it’s more about the craft of the software and you just want to create the best software ever and sometimes occasionally they create things that are very important and used in many places. Sometimes not accidentally, sometimes intentionally as well and then, yeah, when it gets to that scale.

I think my advice is also don’t be afraid to say you need help. I think many maintainers feel like they need to do it on their own or think that people don’t care about their issues, but there are people out there who care about giving the adequate support to maintainers and creating communities of care for them. Definitely don’t be afraid. My advice for maintainers is don’t be afraid to ask for help and people do care about the work that you do. And my advice for others is please listen to maintainers. They know what they’re doing.

CRob (14:42)
Excellent. That’s excellent advice. Thank you. And finally, do you have a call to action, whether it’s kind of personal, like you just mentioned about for maintainers or contributors, or kind of around the Sovereign Tech Agency?

Tara Tarakiyee (14:55)
We do see the significant need or the significant under supply of what level of resources we need to put into our digital infrastructure. And there’s a huge gap between how many resources we’re putting in right now compared to what’s actually needed to create like a healthy, vibrant system.

Like, we’re still far off at the moment that, and I don’t think that many people realize that. So my call to action would be, let’s take this problem more seriously. Let’s invest like real resources, solving, like, the very real problems. We can’t wait til the next Log4j to happen and then say, oh my God, this could have been avoided.

I’m sort of also…maybe because like I’ve been working, doing this work for like 15 years now, tired of like that cyclical nature of like something big happens, people start caring. And then two years later, things revert back. Yeah, let’s, let’s try to break that cycle a little and put, like, significant investment that’s more long-term into creating maintainable, like sustainable support systems for our open source infrastructure.

CRob (16:00)
Excellent. Thank you. I appreciate you coming in to share your wisdom and your experiences through the Sovereign Tech Agency. I wish you a great day.

Announcer (16:09)
Like what you’re hearing? Be sure to subscribe to “What’s in the SOSS?” on Spotify, Apple Podcasts, AntennaPod, Pocket Casts or wherever you get your podcasts. There’s a lot going on with the OpenSSF and many ways to stay on top of it all. Check out the newsletter for open source news, upcoming events and other happenings. Go to openssf.org slash newsletter to subscribe. Connect with us on LinkedIn for the most up-to-date OpenSSF news and insight and be a part of the OpenSSF community at openssf.org slash get involved. Thanks for listening, and we’ll talk to you next time on What’s in the SOSS?