Growing with open source projects - Josh Thurman from Uffizzi

Josh 0:00
I think we were at the cube con conference in, in Valencia and talking to folks and like we could we could help them out this open source project as like we could do this for cons of open source projects. And it's all just like three problems at once for us. Hi, everyon e.

Jack Bridger 0:17
You're listening to scaling dev tools, the show that investigates how dev tools go from zero to one. I'm joined today by Josh Thurman, who is the founder of Uffizi, which is a preview environment for pull requests company. And I'm really excited today because Josh is doing some very interesting stuff that I've not seen anyone else do. Thanks so much for joining Josh.

Unknown Speaker 0:40
Yeah, thanks. Thanks, Jack, I appreciate you having me on.

Jack Bridger 0:43
Could you tell us a bit about you fizzy and about yourself? Yeah, for

Unknown Speaker 0:47
sure. So you fizzy is broadly in the environments as a service category. And so we're in the business of preview environments or ephemeral environments, those terms are effectively used synonymously. But the ability to rapidly create a test environment for your full stack, in response to a pull request, to test their iterate there, and then to completely take that away, hence, the ephemeral nature of it, right? It's short lived. And so the problem we're solving is the whole software communities using shared environments, that creates a host of problems, which we could probably dive more into. But we solve those problems with the short lived environments, helping developers QA, even product folks be able to rapidly test rapidly iterate and, and also not have to deal with a lot of the management headaches of environments that, you know, tend to happen over time. So that's what we do. And I'm excited to be here.

Jack Bridger 1:49
Yeah, so really cool problem that you're digging into. Because I remember the first time we had preview environments, so one of the companies I worked at, and it's just such a game changer in terms of, like, making it so much easier for everyone to test it and try it out. And, yeah, that's awesome.

Unknown Speaker 2:07
Yeah, for sure. I mean, a lot of the, you know, what indicated for us, like, there was a market here is just talk, you know, you know, having hundreds of conversations and like pulling, gleaning a lot of insights in the space. And, you know, some of the worst things I've seen that teams have to do is, this one team had a, they literally had a signup sheet. Like, it was like an online signup sheets like, hey, when can I use like the the quote unquote, dev environment? And like, you have to block off the time. And see, that's like, the worst I've seen is like, is it truly contested and like, to the point where they're, they're actually like, physically coordinating when people can use that. Other issues are, you know, I've seen developers who they're like, kind of afraid to merge, because they like afraid they might break the environment where put a bug in there. And they'll get on a zoom call, and like, do kind of a peer review, you know, with that person to make sure it's all good, right? And so and that's, and I would, I would I do recommend pair programming, that's good to go. But like, that's not a great solution for the problem that they're trying to solve. I think you see people VPN and other people's machines to try to check issues. And so that combined with you know, on larger organizations, you have kind of capacity issues, right? Capacity planning, you get into the enterprise, and it's like, well, how many environments do we need, and they have sort of mushroom farms of environments have been created. They're used, like, once, and they keep running, because no one told the DevOps guy to like, tear it back down, right? And so environments and servers or federal environments help with that problem, too. And so, you know, bigger picture, it's like, hey, what a like, what are the kind of existential problems we're trying to solve is, I think everyone's trying to do more with less these days, right? We're kind of in this weird economic situation where inflation has been high interest rates are up, not really a full blown recession, but you've seen a lot of layoffs. You know, so on the enterprise side, everyone's trying to get more agile and leaner, right? And so, having the ability to have as many environments as you need when you need them, and only for as long as the numbers is really helpful, it reduces your reliance on your DevOps folks who, you know, they've got higher level issues, they need problems to solve. And you also have sort of Empower your developers by giving them environments where they need like, Well, you shouldn't have to wait right? It's like it's silly to be like, well, we have this code freeze, or, or like even like this sort of fear that like well, this this Sprint's kind of done and we don't want to mess it up. So like, let's not push this thing even though it's ready, because I'm like, I'm afraid to like commit it to my QA environment and then like, I may delay my release, right. And, and, of course, certainly at the enterprise level, delayed releases, they call Millions, right? I mean, at that kind of scale, like I've missed revenue opportunities, so I kind of went deep on enterprise. On the startup side, they have another existential problem is like, Hey, I'm trying to get to my seed round or my series A or my series B, and like, am I gonna have enough time to do that? And like, I've got to move faster? What can I do to get a competitive advantage? You know, to get the proof, I need to get the next round. Of course, the VC market has tightened up, like considerably, like in the last year. And so I think, you know, certainly, like, I go back to when we were starting out, like, I, I'll do anything for competitive advantage, like I, you know, I'm an athlete, and like, I do triathlons. And like, I'm a sucker for anything if I think single player will give me like a 3% advantage, or 1%. Like, I'll do it, right. It's like, so if someone brings a tool to me, it's like, Hey, 2030 40%, improvements in release frequency development velocity? Like, I will try that. Of course, I'll try that. Like, it's a competitive market out here. Like, why wouldn't we do that? So we were helping teams, do you have those kind of numbers? And that's exciting for us.

Jack Bridger 6:16
Yeah, that's actually a really interesting point. Now that you've kind of touched on and I guess, like, as a as a triathlete, your time is the kind of principal thing that you're caring about, right? And then is it like, when you're when you're thinking about, like release speeds? And you know, you can improve release speeds by 20%? Like, who are you consciously going after people that kind of really care about release speed as they're, like, you know, their equivalent of a, you know, triathlon finishing time?

Unknown Speaker 6:47
Yeah, for sure. I mean, I think, you know, you really can't find a team that is going to say they don't, they don't care about release frequency or development velocity, we're getting challenged, most teams are simply not measuring those types of things. So then it becomes like, well, I can't measure it, like, how I'm even gonna know. Right, but, you know, Google had put up the door metrics, I think a lot of teams are doing that, which is the key metric there is release frequency as a measurement. But there's, there's other things you can measure, I mean, you know, number of merges per engineer over a period of time is a really good one. And then like, Hey, what are the total number of issues like you can push through, you know, in any given time, and like, the KPIs with these tend to be like, lead time, cycle time, and like code stability, right. And, and different teams measure those in different ways. But I do you think, you know, release frequency, or are they, you know, for startups, it's about release frequency, like, you know, we release like, pretty much every day. And, you know, we used to not do that, frankly. So before we had our product. You know, before we could use our own product, we had the traditional sort of, you know, QA that was sort of the unstable environment that we had a staging that was more stable, and then, and like we were releasing once a week, and eventually, once we could use our own product, like we now released every day, we don't, we got rid of both the static environments, we just use our temporary environments. And it's super fast, right? It's like, the way I think about it is everything's a hotfix. And like, it's okay, in a startup, because like, you're trying to move fast and like, it's your user still will accept, like bugs that pop in, like, No, you can fix those fast too. So it's like, your time to recover is not not such a big issue. And then, but on the, I'm gonna like I'm talking about two sides, because there's, frankly, we have both customers. And so I think most people would tell you, like, you need to pick one. And I generally believe that's true, as a startup founder, except that we have both types of customers both have found value in this. And so I'm now kind of more like, well, I'm going to try to just prove that facts. But, but like, on the enterprise side, like I'll use, you know, Spotify, as backstage team uses you Fevzi we're spinning up 400 ephemeral environments for them a month. There's about 200 engineers who have used our service. And you know, backstage is huge, right? It's like 20,000 started to get up. But as a million end users like 500 enterprises are using it. So those maintainers are under a tremendous amount of pressure to pack more features into every release. So they have a scheduled release cycle. So they do like kind of like a beta release. They call it a next release every week, but their official releases go out once a month. It's like a Tuesday in the middle of the month. Right? And so they're trying to get more issues packed into every release, you know, which is that's a different way of maybe looking at it's not the release frequency is set, but they're actually releasing more issues per release, and that that matters to them. Especially matters so like, I don't know what spot defies plan was but you know, they open source about three years ago, and it's gone so well. And maybe they planned this all along, I don't know. But you know, they're now monetizing they, they basically sell subscription plugins, everyone is using it. And so like, it's become a strategic project for them. And so obviously, they care a lot about that. So going faster is something that, you know, when I talked to like Ben Lambert's one of the the senior engineers there and who we worked with, help basically implement, they're the easy solution for them. And you can just get the sense that it's been there, there's a tremendous amount of pressure on them to, to just the volume, they are getting hundreds of contributions every month. So the core team, I think it's around 50, folks from Spotify, but there's about 1000, total contributors all the time, but like, in any given month, there's like 150 200, contributors, right, opening pull requests, they're, they're filtering through four pull requests a month. So that kind of volume, anything that saves them just a little bit of time. You know, basically faster PR reviews, when there are issues, it's a faster feedback loop, because we're both talking about the same environment like, you know, I looked at this, it's not quite right, can you fix it? The person pushes the fix, it's in the environment that's already sitting there. With the pull request. Yep, it's good to go. And now that thing gets merged faster than the alternative, which is, you know, hey, either I'm like merging to a shared environment, testing it there, or I'm like, pulling on my local machine. And, and, you know, again, competitive advantages, everything. It's like, I would much rather have an environment that's there for this purpose right here in front of me than having to like go do some manual work to test the thing that that needs to be tested.

Jack Bridger 11:47
Yeah. Yeah, it makes sense. It makes sense. And actually, like, that's a good segue onto, onto Spotify backstage and like open source in general. Yeah. And I think something that's super interesting about how you've been doing go to market is, you mentioned to me that you've been going specifically after these open big open source projects, and like helping them use you fizzy as a way to get customers. Yeah. And I've not seen many other companies do this, especially at the early stage.

Unknown Speaker 12:17
Yeah. So you know, the way I look at it, like, pretty much any startup has, you know, one, you've got to get your beta community going. And that's really hard, because your product is really not quite there. And, you know, engineers are skeptical, right, of like, trying anything that's not, you know, they know, it's not quite ready. So you're trying to build a better company, because you need the feedback to make the product good enough that you can go kind of mass market. But you also need you need credibility, like who's using this? Well, no one at first. Right? And then, and then you also need visibility, like, no one knows about you. And so, gotcha. I think we're at the the cube con conference in, in Valencia, and talking to folks, and we started talking to the backstage folks, and we're like, we could, we could help them out with this open source project as like, we could do this for tons of open source projects. And it's all like three problems at once, for us. And so, so that's what we started doing and doing it very deliberately, as really our go to market. And, and it absolutely has helped with those things. So, you know, gosh, it first it was like, really painful. Because, you know, you know, we had our own beta customers, of course, but like, you know, there's all types of applications out there in our solution, you define your app and Docker Compose, and and like, that's, that's quite popular, but like, how everyone's using it, like, there's slight variabilities to it. And so, you know, the first like, handful out the gate, like we couldn't, we couldn't technically meet the needs of the project. And that was really like, it's, it's frustrating. So you think you're there like, Hey, we're not there, guys. So so then we we fix the product to be more useful and more broadly useful. And once we did that, then we get more open source projects. And as we get more projects, like, you know, I think it's fair that to say that, like, the open source, these maintainers, that they're the leaders in the industry, right? Like, they're out there working transparently, and they're doing things. You know, they're, frankly, the most advanced methods are kind of the best best practices, right, that the rest of the dev community follows. So it's really helpful to have like that level of credibility, giving us that feedback. And also validating us saying, Hey, this is a great product, like, you know, and we're obviously they're using it now and I'm getting a lot of benefit out of it. So I you know, as a founder, that's one of the best, you know, signs you can get as like, Hey, this is this is a really smart person or folks and they think the product is valuable. That's a really good sign to me that that we're on to something here. And obviously, you know, I mentioned the visibility piece, like, it's all in the open, all the implementations are out there, like, you know, we talked about we're talking about, engineers are naturally skeptical, and they should be. But you can go look at all these repos and see, hey, this is exactly how it's set up. This is how it's integrated with GitHub actions. This is the file that's being used to define the application for every ephemeral environment. And yeah, so like, it's, it's been good for us. I'm, I'm glad we did it. And, you know, I, you know, when you can say, you know, you're supporting, I like that we're supporting a lot of icon usurpers. So, like, at first with belly search, like, it's awesome, like search tool, like built in Rust, it's like lightning fast. Like, you know, Elastic Search has been like the player for for pretty good while now like, Melissa, just coming in and just crushing it, you know, with, with, with a really great tool. And we talked to those maintainers they're like, they're like, Yeah, we'd love to have, you know, thermal environments. And that's a, you know, it's a CLI tool, it's a, we basically spin up their surf server, and they run tests through a web terminal, which is just sort of one of the many uses use cases for use easy, but you know, you've got them you've got, we support NoCo dB, who is basically a open source, err, terrible, airtable alternative, and they're crushing it, and they think this is great. And then one of our customers tilde is like trying to take a little bit of stripe market on pay, you know, monetizing payments. So like supporting a new generation of builders is really exciting for us. And, you know, I think what people say like, now that these folks have ephemeral environments, they're just they're not going back. Like, if you, if you were to take it away, they'd be like, what, like? And I think, you know, we talked to some people he's like, Yeah, I had it in my own company. I'd love to have it here. Because I think people do recognize the the benefits associated with them.

Jack Bridger 17:02
Yeah, I think you're right. And it's is something that is hard to go back from, how did you kind of land on this space and kind of coming, like landing on something that is so important to people?

Unknown Speaker 17:15
Yeah. So I would say through like, gross failure. And just so, you know, I go back, so I was a Navy SEAL most of my adult life, and actually the military, like late 2018, wanted to be an entrepreneur want to be in the tech space. So partnered up with my co founder, we were kind of doing some like private cloud contracting stuff, we're like, hey, we want to, we want to really, you know, launch something, you know, that helps developers out so so we set off on this dubious task of, we're like, hey, let's build a Heroku competitor. We're like, hey, Heroku hasn't been proven so long. Like, it's super expensive. And user experience isn't that great compared to what it could be. And so, so we built that thing. And we launched that thing. And, you know, as first time founders, like, not knowing a lot of things, the market was like, it was saturated. And like, even though our product was was quite good, and people liked it, we could not remotely compete with the scale, or the economies of scale that like, not only a Roku, but Digital Ocean, like launching our platform to like literally the same time. And so that was a frankly, it was a it was dumb. Like we should have done that, like I look, I can say that now, like we didn't have, the product wasn't so much better that you were going, we were going to like, you know, you serve Heroku or like, even like, take up a huge market niche. So we kind of had some, like dark times, realizing that this is like, mid 2021. And, you know, we had some money, we had a team we had, like us, our software was capable. And we used our network to be like, hey, you know, maybe there's other people or you can repackage this in a useful way. And, and basically, we're saying like, hey, my developers need to spin up environments all the time, like, I don't want. I don't want to host on your platform. But I would love to have a temporary testing environment. And so that basically, the set is on this path. And we really had the the next design idea, we really had to do a lot of product work to transition out of that, but the core was kind of there. And yeah, so we just kept iterating obviously on it. And then I know I'm going a little deep here, but we got a lot of feedback if people want. I like a really tight integrations with GitHub actions. So we publish a reusable workflow that so people the big thing is like I'll put a lot of time in there builds their customized and so a general build solution might not be or it doesn't fit for a lot of folks particularly kind of like more advanced teams and so and I go back to like the Spotify situation, they I guess they, they had tried another solution other third party solution, but the bill was proprietary. I mean, as a proprietary, it was, it wasn't accessible. It was on like, you know, the company's infrastructure. So we plug directly in to get a vaccine. So they have complete control and visibility, were just a step and a process they've already set up. Yeah, so we failed in our first startup, we pivoted out of that. And then fortunately, we had enough, enough left, if you will, in the tank, both both mentally, emotionally and resource wise. Yeah. Which is a whole nother level to it to keep going and then and find like a niche that really needed to be filled. And provide value to folks.

Jack Bridger 20:46
Yeah, I think that's it often doesn't start out right as like the one because you kind of have to start somewhere. And unless you have, like, this idea you're just pulled to because everyone needs it. Yeah. It's like, often, in a way, that's the best way to do it. I don't know if it's the best way. But like, a lot of people do it. Right. Where it's like, you start building something. And like people are like, it's okay. And then they're like, but yeah, I really want this overfit. Yeah. Like, Oh, okay. Yeah, that's, and yeah, as you said, it's like, if you've got the enough left in the tank in on all fronts to actually go after there's often the best, the best way?

Unknown Speaker 21:25
Yeah, I think there's a lot of startup stories that are kind of like a, you have kind of the right, you're moving in the right direction, but it's not quite right. And that's that critical, like early feedback. And being willing to like having the ability to take that I think is really important, because it's really easy to get emotionally attached to your idea, right? It's like, Hey, this is your idea, this is your baby. And it can be pretty easy to like, reject feedback that you don't like to hear, right. Like in the, you know, so I mentioned that was a seal. And so like, one of the things like one of the things we would say is like, you'd be planning an operation, right? And, you know, like, Oh, this is gonna be this, I got this perfect plan. I've been working on it. And like, someone walks up who like, hasn't, like, they just haven't been there haven't been doing the work. And they're like, Oh, why don't you just do this? And like, it's obviously better? And then be like, no, no, like, I want to defend my idea, right? But it's like, we call it like, Don't Don't be a bitch to your emotions. It's like, you have to be like, shit, yes. I just spent like, a day on this plan. But you're right, like, you walked up and saw, like, you had a different perspective. And like, you're right, you know, and I'm wrong. And I have to, like, own that. And, like, do that. But, you know, if you want to have a high performing organization, you have to operate like that. You've got to like, you know, you can't get can't get your feelings hurt over when there's obviously like, better system plans out there are ways to do things.

Jack Bridger 23:00
Yeah, and I guess maybe I say more about, like, what you you and your co founder have built in terms of like, how you work together and kind of what you'd learned and kind of being nimble? And probably that was the valuable part of what you did in that time. And probably will still be right? Yeah, for sure. You know, you fizzy is like, right now, like, this is this is the area but yeah, there might be like things that you kind of opportunities that come up or like, yeah,

Unknown Speaker 23:29
yeah, for sure. Like, yeah, we're trying to stay malleable. I mean, like, we can't find anyone who thinks that the concept of ephemeral environments is like, not like really not value. I mean, it comes down to an L. So we ran a survey at the end of the year, last year, a preview of virus to put out a report on like standard preview environments. And we were fortunate to have I don't if you know, the Open Source Initiative, but it's it's a nonprofit that the basically like outlines a lot of the guidance around like, what is open source and the licensing and that type of thing. And they sort of corral all that, but it was the some really good folks over there that they helped us on the survey, basically, we get a good audience to give us, you know, feedback, but like 80% of the respondents said that they think, you know, preview or femoral environments are valuable. Where it gets where it gets tricky is it's a really, it's a hard problem. Because there's so much it's everything's dynamic, right? It's like, hey, every new environment, it's like, okay, new networking, new URL. What about my data? Like, how am I going to log in like, these are hard problems that have frankly prevented a lot of people from like, moving to a firmer like, it's not that people don't think it's valuable, it's it's the friction of like transitioning, of course, that we're coming in to help try to lower the friction you know, down to a level where it's not too difficult for teams to onboard and and get rolling.

Jack Bridger 24:58
Yeah, and actually like on Ah, like, it's one of those things where I felt like everyone, if you're not doing it, you know, you should be doing it. But how do you create that kind of like now? Like, because this is what it seems like, it's one of those things that's easy to just be like, Yeah, we know we should do this, but like, we're really busy. Not right now. Yeah, yeah.

Unknown Speaker 25:19
For sure, like you're touching on something that I think is it's like, you know, we're moving along, we get along, we have a test environment, like, it's good. Like, how do you how do you get to the pain point? I think it does come down to like, you know, the teams are really kind of like the most aggressive like, and I say that because there's a lot of, again, these open source projects are like, they're trying to like, kind of like take down like, take over market, it's frankly, like already established, they're like, Yeah, I'll do anything for like a competitive advantage to help me out here. And then, and then like, I go, I go back to like, the backstage thing. It's like, there's really like a huge pressure cooker on those folks to, to release. I mean, again, like, I mean, like Netflix, American Airlines, like Siemens, like all these big companies use that. And they, of course, they're like, hey, we want this all to get better. There's it, the spotlight is on this team to make that happen, right. And so I think it's when those kind of existential pressures come in, particularly if they have teams of like, unfortunately to do with layoffs to like, you know, that CP CTO, the VP of engineering, whoever it is, is going to be expected to continue to produce even though they have, frankly, like less resources, like available to him.

Jack Bridger 26:42
So sounds kind of like you're tying the challenges that they're having, like, the real challenges around, as you said, I think in the beginning, like doing more with less,

Unknown Speaker 26:52
yeah, I think that's sort of like the existent existential pressure, right, of like, improving and then, and then like, this kind of, like, daily reminders of, you know, I'm sitting around like, Are my engineers are sitting around, like, unable to test something if they don't have an environment available to them. Right. And like, it's 2023. Like, that shouldn't be the case, right, like, but I think teams are still really, really struggling with this.

Jack Bridger 27:20
Yeah, that's a good point. I think it's something that is very, probably has a lot of potential to really, like, stir up emotions with people. And like, I think it's something like you all have done really well. And if you've seen rutile, but like, when you go to the homepage, it's like, stop. I can't remember the exact wording, but it's all like stop faffing around with like, different, like, data wrangling stuff and doing annoying, like, tables, and they really like play on this emotion and like, yes, you know, that struggle? And seems like you probably have a lot of potential there to Yeah, I mean, we engineers sitting around not doing anything for sure.

Unknown Speaker 27:55
Well, you know, you should always be like empowering your people investing in your people, right? That's like, I go back to like, my, you know, in Special Forces, like, one of the core tenets is like, hey, people over hardware, right? Of course, that translates to like, Well, I think the Agile Manifesto says the same thing. But it's, you know, if you're not giving your people the tools they need, like you you're not actualizing your potential, right, like, and so I think there's a lot of room for improvements, performance improvements, like, again, going back to like, how you measure those release frequency development velocity, but yeah, there's a lot of room there when you when you give the people give them the tools they need, right, give them their environments, like, make it easy. Don't have these like, sort of hurdles or roadblocks that that are, you know, going to be dragging your organization down.

Jack Bridger 28:53
Yeah, definitely. Josh, I think that's all we've got time for. Okay. We've started doing a TLDR. And what, what would be your kind of key takeaways for other dev tool founders to take away from this conversation?

Unknown Speaker 29:13
Yeah, so I would, I would say like, don't be afraid to approach the open source community, if you've got a new tool that can help them out, you know, it's, they really are quite approachable. And, you know, they all work on GitHub, and, and you can reach them there. So don't be afraid to reach out and again, like, don't do it as like a spammy thing, do it as a, Hey, I'm gonna provide value to your to your project and like, do the work like, you know, do the work for them. It's not like, Hey, I'm gonna throw this thing and like, you can think about using it. You know, I got a big believer in. You've got to provide value really before you can like extract value. And so don't be afraid to do things that don't scale. l early to get the things you need to scale. So that would probably be my biggest takeaway for other kind of founders and folks trying to scale dev tools.

Transcribed by https://otter.ai