 Hi, this is your host, Lim Parthian. Welcome to brand new episode of DIY Let's Talk. And today we have with us David Tweet, founder of Rode, David is great to have you on the show. Hey, good, glad to be here. This is the first time you know I'm talking to you on this show. So I would love to know a bit about the company since you're a founder. So talk about what problem you saw that you wanted to solve. Well, Rode is a developer portal and software catalog based on a tool called Backstage. Backstage is an open source project. It actually started inside Spotify back in about 2016. It was used there to help them get through hyper growth and is kind of originates in the platform team there. It's a developer portal. It's how engineers at least do their day-to-day work inside Spotify. And it was open sourced in 2020. I had just quit my previous job in Workday at this time. And it was kind of a fortuitous coming together. Decided to start a developer portal and software catalog company based on Backstage. Really enjoyed and loved the vision that Spotify had laid out for it. And so, yeah, we've been working with Backstage for almost three years at this point. Have a wide number of customers in all sorts of industries like finance, pharma, security. Work with platform teams and engineers every day and love every minute of it. Thanks for sharing this story. Now, can you talk about the importance of having internal developer portals and also once again, most essentially open source project like Backstage as you said is Spotify open sourced it. Yeah, for sure. So, I mean, let me take you back to Workday where I was working before because we solved this problem internally inside Workday. And I was working on the platform team there. I think I joined in 2015 as a software engineer, but I was a product manager for four years there too. So, you know, we had just started a platform. It was based on OpenStack, a virtualization platform. This is a few years ago. And we were slowly growing the number of different components or microservices, let's say that were deployed on this new platform. And so we just launched it and it was growing slowly. We got to about 40 or 50 services at one point. All these different app teams were deploying their software onto our platform. And we kind of stopped and thought, well, hold on a second. You know, what is all this stuff? How do we answer basic questions about the tools or the software that people are deploying onto our platform? And so we did the simple solution. We just got a spreadsheet. We listed all the different pieces of software down one side. We would list out the software, the engineering manager, the product manager, the language it's written in, kind of simple metadata about all of the software that was being deployed in our platform. And we used it for reporting. We used it to run migrations. You know, sometimes we would say, well, all these services have up taken our new API and these other ones haven't and kind of copy pasted around the place and what we were really trying to do was solve the discoverability problem. You know, we just didn't have the ability to answer basic questions about the software that was running in the organization and deployed on our platform. And so we used the spreadsheet for a period to do that. The spreadsheet kind of broke down at a point because it was copy pasted too much and just had stale information. And then we set out to build a software catalog and a developer portal inside Workday for our application developers to use. It was quite a successful project. We used it really for two things. One, improve discoverability, help people answer questions about the software being built in the company and the teams that were building that software. And then secondly, to improve standardization of that software and reduce the time that it takes to get a new piece of software to production for the first time. So, you know, helping Workday deliver more value for its customers at the end of the day. And it was a really great project. And I thought, well, there must be other companies out there who are struggling with the same problem. Surely there's a generalizable solution here. So really two things, discoverability and standardization. That's how I think about the value out of the developer portal and software catalog. Talk about the importance of open source for a role itself. And how are you folks engaged with open source projects? Yeah, so I mean, we are the second largest contributor to backstage after Spotify. Now I will say we're far behind. It's a much bigger company, as you can imagine. We have seven people in the engineering team at this time. But contributing to open source is very important to us. And we do want to have stewardship and bring a sense of love to the open source projects that we use for. We do benefit from them. And so we do feel like it's really important to give back. It's also just really good for the company, right? Because we're widely known in the community, that helps to bring those customers. We're a trusted source in the backstage community. People know that we're experts in the tool. And so they trust us to manage their backstage instances. We're a SaaS platform for backstage, fundamentally. And so it's a source of lead generation for Rode at the end of the day. It's also just much better for our customers. So it's kind of a triple win. So our customers sometimes do want to make modifications or add functionality to backstage for their own use cases. And instead of needing to rely on us to deliver that functionality, they can always just go and contribute it to backstage and it will roll out on Rode shortly after. Once the release cycle has processed. So really, look, it's just the right thing to do. It's better for us. It's better for the backstage and it's better for our customers also. Can you talk about the adoption of backstage across industries? Because sometimes a project starts a company to solve a specific problem. But as an open source project, suddenly you see the use cases are beyond your imagination. What are you seeing there? Yeah, I do think that they fall into that discoverability and standardization bucket kind of broadly across the board. The thing about a developer portal is it needs to connect into so many different tools inside an organization in order to bring its value. And really that's where I think the diversity is in terms of how backstage is being used. There are companies who are having tons of success using it as an API catalog. So people are browsing API specs inside backstage. People are having success doing measuring software maturity and displaying those measurements, storage metrics, numbers of vulnerabilities inside different software projects, et cetera. Like all of this information is raised and backstage is used as the centralized dashboard for reporting around software maturity. That's a big use case that we're seeing a lot. Our customers are very interested in it and we're investing in that area in Rode2. Other companies don't really use the catalog of backstage at all. They are not so interested in having a catalog of software but they use the scaffolder which is a feature of backstage that people can use to automate this creation of new software. And they give that feature to their app teams so that they can use it to create new software which is both faster to get the production but also has the best practices of the organization already built into it due to its templating functions. And that's really where they wanna focus and they get a lot of value from that. So backstage is a tool with a lot of surface area. It can solve a lot of problems. And because of its open source nature, people have kind of tailored it for lots of different use cases. We think that's exciting. It means it can actually fulfill its vision as a developer portal and a single place where people go inside engineering organizations to do their day-to-day work. Can you talk about some of the new additions or new features that you folks added? Yeah, sure. So I mean, I mentioned just a second ago about software maturity metrics. Our customers have over the years gotten to a fairly high level of understanding about the software that's deployed inside their companies and that their teams are building. And really the next question that they come to us with is, well, we know that we have all their software now but how mature is it? How secure is it? How compliant is it? How operable is it in production? And so they come to us with this question and we've obviously tried to help them answer it themselves. So we've built tech insights. It's an add-on that we are selling on top of backstage. It's only available on Rode at the moment and you can use it to measure the maturity of software. So you can create checks, like all production software must have zero critical severity CVEs and that will run against your catalog in an automated fashion and then it will report back to anyone who wants to know the information to highlight software which needs a bit more security love or needs a bit more production readiness love. And then teams like security and teams like the SREs or Ops can dig into this software a little bit more and try to help the teams who are producing that software so that overall across the entire company software is just continuously getting better. If you look at some of the process of culture shifts that are happening, of course, shift is there. And then we had also, you mentioned, sorry, we talked about platform engineering. Of course, the whole chaos engineering is there. We talk as bomb. So the thing is we have to look at it from the holistic perspective. So talk about the role that you folks play and at what stage you folks do it. Yeah, I mean, so we work primarily with the platform team inside organizations. We'll work with anybody from 100 engineers up to multiple thousands of engineers. There is a kind of a sweet spot where if you're a gigantic company like American Airlines, then you can get a team of 16 people working on self hosted backstage and running inside your organization yourself. If you're smaller or not, then Rode is probably the best option for you and will help you speed up your journey much more than you would by yourself. But yeah, there's a lot of diversity in the industries and the teams that we work with inside these companies. Where it's really to think about who's getting the core value. It's all developers inside the organization because they're able to move faster. They're able to answer questions like where's the docs for the geocoding service much more quickly. And everybody gets a little bit more productive when everybody gets produces better software at the end of the day. David, thank you so much for taking time out today. I'll of course talk about Rode and of course the whole evolution of this industry. Thanks for those insights and I would love to chat with you again. Thank you. Thank you very much. Pleasure to be here.