[{"data":1,"prerenderedAt":84},["ShallowReactive",2],{"bridging-bytes-open-source-outlook":3,"bridging-bytes-open-source-outlook-next":68},{"id":4,"slug":5,"vimeo_id":6,"description":7,"tile":8,"length":9,"resources":10,"people":11,"episode_number":21,"published":22,"title":23,"video_transcript_html":24,"video_transcript_text":25,"content":10,"status":26,"episode_people":27,"recommendations":57,"season":58,"seo":10},"d74e3c5c-77dc-4f34-a247-2cb6cf7cee12","open-source-outlook","923062947","A discussion on the past, present, and future of open source, including what it means to be \"Post-Open\" and build sustainable businesses.","863084c0-77cc-4b22-af18-9d7af9ca6165",69,null,[12,15,18],{"name":13,"url":14},"Ben Haynes","https:\u002F\u002Fdirectus.io\u002Fteam\u002Fben-haynes",{"name":16,"url":17},"Steven Tey","https:\u002F\u002Ftwitter.com\u002Fsteventey",{"name":19,"url":20},"Bruce Perens","https:\u002F\u002Ftwitter.com\u002FBrucePerens",2,"2024-03-14","Open Source Outlook","\u003Cp>Speaker 0: Let us kick it off. So this is the second episode of Bridging Bytes. This time, we have we have bridged from the last episode of the intersection of design and development, and now we are talking about, the open source Outlook. So, obviously, a very important topic, something that's near and dear to my heart, having worked on Directus now for 2 decades, over half of that as an open source maintainer. And then we have some amazing, guests here that are gonna be leading the chart in terms of this conversation.\u003C\u002Fp>\u003Cp>So I'll be moderating the the chat. I can give a quick background, and then I'll introduce our 2 our 2 guests. So, my name is Ben Haines. I am CEO and founder of Directus, the open source, data management platform. And I've been I built the platform originally in 2004, and we actually open sourced it in around 2010, 2011.\u003C\u002Fp>\u003Cp>So we'll get into more of the history of of what we did in our open source journey. But, I'd like to next introduce Bruce Perrons, who is sort of the the godfather, I think we were calling him, of open source. Bruce actually created the open source initiative, which I think was in 1997. Give her we'll let him\u003C\u002Fp>\u003Cp>Speaker 1: 87.\u003C\u002Fp>\u003Cp>Speaker 0: When was it?\u003C\u002Fp>\u003Cp>Speaker 1: 1987 was the creation of the open source initiative in the open source definition. And the document actually came about, I think, 8 months before, it was then the Debian free software guidelines.\u003C\u002Fp>\u003Cp>Speaker 0: Yep. Obviously, there's some interesting aspects of using the word free versus the term that was actually chosen, which was open source. But yeah. So we have Bruce Perrons here, who is the cofounder of the Open Source Initiative. And, you know, great thanks to your work, I believe, within, Debbie.\u003C\u002Fp>\u003Cp>Basically, Bruce, why don't you give a quick, overview of your background and and and what brought you here?\u003C\u002Fp>\u003Cp>Speaker 1: I I'm sorry. It really was 97. I'm just going over the calendar in my head. So, 87 was actually when I got to Pixar, and, I started as a filmmaker, was one of the founders of computer graphic 3 d feature film animation, and worked at Pixar and their predecessor in New York for 19 years in total. Have a credit if you go on IMDB on a couple of films.\u003C\u002Fp>\u003Cp>And in, 97 we'll get that right now. I wanted to define what Debian, included, and we created something called the Debian free software guidelines. And then a little later, a group met and said, well, let's market free software to business and call it open source. And, so that happened. And I was called up the next day and I said, well, great.\u003C\u002Fp>\u003Cp>I'll take my Debian free software guidelines and make them the open source definition. And so there we go. It's been a long time, and it's been incredibly successful. If I had said to you, back then, we're going to, give away our software and completely take over the industry by doing it. And we're going to make an encyclopedia, and it's going to be the first thing to put a Microsoft product and Carta out of business.\u003C\u002Fp>\u003Cp>If I had told you that, you would have just said, well, I wanna smoke that dope too. So, so it it's been a long strange trip. Hasn't it?\u003C\u002Fp>\u003Cp>Speaker 0: Yeah. Well, I here I am sitting here, you know, so excited to be 20 years in, to the entirety of my project, Directus. And you've got, you know, 20 years under your belt just, you know, with, you know, elements of your your history. So thank you so much, Bruce. It's really exciting to have you here.\u003C\u002Fp>\u003Cp>Lots of knowledge, obviously, spanning back to the the mid nineties and even before with, you know, your work on those projects. I think next, I'd like to introduce Steven Tay who's joining us. Stephen, I'll let you give a quick background from what you did with with Vercel and what you're doing now at dub.co.\u003C\u002Fp>\u003Cp>Speaker 2: For sure. It's an honor to be here. I feel incredibly humbled by the the the wealth of experience that you guys bring to the table. I think Bruce was talking about how he he he did that DBL thing in 97. I'm like, that was the year I was born.\u003C\u002Fp>\u003Cp>So it was like a little bit of a it it feels very humbling. But, yeah, my name is Steven. I was, a developer advocate at Vercel for the last two and a half years. I started in 2021. It was there where I got, introduced to the open source community, got to actually learn and became a better developer.\u003C\u002Fp>\u003Cp>Before that, I was doing a lot of, like, data science, coding in Jupyter Notebooks, not really building any, like, software that's used by the end user. So I I learned a ton through my time at, Vercel. I built a lot of open source templates, open source, guides technical guides that people can use to learn about Vercel's technologies like Next. Js, Turbo, Rebo, etcetera. And, it was actually through Vercel.\u003C\u002Fp>\u003Cp>So we we dub this company that I started back in December of last year, it came about as a side project that I built when I was at Versal. I I had this need to, like, be able to share links, on on social media with really nice preview images, and it started from a very niche use case, but then eventually blossomed beyond that into a full link management tool. So, it was in December when I when I started talking to a lot of our users and realized that the market opportunity behind Dubb, It's a start company around it, and here we are.\u003C\u002Fp>\u003Cp>Speaker 0: I love that. Thank you so much, Steven. That's a it's an awesome intro. I mean, obviously, we have, you know, different levels of experience, with open source, with building, but that's kind of how open source works. You know, you've got maintainers and contributors and users.\u003C\u002Fp>\u003Cp>You have some projects that are out there and they're just small little packages or libraries like an SDK, you know, with one hobbyist sort of kind of maintaining it on the weekend versus things like Directus and, you know, even larger operating systems or platforms supported by tens or hundreds of developers. And I think, you know, in the last few years, we've seen all sorts of things happen, that really showcase the importance of of open source, vulnerabilities like Log 4J or just the the escalation of different open source platforms, like, really taking hold in the ecosystem. So it's obviously a very timely conversation. Specifically, my passion is around I I've spoken with Bruce for a while about this actually, is about how to build I think it's a nice acronym, SOS, but sustainable open source. Of course, SOS being, you know, talking to how important this is to get right and to do it timely.\u003C\u002Fp>\u003Cp>But I think we can kinda dive in. The purpose of this, Bridging Bytes episode is really to talk about this theme of open source, past, present, and future. You know, we we, of course, have Bruce here to to really help us understand the roots and how this came to be. We made our our platform open source a decade ago, you know, obviously based on the WordPress license using GPL. And then we are we relicensed about 10 months ago.\u003C\u002Fp>\u003Cp>So there's all sorts of things happening in the past and present. And, of course, you have to be really mindful of where do things go next. You know, how do we actually make open source sustainable? I've heard some pretty interesting ideas from Bruce that I'm sure he'll share around his ideas of what he's calling post open, at least as a working title for now. We'll figure out what that might look like.\u003C\u002Fp>\u003Cp>But, yeah, so I think we should we can dive in. And my first question would be for for Bruce. Bruce, I'm curious, in all the experiences that you've had, maybe you could share how those have shaped your views, of the evolution and impact of open source over such a long tenure over over these decades since 1997, not 87, but through now. How do you think that those experiences have shaped, you know, your views on on that evolution?\u003C\u002Fp>\u003Cp>Speaker 1: Well, I should just say a long, long time ago as if I'm telling a story because it feels like forever. But, so I I started out, working for a film company, and I I had fun. I mean, we did something for the first time. You know, we we made our IPO. They let us have our IPO at the same time that we put out the first three d feature animated film, which was crazy.\u003C\u002Fp>\u003Cp>And so it it was a really interesting ride, but I started at this point to work on Linux because, we were using Unix at Pixar, and the PC was coming out. The PC started to be capable of running Linux. And then, Steve Jobs for a while had his office right across from mine. This was not because I was important, but because they wanted to keep an eye on me. And so, one day, Steve made his peace with Bill Gates, and the next workstation stopped being on Steve's desk, and there was a Windows laptop.\u003C\u002Fp>\u003Cp>And Steve would tell us that, you know, eventually, we'd switch off of Unix, and we'd all be using Windows to do our animation. And no one was very happy with that, and especially then because before Linux was really big, the quality of Windows was very poor because they could afford to have very poor quality. They were essentially the only game in town. And so I started working on Linux and tried SLS and a few other things, you know, ancient distributions, and and then landed on Debian. And at the time, my idea was making a Linux system for amateur radio operators, ham radio.\u003C\u002Fp>\u003Cp>And the reason for that was there was a lot we could do with software, and I thought we could put it all together. Well, that never happened, but I became Debian project leader along the way. And I think it was becoming more important than my work at Pixar. And the real moment for me was one day I got an email from someone and they said, I wanna use Debian with a serial console. Do you can you tell me how?\u003C\u002Fp>\u003Cp>And that wasn't a feature at the time. And I thought it was interesting, and I I sat down at Pixar, you know, when I should have been working and figured out how to do it and sent this fellow an email. And he wrote back and said, that works great. This is going on the next space shuttle flight. And so I walked all around Pixar looking for someone to tell this to.\u003C\u002Fp>\u003Cp>The only person there who knew about Linux was working from home that day. And so, it came a time when people would say to me, well, you're having such an exciting life. You've come out with a film, and your company has an IPO. And isn't this so exciting? And I'd say, yeah.\u003C\u002Fp>\u003Cp>But my hobby project is orbiting in space. And at that point, I sorta decided maybe I would eventually leave Pixar and work on Linux and open source full time. And so we have had a history of that sort of serendipity. I mean, the hobby project of a students. You know, Linus was a student and maybe a lecturer, takes over the operating system world, and the industry software is taken over by amateurs who give away their software.\u003C\u002Fp>\u003Cp>I mean, at this point, none of them were working for companies. And IBM abandoned AIX in favor of this hobby project. So all of these amazing things were happening and why the world was ready. There was a a market vacuum, and this came along and filled it. And people don't realize that this is all straight economics.\u003C\u002Fp>\u003Cp>It's it's no you know, some people call it freakonomics, but there's nothing freaky about it. It's just economics.\u003C\u002Fp>\u003Cp>Speaker 0: Yeah. I mean, it it goes without saying, you know, by some estimates, you know, open source power is 80% of modern code. So, you know, there's quotes from people over at Google, Filippo Valsorta, who had said something. I've had this quote here. He said, open source software runs the Internet and by extension the economy.\u003C\u002Fp>\u003Cp>And I think that kind of really qualifies like how large open source has become. Obviously, in the early days when you're working, on defining it, Bruce, there was all sorts of there was the, I think you mentioned in Debian, you had the Debian Social contract, in 93. And there's the SPI, which was, you know, software for the public interest. You did the OSI, the Open Source Initiative. There's all sorts of, like, what's the term gonna be?\u003C\u002Fp>\u003Cp>What are the rules? How do we, you know, really label these things? And what we got from that is essentially ten sort of rules or guidelines for what is open source, which is right there, you know, on opensource.org. It was how did you guys come up with those 10 terms? I mean, I I I've looked at them quite a bit because we have an open source source spirit.\u003C\u002Fp>\u003Cp>You know, our ethos has been that since the beginning. But, of course, with a license change and trying to stay true to the terminology of source available versus open source versus whatever new terms we come up with, there's always gonna be those 10 terms sitting there within the OSI. So was that was that an easy or difficult thing to, you know, sort of memorialize for the world?\u003C\u002Fp>\u003Cp>Speaker 1: Well, first, I don't wanna take all the credit. We are standing on the shoulders of Richard Stallman and the free software movement. And, Richard and I were actually speaking at a UN Summit in Tunisia, and I said we're standing on the shoulders of Richard Stallman, and he goes like this. And so, I think that we've had a lot of, different words for what we're doing. And because of that, the concept of having a brand came up.\u003C\u002Fp>\u003Cp>You know, there was free software and there was Shareware. Remember Shareware? And\u003C\u002Fp>\u003Cp>Speaker 0: Shareware and Freeware. There was, like, all the wheres. And it's interesting thinking of, like, how the word free left. Like, you still have thos, you know, free and open source software. But, you know, the freeware versus open source and the difference in perception, again, something that we deal with when we're now selling licenses for, you know, we've for years, been selling licenses for open source software through our cloud SaaS and, you know, breaking the perception of from free to paid is an interesting gap to kind of, cross.\u003C\u002Fp>\u003Cp>But\u003C\u002Fp>\u003Cp>Speaker 1: So so I'll give you another word that everyone's forgotten, consortium. It used to be that real software products were made by consortia, which was a collaboration of companies. And the problem was that they all had their own different interests and that the engineers did not control the operation. So the consortia had a lot of trouble getting along. And my very favorite, consortium story is the X Window System Consortium decided one day that they would not have a canonical user interface for x.\u003C\u002Fp>\u003Cp>And Microsoft, of course, ate their lunch because they did. And and what the x consortium was trying to do at that point was allow each of the different Unix workstation manufacturers to differentiate their work station and also to lock in their customers by having a different user interface for that version of Unix. And they didn't realize that if they didn't work together, Microsoft would just take over the market and, you know, go find a Unix workstation today that isn't a a Linux or BSD system on a PC. So we had all of these economic issues, and we also had the need to create a brand. And so the open source initiative came by because, in Debian, we wanted to say what Debian was, and also we wanted to elucidate our social contract with the community.\u003C\u002Fp>\u003Cp>And so we, wrote the Debian social contract and the Debian free software guidelines. I sort of created and edited it, and we had a 1 month discussion with the Debian developers about it and then publish the results. And this, part of it became the open source initiative, definition. The Debian social guidelines is still very prominent on the Debian site, and you can see the other part that became the open source definition at the end of it.\u003C\u002Fp>\u003Cp>Speaker 0: Yeah. No. And that's something I think referred to quite a bit, especially as new licenses come out, you know, making sure they check all 10 of those boxes, to truly call themselves open source, you know, and not have some big glaring asterisk. Yeah. That's it's amazing just to hear the history of, like, all this tumultuous, like, what is this you know, there's just a huge landscape that was not defined.\u003C\u002Fp>\u003Cp>So it's exciting to hear it was defined. Same issues that we're still facing today in terms of how you get financing and make sure you have an authoritative, list of of defining what this is, and that that's being, fostered by people who actually care about what it what it's supposed to mean and not just guiding it based on commercial endeavors. Steven, I'd like to, start over to you. Obviously, you've had, 2 sort of key roles that that you highlighted in your intro. Obviously, going from DevRel over at Vercel, to now founding, dub.co.\u003C\u002Fp>\u003Cp>I'm curious how your perspectives of open source, you know, in the development of those those open source projects has changed, and evolved over that transition of your your career.\u003C\u002Fp>\u003Cp>Speaker 2: Yeah. For sure. I think there's there's definitely been quite a shift in terms of, like, the way open source, I guess, the way we view open source personally. But one thing has always stayed true, and I can go through the distinctions there. So when I was at Vercel, we basically maintained this fairly popular React framework called Next.\u003C\u002Fp>\u003Cp>Js. It's basically a framework for you to build with React, service side rendering, and basically an entire full stack applications with batteries built in, like API routes. You can even do stuff like, having a middleware to do redirects, rewrites, and all these different things that regular React would, you know, it'd be harder to build with that. And through Next. Js, it we were able to tap into a massive customer group and and not, I guess, not exactly customers, but, like, potential users that could be converted to customers.\u003C\u002Fp>\u003Cp>Folks like, let me see here. Like, folks like, Netflix. I I I remember tweeting at one time that 4 of the world's largest streaming platforms, Hulu, max.com, Amazon Video, Netflix, they were all using XJaaS, which is kinda cool to see. And, through that sort of, I guess, user base, we're able to expand our enterprise, pipeline because we are able to tap into engineering managers who are using X. Js and and sort of pitch them our host of solution and give them a sort of white gloved approach to spinning up and and maintaining that Next.\u003C\u002Fp>\u003Cp>Js applications. So in that sense, the symbiotic relationship between Next. Js and Resell was very clear. It was like, you know, you have this open source framework, MIT licensed, and you have this proprietary hosted solution that basically, does your Next. Js hosting for you, and you have you have to worry about stuff like Kubernetes maintenance and stuff like that.\u003C\u002Fp>\u003Cp>So that was that that sort of relationship was very interesting. And the work that I did there was also sort of different because, I wasn't working a lot on Next. Js specifically. I was mostly more working on developer efficacy, which is building open source templates, and that sort of, like, drew me to gravitate towards another side of open source, which is building templates and also products that are open source, but at the same time, licensed under AGPL, which would give you, the the maintainer or the the company behind the project a certain level of ownership and control, over how the prod the the code is distributed. So, that sort of drew me to to basically build Dubb as an open source, first project.\u003C\u002Fp>\u003Cp>It started as a project, and it's it's our company. And, so the relationship here is slightly different. Right? It's it's more of a we we call ourselves a cost, which is like a commercial open source, software, which is similar to what, for example, MongoDB started back in the day with, like they had their open source database system that people can easily clone and just run it themselves. And then now it sort of evolved into the wave of, companies like cal.com, which is an entirely open source company sorry, open source product that's, they have their repo, it's out in the public, and they also run that for the hosted service.\u003C\u002Fp>\u003Cp>And they also have, like, a directory that is enterprise only. So if you want to use code in that directory, you would have to buy an enterprise license. And that's sort of the direction that we're going towards, and it certainly has changed quite a bit about how I think about licenses, how I think about getting contributor permissions, and stuff like that. There's so much nuance to to this whole ecosystem that, honestly, I'm still trying to figure out. I'm working with a few lead councils to understand where we should be, you know, what sort of precautions should we take, what sort of, licenses should we potentially change to in the future.\u003C\u002Fp>\u003Cp>So, yeah, very excited to to to discuss this with you guys more and and sort of get your thoughts and and advice on this this whole, space and how we we should move forward.\u003C\u002Fp>\u003Cp>Speaker 0: Yeah. No. That that's awesome. I think I mean, I've seen I've lived several of those different iterations of, like, how you commercialize, how you make that more sustainable. Seemed like you were describing sort of like an open core model.\u003C\u002Fp>\u003Cp>Sometimes, you know, you can also work that and call it like an icing on the cake model. There's also the support, like the professional services where you have almost like an agency that leverages it and to get that support and the authoritative maintainers, you know, access to them. That's a paid service. Of course, that can be difficult to scale because you have to scale humans, and not just scale the software out, as you distribute it. So it's interesting to hear, you know, all the different methods.\u003C\u002Fp>\u003Cp>And it kind of ties me into there's a few other questions I'd like to run through before we open it up to the audience. But maybe we'll we'll rapid fire these so that we can actually make sure we we work our way through it. But I think the next one that I think is interesting in this, you know, mid nineties all the way through the mid 20 twenties, where we are now, what would you either of you say are some of, like, the biggest milestones that have significantly impacted this open source landscape? You know, whether it's for maintainers, users, and awareness of, you know, open source as a whole. I'm just curious.\u003C\u002Fp>\u003Cp>I'll I'll leave that pretty broad. But any big developments or milestones that, you guys can think of regarding open source?\u003C\u002Fp>\u003Cp>Speaker 1: Well, I'll talk about myself. In 2005, I wrote a paper called the emerging economic paradigm of open source. And I think that it's very relevant to business and so called costs or commercial open source businesses because it explains how the economics work and goes into the business differentiator of your business. And every business has differentiators, which make their business appear different directly to the customers than others. And, you know, one of your differentiators is you've got dub.c0, and other people have 7 or 8 long, character URLs.\u003C\u002Fp>\u003Cp>And so, we can open source everything but our business differentiators and collaborate with our very worst competitors on everything but our business differentiators because they're probably the people who need the same infrastructure we do. But we shouldn't open source our business differentiators until they rot. And over time, they will no longer be differentiating your business because other companies will have them. And at that point, it makes perfect sense, for that to be open source. So I think this perception of where open source could actually fit in a business and that you were not creating economic suicide and joining the communist workers' paradise by, taking it up, was a a very important one, and and I think that it was pioneered by the big Internet companies.\u003C\u002Fp>\u003Cp>And so when Google and others take up open source, everyone else notices and says, well, these guys are making tons of money, and maybe there's something we should do there too. Another thing I talked about in that paper was a sort of 80 20 phenomenon, which is 80% of the software in your business is non differentiating. So you have a choice of how you make it. You can build it yourself because you have not invented hear disease, and you think everything you do in your company is better. This used to be a a more prevalent thing than it is today.\u003C\u002Fp>\u003Cp>Or you can get it from the open source community. So say you use open source to reduce the cost and risk of developing that 80% of non differentiating software. You take the money that you saved on that, and you move it into making your business differentiators better. And it was the development of economic perceptions like this that I think made it smooth for a company to participate in open source. And and I'm not taking the credit.\u003C\u002Fp>\u003Cp>I think everyone could have made the same observations. But if you, go back and look at that paper, I think it's still very relevant to businesses today.\u003C\u002Fp>\u003Cp>Speaker 0: Yeah. No. And certain certainly a large milestone. Steven, any thoughts on other other milestones in the open source world?\u003C\u002Fp>\u003Cp>Speaker 2: Yeah. I'm I was struggling to come up with one because, I'm fairly new to that open source space, but I I just wanna comment on what Bruce mentioned. I think it's very, very, interesting to hear about that 80 20. It's sort of like the paradox principle where you you take the the you basically leverage open source as a way to collaborate with other amazing developers. And I feel like for us personally at Dubb, the 3 sort of main benefits of being open source is 1, you get to tap into this massive talent developers and people that are, you know, constantly, contributing to open source code, and as a result, your code base becomes more secure.\u003C\u002Fp>\u003Cp>I believe Mark Zuckerberg came up with this quote in an interview a long time ago is that open source software is generally more secure. So that's one. And secondly, there's also the aspect of tapping into larger enterprise customers that you never would have been able to work with if you're not open source. So in our case, Dubb is actually used, we're currently working with the government of Malaysia, which coincidentally is where I'm from, to basically, they're they're forking our our code base to build, like, a official government link shortener for the employees to be able to use, and that's something that we could never have done if we were closed source and they will have to subscribe to our software. So that's something that's really cool to be able to collaborate with all these different, like, agencies that have much larger, like, bureaucratic red tape, stuff like that.\u003C\u002Fp>\u003Cp>And thirdly, definitely the the aspect around open source and the trust and transparency that goes into it is also massive. Like, you cannot just be putting spyware or, like, you know, like, ads and, like, what's it called, privacy invasion software into your code base just because you wanna, like, track your users or, like, I don't know, find a way to sell ads and stuff like that because your code is fully out there and people are scrutinizing it. So and as a result, like, companies are willing to trust and use the software more and goes through procurement much easier than if it was closed sourced. So Yeah. I feel like those are the 3 that we've seen so far.\u003C\u002Fp>\u003Cp>Yeah.\u003C\u002Fp>\u003Cp>Speaker 0: It's interest yeah. And I it's interesting to think of how much trust you can get. You've made your source available. You've made it open source, you know, through the license. These these steps are amazing to make to give you the transparency you need, which as you said, like, there's no hidden code.\u003C\u002Fp>\u003Cp>There's no black box, and it's like, oh, what happens there? You're sending, you know, telemetry back to the mother ship or something weird and you're just unaware. But it's interesting that that transparency, while it does give you the ability to audit the code, you know, we at Directus were actually in use in the public sector. So the Department of Defense in the US and the Department of Energy. You know, we couldn't really do those things if they couldn't see the code end to end.\u003C\u002Fp>\u003Cp>But at the same time, smaller open source organizations, almost always underfunded, really can't afford the security analysis or security researchers, to actually formally ensure that it is the code is audited audited. You know? So auditable and audited are 2 different things. And I think one milestone that comes to mind for me was sort of that big moment with log for 4 j or log you know, from the log 4 shell, vulnerability where people suddenly were very aware of how reliant, everything in the world was to open source, you know, specifically this one package. But, that I think was a really big moment for beyond just open source maintainers that are aware of their own value, of course, but everybody leveraging their systems to be also aware of how critical open source is to what they're building.\u003C\u002Fp>\u003Cp>Speaker 2: So It's crazy. It's I was chatting with this, the he's a product manager at TypeScript of TypeScript at Microsoft, and, we were talking about this, it's a funny analogy where that's I think it's like the what's it called? Like, p k p x p xcd comic or something where it's like p xcd? SKCD comic. Exactly.\u003C\u002Fp>\u003Cp>Where it's like this entire world that's, like, balancing on the shoulders of one big\u003C\u002Fp>\u003Cp>Speaker 0: wall. Yeah. It's a very famous it's a very famous one. You've got this, like, Jenga Castle, and then suddenly there's, like, one little piece that could not be removed, which\u003C\u002Fp>\u003Cp>Speaker 1: is They buy a hobbyist in Ohio.\u003C\u002Fp>\u003Cp>Speaker 0: Yeah. So exact exactly. It's one of the probably the most popular xkcd comics if if editing can, like, toss it somewhere on here so everybody can see what we're talking about. But, super, super interesting to kind of visualize exactly what we're talking about here. And I think before, you know, some of those bigger vulnerabilities, people just weren't aware of it.\u003C\u002Fp>\u003Cp>Now they are, and, of course, we're trying to remediate how do we solve that. Not always the easiest thing to resolve, but I think the visibility and awareness of, open source, whether it's commercial or free or otherwise, it needs to be sustainable. This is not only a hobbyist project for people. This is, you know, supporting big enterprises and and therefore, you know, big parts of the economy.\u003C\u002Fp>\u003Cp>Speaker 1: I think there's another point that's really important about security especially is that the size of the code base that we use increases exponentially. So when open source started, a 100000 line code base was a large code base. Debian, I think, is now 1,500,000,000 lines. And so as the size of the code base increases, of course, the attack surface increases as well. And, thus, we are now at the point where no company can look at everything with their own employees regardless of the size of the company.\u003C\u002Fp>\u003Cp>Speaker 0: To your point, Bruce, the scale of everything is getting so big. I mean, I forget figured was it called everything or whatever that NPM package was that had a dependency of everything? The dependency trees. You know, when we go through our institutional financing, there's big checks to make sure that we've done everything appropriately, and you have to provide for your software the full dependency tree. Those things just get so enormous, you know, to your points.\u003C\u002Fp>\u003Cp>Everything depends on other things. And then you have some crazy joke, like, whatever that everything package, I think that's what it was called, That suddenly you can't remove because it is a dependency on so it becomes very complex very quickly. And how do I get out of this complexity and make things sustainable? I I guess it's sort of the next question Yeah. That I'd love to cover is, you know, you have these open source projects, hobbyists or otherwise.\u003C\u002Fp>\u003Cp>Obviously, we're talking about how heavily relied upon they are. How can those projects and maintainers transition to commercial viability, to sustainability, to supporting themselves? And as the project grows, again, myself and Drake, you know, created this, you know, 10 years ago. We were working on it together, just the 2 of us, as an open source org. Now there's 30 people at the company full time that it takes, to kinda support this this project.\u003C\u002Fp>\u003Cp>Those are full time salaries. That's a big, big cost. I'd love to hear your, both your thoughts on how these open source projects can transition to, a you know, to be commercially viable.\u003C\u002Fp>\u003Cp>Speaker 1: Well, I think they do it kind of poorly today. And so let's take support because support is the way that a lot of companies try to make money, and open source companies don't do support very well. Why is that? Because they support their own program. Okay?\u003C\u002Fp>\u003Cp>Now say you're a customer, an enterprise customer, and you have 200 important open source programs in your business, then maybe you have 200 support entities. And your job when a bug comes up is to isolate the bug, figure out which of those support entities to call, and then convince them it really is their fault while they all point at each other. And so, open source support, I don't think works all that well, and people get IBM support contracts because IBM says we're gonna support everyone. So that's one of the big problems that we have.\u003C\u002Fp>\u003Cp>Speaker 0: Saying support is not a good option. What would be, like, what would be a an actual like a viable commercial option then for these maintainers to, bootstrap themselves?\u003C\u002Fp>\u003Cp>Speaker 1: Well, continuing to talk about how open source does it today, we also have the widget frosting paradigm, which is you take a, open source thing and then you sell a proprietary enhancement to it. And so that is the way I believe that your company operates beside its support revenue and that a lot of companies do it. You don't have to do it right now in Dubb because you own Dubb. But if you had a whole lot of different, link aggregation companies doing the exact same thing, you'd have to sit back and say, well, I'm gonna have to strategize again. So we've really been doing open source for a long time, and it is time to sit back and re strategize open source to achieve some of the things that we haven't achieved.\u003C\u002Fp>\u003Cp>Okay. So number 1, if the developer does not work for, one of these companies like Google that actually pays developers to do open source, they're probably not compensated. If they don't work for Google, they don't work for your company. And I've had people say to me, well, open source is mostly in companies today. That's a symptom.\u003C\u002Fp>\u003Cp>It's a symptom of the fact that there's no other way to support your family than working for one of these companies that pays you to be an open source developer. Okay. Another problem that we have is we only program for ourselves, and this is actually a diversity, equity, and inclusion problem is we're great systems programmers, and we make really sophisticated applications for people like us. And thus, the the person on the street may not have heard of open source. They probably heard of blind.\u003C\u002Fp>\u003Cp>And if you look at what applications they're using, they are using applications on their phone from Apple and Google, and the infrastructure of those things is open source. So Apple and Google, you know, they they consider the customer to be the product, and the main way that they make revenue is surveilling that customer and presenting advertising to that customer. And, so what we see is that the customer is somewhat abused by these companies, and we enable it. The open source community provides all of the infrastructure for it. So here we are with a world where privacy is concerned while open source stands for privacy.\u003C\u002Fp>\u003Cp>Security is a concern, and and we stand for that too. And why aren't we making the applications that everyone uses? Because the developers want to write for themselves and people just like them. And so, well, maybe we need to pay those developers so that they're right for other people. So I I sat down with these ideas and said, okay.\u003C\u002Fp>\u003Cp>Maybe it's time to transition beyond open source to something I call post open. And that may not be the permanent name because the permanent name has to be trademarkable. So post open is free for the person that we want to help, which is the common person, the individual, the small business. This is a business with revenue under $5,000,000. End user revenue has to be end user because it's too easy to circumvent otherwise.\u003C\u002Fp>\u003Cp>You know, when I worked for a film company, they used to tell us, if your film makes a profit, you're doing your accounting wrong. So end user revenue to prevent circumvention. So if you're a company that makes over that $5,000,000 line or you wish to make proprietary modifications or you wish to put the post open software in a product that you sell, whether it's a device or a service or or a piece of software that you ship, then you have to get a paid license. And once you have a paid license, you pay about 1% of your end user revenue. And once a year, you audit what software you're using and you tell us, and that's compliance.\u003C\u002Fp>\u003Cp>If you do the audit, you write a check, and you're done with compliance for the year. Now this is gonna be really important to companies because right now they have $7,000,000 per year open source compliance departments, and and some of them would actually spend less on post open. So now we've got a revenue stream. Okay. We give that revenue back to developers.\u003C\u002Fp>\u003Cp>One of the ways that we do it is we instrument their Git repositories and we see who the contributors are. And we've seen from our users what they're using, and thus, we have some idea of how to apportion the money and give it back to the developers. Now in practice, this is more complex because there are people like colonel janitors and architects who might end up having time cards because you don't measure them by lines of code. So we're paying these people. We can also start paying them to write applications for the common person and start to reach that market and maybe displace some of the people who aren't working in the interest of that kind of person today.\u003C\u002Fp>\u003Cp>The other thing that we can do is post open is a collection. It's all the software that you put under a post open license, and we can offer support for the entire collection because there's a centralized organization behind this. And the centralized organization offer support for the whole post open collection behind the scenes uses the project maintainers to do maintenance, but they aren't talking to the support customer directly anymore, and they'd be more comfortable that way. They're only in the support business to make money. We funnel the support revenue back to them as well.\u003C\u002Fp>\u003Cp>So this is more complicated. It has PR and trust issues because there is a central organization and everyone has to trust it. If it forks a hundred different ways, it won't work for everyone for anyone. It's a very complex idea. I sat down and I wrote the post open license and it was 325 lines.\u003C\u002Fp>\u003Cp>And there are actually 4 more documents that go with it. Okay. So there's one for the paid user. There's an operating agreement among the developers, and there's a process for infringers to come back into compliance. So I will end up with well over a 1,000 lines between all of these.\u003C\u002Fp>\u003Cp>Fortunately, you don't have to read all of them, just the one that applies to your situation. This may be too complicated to ever happen. This may not gain share, but I think it's an interesting idea. And one of the ways that I would win over the current open source developers and companies like yours is you can dual license post open. So you can continue to be open source, but anyone who's paying for post open now is has got your open source under that agreement and you start getting paid the open source, they start getting easier compliance support, etcetera.\u003C\u002Fp>\u003Cp>So, you know, consider a company like yours, when you started today or tomorrow with PostOpen, you could say, I'm going to invest in developing this software, and I'm going to get a lot of users through PostOpen, and I'm going to get revenue through that paradigm. And all of my software can be disclosed. It can be free for everyone for whom it counts that it's free. You know, once you make over $5,000,000 a year, it's not important that something's free any longer. And, so I think there are a lot of reasons that this is very compelling and I'm actually getting very little pushback on the idea that the pushback I'm getting is, well, today, open source is mostly business, and Bruce doesn't realize that.\u003C\u002Fp>\u003Cp>Well, that's a symptom. That's not the way it should be. So I'd I'd love to hear, you know, how you feel about this, whether you think it's a total pipe dream.\u003C\u002Fp>\u003Cp>Speaker 2: Yeah. You and I spoke\u003C\u002Fp>\u003Cp>Speaker 0: about this, Bruce, for a while. The the show is called Bridging Bites, but I think you just bridged questions. Because I think you actually that was a very comprehensive answer, but it actually was an answer to the next two questions that I was gonna ask. So, that was super, super helpful. Obviously, there's strong alignment with what we've done at Directus with our unique usage grants within BSL.\u003C\u002Fp>\u003Cp>But before I kinda kinda we chat through that, I'm curious, Steven, what what license are you currently using, for for for Dubco? And I guess just and in response to that, sort of Bruce had kinda called out I think you called it frosted widgets, which sounds like a a really fun cereal.\u003C\u002Fp>\u003Cp>Speaker 1: Widget frosting. Actually, Eric Raymond made that up.\u003C\u002Fp>\u003Cp>Speaker 0: Oh, well, we called it icing on the cake model. We actually tried that, And we found we were focusing too much on the icing, which is part the part we sell. And the cake, the open source core, was suffering. And so we actually changed our model to this this new licensing strategy based on having tried that. Again, 2 decades, we've tried a lot of different things.\u003C\u002Fp>\u003Cp>But, Steven, maybe you could give me your your what what license are you currently on?\u003C\u002Fp>\u003Cp>Speaker 2: We're yeah. We're currently on AGPL, which basically means that you can own and host your own, version of Dubb and even keep it close, as long as you keep it open source. If you wanna keep it close source and make changes to it, you have to purchase like an enterprise license. And to to respond to the point about like, you know, monetization and open sources, notoriously really, sort of open source maintainers have been notoriously underpaid and under, you know, loved in a way because there are so many packages out there that's just like people just maintaining it tirelessly, especially if you're not getting paid by a company like Microsoft or Vercel. Vercel does a really good job in in the sense, like, for for, you know, open source repos, like, you know, projects like Turborepo, Next.\u003C\u002Fp>\u003Cp>Js, and a few other projects. But if you're not part of that sort of privileged group of developers, you just generally just go out and compensate it. The way we sort of monetize this, we basically have a SaaS offering that is actually not icing on the cake model. It's 1 to 1 exactly, like if you purchase a plan on that, versus if you self hosted, you get the same exact features, but we're sort of moving towards the direction of what telecom is doing, where if you need, like, enterprise features, like, I don't know, RBAC, where it's like role based access access controls or SAML and SSO, all these different, like, enterprise fee feature features, we will put that behind, like, enterprise license. And if you want to use those features, you will have to, you know, purchase, like, a license key, and that's a very, you know, smart model.\u003C\u002Fp>\u003Cp>It's sort of an icing on the cake model, but in general, like, there's not exactly discrimination if you're self hosting versus if you're, you know, paying for a subscription. There's also another model that I think is really interesting, which is once.com, the one that's launched by the founders of Basecamp, 37 signals. They're they're doing this model where it's like pay once and use forever, And you it's sort of like that whole story of how software is sort of like a pendulum goes from licensing software to SaaS and now back to licensing. So it's a very interesting model. I personally think it's I don't know how, like, sustainable it is, how scalable it is, but I think there's a lot of potential there.\u003C\u002Fp>\u003Cp>And I think as the world thinks more towards, like, privacy, owning own data, I think and as people get more technically savvy and have the infrastructure to do so, I think that's, where this kind of model will will flourish. But as of today, like, I I'm that that's why we're going with, like, the SaaS model where if you really want, like, you know, super easy sign up, create a link, you can just use our SaaS product. And then if you're more technically savvy, you wanna own your own data and privacy or whatever, you can self host it. So that's why we went with that.\u003C\u002Fp>\u003Cp>Speaker 0: Yeah. And that's a that's a really strong model. I mean, we again, we had that sort of gated icing. I've I've listened to to Kyle Poyer, at OpenView, RIP, sort of talk about product led growth and usage based pricing and and also how you can gate those features. He had really interesting ideas around how you really shouldn't gate, the features that people real are gonna resonate with users.\u003C\u002Fp>\u003Cp>But, you know, people know what SSO is. They they potentially know what RBAC is and how they can leverage it. So to enable those enterprise features at a as a paid offering, I think is a really smart way to do it. It it it's, you know, just really up to you. Like, does that work for your business model or not?\u003C\u002Fp>\u003Cp>Does that sort of unlock enough commercialization or not? But yeah. No. That's, I think that's really interesting. Do you have any thoughts before I wanna switch into the sort of q and a.\u003C\u002Fp>\u003Cp>And anybody in the audience, feel free to start throwing some comments or some questions in and then we'll we'll get to them in the the last few minutes here. But, what you had described, Bruce, in terms of post open, you know, name pending, seems almost like a multi tenant version of what we did at Directus. Again, just for those who weren't part of our enormous GitHub discussion where we talked about this in public with the community before we made the license change. We basically said, here's the problem. This needs to be sustainable.\u003C\u002Fp>\u003Cp>Mouths to feed, you know, as Bruce said with the family. Everyone's got families, that need, to be supported. We said, here's the problem. Here's some solutions. One of which was the BSL license.\u003C\u002Fp>\u003Cp>And then we used, interestingly, the same sort of model in parallel with what Bruce said. $5,000,000 and up, and you are sort of this commercial entity that most likely can afford to contribute. You know, again, developers and individuals and hobbyists contribute through code and docs and testing. The large enterprises weren't contributing. So it holds them and makes them, you know, beholden to that commercial license while the majority of users below 5,000,000 can actually use it effectively as free and open source software.\u003C\u002Fp>\u003Cp>We did that in public, you know, with some radical transparency to make sure that everybody understood exactly what we're doing and why. And if there are any other options people had, you know, throw them out there and let's let's consider them. In the end, of course, we went with BSL with that usage grant for if it's under $5,000,000, you're completely good. You know, effectively open source for production, commercial, however you wanna use it. But I'm curious, you know, the model that Bruce described, Steven, would that sort of work for you, the sort of multi tenant?\u003C\u002Fp>\u003Cp>You use a dual license and then potentially, you know, it's it's sort of a unified system or it's it's one centralized, I don't know if if what you would call it yet, Bruce. But this idea of them collecting revenue from the end user, or or fees and then distributing it. I can imagine it'd be so difficult to have, attribution and, this idea of, like, the composition of who which maintainers get how much revenue. There's a lot of questions to solve there. But any thoughts on that, Steven?\u003C\u002Fp>\u003Cp>Just because that's what was my question, like the future of open source. Bruce has sort of pitched this grand idea. I wanna give you a second to respond.\u003C\u002Fp>\u003Cp>Speaker 2: Yeah. I think that's definitely very interesting. We've we've definitely considered that in the past, and I personally have start like, tried to do, like you know, there's this there's this really cool tool called Algora that basically allows you to do, like, what's it called? Like, bounties where if if an open source contributor solves one of the bugs or or reports a bug and fixes it or creates a new feature, you can pay out bounties directly to them using using you just need to, like, mention the bot and say, tip a $100 or something like that, and that's really cool. That's it's a really cool way to do it.\u003C\u002Fp>\u003Cp>We haven't thought much into, like, obviously, being able to take the end user profits and basically compensate officers maintainers, primarily because we haven't really gotten a lot of, like, contributions so far. I think that's something that we want to sort of encourage and do more in the future. We've definitely got a few really good ones, but I think, as of right now, we haven't invested a lot of introduction to that because of that. But I do think there's also a really interesting distinction between software that you can potentially self host and basically, for example, if you're building, like, I don't know, project management software and that is open source, and you basically are able to take that and just run it on your own instance or whatever, like, a cloud provider that you have versus something that would require a lot of, like, usage based like, I think you mentioned use usage based pricing and stuff like that. Basically, if you're building, like, an AI app that requires, you know, OpenAI, API calls, and that basically costs money to maintain, That's something that's a little bit different because it's like you rely on, like, a proprietary, you know, software, and that's why people are looking into also using open source, providers for LLMs as well, like, Ollama, which is a good one, I think.\u003C\u002Fp>\u003Cp>So, basically, there's this interesting sort of bifurcation between open source software that you can easily maintain on your own VM versus one that relies on proprietary APIs, and that's sort of the, sort of we we we're actually currently trying to move away from relying on these, like, providers to something that you can truly own and self host. But but as of right now, it's not fully all the way there yet. So\u003C\u002Fp>\u003Cp>Speaker 0: Yeah. And that's again, I think Bruce mentioned the idea of 80 20 rule. That's something that we we've been using, at Directus for a long time, 10 plus years where we the core software is is aiming to solve 80% of the use case and the functionality. And then the last 20% is, you know, configuration and extensions and and custom code. And that's exactly the problem that was that we were trying to solve is you have these, like, paid API keys and and integration with services that might be paid.\u003C\u002Fp>\u003Cp>So we make sure those all go into the extensions to avoid that exact issue. So, yeah, it's it's interesting to see sort\u003C\u002Fp>\u003Cp>Speaker 2: of that\u003C\u002Fp>\u003Cp>Speaker 0: alignment across all these different things that we've been doing, you know, more siloed. There's a few a few questions here. I think we're over time, but let's see if we can get at least to 1. Alec Bass from Efficient. App had asked a few questions.\u003C\u002Fp>\u003Cp>One was about, you know, how you figure out what is OpenCore versus maybe, the the gated side. I think we touched on that. So let's ask it go through a second question which was, how do you know if someone is using, you know, say, Dubb or Directus privately within their SaaS or within their system without a license. I'll quickly give my take on that because this is something that we have and continue to talk through at Directus. When we made the change to BSL, much like, of course, that was created by, Maria DB with the original author of the license, Hashicorp and Cockroach and Couchbase and Surreal.\u003C\u002Fp>\u003Cp>They've all made that change. That usage grant means that people can use an open source under 5,000,000. But if you're over 5,000,000 or otherwise, how do you keep people honest? You know, we today use an honor system where it's like, that's the license. We hope that you honor it.\u003C\u002Fp>\u003Cp>Typically, if you imagine the people who would be the commercial license over 5,000,000, maybe they're more motivated as a larger company to stay true to the legal document. But we've been also exploring the idea of like a key registration system and telemetry that actually, you know, opt in, opt out for GDPR reasons. But let's understand who's using the software. Let's, you know, error reporting or all these different pieces of information can help you give a sense of who's using your software, how they're using it. But obviously, especially with developer tooling where that network traffic is always monitored and should be, You have to be really judicious in what information you you try to send back to yourself to understand who's using the software or how.\u003C\u002Fp>\u003Cp>Steve, I guess the question was to you at at Dubb. Do you have any thoughts around how you're doing that now?\u003C\u002Fp>\u003Cp>Speaker 2: Yeah. That's incredibly I actually had the had a similar, train of thought as well. We currently don't do telemetry for, like, self hosted versions of Dubb, which can get a little tricky. Like, how do you find people who are self hosting? And that's sort of something that we we want to, like, try and do and bake it into our license in the future where it's, like, it's completely anonymized telemetry simply just to detect, like, how much link redirects that you've used within your self hosted version of Dubb.\u003C\u002Fp>\u003Cp>That's 1. And then secondly, I wanted to point out, it's very interesting. Recently, we found a few, like, clones of doubt. They basically took our repo and just ran, like, a commercial service that's completely closed source, and it's, like, a full violation against our license. So that was something that very interesting that we had to deal with.\u003C\u002Fp>\u003Cp>We had to, like, I was consulting with my legal counsel, and we wrote, like, a letter to the the hosting provider and say, you know, this is sort of like a DMCA takedown because they're not compliant with the license. So there's a lot of, like, I feel like dealing in open source sort of makes you like a like a legal candidate. You can you can basically, you know, pass the bar now. You know? You learn a lot of these, like, legal stuff, and I definitely learned a lot myself, in terms of, like, evaluating different licenses.\u003C\u002Fp>\u003Cp>And I think telemetry is a very good point that you that you pointed out, and I think that's something that we definitely wanna go, in the future. Think cal.com does that really well too. They they basically log, the number of bookings in, like, the the open source self hosted versions that people run-in their servers. And if you cross a certain amount, that's when you need to have, like, enterprise license. It's really smart to have that threshold, as well.\u003C\u002Fp>\u003Cp>So yeah.\u003C\u002Fp>\u003Cp>Speaker 0: Yeah. No. That that's a that's a huge point.\u003C\u002Fp>\u003Cp>Speaker 1: Go ahead, Bruce. So my consulting business, helps the infringer come back into compliance. So this is the company that used open source outside the license, usually got caught, and, now they have to fix it preferably without being sued or spending too much money. And one of the things that I really find surprises to companies is the community knows what is in your compiled software, that out in the open source community, not only the developers, but their users will see something comes out and they'll say, oh, well, this functionality looks like such and such an open source program. And they look inside, which is easier than a lot of people realize, and they see it's there.\u003C\u002Fp>\u003Cp>I have in fact found my name in a number of commercial products. And so, if if you make a distributed product containing open source, you're gonna get caught, especially if it's a consumer product because the consumer products are the ones that a lot of people see and care about. It might not happen quite as often in the b to b In a, software as a service business like Dubb, it's a little harder because you might have to look at things like, well, what are the Internet responses here to HTTP, etcetera, and say, well, that's exactly the way that my software would do it. But it it is much easier to get caught than anyone realizes, and it usually happens. Now\u003C\u002Fp>\u003Cp>Speaker 0: There will always be workarounds. Right? Like, whatever sort of pricing model or licensing system you put in place or telemetry that, you know, you can always just air gap it, turn off your network, and, you know, it's easy to work around all these things. So you have to incentivize users to do the right thing. And hopefully, you can do that by just having an amazing community and premium software that works well and people want to see continue.\u003C\u002Fp>\u003Cp>But, yeah, it's a it's a very slippery slope. I think it's it's really interesting to see, like, how this will progress in the future. We touched on post open, Bruce's idea about, you know, how this could be centralized and sort of funded, in a multi tenant way. We touched on, like, the direct us and and to an extent how Dubb is doing it. I can think Dubb is a little bit more, Steven, correct me if I'm wrong, but sort of this, open core model where you're taking the same software, but you also have, paid features that are gated on the enterprise side and trying to identify exactly what goes in that bucket, and selling those services.\u003C\u002Fp>\u003Cp>And then Directus, we've kinda got that unique BSL license similar to kind of both sides, where we are trying to say, you know, the larger players, let's make sure they can shoot contribute. It's an honor system. But at the end of the day, I think what we can all agree on is whatever license or strategy becomes sort of the the really the holy grail of of open source or post open or or free and open source software, whatever the names and terms are, it needs to have critical mass. I think we've seen that in the naming conventions decades ago. We're seeing it now.\u003C\u002Fp>\u003Cp>It's really difficult with, you know, the the directest license, you know. It would just be so hard to get, traction there. So whether it's post open or BSL or some, you know, flavor or anything in between, we need we need to get that critical mass. And, of course, that comes with a lot of complexity. We talked about the legal complexity and cost of getting, you know, attorneys to sort of review these documents, trying to make it succinct so people can read it.\u003C\u002Fp>\u003Cp>Bruce, you touched on having a lengthy license and how do we sort of distill that down to something that, both legal and developers can, you know, if you're not a lawyer, you can still understand exactly the implications of the license. There's so much sort of at stake here and there's so many people working on how we can solve it. But it's really exciting to have both of you here on Bridging Bites talking about, you know, what this could look like. I think it's gonna have to be a little bit of a TBD to see where we end up. Lots of great questions in the, in the audience.\u003C\u002Fp>\u003Cp>Sorry we didn't get to get to all of them. But hopefully we'll be able to circle back on one of the future episodes episodes and cover some more. And of course, we will start texting some of the folks in here and see if we can give some manual responses as well. But I did want to thank, Bruce Perrons, and Stephen Tey for joining, this episode and talking about the past, present, and future of open source. Thank you everybody for for watching, and we'll we'll make sure that this is recorded so everybody can can catch up soon on, Directus TV.\u003C\u002Fp>\u003Cp>So that'll be super exciting. Thank you both for joining.\u003C\u002Fp>","Let us kick it off. So this is the second episode of Bridging Bytes. This time, we have we have bridged from the last episode of the intersection of design and development, and now we are talking about, the open source Outlook. So, obviously, a very important topic, something that's near and dear to my heart, having worked on Directus now for 2 decades, over half of that as an open source maintainer. And then we have some amazing, guests here that are gonna be leading the chart in terms of this conversation. So I'll be moderating the the chat. I can give a quick background, and then I'll introduce our 2 our 2 guests. So, my name is Ben Haines. I am CEO and founder of Directus, the open source, data management platform. And I've been I built the platform originally in 2004, and we actually open sourced it in around 2010, 2011. So we'll get into more of the history of of what we did in our open source journey. But, I'd like to next introduce Bruce Perrons, who is sort of the the godfather, I think we were calling him, of open source. Bruce actually created the open source initiative, which I think was in 1997. Give her we'll let him 87. When was it? 1987 was the creation of the open source initiative in the open source definition. And the document actually came about, I think, 8 months before, it was then the Debian free software guidelines. Yep. Obviously, there's some interesting aspects of using the word free versus the term that was actually chosen, which was open source. But yeah. So we have Bruce Perrons here, who is the cofounder of the Open Source Initiative. And, you know, great thanks to your work, I believe, within, Debbie. Basically, Bruce, why don't you give a quick, overview of your background and and and what brought you here? I I'm sorry. It really was 97. I'm just going over the calendar in my head. So, 87 was actually when I got to Pixar, and, I started as a filmmaker, was one of the founders of computer graphic 3 d feature film animation, and worked at Pixar and their predecessor in New York for 19 years in total. Have a credit if you go on IMDB on a couple of films. And in, 97 we'll get that right now. I wanted to define what Debian, included, and we created something called the Debian free software guidelines. And then a little later, a group met and said, well, let's market free software to business and call it open source. And, so that happened. And I was called up the next day and I said, well, great. I'll take my Debian free software guidelines and make them the open source definition. And so there we go. It's been a long time, and it's been incredibly successful. If I had said to you, back then, we're going to, give away our software and completely take over the industry by doing it. And we're going to make an encyclopedia, and it's going to be the first thing to put a Microsoft product and Carta out of business. If I had told you that, you would have just said, well, I wanna smoke that dope too. So, so it it's been a long strange trip. Hasn't it? Yeah. Well, I here I am sitting here, you know, so excited to be 20 years in, to the entirety of my project, Directus. And you've got, you know, 20 years under your belt just, you know, with, you know, elements of your your history. So thank you so much, Bruce. It's really exciting to have you here. Lots of knowledge, obviously, spanning back to the the mid nineties and even before with, you know, your work on those projects. I think next, I'd like to introduce Steven Tay who's joining us. Stephen, I'll let you give a quick background from what you did with with Vercel and what you're doing now at dub.co. For sure. It's an honor to be here. I feel incredibly humbled by the the the wealth of experience that you guys bring to the table. I think Bruce was talking about how he he he did that DBL thing in 97. I'm like, that was the year I was born. So it was like a little bit of a it it feels very humbling. But, yeah, my name is Steven. I was, a developer advocate at Vercel for the last two and a half years. I started in 2021. It was there where I got, introduced to the open source community, got to actually learn and became a better developer. Before that, I was doing a lot of, like, data science, coding in Jupyter Notebooks, not really building any, like, software that's used by the end user. So I I learned a ton through my time at, Vercel. I built a lot of open source templates, open source, guides technical guides that people can use to learn about Vercel's technologies like Next. Js, Turbo, Rebo, etcetera. And, it was actually through Vercel. So we we dub this company that I started back in December of last year, it came about as a side project that I built when I was at Versal. I I had this need to, like, be able to share links, on on social media with really nice preview images, and it started from a very niche use case, but then eventually blossomed beyond that into a full link management tool. So, it was in December when I when I started talking to a lot of our users and realized that the market opportunity behind Dubb, It's a start company around it, and here we are. I love that. Thank you so much, Steven. That's a it's an awesome intro. I mean, obviously, we have, you know, different levels of experience, with open source, with building, but that's kind of how open source works. You know, you've got maintainers and contributors and users. You have some projects that are out there and they're just small little packages or libraries like an SDK, you know, with one hobbyist sort of kind of maintaining it on the weekend versus things like Directus and, you know, even larger operating systems or platforms supported by tens or hundreds of developers. And I think, you know, in the last few years, we've seen all sorts of things happen, that really showcase the importance of of open source, vulnerabilities like Log 4J or just the the escalation of different open source platforms, like, really taking hold in the ecosystem. So it's obviously a very timely conversation. Specifically, my passion is around I I've spoken with Bruce for a while about this actually, is about how to build I think it's a nice acronym, SOS, but sustainable open source. Of course, SOS being, you know, talking to how important this is to get right and to do it timely. But I think we can kinda dive in. The purpose of this, Bridging Bytes episode is really to talk about this theme of open source, past, present, and future. You know, we we, of course, have Bruce here to to really help us understand the roots and how this came to be. We made our our platform open source a decade ago, you know, obviously based on the WordPress license using GPL. And then we are we relicensed about 10 months ago. So there's all sorts of things happening in the past and present. And, of course, you have to be really mindful of where do things go next. You know, how do we actually make open source sustainable? I've heard some pretty interesting ideas from Bruce that I'm sure he'll share around his ideas of what he's calling post open, at least as a working title for now. We'll figure out what that might look like. But, yeah, so I think we should we can dive in. And my first question would be for for Bruce. Bruce, I'm curious, in all the experiences that you've had, maybe you could share how those have shaped your views, of the evolution and impact of open source over such a long tenure over over these decades since 1997, not 87, but through now. How do you think that those experiences have shaped, you know, your views on on that evolution? Well, I should just say a long, long time ago as if I'm telling a story because it feels like forever. But, so I I started out, working for a film company, and I I had fun. I mean, we did something for the first time. You know, we we made our IPO. They let us have our IPO at the same time that we put out the first three d feature animated film, which was crazy. And so it it was a really interesting ride, but I started at this point to work on Linux because, we were using Unix at Pixar, and the PC was coming out. The PC started to be capable of running Linux. And then, Steve Jobs for a while had his office right across from mine. This was not because I was important, but because they wanted to keep an eye on me. And so, one day, Steve made his peace with Bill Gates, and the next workstation stopped being on Steve's desk, and there was a Windows laptop. And Steve would tell us that, you know, eventually, we'd switch off of Unix, and we'd all be using Windows to do our animation. And no one was very happy with that, and especially then because before Linux was really big, the quality of Windows was very poor because they could afford to have very poor quality. They were essentially the only game in town. And so I started working on Linux and tried SLS and a few other things, you know, ancient distributions, and and then landed on Debian. And at the time, my idea was making a Linux system for amateur radio operators, ham radio. And the reason for that was there was a lot we could do with software, and I thought we could put it all together. Well, that never happened, but I became Debian project leader along the way. And I think it was becoming more important than my work at Pixar. And the real moment for me was one day I got an email from someone and they said, I wanna use Debian with a serial console. Do you can you tell me how? And that wasn't a feature at the time. And I thought it was interesting, and I I sat down at Pixar, you know, when I should have been working and figured out how to do it and sent this fellow an email. And he wrote back and said, that works great. This is going on the next space shuttle flight. And so I walked all around Pixar looking for someone to tell this to. The only person there who knew about Linux was working from home that day. And so, it came a time when people would say to me, well, you're having such an exciting life. You've come out with a film, and your company has an IPO. And isn't this so exciting? And I'd say, yeah. But my hobby project is orbiting in space. And at that point, I sorta decided maybe I would eventually leave Pixar and work on Linux and open source full time. And so we have had a history of that sort of serendipity. I mean, the hobby project of a students. You know, Linus was a student and maybe a lecturer, takes over the operating system world, and the industry software is taken over by amateurs who give away their software. I mean, at this point, none of them were working for companies. And IBM abandoned AIX in favor of this hobby project. So all of these amazing things were happening and why the world was ready. There was a a market vacuum, and this came along and filled it. And people don't realize that this is all straight economics. It's it's no you know, some people call it freakonomics, but there's nothing freaky about it. It's just economics. Yeah. I mean, it it goes without saying, you know, by some estimates, you know, open source power is 80% of modern code. So, you know, there's quotes from people over at Google, Filippo Valsorta, who had said something. I've had this quote here. He said, open source software runs the Internet and by extension the economy. And I think that kind of really qualifies like how large open source has become. Obviously, in the early days when you're working, on defining it, Bruce, there was all sorts of there was the, I think you mentioned in Debian, you had the Debian Social contract, in 93. And there's the SPI, which was, you know, software for the public interest. You did the OSI, the Open Source Initiative. There's all sorts of, like, what's the term gonna be? What are the rules? How do we, you know, really label these things? And what we got from that is essentially ten sort of rules or guidelines for what is open source, which is right there, you know, on opensource.org. It was how did you guys come up with those 10 terms? I mean, I I I've looked at them quite a bit because we have an open source source spirit. You know, our ethos has been that since the beginning. But, of course, with a license change and trying to stay true to the terminology of source available versus open source versus whatever new terms we come up with, there's always gonna be those 10 terms sitting there within the OSI. So was that was that an easy or difficult thing to, you know, sort of memorialize for the world? Well, first, I don't wanna take all the credit. We are standing on the shoulders of Richard Stallman and the free software movement. And, Richard and I were actually speaking at a UN Summit in Tunisia, and I said we're standing on the shoulders of Richard Stallman, and he goes like this. And so, I think that we've had a lot of, different words for what we're doing. And because of that, the concept of having a brand came up. You know, there was free software and there was Shareware. Remember Shareware? And Shareware and Freeware. There was, like, all the wheres. And it's interesting thinking of, like, how the word free left. Like, you still have thos, you know, free and open source software. But, you know, the freeware versus open source and the difference in perception, again, something that we deal with when we're now selling licenses for, you know, we've for years, been selling licenses for open source software through our cloud SaaS and, you know, breaking the perception of from free to paid is an interesting gap to kind of, cross. But So so I'll give you another word that everyone's forgotten, consortium. It used to be that real software products were made by consortia, which was a collaboration of companies. And the problem was that they all had their own different interests and that the engineers did not control the operation. So the consortia had a lot of trouble getting along. And my very favorite, consortium story is the X Window System Consortium decided one day that they would not have a canonical user interface for x. And Microsoft, of course, ate their lunch because they did. And and what the x consortium was trying to do at that point was allow each of the different Unix workstation manufacturers to differentiate their work station and also to lock in their customers by having a different user interface for that version of Unix. And they didn't realize that if they didn't work together, Microsoft would just take over the market and, you know, go find a Unix workstation today that isn't a a Linux or BSD system on a PC. So we had all of these economic issues, and we also had the need to create a brand. And so the open source initiative came by because, in Debian, we wanted to say what Debian was, and also we wanted to elucidate our social contract with the community. And so we, wrote the Debian social contract and the Debian free software guidelines. I sort of created and edited it, and we had a 1 month discussion with the Debian developers about it and then publish the results. And this, part of it became the open source initiative, definition. The Debian social guidelines is still very prominent on the Debian site, and you can see the other part that became the open source definition at the end of it. Yeah. No. And that's something I think referred to quite a bit, especially as new licenses come out, you know, making sure they check all 10 of those boxes, to truly call themselves open source, you know, and not have some big glaring asterisk. Yeah. That's it's amazing just to hear the history of, like, all this tumultuous, like, what is this you know, there's just a huge landscape that was not defined. So it's exciting to hear it was defined. Same issues that we're still facing today in terms of how you get financing and make sure you have an authoritative, list of of defining what this is, and that that's being, fostered by people who actually care about what it what it's supposed to mean and not just guiding it based on commercial endeavors. Steven, I'd like to, start over to you. Obviously, you've had, 2 sort of key roles that that you highlighted in your intro. Obviously, going from DevRel over at Vercel, to now founding, dub.co. I'm curious how your perspectives of open source, you know, in the development of those those open source projects has changed, and evolved over that transition of your your career. Yeah. For sure. I think there's there's definitely been quite a shift in terms of, like, the way open source, I guess, the way we view open source personally. But one thing has always stayed true, and I can go through the distinctions there. So when I was at Vercel, we basically maintained this fairly popular React framework called Next. Js. It's basically a framework for you to build with React, service side rendering, and basically an entire full stack applications with batteries built in, like API routes. You can even do stuff like, having a middleware to do redirects, rewrites, and all these different things that regular React would, you know, it'd be harder to build with that. And through Next. Js, it we were able to tap into a massive customer group and and not, I guess, not exactly customers, but, like, potential users that could be converted to customers. Folks like, let me see here. Like, folks like, Netflix. I I I remember tweeting at one time that 4 of the world's largest streaming platforms, Hulu, max.com, Amazon Video, Netflix, they were all using XJaaS, which is kinda cool to see. And, through that sort of, I guess, user base, we're able to expand our enterprise, pipeline because we are able to tap into engineering managers who are using X. Js and and sort of pitch them our host of solution and give them a sort of white gloved approach to spinning up and and maintaining that Next. Js applications. So in that sense, the symbiotic relationship between Next. Js and Resell was very clear. It was like, you know, you have this open source framework, MIT licensed, and you have this proprietary hosted solution that basically, does your Next. Js hosting for you, and you have you have to worry about stuff like Kubernetes maintenance and stuff like that. So that was that that sort of relationship was very interesting. And the work that I did there was also sort of different because, I wasn't working a lot on Next. Js specifically. I was mostly more working on developer efficacy, which is building open source templates, and that sort of, like, drew me to gravitate towards another side of open source, which is building templates and also products that are open source, but at the same time, licensed under AGPL, which would give you, the the maintainer or the the company behind the project a certain level of ownership and control, over how the prod the the code is distributed. So, that sort of drew me to to basically build Dubb as an open source, first project. It started as a project, and it's it's our company. And, so the relationship here is slightly different. Right? It's it's more of a we we call ourselves a cost, which is like a commercial open source, software, which is similar to what, for example, MongoDB started back in the day with, like they had their open source database system that people can easily clone and just run it themselves. And then now it sort of evolved into the wave of, companies like cal.com, which is an entirely open source company sorry, open source product that's, they have their repo, it's out in the public, and they also run that for the hosted service. And they also have, like, a directory that is enterprise only. So if you want to use code in that directory, you would have to buy an enterprise license. And that's sort of the direction that we're going towards, and it certainly has changed quite a bit about how I think about licenses, how I think about getting contributor permissions, and stuff like that. There's so much nuance to to this whole ecosystem that, honestly, I'm still trying to figure out. I'm working with a few lead councils to understand where we should be, you know, what sort of precautions should we take, what sort of, licenses should we potentially change to in the future. So, yeah, very excited to to to discuss this with you guys more and and sort of get your thoughts and and advice on this this whole, space and how we we should move forward. Yeah. No. That that's awesome. I think I mean, I've seen I've lived several of those different iterations of, like, how you commercialize, how you make that more sustainable. Seemed like you were describing sort of like an open core model. Sometimes, you know, you can also work that and call it like an icing on the cake model. There's also the support, like the professional services where you have almost like an agency that leverages it and to get that support and the authoritative maintainers, you know, access to them. That's a paid service. Of course, that can be difficult to scale because you have to scale humans, and not just scale the software out, as you distribute it. So it's interesting to hear, you know, all the different methods. And it kind of ties me into there's a few other questions I'd like to run through before we open it up to the audience. But maybe we'll we'll rapid fire these so that we can actually make sure we we work our way through it. But I think the next one that I think is interesting in this, you know, mid nineties all the way through the mid 20 twenties, where we are now, what would you either of you say are some of, like, the biggest milestones that have significantly impacted this open source landscape? You know, whether it's for maintainers, users, and awareness of, you know, open source as a whole. I'm just curious. I'll I'll leave that pretty broad. But any big developments or milestones that, you guys can think of regarding open source? Well, I'll talk about myself. In 2005, I wrote a paper called the emerging economic paradigm of open source. And I think that it's very relevant to business and so called costs or commercial open source businesses because it explains how the economics work and goes into the business differentiator of your business. And every business has differentiators, which make their business appear different directly to the customers than others. And, you know, one of your differentiators is you've got dub.c0, and other people have 7 or 8 long, character URLs. And so, we can open source everything but our business differentiators and collaborate with our very worst competitors on everything but our business differentiators because they're probably the people who need the same infrastructure we do. But we shouldn't open source our business differentiators until they rot. And over time, they will no longer be differentiating your business because other companies will have them. And at that point, it makes perfect sense, for that to be open source. So I think this perception of where open source could actually fit in a business and that you were not creating economic suicide and joining the communist workers' paradise by, taking it up, was a a very important one, and and I think that it was pioneered by the big Internet companies. And so when Google and others take up open source, everyone else notices and says, well, these guys are making tons of money, and maybe there's something we should do there too. Another thing I talked about in that paper was a sort of 80 20 phenomenon, which is 80% of the software in your business is non differentiating. So you have a choice of how you make it. You can build it yourself because you have not invented hear disease, and you think everything you do in your company is better. This used to be a a more prevalent thing than it is today. Or you can get it from the open source community. So say you use open source to reduce the cost and risk of developing that 80% of non differentiating software. You take the money that you saved on that, and you move it into making your business differentiators better. And it was the development of economic perceptions like this that I think made it smooth for a company to participate in open source. And and I'm not taking the credit. I think everyone could have made the same observations. But if you, go back and look at that paper, I think it's still very relevant to businesses today. Yeah. No. And certain certainly a large milestone. Steven, any thoughts on other other milestones in the open source world? Yeah. I'm I was struggling to come up with one because, I'm fairly new to that open source space, but I I just wanna comment on what Bruce mentioned. I think it's very, very, interesting to hear about that 80 20. It's sort of like the paradox principle where you you take the the you basically leverage open source as a way to collaborate with other amazing developers. And I feel like for us personally at Dubb, the 3 sort of main benefits of being open source is 1, you get to tap into this massive talent developers and people that are, you know, constantly, contributing to open source code, and as a result, your code base becomes more secure. I believe Mark Zuckerberg came up with this quote in an interview a long time ago is that open source software is generally more secure. So that's one. And secondly, there's also the aspect of tapping into larger enterprise customers that you never would have been able to work with if you're not open source. So in our case, Dubb is actually used, we're currently working with the government of Malaysia, which coincidentally is where I'm from, to basically, they're they're forking our our code base to build, like, a official government link shortener for the employees to be able to use, and that's something that we could never have done if we were closed source and they will have to subscribe to our software. So that's something that's really cool to be able to collaborate with all these different, like, agencies that have much larger, like, bureaucratic red tape, stuff like that. And thirdly, definitely the the aspect around open source and the trust and transparency that goes into it is also massive. Like, you cannot just be putting spyware or, like, you know, like, ads and, like, what's it called, privacy invasion software into your code base just because you wanna, like, track your users or, like, I don't know, find a way to sell ads and stuff like that because your code is fully out there and people are scrutinizing it. So and as a result, like, companies are willing to trust and use the software more and goes through procurement much easier than if it was closed sourced. So Yeah. I feel like those are the 3 that we've seen so far. Yeah. It's interest yeah. And I it's interesting to think of how much trust you can get. You've made your source available. You've made it open source, you know, through the license. These these steps are amazing to make to give you the transparency you need, which as you said, like, there's no hidden code. There's no black box, and it's like, oh, what happens there? You're sending, you know, telemetry back to the mother ship or something weird and you're just unaware. But it's interesting that that transparency, while it does give you the ability to audit the code, you know, we at Directus were actually in use in the public sector. So the Department of Defense in the US and the Department of Energy. You know, we couldn't really do those things if they couldn't see the code end to end. But at the same time, smaller open source organizations, almost always underfunded, really can't afford the security analysis or security researchers, to actually formally ensure that it is the code is audited audited. You know? So auditable and audited are 2 different things. And I think one milestone that comes to mind for me was sort of that big moment with log for 4 j or log you know, from the log 4 shell, vulnerability where people suddenly were very aware of how reliant, everything in the world was to open source, you know, specifically this one package. But, that I think was a really big moment for beyond just open source maintainers that are aware of their own value, of course, but everybody leveraging their systems to be also aware of how critical open source is to what they're building. So It's crazy. It's I was chatting with this, the he's a product manager at TypeScript of TypeScript at Microsoft, and, we were talking about this, it's a funny analogy where that's I think it's like the what's it called? Like, p k p x p xcd comic or something where it's like p xcd? SKCD comic. Exactly. Where it's like this entire world that's, like, balancing on the shoulders of one big wall. Yeah. It's a very famous it's a very famous one. You've got this, like, Jenga Castle, and then suddenly there's, like, one little piece that could not be removed, which is They buy a hobbyist in Ohio. Yeah. So exact exactly. It's one of the probably the most popular xkcd comics if if editing can, like, toss it somewhere on here so everybody can see what we're talking about. But, super, super interesting to kind of visualize exactly what we're talking about here. And I think before, you know, some of those bigger vulnerabilities, people just weren't aware of it. Now they are, and, of course, we're trying to remediate how do we solve that. Not always the easiest thing to resolve, but I think the visibility and awareness of, open source, whether it's commercial or free or otherwise, it needs to be sustainable. This is not only a hobbyist project for people. This is, you know, supporting big enterprises and and therefore, you know, big parts of the economy. I think there's another point that's really important about security especially is that the size of the code base that we use increases exponentially. So when open source started, a 100000 line code base was a large code base. Debian, I think, is now 1,500,000,000 lines. And so as the size of the code base increases, of course, the attack surface increases as well. And, thus, we are now at the point where no company can look at everything with their own employees regardless of the size of the company. To your point, Bruce, the scale of everything is getting so big. I mean, I forget figured was it called everything or whatever that NPM package was that had a dependency of everything? The dependency trees. You know, when we go through our institutional financing, there's big checks to make sure that we've done everything appropriately, and you have to provide for your software the full dependency tree. Those things just get so enormous, you know, to your points. Everything depends on other things. And then you have some crazy joke, like, whatever that everything package, I think that's what it was called, That suddenly you can't remove because it is a dependency on so it becomes very complex very quickly. And how do I get out of this complexity and make things sustainable? I I guess it's sort of the next question Yeah. That I'd love to cover is, you know, you have these open source projects, hobbyists or otherwise. Obviously, we're talking about how heavily relied upon they are. How can those projects and maintainers transition to commercial viability, to sustainability, to supporting themselves? And as the project grows, again, myself and Drake, you know, created this, you know, 10 years ago. We were working on it together, just the 2 of us, as an open source org. Now there's 30 people at the company full time that it takes, to kinda support this this project. Those are full time salaries. That's a big, big cost. I'd love to hear your, both your thoughts on how these open source projects can transition to, a you know, to be commercially viable. Well, I think they do it kind of poorly today. And so let's take support because support is the way that a lot of companies try to make money, and open source companies don't do support very well. Why is that? Because they support their own program. Okay? Now say you're a customer, an enterprise customer, and you have 200 important open source programs in your business, then maybe you have 200 support entities. And your job when a bug comes up is to isolate the bug, figure out which of those support entities to call, and then convince them it really is their fault while they all point at each other. And so, open source support, I don't think works all that well, and people get IBM support contracts because IBM says we're gonna support everyone. So that's one of the big problems that we have. Saying support is not a good option. What would be, like, what would be a an actual like a viable commercial option then for these maintainers to, bootstrap themselves? Well, continuing to talk about how open source does it today, we also have the widget frosting paradigm, which is you take a, open source thing and then you sell a proprietary enhancement to it. And so that is the way I believe that your company operates beside its support revenue and that a lot of companies do it. You don't have to do it right now in Dubb because you own Dubb. But if you had a whole lot of different, link aggregation companies doing the exact same thing, you'd have to sit back and say, well, I'm gonna have to strategize again. So we've really been doing open source for a long time, and it is time to sit back and re strategize open source to achieve some of the things that we haven't achieved. Okay. So number 1, if the developer does not work for, one of these companies like Google that actually pays developers to do open source, they're probably not compensated. If they don't work for Google, they don't work for your company. And I've had people say to me, well, open source is mostly in companies today. That's a symptom. It's a symptom of the fact that there's no other way to support your family than working for one of these companies that pays you to be an open source developer. Okay. Another problem that we have is we only program for ourselves, and this is actually a diversity, equity, and inclusion problem is we're great systems programmers, and we make really sophisticated applications for people like us. And thus, the the person on the street may not have heard of open source. They probably heard of blind. And if you look at what applications they're using, they are using applications on their phone from Apple and Google, and the infrastructure of those things is open source. So Apple and Google, you know, they they consider the customer to be the product, and the main way that they make revenue is surveilling that customer and presenting advertising to that customer. And, so what we see is that the customer is somewhat abused by these companies, and we enable it. The open source community provides all of the infrastructure for it. So here we are with a world where privacy is concerned while open source stands for privacy. Security is a concern, and and we stand for that too. And why aren't we making the applications that everyone uses? Because the developers want to write for themselves and people just like them. And so, well, maybe we need to pay those developers so that they're right for other people. So I I sat down with these ideas and said, okay. Maybe it's time to transition beyond open source to something I call post open. And that may not be the permanent name because the permanent name has to be trademarkable. So post open is free for the person that we want to help, which is the common person, the individual, the small business. This is a business with revenue under $5,000,000. End user revenue has to be end user because it's too easy to circumvent otherwise. You know, when I worked for a film company, they used to tell us, if your film makes a profit, you're doing your accounting wrong. So end user revenue to prevent circumvention. So if you're a company that makes over that $5,000,000 line or you wish to make proprietary modifications or you wish to put the post open software in a product that you sell, whether it's a device or a service or or a piece of software that you ship, then you have to get a paid license. And once you have a paid license, you pay about 1% of your end user revenue. And once a year, you audit what software you're using and you tell us, and that's compliance. If you do the audit, you write a check, and you're done with compliance for the year. Now this is gonna be really important to companies because right now they have $7,000,000 per year open source compliance departments, and and some of them would actually spend less on post open. So now we've got a revenue stream. Okay. We give that revenue back to developers. One of the ways that we do it is we instrument their Git repositories and we see who the contributors are. And we've seen from our users what they're using, and thus, we have some idea of how to apportion the money and give it back to the developers. Now in practice, this is more complex because there are people like colonel janitors and architects who might end up having time cards because you don't measure them by lines of code. So we're paying these people. We can also start paying them to write applications for the common person and start to reach that market and maybe displace some of the people who aren't working in the interest of that kind of person today. The other thing that we can do is post open is a collection. It's all the software that you put under a post open license, and we can offer support for the entire collection because there's a centralized organization behind this. And the centralized organization offer support for the whole post open collection behind the scenes uses the project maintainers to do maintenance, but they aren't talking to the support customer directly anymore, and they'd be more comfortable that way. They're only in the support business to make money. We funnel the support revenue back to them as well. So this is more complicated. It has PR and trust issues because there is a central organization and everyone has to trust it. If it forks a hundred different ways, it won't work for everyone for anyone. It's a very complex idea. I sat down and I wrote the post open license and it was 325 lines. And there are actually 4 more documents that go with it. Okay. So there's one for the paid user. There's an operating agreement among the developers, and there's a process for infringers to come back into compliance. So I will end up with well over a 1,000 lines between all of these. Fortunately, you don't have to read all of them, just the one that applies to your situation. This may be too complicated to ever happen. This may not gain share, but I think it's an interesting idea. And one of the ways that I would win over the current open source developers and companies like yours is you can dual license post open. So you can continue to be open source, but anyone who's paying for post open now is has got your open source under that agreement and you start getting paid the open source, they start getting easier compliance support, etcetera. So, you know, consider a company like yours, when you started today or tomorrow with PostOpen, you could say, I'm going to invest in developing this software, and I'm going to get a lot of users through PostOpen, and I'm going to get revenue through that paradigm. And all of my software can be disclosed. It can be free for everyone for whom it counts that it's free. You know, once you make over $5,000,000 a year, it's not important that something's free any longer. And, so I think there are a lot of reasons that this is very compelling and I'm actually getting very little pushback on the idea that the pushback I'm getting is, well, today, open source is mostly business, and Bruce doesn't realize that. Well, that's a symptom. That's not the way it should be. So I'd I'd love to hear, you know, how you feel about this, whether you think it's a total pipe dream. Yeah. You and I spoke about this, Bruce, for a while. The the show is called Bridging Bites, but I think you just bridged questions. Because I think you actually that was a very comprehensive answer, but it actually was an answer to the next two questions that I was gonna ask. So, that was super, super helpful. Obviously, there's strong alignment with what we've done at Directus with our unique usage grants within BSL. But before I kinda kinda we chat through that, I'm curious, Steven, what what license are you currently using, for for for Dubco? And I guess just and in response to that, sort of Bruce had kinda called out I think you called it frosted widgets, which sounds like a a really fun cereal. Widget frosting. Actually, Eric Raymond made that up. Oh, well, we called it icing on the cake model. We actually tried that, And we found we were focusing too much on the icing, which is part the part we sell. And the cake, the open source core, was suffering. And so we actually changed our model to this this new licensing strategy based on having tried that. Again, 2 decades, we've tried a lot of different things. But, Steven, maybe you could give me your your what what license are you currently on? We're yeah. We're currently on AGPL, which basically means that you can own and host your own, version of Dubb and even keep it close, as long as you keep it open source. If you wanna keep it close source and make changes to it, you have to purchase like an enterprise license. And to to respond to the point about like, you know, monetization and open sources, notoriously really, sort of open source maintainers have been notoriously underpaid and under, you know, loved in a way because there are so many packages out there that's just like people just maintaining it tirelessly, especially if you're not getting paid by a company like Microsoft or Vercel. Vercel does a really good job in in the sense, like, for for, you know, open source repos, like, you know, projects like Turborepo, Next. Js, and a few other projects. But if you're not part of that sort of privileged group of developers, you just generally just go out and compensate it. The way we sort of monetize this, we basically have a SaaS offering that is actually not icing on the cake model. It's 1 to 1 exactly, like if you purchase a plan on that, versus if you self hosted, you get the same exact features, but we're sort of moving towards the direction of what telecom is doing, where if you need, like, enterprise features, like, I don't know, RBAC, where it's like role based access access controls or SAML and SSO, all these different, like, enterprise fee feature features, we will put that behind, like, enterprise license. And if you want to use those features, you will have to, you know, purchase, like, a license key, and that's a very, you know, smart model. It's sort of an icing on the cake model, but in general, like, there's not exactly discrimination if you're self hosting versus if you're, you know, paying for a subscription. There's also another model that I think is really interesting, which is once.com, the one that's launched by the founders of Basecamp, 37 signals. They're they're doing this model where it's like pay once and use forever, And you it's sort of like that whole story of how software is sort of like a pendulum goes from licensing software to SaaS and now back to licensing. So it's a very interesting model. I personally think it's I don't know how, like, sustainable it is, how scalable it is, but I think there's a lot of potential there. And I think as the world thinks more towards, like, privacy, owning own data, I think and as people get more technically savvy and have the infrastructure to do so, I think that's, where this kind of model will will flourish. But as of today, like, I I'm that that's why we're going with, like, the SaaS model where if you really want, like, you know, super easy sign up, create a link, you can just use our SaaS product. And then if you're more technically savvy, you wanna own your own data and privacy or whatever, you can self host it. So that's why we went with that. Yeah. And that's a that's a really strong model. I mean, we again, we had that sort of gated icing. I've I've listened to to Kyle Poyer, at OpenView, RIP, sort of talk about product led growth and usage based pricing and and also how you can gate those features. He had really interesting ideas around how you really shouldn't gate, the features that people real are gonna resonate with users. But, you know, people know what SSO is. They they potentially know what RBAC is and how they can leverage it. So to enable those enterprise features at a as a paid offering, I think is a really smart way to do it. It it it's, you know, just really up to you. Like, does that work for your business model or not? Does that sort of unlock enough commercialization or not? But yeah. No. That's, I think that's really interesting. Do you have any thoughts before I wanna switch into the sort of q and a. And anybody in the audience, feel free to start throwing some comments or some questions in and then we'll we'll get to them in the the last few minutes here. But, what you had described, Bruce, in terms of post open, you know, name pending, seems almost like a multi tenant version of what we did at Directus. Again, just for those who weren't part of our enormous GitHub discussion where we talked about this in public with the community before we made the license change. We basically said, here's the problem. This needs to be sustainable. Mouths to feed, you know, as Bruce said with the family. Everyone's got families, that need, to be supported. We said, here's the problem. Here's some solutions. One of which was the BSL license. And then we used, interestingly, the same sort of model in parallel with what Bruce said. $5,000,000 and up, and you are sort of this commercial entity that most likely can afford to contribute. You know, again, developers and individuals and hobbyists contribute through code and docs and testing. The large enterprises weren't contributing. So it holds them and makes them, you know, beholden to that commercial license while the majority of users below 5,000,000 can actually use it effectively as free and open source software. We did that in public, you know, with some radical transparency to make sure that everybody understood exactly what we're doing and why. And if there are any other options people had, you know, throw them out there and let's let's consider them. In the end, of course, we went with BSL with that usage grant for if it's under $5,000,000, you're completely good. You know, effectively open source for production, commercial, however you wanna use it. But I'm curious, you know, the model that Bruce described, Steven, would that sort of work for you, the sort of multi tenant? You use a dual license and then potentially, you know, it's it's sort of a unified system or it's it's one centralized, I don't know if if what you would call it yet, Bruce. But this idea of them collecting revenue from the end user, or or fees and then distributing it. I can imagine it'd be so difficult to have, attribution and, this idea of, like, the composition of who which maintainers get how much revenue. There's a lot of questions to solve there. But any thoughts on that, Steven? Just because that's what was my question, like the future of open source. Bruce has sort of pitched this grand idea. I wanna give you a second to respond. Yeah. I think that's definitely very interesting. We've we've definitely considered that in the past, and I personally have start like, tried to do, like you know, there's this there's this really cool tool called Algora that basically allows you to do, like, what's it called? Like, bounties where if if an open source contributor solves one of the bugs or or reports a bug and fixes it or creates a new feature, you can pay out bounties directly to them using using you just need to, like, mention the bot and say, tip a $100 or something like that, and that's really cool. That's it's a really cool way to do it. We haven't thought much into, like, obviously, being able to take the end user profits and basically compensate officers maintainers, primarily because we haven't really gotten a lot of, like, contributions so far. I think that's something that we want to sort of encourage and do more in the future. We've definitely got a few really good ones, but I think, as of right now, we haven't invested a lot of introduction to that because of that. But I do think there's also a really interesting distinction between software that you can potentially self host and basically, for example, if you're building, like, I don't know, project management software and that is open source, and you basically are able to take that and just run it on your own instance or whatever, like, a cloud provider that you have versus something that would require a lot of, like, usage based like, I think you mentioned use usage based pricing and stuff like that. Basically, if you're building, like, an AI app that requires, you know, OpenAI, API calls, and that basically costs money to maintain, That's something that's a little bit different because it's like you rely on, like, a proprietary, you know, software, and that's why people are looking into also using open source, providers for LLMs as well, like, Ollama, which is a good one, I think. So, basically, there's this interesting sort of bifurcation between open source software that you can easily maintain on your own VM versus one that relies on proprietary APIs, and that's sort of the, sort of we we we're actually currently trying to move away from relying on these, like, providers to something that you can truly own and self host. But but as of right now, it's not fully all the way there yet. So Yeah. And that's again, I think Bruce mentioned the idea of 80 20 rule. That's something that we we've been using, at Directus for a long time, 10 plus years where we the core software is is aiming to solve 80% of the use case and the functionality. And then the last 20% is, you know, configuration and extensions and and custom code. And that's exactly the problem that was that we were trying to solve is you have these, like, paid API keys and and integration with services that might be paid. So we make sure those all go into the extensions to avoid that exact issue. So, yeah, it's it's interesting to see sort of that alignment across all these different things that we've been doing, you know, more siloed. There's a few a few questions here. I think we're over time, but let's see if we can get at least to 1. Alec Bass from Efficient. App had asked a few questions. One was about, you know, how you figure out what is OpenCore versus maybe, the the gated side. I think we touched on that. So let's ask it go through a second question which was, how do you know if someone is using, you know, say, Dubb or Directus privately within their SaaS or within their system without a license. I'll quickly give my take on that because this is something that we have and continue to talk through at Directus. When we made the change to BSL, much like, of course, that was created by, Maria DB with the original author of the license, Hashicorp and Cockroach and Couchbase and Surreal. They've all made that change. That usage grant means that people can use an open source under 5,000,000. But if you're over 5,000,000 or otherwise, how do you keep people honest? You know, we today use an honor system where it's like, that's the license. We hope that you honor it. Typically, if you imagine the people who would be the commercial license over 5,000,000, maybe they're more motivated as a larger company to stay true to the legal document. But we've been also exploring the idea of like a key registration system and telemetry that actually, you know, opt in, opt out for GDPR reasons. But let's understand who's using the software. Let's, you know, error reporting or all these different pieces of information can help you give a sense of who's using your software, how they're using it. But obviously, especially with developer tooling where that network traffic is always monitored and should be, You have to be really judicious in what information you you try to send back to yourself to understand who's using the software or how. Steve, I guess the question was to you at at Dubb. Do you have any thoughts around how you're doing that now? Yeah. That's incredibly I actually had the had a similar, train of thought as well. We currently don't do telemetry for, like, self hosted versions of Dubb, which can get a little tricky. Like, how do you find people who are self hosting? And that's sort of something that we we want to, like, try and do and bake it into our license in the future where it's, like, it's completely anonymized telemetry simply just to detect, like, how much link redirects that you've used within your self hosted version of Dubb. That's 1. And then secondly, I wanted to point out, it's very interesting. Recently, we found a few, like, clones of doubt. They basically took our repo and just ran, like, a commercial service that's completely closed source, and it's, like, a full violation against our license. So that was something that very interesting that we had to deal with. We had to, like, I was consulting with my legal counsel, and we wrote, like, a letter to the the hosting provider and say, you know, this is sort of like a DMCA takedown because they're not compliant with the license. So there's a lot of, like, I feel like dealing in open source sort of makes you like a like a legal candidate. You can you can basically, you know, pass the bar now. You know? You learn a lot of these, like, legal stuff, and I definitely learned a lot myself, in terms of, like, evaluating different licenses. And I think telemetry is a very good point that you that you pointed out, and I think that's something that we definitely wanna go, in the future. Think cal.com does that really well too. They they basically log, the number of bookings in, like, the the open source self hosted versions that people run-in their servers. And if you cross a certain amount, that's when you need to have, like, enterprise license. It's really smart to have that threshold, as well. So yeah. Yeah. No. That that's a that's a huge point. Go ahead, Bruce. So my consulting business, helps the infringer come back into compliance. So this is the company that used open source outside the license, usually got caught, and, now they have to fix it preferably without being sued or spending too much money. And one of the things that I really find surprises to companies is the community knows what is in your compiled software, that out in the open source community, not only the developers, but their users will see something comes out and they'll say, oh, well, this functionality looks like such and such an open source program. And they look inside, which is easier than a lot of people realize, and they see it's there. I have in fact found my name in a number of commercial products. And so, if if you make a distributed product containing open source, you're gonna get caught, especially if it's a consumer product because the consumer products are the ones that a lot of people see and care about. It might not happen quite as often in the b to b In a, software as a service business like Dubb, it's a little harder because you might have to look at things like, well, what are the Internet responses here to HTTP, etcetera, and say, well, that's exactly the way that my software would do it. But it it is much easier to get caught than anyone realizes, and it usually happens. Now There will always be workarounds. Right? Like, whatever sort of pricing model or licensing system you put in place or telemetry that, you know, you can always just air gap it, turn off your network, and, you know, it's easy to work around all these things. So you have to incentivize users to do the right thing. And hopefully, you can do that by just having an amazing community and premium software that works well and people want to see continue. But, yeah, it's a it's a very slippery slope. I think it's it's really interesting to see, like, how this will progress in the future. We touched on post open, Bruce's idea about, you know, how this could be centralized and sort of funded, in a multi tenant way. We touched on, like, the direct us and and to an extent how Dubb is doing it. I can think Dubb is a little bit more, Steven, correct me if I'm wrong, but sort of this, open core model where you're taking the same software, but you also have, paid features that are gated on the enterprise side and trying to identify exactly what goes in that bucket, and selling those services. And then Directus, we've kinda got that unique BSL license similar to kind of both sides, where we are trying to say, you know, the larger players, let's make sure they can shoot contribute. It's an honor system. But at the end of the day, I think what we can all agree on is whatever license or strategy becomes sort of the the really the holy grail of of open source or post open or or free and open source software, whatever the names and terms are, it needs to have critical mass. I think we've seen that in the naming conventions decades ago. We're seeing it now. It's really difficult with, you know, the the directest license, you know. It would just be so hard to get, traction there. So whether it's post open or BSL or some, you know, flavor or anything in between, we need we need to get that critical mass. And, of course, that comes with a lot of complexity. We talked about the legal complexity and cost of getting, you know, attorneys to sort of review these documents, trying to make it succinct so people can read it. Bruce, you touched on having a lengthy license and how do we sort of distill that down to something that, both legal and developers can, you know, if you're not a lawyer, you can still understand exactly the implications of the license. There's so much sort of at stake here and there's so many people working on how we can solve it. But it's really exciting to have both of you here on Bridging Bites talking about, you know, what this could look like. I think it's gonna have to be a little bit of a TBD to see where we end up. Lots of great questions in the, in the audience. Sorry we didn't get to get to all of them. But hopefully we'll be able to circle back on one of the future episodes episodes and cover some more. And of course, we will start texting some of the folks in here and see if we can give some manual responses as well. But I did want to thank, Bruce Perrons, and Stephen Tey for joining, this episode and talking about the past, present, and future of open source. Thank you everybody for for watching, and we'll we'll make sure that this is recorded so everybody can can catch up soon on, Directus TV. So that'll be super exciting. Thank you both for joining.","published",[28,38,47],{"people_id":29},{"id":30,"first_name":31,"last_name":32,"avatar":33,"bio":34,"links":35},"a6d7970d-d2f9-467c-bebc-2f30d207b48e","Bruce","Perens","4ef9b646-2752-4e45-ba34-4bd70c13fe33","Founder of Open Source movement in software",[36],{"url":20,"service":37},"twitter",{"people_id":39},{"id":40,"first_name":41,"last_name":42,"avatar":43,"bio":44,"links":45},"5ced2d05-20d5-43c7-8990-455674e1bec7","Steven","Tey","f67066e5-e598-4937-8091-1968f3c57379","Founder of Dub.co",[46],{"url":17,"service":37},{"people_id":48},{"id":49,"first_name":50,"last_name":51,"avatar":52,"bio":53,"links":54},"4f76549a-cebc-439b-98da-cc0568e708a9","Ben","Haynes","8d3aa9f0-f76f-4c77-82fe-0bab6d40ef41","CEO at Directus",[55],{"url":14,"service":56},"website",[],{"id":59,"number":60,"year":61,"episodes":62,"show":65},"d0ae16c8-ec29-4076-87e2-f4e0ef7383ea",1,"2023",[63,4,64],"31c435b5-daf6-47c0-b158-9846dd808982","d7bb19ee-8843-4543-aa2a-b37a66806eea",{"title":66,"tile":67},"Bridging Bytes","41d22af0-1a92-46d9-ae97-dd6228b279a3",{"id":64,"slug":69,"season":59,"vimeo_id":70,"description":71,"tile":72,"length":9,"resources":10,"people":10,"episode_number":73,"published":74,"title":75,"video_transcript_html":76,"video_transcript_text":77,"content":10,"seo":78,"status":26,"episode_people":79,"recommendations":83},"how-agencies-innovate","964703470","A discussion on how agencies source and assess technology, including the process of technology sourcing, evaluating technology for clients and addressing client concerns.","d2ea6ed3-0c8e-4257-b763-45fde6f07a76",3,"2024-07-02","How Agencies Innovate","\u003Cp>Speaker 0: Today, we are doing another Bridging Bytes episode, in the midst of our of our Leap Week, Leap Week 3, over at Directus. So an exciting time for multiple reasons, but, super super jazzed to be here, joined by Steven Majid and or Megitt, sorry, and Nemanja, Nićiforović. We are gonna be running through how agencies innovate, something very, you know, important to me. This is how I kinda got started with Directus, got started in general. So, yeah, we'll be spending next hour or so running through all things agencies, sort of the the primer, the the history of Directus, and then diving into all the, so the nuance of, you know, the overlap between agencies and how you choose your software, how you, you know, build out these projects, oftentimes very, very different projects for different clients.\u003C\u002Fp>\n\u003Cp>So I think it would probably make sense. Why don't we dive in with some introductions? I can go first just kinda lay you know, set the stage for, again, you know, how I got started with Directus, with my agency, that I started about 20, 20 some odd years ago, called Ranger Studio out of New York City. We were headquartered in Brooklyn. It was, truly, you know, going back to 1 of our previous bridging bytes episodes, it was the intersection of design and development.\u003C\u002Fp>\n\u003Cp>So we were lucky enough to do builds for some of the amazing, you know, marketing and design studios out there, you know, IDEO, Wolf Allens, Pentagram, Interbrand, etcetera. And we would work to basically be the hands, to build out their their projects for amazing clients. You know, we worked with Google and Snapchat, AOL, AT and T, the US government, just doing really white glove amazing projects, you know, thus Directus because we needed to find software that would actually fit the bill for all of those. But ran that studio for about 15 years, until it sort of transitioned into into Directus, formally. But, yeah, it was it was a very interesting you know, we'll we'll get into it, I think, more in this episode, but it's very interesting sourcing, technology, especially back then 20 years ago when technology was very different.\u003C\u002Fp>\n\u003Cp>There was far less to choose from. There wasn't as much information about what you were choosing. But that's really how I how I got started with Directus was building software that would make, our internal development more efficient, give us administrative tools we could hand off to those end customers, that wasn't strictly, a head you know, a CMS. They didn't even have have headless back then, or was it something completely custom? That's really what we ended up doing constantly.\u003C\u002Fp>\n\u003Cp>It was just building custom, solutions and back ends for every project, which is inefficient. So today, we're gonna be diving into how people do it today, the modern way of approaching this problem. So why don't we start off, Steven Meggitt, who is over from, if you wanna give give an intro. Sounds good. Awesome.\u003C\u002Fp>\n\u003Cp>Speaker 1: Sounds good. Ben, that was AAA good intro and backstory for, the genesis of of Directus. It seems that, you're not the only agency that started out that way. 37 signals, I think, comes to mind of a similar trajectory. So it's it's interesting to hear that.\u003C\u002Fp>\n\u003Cp>Pleasure to be here, Ben, Manja. Great to connect with you as well. Thanks for Directus for for having me on having us on. So I've been at for, close to 5 years now. I've spent my career designing, developing, and delivering really, really unexpectedly clever customer experiences that generate return on investment.\u003C\u002Fp>\n\u003Cp>I started in 2, 001 in my parents' basement, and then built a small but highly focused digital agency. Ben, you talked about the intersection of design and development. I like to add in 1 more element to that, where my agency was highly, highly focused on research, user experience and design and development. And that eventually led to me growing the the agency pretty organically and built a small but highly focused agency on those elements. And that led to an acquisition by in 2019, to help build out, what was then a, city centric design studio capability, which then was was then grown into a national practice.\u003C\u002Fp>\n\u003Cp>So now I'm a partner in the customer transformation practice, which brings together the work that I do in the studio, along with everything that I'm passionate about, which is helping organizations really build sustainable value and growth by making every touchpoint in the customer journey an exceptional 1.\u003C\u002Fp>\n\u003Cp>Speaker 0: That is awesome. Yeah. And, you know, 37 signals, obviously, that's a great sort of template. You know, was taking very close looks at them back in the day and, you know, III are they still around?\u003C\u002Fp>\n\u003Cp>Speaker 1: Oh, yeah.\u003C\u002Fp>\n\u003Cp>Speaker 0: Yeah. I I get I get whiffs of, like, you know, the there are, different product suites every once in a while, but I can never can never quite tell. Some people are a little bit more ephemeral. But, thank you so much, Steven. That's that's a great great intro.\u003C\u002Fp>\n\u003Cp>Super happy to have you here. Nemanja, do you wanna, run through a quick intro from over at Workinco?\u003C\u002Fp>\n\u003Cp>Speaker 2: Yep. Hi, everyone. My name is Nemanja, and I'm a technology partner at, Workinco. I've been with WorkingCo since December 2013, joined as developer number 4, and, it's been quite a ride. I've been, meddling with almost any technology project that we've ever worked on.\u003C\u002Fp>\n\u003Cp>From Virgin America that, made Working Code what it is, over through NBA, Disney, Google, CBS, more recently Contentful and Decathlon. As far as, my trajectory goes, I started coding, straight out of high school, like 2, 002. And I was always fascinated by hands on work, clean architecture, design patterns, and I was fortunate to have great mentors before Workingco and during Workingco. So 1 of the things that made me stick around for for as long as I have is that Working Group partners, in particular, are very hands on, so I get to do what I love every single day still.\u003C\u002Fp>\n\u003Cp>Speaker 0: Little known. I don't even think we talked about this, Nemanja, but I actually when I was when I moved to the city and I was figuring out exactly where I was gonna be, you know, working next, I actually went over to Work and Co. I knew some of the partners over there at the time, and applied. I was like, I would love to work here. This is an amazing, amazing shop.\u003C\u002Fp>\n\u003Cp>Things went a different direction. I ended up starting my own, my own agency, but I certainly what that is what you described is exactly what resonated with me is all the partners were super hands on. There was no, you know, okay. All these, you know, lower level junior designers are gonna go out and do the grunt work, etcetera. Everybody was really active in, you know, building out, the project.\u003C\u002Fp>\n\u003Cp>And, again, not just amazing clients, but amazing projects for those clients. Excellent. So that's basically intros. I think again, just to reiterate, today, we're gonna be really going through, the agency side, how we how we sourced different technologies, which, of course, can be very disparate. You've got, depending on the agency, some are a little bit more.\u003C\u002Fp>\n\u003Cp>This is, you know, lather and repeat exactly what we do, you know, bread and butter. And then others are more divergent, in in the types of project they take on. And, of course, that means that the tech that you use to build those projects can be all over the place. And so sourcing, assessing, you know, and making recommended, recommendations to those clients can be can be very tricky. There's a lot to sort of cover there.\u003C\u002Fp>\n\u003Cp>Maybe we kick it off. Steve, I'd love to hear a little bit more about how, you know, you, your team, and and navigates, you know, the process of recommending that that tech, for your clients. You know, especially given your role, that dual role as an auditor, and also a consultant.\u003C\u002Fp>\n\u003Cp>Speaker 1: Yeah. It's a tough 1. Or sometimes it can be a tough 1, especially if we audit the clients. So, generally speaking, you know, the the audit side of the house and the consulting side of the house remain separated. It's sort of the the only way that that it can work.\u003C\u002Fp>\n\u003Cp>We end up if if they're intertwined, then we end up in a situation where we could be auditing our own work. And from a conflict of interest perspective, that doesn't really work. It it reduces our integrity, and it reduces our objectivity from as an auditor. So, I think we tend to be a little bit more on the risk averse side. And oftentimes, you don't actually recommend, technology to our client.\u003C\u002Fp>\n\u003Cp>We take a very empathetic approach and try to understand, what our clients' business objectives are, and we try to understand what their current state is from a technology posture is. So what are the legacy tools that they've got in place right now? What are their growth ambitions? What is gonna prevent them from achieve helping them achieve those growth ambitions? And then we sort of lay out a criteria for understanding, okay, who are the possibilities that might help them either leave their legacy architecture in place and and do a bolt on to newer technology, or we identify a path forward that, you know, involves slowly removing that legacy, technology.\u003C\u002Fp>\n\u003Cp>But we we talk through this with the client, and we under and we get them to understand what does the road map look like and then how we would chunk out that road map and reduce risk for them along the way, reduce spend, for them along the way, and just overall make sure that we are paying attention to their, you know, strategic objectives and their regulatory environment, as well as, you know, the industry that they're operating in. I think that is primarily the place that plays, is really just taking that empathetic approach, knowing that we operate in almost every single sector globally, and knowing really, really key, insight around regulatory environment, strategic objectives of an of an organization, as well as their technology posture and sort of taking that big lens and then identifying what the route forward is going to be.\u003C\u002Fp>\n\u003Cp>Speaker 0: Yeah. That makes it. I'm curious. You kinda you mentioned sort of digital transformation at the enterprise level. When you see that type of modernization, do you is it more often than not that people are looking to do it, you know, pretty swiftly, like rip the band aid off approach, or are they sort of 1 1 foot at a time?\u003C\u002Fp>\n\u003Cp>Like, let's do this incrementally. Let's look at phase 1 and sort of, like you said, maybe it's getting bolted on to the side. Maybe there's some technical debt. Maybe it's more expensive to do it, you know, incrementally. But what seems to be, sort of best practice, or what do you what do you see more of these days within that?\u003C\u002Fp>\n\u003Cp>Speaker 1: It's a really good question. I I think very rarely is it ripped the Band Aid off because when you're talking about digital transformation, I know it's a term that's probably often maligned at this point. It's just it's just transformation at this point. It's really hard to just cut over and make something new because the way that we look at everything, it's it's people, process, and technology. And if you're changing technology, there's a really good chance that you're changing process.\u003C\u002Fp>\n\u003Cp>And if you're changing process, it's gonna impact people. And so whenever you rip the band aid off or make that very, very quick change, you have to have a very, very robust change management work stream that's attached to a project. And, you know, being we're in a fortunate enough position that we've got technology consulting, business consulting, people advisory consulting. We bring this massive amount of expertise in large scale transformations that can sort of safeguard and risk mitigate the, the areas where it could get a little hairy. And more often than not, the technology isn't the hard part.\u003C\u002Fp>\n\u003Cp>It's the people part that makes it really, really difficult for adoption and for new process knowledge transfer and for change management. So, I guess, long winded way of saying, rip the Band Aid off to your detriment if you don't include a change management work stream.\u003C\u002Fp>\n\u003Cp>Speaker 0: Yeah. Oh, absolutely. And, again, like, rip the Band Aid off isn't necessarily you know, it's just a 1 and done. It's it's still, like, how expeditious are you trying to be? It's probably it's always gonna be phased out Yeah.\u003C\u002Fp>\n\u003Cp>Or or done in phases, I should say. But, yeah, no. That that makes a lot of sense. I I like the sort of the people process in tech, more of a holistic view of, you know, how you approach these problems. Nemanja, I'm curious.\u003C\u002Fp>\n\u003Cp>So at Work and Co, you know, how do you how do you guys balance, like, the innovation and responsibility when you are selecting, you know, technology for for your clients?\u003C\u002Fp>\n\u003Cp>Speaker 2: Yeah. The eternal question. I wish I knew. But joking aside, innovation, as you know, is inevitable in our line of work. It's impossible to be in technology and not to innovate, or else to be named the dinosaur by everyone else in the industry very, very quickly.\u003C\u002Fp>\n\u003Cp>And, we are where we are because we innovate constantly. There are a couple of ways. I identified 3 as the main equally important ways of balancing responsibility, which is proper planning. And I cannot emphasize this enough. We pride ourselves in a really, really thorough planning and discovery phase before we even get to, any actual engineering work where you can, mitigate these risks and, create strategies, about how you're going to implement.\u003C\u002Fp>\n\u003Cp>Steven said a wonderful thing, which is changing technology. Technology is simple. That's why I like it. Technology is very straightforward, and it's an exact science. Everything that comes as a side effect, as a consequence.\u003C\u002Fp>\n\u003Cp>Adoption by people, some cost fallacy, pushback by the clients' teams, those are the real problems to solve. And these are most often at least tackled during the planning planning phase. So a very, very comprehensive planning phase, then validating as a second point, validating the ideas we get to, through the planning phase via prototyping. 1 of our 1 of our paradigms at Working Call is, prototypes, not presentations. And I can't stress how amazing that is.\u003C\u002Fp>\n\u003Cp>Playing around with a new technology and making something work, discovering ups and downs throughout the journey, There's no white paper that can that can beat an actual working prototype and that can give you a sense and a feel about the community, about the usage, about the tooling. So, definitely, prototyping is the second point. And then, last but not least, agility in its purest form and in its purest sense, the context is the ability to rapidly adapt and respond to changes. Many times, these innovations, like if you balance responsibility with innovation, it's inevitable that you'll miss the mark quite a few times. It's really important to be agile, and it's really important to then change course, to have, an open, direct, and candid conversation with all the stakeholders and to course correct to something that's better for the the the work, the client, and everyone involved.\u003C\u002Fp>\n\u003Cp>So being truly being truly agile and nimble when hurdles inevitably come is what helps balance out the constant call of innovation, especially now when the newer the newer lineage of developers just rush to every new innovation because there's this appeal, And, it's really enticing to use cool new tools. So\u003C\u002Fp>\n\u003Cp>Speaker 0: Yeah. I mean, as a as a developer myself, like, you know or in our entire team at Directus, it's like there's always this. It's like, oh, I just wanna try it out. You know? Especially because we're open source.\u003C\u002Fp>\n\u003Cp>People have this. You know, typically, open source is like nights and weekends, and it's like you can do whatever you want. And then when that becomes your day job, it's, you know, that balance is a little bit more interesting. You know, we're obviously very small, you know, had a full time head count of, like, 30 plus, but, Work and Co, a lot larger. And obviously, a lot even larger still.\u003C\u002Fp>\n\u003Cp>Nemanja, you mentioned sort of agile. I always used to kinda refer to that, as, like, a really important facet of of our agency, etcetera, but always, you know, mention the lowercase a so not to be confused with the methodology. I like nimble. Do you feel is do you feel like it's more important for for Work and Co, you as, as the agency? You find it more easier for you as an agency to be nimble, and and does that sort of align with your clients a lot, or are they a little bit, like, who where would you say the balance is there?\u003C\u002Fp>\n\u003Cp>Because I could imagine, you know, you you get your sort of things locked in, and you're ready to change at any moment, but maybe even after you've done run through some prototypes and you've gone through what things might look like, maybe they have more of a a set vision and they're not as nimble, once you get into the process? Or what what would you what are your thoughts on that?\u003C\u002Fp>\n\u003Cp>Speaker 2: Yeah. III think the the word I like even more than agile is candid. I think it's really, really important to get to the bottom of why. Like, 1 of our partners, 1 of our founding partners, Joe Stewart, said when we did Virgin America, the clients know their business a 1000 times than we a 1000 times better than we ever will. There's always a reason for pushback.\u003C\u002Fp>\n\u003Cp>And as I said, it could be sunken cost fallacy. It could be the teams not being ready to adopt new technology. It could be because the technology is so deeply ingrained in the process, in the staffing, in everything that Steven mentioned. It it it's just really hard to pull out, like, a LEGO block and then replace with a nicer 1. So when things like this happen, when the other side, the the clients aren't as nimble, I think it's our responsibility as their partner to figure out why, and then to try to build a relationship and a sense of joint ownership.\u003C\u002Fp>\n\u003Cp>So the decision we land at is the decision that's best for the product and that's best for the work. I feel like very rarely is there irrational pushback. 9 out of 10 times, it's very good reasoning that's hidden behind business decisions and, people decisions. It's it's not as simple as it looks. That's why I like technology.\u003C\u002Fp>\n\u003Cp>Technology is super simple. Like, this is the perfect database to store this type of data, and that's where it ends. With business, it's much much more complicated.\u003C\u002Fp>\n\u003Cp>Speaker 0: Yeah. Much I mean, the tech is is purely objective and that that at least removes it not removes it from the equation, but makes it an easier part of the equation. But I would say, you know, we talk about all these different intersections. There's certainly an intersection of people and tech. You know, specifically, when you're building out a project, that technology will be used by people.\u003C\u002Fp>\n\u003Cp>And, again, something that I'm aware of, 1 of the big reasons we built Directus was, you know, unifying you. This great shift from, like, the monolithic ERP systems to microservices was was amazing, but it also means, you know, those people might now have a lot more complexity in their day to day of, you know, 10, 20 different portals they log into and different APIs they have to, you know, go into references for, etcetera. So it's I I guess that sort of leads into the next question, which I'm curious, for both of you, your respective agencies. You know, how when you're really just getting started, how you do that initial sourcing of of tech, you know, for the stack of a project or for a whole company depending on the scope. Like, what is the key criteria you look for?\u003C\u002Fp>\n\u003Cp>You know, through the lens of the tech is simple, you know, you know, in a way, but the people in the process are are a bigger part of the of the problem to be solved, but also very interrelated with the technology choices. And open for open for either of you.\u003C\u002Fp>\n\u003Cp>Speaker 1: Well, I think it I think it has to it has to start with business value. I I think that's the the most logical place to start. Inherently, I think you you have to go under the assumption that if if a client is engaging you, they're engaging you for a reason, that their business isn't where it wants to be. And they're either trying to streamline internal processes and backstage, goings on, or they're trying to enhance and improve the front stage experience for their customers. And so the only reason really to consider new technology or new engagement is going to be the, you know, the additive business value that the technology is going to bring.\u003C\u002Fp>\n\u003Cp>And so for us, I mean, Nemanja said it actually quite well in the in the previous in the previous question, where he's talking about, you know, there's there's always gonna be pushback, and there's always gonna be things that people are not telling you. And all of that is gonna come down to you, the client, or you, the vendor, working with the client, trying to establish trust in a relationship, and you can really only move at the speed of trust. And so the faster that you can develop that trust with the client, you're gonna get the whole story, and you're going to get the underlying reasons for considering a change. And that helps to understand how to move forward. You know, there's there's not a whole lot of rocket science here.\u003C\u002Fp>\n\u003Cp>We're talking about technology being simple. I think we often need to boil down business into more simplified terms where people just like doing business with people they like. And, usually, when you like someone, you're going to be open and trusting that they have your best interest at heart and that they're coming from a place of abundance that just wants to be helpful. And I think that's the benefit of working at is that I get to turn off, you know, this, agency owner cash flow mentality and turn on, well, how can I be the most helpful partner for this client? And I think that's really, you know, where it starts is truly understanding the the the place that they're in, the place that they wanna get to, and how new technology is going to unlock new value for them with the challenges that they're facing.\u003C\u002Fp>\n\u003Cp>Speaker 0: A 100%. Yeah. And, like, absolute the idea that people wanna spend time with, do business with, whatever the the relationship is, like, they you people wanna spend time with people that they respect, that they that they like. You know? That you're gonna be interacting with people on a daily basis.\u003C\u002Fp>\n\u003Cp>You're gonna be getting good news and bad news. You're gonna have to have the, you know, the agility, and and with that comes, you know, the trust that's very much resonates with me. I I found that that was, 1 of the best ways to ensure really solid communication was just establish that trust, at the onset of even before you've, you know, closed the job. You know, when you're in the RFP state and you're trying to make sure that that you're, you're getting awarded that bid is be the most likable client. Like, they just want to have another meeting with you.\u003C\u002Fp>\n\u003Cp>Like, even just starting there is is is a pretty great place to be.\u003C\u002Fp>\n\u003Cp>Speaker 1: It it's funny you it's funny you say that, because I'm probably gonna be giving away 1 of my, my own secrets here, but that's okay. I'm coming from a place of abundance and being helpful. But to your point, Ben, you'll always get like, every single agency pitch team, will get the question, you know, why should I choose you, in the presentation stage? And it's always someone who's, like, asking the question and then sitting back in their chair waiting for you to squirm. I have found that answering that question in a way that just sort of lays everything bare to that point and creates a foundation for trust is the reason why we've been successful in those stages.\u003C\u002Fp>\n\u003Cp>And, you know, my my template answer for that question, it it it's essentially look. Everyone you're gonna speak to is gonna have a great body of work and great case studies and a great portfolio. We do too. Everyone is gonna come to the table with a methodology and something that is going to help derisk the project. We do too.\u003C\u002Fp>\n\u003Cp>But what you're not going to get in everyone and what you are going to get in us is going to be a team that is advocating for your business outcomes and your audience, and we'll have arguments with you. And we will have passionate discourse about the best possible solution, but we're also gonna be able to come back to the table the next day and like each other and continue to work together and make your project a success.\u003C\u002Fp>\n\u003Cp>Speaker 0: Yeah. And that that is, like, the respect. It's like that radical transparency. We're not just gonna say what you wanna hear. You know, if you gotta hear the latest trend of technology, like, yeah.\u003C\u002Fp>\n\u003Cp>Oh, I know that you're gonna be jazzed by hearing this. So, like, it's really about having the trust, that the can and the candor to be able to say what's needed to be said to to get that project. Because, again, if it's not successful project for them, certainly won't be for you. You're not gonna have the client, you know, as a repeat business. Yeah.\u003C\u002Fp>\n\u003Cp>It won't be a great case study, etcetera. Nemani, I'm I'm curious your thoughts on that that same question, you know, how, how you over at Work and Co, you know, find find that initial tech and what you're really, assessing assessing it against.\u003C\u002Fp>\n\u003Cp>Speaker 2: Yeah. So, for us, the most important thing is to really truly understand our clients' long term value objectives. I think that's the fits really nicely into the narrative of business requirements often being a lot more complex than the tech ones. We make sure that we establish a vision for the experience that we're building for both the team and the end users, and then we work with the clients to determine the KPIs. After we are sure that we agree on what problems we're trying to solve, we can guarantee that we're not trying to use technology to dictate how we're gonna solve the problem, but it that it's the other way around, that we're gonna use technology as a tool.\u003C\u002Fp>\n\u003Cp>And then there are several critical criteria that we use to evaluate technologies. Number 1 is always efficiency and effectiveness in solving the problem. Not every technology is good at solving everything. We've learned about that with Clojure, for example, an amazing language who solve a lot of really complex data manipulations, not great at other stuff. And user base and community adoption equally important.\u003C\u002Fp>\n\u003Cp>Are there people that you can talk to when you hit a a wall? Is there a is there a lot of libraries? Is there an open source community? Are there people that are evangelists for the technology actively speaking and promoting their their their tech? And then availability of resources and documentation, of course.\u003C\u002Fp>\n\u003Cp>Once all of this finds a like, an average market that's good, we try it out. We either build the proof of concepts that I've mentioned, trying to solve specific parts of problems, or we use the tool to, work on an internal initiative we have. We do this a lot, where we have a bunch of internal internal tools, where we try technologies or stacks out that fit seem like they could fit the problem nicely, and that gives us firsthand experience in some of the newer stuff that we wouldn't feel comfortable trying out with clients immediately. It's an investment, but it's a well well worth investment.\u003C\u002Fp>\n\u003Cp>Speaker 0: Yeah. A 100%. It's interesting too. I think you kinda led by saying, you know, focusing on on the long term vision, the long term solution, etcetera. What how do you quantify that?\u003C\u002Fp>\n\u003Cp>Like, when I was, you know, working through similar projects, everyone has a different idea of long term. Some people, you know, sit on a digital experience that's built for a decade, then they come back like, hey. It's not working because things got deprecated. It's not even supported or whatever. Other people have a very rapid, you know, iterative cycle.\u003C\u002Fp>\n\u003Cp>But, also, there's, like, strata to what you're building. You know, to what what we build for clients, there's foundational levels that can, you know, have the longevity to to survive and sort of support multiple iterations of a project. And maybe the facade, you know, the front end or what have you, maybe that does change and this that's part of the stack gets swapped out more frequently. But, you know, on the whole, like, what when you're talking about, like, long term vision, I'm curious I'm curious what that means, to you in the in that dialogue with your clients.\u003C\u002Fp>\n\u003Cp>Speaker 2: In that sense, it means more whether the emphasis is going to be on like, long term vision for me particularly means scale and performance more than anything else. Like, how do we see the platform, grow over time? Do we see a huge surge in in the number of users, the number of visits? Do we see the data spiraling out of the the capabilities of the current platform? So we have a very honest conversation at the beginning about life cycle of technologies and stacks, about the the need to update libraries and platforms and the need to maintain as if you would maintain any other machine.\u003C\u002Fp>\n\u003Cp>The fact that it's software and that it's abstract does not remove the the reality of it being a machine. But the context there is more of a are we building a small tool for a discrete number of users? Do you see this growing? Do you see this expanding both in terms of people using it, the data living in it, and the number of features? Do you see your business expanding into other areas, out of which this part that we're building now will be a, foundational framework for or maybe a part of a larger system?\u003C\u002Fp>\n\u003Cp>All these things help a lot with decision making. Overoptimization is the root of all evil, said someone really smart. I can't remember who. But the point is you are not gonna build a an insane event bus orchestration layer with Kafka for an app that's gonna be used by 100, maybe 1, 000 of people. It's redundant and unnecessary and a huge waste of time.\u003C\u002Fp>\n\u003Cp>So aligning on on what the build is the build strives to be down the road, helps a lot with cost, helps a lot with effort, and with the the technology choices as well.\u003C\u002Fp>\n\u003Cp>Speaker 0: Yeah. No. A 100%. You said over optimization never I also think that optimizing too early. I mean, there's there's all sorts of gotchas, you know, in there.\u003C\u002Fp>\n\u003Cp>But now I'm I'm curious. Is there an example, you know, that that you can think of that you've, like, you know, pretty recently where you maybe had some issues that you had to overcome with with a client in these in this decision process?\u003C\u002Fp>\n\u003Cp>Speaker 2: Yeah. 1 of 1 of the examples that, comes to mind is working, with a client partnering to transform their legacy technical ecosystem, making sure that it can better serve the needs of their increasingly digitally focused user base. And then a critical decision point was choosing between building separate mobile apps using bespoke technologies like Swift and, Kotlin, or going through a cross platform mobile framework like Flutter that we really, really like or, React Native. And, the decision was complex. It involved a lot of a lot of moving parts.\u003C\u002Fp>\n\u003Cp>The existing team capability, their goals, their capacity, their performance, and that long term vision that we mentioned, which is how they see the the product moving forward. Also, security, a really, really important point. Yeah. So the way we approach it is we set the stage by really clearly defining the opportunities and challenges of all the approaches and making sure they understand the context and the impact each approach will take. We define proposed architectures based on the feedback that we got from them.\u003C\u002Fp>\n\u003Cp>Again, developed a lot of proof of concepts to show how different technologies on different devices behave when solving the same problem, and then went with a decision that I think all of us, the clients and us included, were very, very satisfied by and got a great outcome. And it was a it was not an easy process, I would.\u003C\u002Fp>\n\u003Cp>Speaker 0: It\u003C\u002Fp>\n\u003Cp>Speaker 2: was really, really tolling to get to a point of mutual satisfaction, but I think what got us there is a very close collaboration. And, again, I'm like a parrot now, but a lot of really honest candid conversations where you have to be really clear. Yes. This is 5% faster and better, but it is going to increase the development time 2 fold or 3 fold. Or maybe saying this is faster, but once you hit, 1, 000 or 2, 000 concurrent users, we are gonna start seeing problems.\u003C\u002Fp>\n\u003Cp>So having these conversations happen in real time and being ahead of the curve and making sure that all the angles are met greatly helps with\u003C\u002Fp>\n\u003Cp>Speaker 0: Yeah. Situation with this. And a lot of knowledge that you as an agency who has gone through this process at different scales, different customers iterated through, you know, okay. We built this, and now here's version 1.1 or 2.0 and the adjustments we had to make make. There's a lot of, you know, institutional knowledge there that you can give to, that client and make sure that you keep things on the rails that requires that trust.\u003C\u002Fp>\n\u003Cp>You know, they they have to understand that you have gone through this before, and you can, you know, hopefully learn just like in life. You can learn from those mistakes before you make them, you know, whenever possible. Steven, how about same thing for you. Like, have you have you had, a project recently where you were sourcing that tech and it just there was some sort of challenge or issue that you that you ran into that you had to try and figure a good way to work around?\u003C\u002Fp>\n\u003Cp>Speaker 1: I think there's always challenges and issues. Yeah.\u003C\u002Fp>\n\u003Cp>Speaker 0: A more notable 1. Yeah.\u003C\u002Fp>\n\u003Cp>Speaker 1: I yeah. I I think we have been doing or, about to conclude a project that is a, a commerce, transformation, retaining legacy ERP and then migrating, the entire experience off of 1 commerce platform to another. And, you know, someone told me once the the, really great analogy. The organization has been speaking French, for, like, years, for however long they've been using this commerce platform. And they know French, and it's second nature to them.\u003C\u002Fp>\n\u003Cp>And moving on to another another commerce platform, yeah, it does the same thing. It's still a commerce platform. It's gonna do cart. It's gonna do checkout, but it's in Spanish. And so now they have to think in French and then translate to Spanish.\u003C\u002Fp>\n\u003Cp>And sometimes the way that you've been speaking and the way that you've been working for so long, even though it's a very similar context, it's an entirely different language, and you have to learn an entirely different language. And so 1 of the things that often comes up in in these scenarios is a client essentially saying, you know, but I wanna do it this way. And there's a limitation of the technology because of the opinionated nature of that technology that's essentially saying, well, you can't do it this way. And so then we need to come together as, you know, vendor or service integrator and and client and have a conversation about what is really driving, you know, this request and what is really driving this requirement. And when you understand what it is, then you can identify maybe a way to work around that.\u003C\u002Fp>\n\u003Cp>And then what you what ends up happening is to to Nemanja's point, a real candid conversation around the value of that workaround. And so it's, you know, we found in 1 of the in what in this example that about 5% of their revenue needed to perform a function that they were requiring. It came from this, you know, servicing of a customer. And so do they really wanna spend, you know, AAAA pretty hefty amount relative to the overall project cost to incorporate something that's gonna take in 3 to 5% of their revenue when they could probably just live without it and then find ways of servicing the customer in a different way that they won't find an impact on. So I I think it's again coming to, you know, really ensuring that you've got future proof and scalable technology from several factors.\u003C\u002Fp>\n\u003Cp>You know, the technology's adaptability to the evolving industry standards or the regulate regulatory environment, its ability to integrate with other systems, and really the provider's commitment to continuous improvement and support. And we look at all of that and its potential to leverage emerging technology. I mean, we're all talking about AI these days, and, you know, Directus has also gotten into the, into the AI game as well. And then looking at those regular reviews and updates, the technology road map, all of that coupled with those candid conversations and trying to find POCs that are going to help create workarounds, but then evaluating the POCs based on return on investment, I think that's, like, the way that that we approach it, and that's the way that we go. And that's a relatively recent as of, like, 2 weeks ago example.\u003C\u002Fp>\n\u003Cp>Speaker 0: Yeah. It's a it's a big 1, and it's it can be hard to kinda make those decisions when you want to be improving. You wanna sort of modernize every ask you know, every corner of of your business, your process, etcetera. And sometimes, like, the ROI is not there. And, you know, when is the right time to kind of remove that technical debt, that legacy, part of the stack?\u003C\u002Fp>\n\u003Cp>You know, or, you know, do you ever you know, do you just kinda band aid it, add infinitum until, the ROI changes or it just no longer functions or, you know, there's there's a lot to that. It's interesting, though. I think you both have mentioned sort of this idea of, like, being opinionated or unopinionated. I'm curious, you know, Steven, you just mentioned making something future proof, which I I always I'll always kinda throw quotes around air quotes around that, and scalable, which I think is a big part of being future proof. You don't know how you're gonna scale necessarily.\u003C\u002Fp>\n\u003Cp>I mean, in an ideal world, you don't know because you could think things are gonna go amazing, they go even better. But how do you ensure that the the tools that you source are future, you know, future proof. And, you know, when you're thinking of things like, you know, the words like unopinionated or opinionated, I think both have, you know, pros and cons. You know, does that tie into this thinking, this, like, methodology for for choosing the Oh, yeah. The the tech?\u003C\u002Fp>\n\u003Cp>Speaker 1: Yeah. Yeah. I I think that everything that I just mentioned around, understanding the technology's ability to, incorporate emerging technology, its evolving nature with industry standards, as well as, you know, regulatory standards. All of that, like, it has to it it creates the the the foundation and the guardrails for businesses to be operating in. And selecting a technology that doesn't take into account those guardrails or those foundational aspects of the business operating environment, I think, is a surefire way to surefire way to choose the wrong technology.\u003C\u002Fp>\n\u003Cp>Speaker 0: Do do you feel that, like, again, just do you feel that something choosing tech that is opinionated and follows those specs, you know, that compliance and just, like, checks those boxes, you know, out of the box, so to speak, off the shelf versus maybe a tool that's more unopinionated, that allows you to take those those paths when needed or if those paths change, if there's a new spec that's introduced to you. You feel like there's a benefit to either of those options, or do they both kinda have their place, depending?\u003C\u002Fp>\n\u003Cp>Speaker 1: I think they both have their place. I I think it's gotta be fit for purpose. Like, commerce is a great example. You do want it to be opinionated to some degree. Like, you don't want to be messing around with the world's best commerce platform, and then find out that your conversion rate is suffering.\u003C\u002Fp>\n\u003Cp>So in some respects, like, if you want to maintain your legacy stack, but you want to change your commerce platform as part of your architecture, then getting the benefit out of that commerce platform, you're going to have to find a way to make your technology stack and architecture work with that platform, if you want to reap the benefits of that. So that's, you know, a very, very purposeful and intentional incorporation of opinionated technology. But then in areas where you don't really know what the end goal is and you have a good inkling as to how you can foundationally get off the ground very quickly with an unopinionated and flexible piece of technology, then that's a a really, really big benefit. So something like Directus is a really, really great place to start because most people can create a frame of reference around Directus as, like, a CMS. And so when you're, you know, doing any kind of project, most projects require a CMS.\u003C\u002Fp>\n\u003Cp>And so you can anchor onto that frame of reference, but then because Directus is so amorphous, it can literally be anything you want it to be or need it to be. And it's got a very friendly microservices architecture. There's really no sort of cookie cutter approach to what you're gonna use Directus for. So that's a a really you know, in my in my experience, that's a good example of leveraging opinionated architecture for what it's intended for and then leveraging something that's as unopinionated as can possibly be to help you grow to what's next.\u003C\u002Fp>\n\u003Cp>Speaker 0: Yeah. And then, ideally, both sides of the coin have strong points of integration so that they work well together. Exactly. Obviously, you wanna, you know, mitigate as much negative space as possible because that's where, you basically just have to start building custom to kinda fill in those gaps. So if you can have things bookend nicely together, and and play both sides of of that, that's sort of the ideal state.\u003C\u002Fp>\n\u003Cp>And, you know, side side note, you we we spoke a week or 2 ago, and you had mentioned you used that word amorphous to describe direct us, and I ran back to the team, and probably end up in all sorts of our our marketing collateral. It was just like a a really great way of describing it. Similar to sort of like nebulous, but nebulous has this kind of like more pejorative, like, what are we? What is this? And amorphous is is is just a great term.\u003C\u002Fp>\n\u003Cp>I love that. Nehemiah, you you had kinda mentioned a second ago, I think it was like prototypes, not presentations. When you are, you know, going out and and sort of pitching to clients, may could you talk a little bit more about that? Like, I'm I'm so curious about, like, that process. Like, what does that look like?\u003C\u002Fp>\n\u003Cp>You know, very aware of, like, what a prototype is, you know, versus a more traditional presentation. But how does that typically go with clients, and and how do they how do they receive that?\u003C\u002Fp>\n\u003Cp>Speaker 2: Very well. I think the first of course, that's never the first step. The first step is gathering requirements and hearing about the problem, aligning on what we need to solve and what needs to be tackled. As we're focused on products a lot, very often, it's a an exciting segment of, the the customer's business or a new feature or a new, new product within their ecosystem. Then we go back to the drawing board, and we build something that we we show the clients.\u003C\u002Fp>\n\u003Cp>And I think that leaves the best impression, by far, seeing something, work. And we have amazing, extremely talented designers that can, in a very, very, I would even say, absurdly short time frames produce amazing work. Once, once you see something that you only have in your head, in front of you on a screen, that helps immensely. I I have never seen I've never seen feedback after a a, like, a keynote presentation as I have after a couple of framer framer prototypes. Then the tech comes into play, and then we have a very, very thorough and deep, initial discussion where we try to understand the the tech team composition, the capabilities, the current infrastructure, architecture platforms, and everything that's there in order to better propose a solution.\u003C\u002Fp>\n\u003Cp>But, yes, the the prototype comes not as a first, but as a very close to first step, where it's the wow effect that, really brings it home. Because, we are visual beings by nature. And, that's why I feel like every developer, every engineer needs to I am let's put it like this. I'm com I used to be completely void of any sense of aesthetics. So math, math, math, then physics and electronics in in university.\u003C\u002Fp>\n\u003Cp>And then I worked through it because we are visual beings and to be in the line of work we are, which is digital, everything is very, very aesthetic, and people respond to, amazing inspiring interfaces. So, that's where I think prototypes are key. Again, seeing these ideas that we all talk about in presentations come to life is the same with features. There's a lot of talk about AI now and the capabilities of LLM and the conversational platforms. Seeing a happy path prototype often says a lot lot more than a bunch of keynote slides illustrating our general capability.\u003C\u002Fp>\n\u003Cp>Just seeing a happy pet alum consult you on which product to buy, I think it sends a really strong message about capability, preparedness, and the the the talent within the team.\u003C\u002Fp>\n\u003Cp>Speaker 0: Yeah. Definitely, if you go into it with the mindset of getting that massive knowledge transfer, like truly understanding, you know, the problems, the root the root, you know, things that need to be solved, the goals, etcetera. And you understand the business, the team. Once you have all that, you know, over at work and co or or UI, like, I think then you can kind of jump into that. It's it's interesting, though.\u003C\u002Fp>\n\u003Cp>I agree. You know, humans are so visual. Like, the idea of, like, inspiring through, like, you know, pen to paper, so to speak, is huge. But at the same time, like, I started thinking because that that's how I operate. You know, I'm very quick to get in and start just divergently coming up with with UX, UI, like prototypes.\u003C\u002Fp>\n\u003Cp>And I feel like that conveys so much, so much more than a presentation if you have that, you know, the initial work ready, you know, informing that process. But, also, it makes me think of, like, books to movies. I watch a lot more movies than I do read books. I you know, just time wise. But there's this idea of, like, you read a book and we're also imaginative creatures.\u003C\u002Fp>\n\u003Cp>Does it ever backfire? Because when you kinda go in with a prototype, that's like the movie. Right? You're sort of saying, like, this is this is what this could look like versus a book, and it's like, oh, that's I read the book, and then it was so different in the movie. And I don't know how I feel about that.\u003C\u002Fp>\n\u003Cp>Once you've kind of gone that direction of a prototype, do you ever feel like you are locked in because they've seen it and it's like, oh, this this is what we want, and then it that agility, that flexibility becomes a little bit more difficult?\u003C\u002Fp>\n\u003Cp>Speaker 2: That's where the the experience of years of pitching like this comes in really, really handily. We build prototypes to solve specific problems, sometimes even specific parts of specific problems. So it's not such a, such a heavy buy in or such a huge commitment. The prototypes often are, vital and instrumental at solving this 1 key thing. And, 9 out of 10 times when we do show a prototype, we know that that's the direction that's ultimately the best for the product.\u003C\u002Fp>\n\u003Cp>So showing a prototype solving that 1 key thing isn't completely selling you into 1 solution. It's a learning experience, and, it's articulated by us being a lot more diverse and potent prototypes that were selling us into solutions. Now it's a a good balance of both. You explain, show capability, demonstrate previous. As Steven said, we all have really nice case studies to fall back where everyone's impressed at how we solved really complex problems for really great really great clients, but then for specific segments or of specific problems, I feel like that's the sweet spot sweet spot for prototypes.\u003C\u002Fp>\n\u003Cp>Not to committing, but great at showing capability and putting like, giving a visual aspect to the solution.\u003C\u002Fp>\n\u003Cp>Speaker 0: Yeah. Oh, I mean, a 100%. Steven, I'm curious. So when we're talking about, like, we're we're presenting to the client, you know, sometimes thing things backfire. When when a client comes in, maybe they already have preconceptions.\u003C\u002Fp>\n\u003Cp>I guess this could apply to to either of you, but they have a preconception. This happened to me a lot. You know, I I used to joke, with with our team that it was, you know, 1 of the executives, like, they had a niece that, like, worked for a company. It's like, this is the bet. Like, I've heard so much about this and, like, that is the preferred stack or tech tech choice.\u003C\u002Fp>\n\u003Cp>You know, I think Carlo had a, who just posted in the in the audience questions had a similar, you know, how do you manage client expectations when the recommendation recommended technology has a steep learning curve? I I think there's, you know, all of these sort of questions around how do you get past, you know, when there's tech that might not be a good fit for the company or it is a good fit, but you're just not aligned. And and maybe trust isn't quite getting you there. You have to really dive in and and, you know, sort of or cover that somehow and and help bridge the gap of, like, yes. I understand that this is, you know, the the latest, you know, hype train tech, or I understand that you've heard a lot about this this other thing from a family member or whatever it might look like.\u003C\u002Fp>\n\u003Cp>But any thoughts on that, like, how you navigate that?\u003C\u002Fp>\n\u003Cp>Speaker 1: So many thoughts. I do like, I I just wanna go back to, Nemanja's comments about, prototyping. I I think prototyping has a huge, huge amount of value in the work that we do for clients. Ben, I'm I certainly don't wanna poo poo your analogy on, you know, books and movies, but I think the important thing there is that, people can either create their own context or the people that they are hiring as experts can help create a better context. And if you leave someone to read the book, then they're creating their own context.\u003C\u002Fp>\n\u003Cp>They're creating their own imagination. They're filling in the gaps for themselves. Whereas the movie is telling them, like, this is what it is, and there's no imagination here. There's nothing, you know, left untold. This is the story, and, you know, you should pay attention to to this story.\u003C\u002Fp>\n\u003Cp>David Kelly, from IDO has got a great quote about prototypes. If a picture is worth a 1, 000 words, a prototype is worth a 1, 000 meetings. And so, like, you know, IIII do love the idea of prototypes because it does create that on ramp to trust. If a client's got a problem that is, you know, in their mind, immutably solve unsolvable, then, you know, a prototype from a experienced and professional team coming in to, you know, help highlight how it could be solved with proof of concepts or prototypes that, like, that accelerates the engagement massively. It creates a huge amount of trust.\u003C\u002Fp>\n\u003Cp>It helps solve a problem. It creates business value, and it's 1 of those things that clients can easily get behind because, again, going back to people, like, doing business with people they like, the person who you're working with has to look good in front of someone. And if you're helping them look good in front of their boss, like, that just solidifies and galvanizes the relationship because you're solving a business problem that goes beyond them. So I'll say that on on prototypes.\u003C\u002Fp>\n\u003Cp>Speaker 0: Well, I just and IIII do agree because, again, we're hired as agencies to it's a full service agency, typically. You know, you are delivering a full suite of deliverables. And I think the the book and or, you know, the the the story itself is 1 piece of that, but it's our job as, you know, on the UX side, the UI side, the all these different pieces to be the cinematographer, to be the director, to to kinda give them the entire experience. Otherwise, you know, you're leaving it up to them. And maybe they're they're great and they have some great visions, but you're also probably gonna end up with a roomful of people\u003C\u002Fp>\n\u003Cp>Speaker 2: who are\u003C\u002Fp>\n\u003Cp>Speaker 0: all interpreting things quite differently. And And then you're gonna be navigating the people problem of, okay. Now we gotta try and wrangle everybody to the same page.\u003C\u002Fp>\n\u003Cp>Speaker 1: Yeah. So I I think the the way the way that that we try to solve that is really trying to be proactive, right from discovery. I there's 2 things that, I will do within my engagements every single time. The first is is, an exercise called the graphic game plan. And, it was initially invented by, Grove Consultants, And, I leveraged this sort of storytelling visual of, hey.\u003C\u002Fp>\n\u003Cp>We're all we're all in our in our car, on our road trip heading towards this destination. The destination is project completion. What is going to be the measure of success for project completion? And then we put everyone everyone, including our team, the client team, puts their measures of success right in the center of that target. Then around that, you've got primary and secondary objectives.\u003C\u002Fp>\n\u003Cp>What do we want this experience to be? How do we wanna feel when we're doing the work? All of these sorts of things, We get them up there on the target as well. Then in the car are gonna be all of the stages and tasks that we need to do in order to achieve our objectives and achieve our our measure of success. Below the car, there's these bumps.\u003C\u002Fp>\n\u003Cp>And those are gonna be the challenges that we're gonna be facing along the way. And then the wheels on the car are gonna be the success factors. If everyone gets into a room and starts talking about success factors, challenges, all of the things that we have to do, the resources available to us, the objectives that we're trying to hit, then everyone owns the scope collectively. There isn't 1 side that owns the scope. And when you both share the scope, that's when you avoid things that I lovingly call climbing Mount Death March, where it's the vendor that is figuring out the scope of the project because it was ill defined at the beginning while they're developing.\u003C\u002Fp>\n\u003Cp>And, like, that is just the worst place to be in. So that's the graphic game plan. And the second thing that I'll do is ensure that we have stakeholder interviews from everyone in the company that could say no even at the 11th hour on the project strategy and the project direction. Because the 1 thing that every project should try to avoid is the swoop and poop. And that's, you know, when you're at a beach having a great day, team's doing great job, and a seagull flies in, shits all over your picnic, and then flies away.\u003C\u002Fp>\n\u003Cp>Speaker 0: And then you're Good luck. There.\u003C\u002Fp>\n\u003Cp>Speaker 1: What's that?\u003C\u002Fp>\n\u003Cp>Speaker 0: I've heard that's good luck. That's a good thing to say. Trying to make you feel a little better about it.\u003C\u002Fp>\n\u003Cp>Speaker 1: Yeah. Only the only the people that, they get crapped on tell you that it's good luck. Yeah.\u003C\u002Fp>\n\u003Cp>Speaker 0: Only in the metaphor.\u003C\u002Fp>\n\u003Cp>Speaker 1: Yeah. So those are the 2 things that we'll do to make sure that we've got alignment, right from the beginning. And that is probably the most important thing. Because if you take a flight around the world, around the equator, and you're 1 degree off course, by the time you get around, you're gonna be 500 miles off target. And that's 1 degree of deviation.\u003C\u002Fp>\n\u003Cp>So better to get that, you know, that heading right on target right from the beginning.\u003C\u002Fp>\n\u003Cp>Speaker 0: Yeah. Yeah. I mean, it becomes rocket science. I mean, you the the more off you are, the earlier you're off, that just kinda compounds and you you're scaling problems. So if you can mitigate that, that's definitely something to be very aware of, in that early process.\u003C\u002Fp>\n\u003Cp>Yeah. Nemanja, I'm curious. Do you have anything similar, like, where you you've kinda had to deal with this issue of people coming in with preconceptions or trying to wrangle, you know, someone away from this idea that really just wouldn't work, but they're they're just struggling to to see the vision and to have that trust.\u003C\u002Fp>\n\u003Cp>Speaker 2: Yeah. More oftentimes than I would like. But, I think that, you can't win them all. Sometimes just having a having done all of your homework, having done an extensive discovery phase, having validated your assumptions, done all the prototyping in the world, shown capability, discussed caveats, her hearing the client out and hearing their reasoning, seeing that there is no greater mystery behind why someone's as adamant as they are about a certain technology or not adopting a certain technology, the conclusion might, in the end, be that it's someone's need. And, that's okay.\u003C\u002Fp>\n\u003Cp>What we do in these situations is that we establish a very, very loud and very clear communication channel throughout the process from the first meeting where things are we're an agency, and we eventually perform a service for our clients. So if you've exhausted all of your options and if there is no other way to argue your point, you just have to be very, very clear and very direct and to communicate very frequently what the risks and consequences of a decision you believe are is suboptimal are. So making sure that this 1 degree deviation that everyone knows that it's gonna be 500 kilometers by the time we get back and alerting date, like, an alarm clock every hour. Like, saying in every retrospective meeting or every time there's an opportunity to discuss technical depth or to discuss progress, just making sure everyone understands the consequences of the choices that we believe were suboptimal. 100%.\u003C\u002Fp>\n\u003Cp>As I said, you can't win them all. There's no way that everyone's always gonna be aligned regardless of how good your argumentation is. But I think it's our responsibility as partners to make sure that we alert to these consequences as often and as early as possible.\u003C\u002Fp>\n\u003Cp>Speaker 0: Yeah. No. A 100%. And I think, again, when things go south, the best thing that can happen is to already have established trust. You know, they they understand why the communication is there, and at least then it's you know, you you can hopefully navigate, through the project or whatever that ends up looking like.\u003C\u002Fp>\n\u003Cp>But, yeah, I we've kind of mentioned that word so much. I it really, you know, going back to, I think, the beginning of this, Steven, you had said you can only move at the speed of trust, which I took a note of. I think that's I think that's an amazing, sort of, like, way to kinda think about this and highlights the importance of that trust and communication, and it connects it to something that's very real. Like, when you're building a project, you've you know, speed. Speed is important.\u003C\u002Fp>\n\u003Cp>You can't you when I was running my agency, there was kind of 4, sort of levers that you really had to work with, and they were all I I think there's even a website where you can turn certain ones on and off. It was speed, scope, cost, and quality. And, of course, any good agency is gonna take quality off the table and say that's always gotta be good. We're we're not gonna sacrifice that. So you have these 3 toggles that you can kinda, you know, choose to choose your own adventure.\u003C\u002Fp>\n\u003Cp>And it's great to know that trust is a huge part of of the speed of the process, because, really, in the beginning when you're figuring out the scope and you're, you know, setting up what the cost looks like, you just efficiency and speed is is the name of the game. You know, how can you get through and and help to establish that and help the client really understand what their options are, that you are the right vendor, or, you know, partner to help them get through this. And I guess it all just comes down to to to that trust. So, we we've said that word a lot, and that's I think that's we we could probably rename this episode into, you know, establishing trust and, you know, the importance of trust at the agency level. But, you know, we we we ran over time a little bit, which is which is always good.\u003C\u002Fp>\n\u003Cp>We didn't even get through through all of our questions here, or, you know, I think there was a few that were thrown into the chat. But, any final thoughts, Steven Steven or Nemanja?\u003C\u002Fp>\n\u003Cp>Speaker 1: Nemanja, why don't you go first?\u003C\u002Fp>\n\u003Cp>Speaker 2: Yeah. I was just gonna say because it piggybacks nicely off of what you've just said. It's not only trust, I would say, it's partnership. Like, 1 of the things that got me, when I was deciding whether I'll go into agencies and service work or whether I'll go into, like, building a product startup or something like that was agencies, at their core, help solve problems, and you can't help if you're in an adversarial position. I really every relationship that we've had with a client that was hugely successful and that brought a lot of, for lack of a better word, happiness to me after the resolution was when we were true partners.\u003C\u002Fp>\n\u003Cp>So it's not like we're warning you this will fail because you're not listening to us. It's like, how do we make sure that since these are the the axioms that we have to work against, we fail less as a team. Like, being a partner to our clients is, I think, a lost forgotten art. Sometimes we get into a mindset of us versus them. I don't think that's a good mindset for agencies or tech providers at all.\u003C\u002Fp>\n\u003Cp>We serve technologies is there to serve solve problems. And, like, at its core, what we do is we facilitate. We use amazing tools to change the world. So partnership and not pointing fingers. The name of the game for me.\u003C\u002Fp>\n\u003Cp>Speaker 0: That's hon. I that's exactly right. Open, trust, you know, those are all key things, but really the goal of those things is to, establish a partnership where you're you're in it together because, I mean, you truly are at the end of the day. Yep. Steven, thoughts on that or, just, you know, closing closing thoughts?\u003C\u002Fp>\n\u003Cp>Speaker 1: Yeah. I I mean, I, I feel like Nemanja and I drink the same Kool Aid. It's 1 of those things where, for me, there was a very, very defining moment earlier on in my agency life where I I really just took on this mantle of being a designer is the most important thing in the world, and I would tell my clients, you know, the overarching responsibility of a designer and and how we're, you know, empowered to create amazing tools. The bottom line is they really didn't give a shit, about my my little speech about, you know, design. And it really sort of came to a head when I started changing the language that I was using around the value of the work that we do and what we bring to the table.\u003C\u002Fp>\n\u003Cp>And it was speaking my client's language, being empathetic to what their needs were and how they were articulating their business problems. And it was all in the language of business. And so if you can get out of your own way and stop speaking the language of design or stop speaking the language of technology and speak the language of business and how the tools that you wield are going to help solve their problem in a way that makes sense to them, that's when you actually engender really good partnership and really good, foundation of trust. And so I think that was a a really key moment for me in my, in my sort of growth and learning, as a agency owner and now someone who's in the, you know, the big 4 consulting world.\u003C\u002Fp>\n\u003Cp>Speaker 0: Yeah. Couldn't could have said it better. I I again, these are all just huge pillars in how you how you kind of establish and foster, those those relationships. And then again, the the benefit of that is then you end up working with these clients, over and over and over again, and they just become huge advocates, for not only the stack that you help them select, you know, which, you know, we're a great great in a great position to be chosen by such a great you know, by so many great companies, but also, you just get to, have that repeat business and long enduring, partnerships with with great companies. So excellent.\u003C\u002Fp>\n\u003Cp>Steve and Damania, this was has been an awesome chat. Again, probably, we'll have to, like, circle back and maybe think about another 1 because a lot more. Again, this is the, you know, the whole reason for me being here, was was how how to solve these problems within an agency and trying to find the right tooling. And it's not always direct us. It's not, you know, that's the name of the game is, you know, just finding finding the right tool for the right job, which is not easy, as we say in an hour and 8 minutes in.\u003C\u002Fp>\n\u003Cp>But thank you both so much for joining, and we'll be seeing you at the rest of Leap Week for everybody else who's who's watching now.\u003C\u002Fp>\n\u003Cp>Speaker 1: Thanks so much for having us.\u003C\u002Fp>\n\u003Cp>Speaker 0: Absolutely. Alright. Thanks, everybody.\u003C\u002Fp>","Today, we are doing another Bridging Bytes episode, in the midst of our of our Leap Week, Leap Week 3, over at Directus. So an exciting time for multiple reasons, but, super super jazzed to be here, joined by Steven Majid and or Meggitt, sorry, and Nemanja, Nichoforovich. We are gonna be running through how agencies innovate, something very, you know, important to me. This is how I kinda got started with Directus, got started in general. So, yeah, we'll be spending next hour or so running through all things agencies, sort of the the primer, the the history of Directus, and then diving into all the, so the nuance of, you know, the overlap between agencies and how you choose your software, how you, you know, build out these projects, oftentimes very, very different projects for different clients. So I think it would probably make sense. Why don't we dive in with some introductions? I can go first just kinda lay you know, set the stage for, again, you know, how I got started with Directus, with my agency, that I started about 20, 20 some odd years ago, called Ranger Studio out of New York City. We were headquartered in Brooklyn. It was, truly, you know, going back to 1 of our previous bridging bytes episodes, it was the intersection of design and development. So we were lucky enough to do builds for some of the amazing, you know, marketing and design studios out there, you know, IDEO, Wolf Allens, Pentagram, Interbrand, etcetera. And we would work to basically be the hands, to build out their their projects for amazing clients. You know, we worked with Google and Snapchat, AOL, AT and T, the US government, just doing really white glove amazing projects, you know, thus Directus because we needed to find software that would actually fit the bill for all of those. But ran that studio for about 15 years, until it sort of transitioned into into Directus, formally. But, yeah, it was it was a very interesting you know, we'll we'll get into it, I think, more in this episode, but it's very interesting sourcing, technology, especially back then 20 years ago when technology was very different. There was far less to choose from. There wasn't as much information about what you were choosing. But that's really how I how I got started with Directus was building software that would make, our internal development more efficient, give us administrative tools we could hand off to those end customers, that wasn't strictly, a head you know, a CMS. They didn't even have have headless back then, or was it something completely custom? That's really what we ended up doing constantly. It was just building custom, solutions and back ends for every project, which is inefficient. So today, we're gonna be diving into how people do it today, the modern way of approaching this problem. So why don't we start off, Steven Meggitt, who is over from, if you wanna give give an intro. Sounds good. Awesome. Sounds good. Ben, that was AAA good intro and backstory for, the genesis of of Directus. It seems that, you're not the only agency that started out that way. 37 signals, I think, comes to mind of a similar trajectory. So it's it's interesting to hear that. Pleasure to be here, Ben, Manja. Great to connect with you as well. Thanks for Directus for for having me on having us on. So I've been at for, close to 5 years now. I've spent my career designing, developing, and delivering really, really unexpectedly clever customer experiences that generate return on investment. I started in 2, 001 in my parents' basement, and then built a small but highly focused digital agency. Ben, you talked about the intersection of design and development. I like to add in 1 more element to that, where my agency was highly, highly focused on research, user experience and design and development. And that eventually led to me growing the the agency pretty organically and built a small but highly focused agency on those elements. And that led to an acquisition by in 2019, to help build out, what was then a, city centric design studio capability, which then was was then grown into a national practice. So now I'm a partner in the customer transformation practice, which brings together the work that I do in the studio, along with everything that I'm passionate about, which is helping organizations really build sustainable value and growth by making every touchpoint in the customer journey an exceptional 1. That is awesome. Yeah. And, you know, 37 signals, obviously, that's a great sort of template. You know, was taking very close looks at them back in the day and, you know, III are they still around? Oh, yeah. Yeah. I I get I get whiffs of, like, you know, the there are, different product suites every once in a while, but I can never can never quite tell. Some people are a little bit more ephemeral. But, thank you so much, Steven. That's that's a great great intro. Super happy to have you here. Nemanja, do you wanna, run through a quick intro from over at Workinco? Yep. Hi, everyone. My name is Nemanja, and I'm a technology partner at, Workinco. I've been with WorkingCo since December 2013, joined as developer number 4, and, it's been quite a ride. I've been, meddling with almost any technology project that we've ever worked on. From Virgin America that, made Working Code what it is, over through NBA, Disney, Google, CBS, more recently Contentful and Decathlon. As far as, my trajectory goes, I started coding, straight out of high school, like 2, 002. And I was always fascinated by hands on work, clean architecture, design patterns, and I was fortunate to have great mentors before Workingco and during Workingco. So 1 of the things that made me stick around for for as long as I have is that Working Group partners, in particular, are very hands on, so I get to do what I love every single day still. Little known. I don't even think we talked about this, Nemanja, but I actually when I was when I moved to the city and I was figuring out exactly where I was gonna be, you know, working next, I actually went over to Work and Co. I knew some of the partners over there at the time, and applied. I was like, I would love to work here. This is an amazing, amazing shop. Things went a different direction. I ended up starting my own, my own agency, but I certainly what that is what you described is exactly what resonated with me is all the partners were super hands on. There was no, you know, okay. All these, you know, lower level junior designers are gonna go out and do the grunt work, etcetera. Everybody was really active in, you know, building out, the project. And, again, not just amazing clients, but amazing projects for those clients. Excellent. So that's basically intros. I think again, just to reiterate, today, we're gonna be really going through, the agency side, how we how we sourced different technologies, which, of course, can be very disparate. You've got, depending on the agency, some are a little bit more. This is, you know, lather and repeat exactly what we do, you know, bread and butter. And then others are more divergent, in in the types of project they take on. And, of course, that means that the tech that you use to build those projects can be all over the place. And so sourcing, assessing, you know, and making recommended, recommendations to those clients can be can be very tricky. There's a lot to sort of cover there. Maybe we kick it off. Steve, I'd love to hear a little bit more about how, you know, you, your team, and and navigates, you know, the process of recommending that that tech, for your clients. You know, especially given your role, that dual role as an auditor, and also a consultant. Yeah. It's a tough 1. Or sometimes it can be a tough 1, especially if we audit the clients. So, generally speaking, you know, the the audit side of the house and the consulting side of the house remain separated. It's sort of the the only way that that it can work. We end up if if they're intertwined, then we end up in a situation where we could be auditing our own work. And from a conflict of interest perspective, that doesn't really work. It it reduces our integrity, and it reduces our objectivity from as an auditor. So, I think we tend to be a little bit more on the risk averse side. And oftentimes, you don't actually recommend, technology to our client. We take a very empathetic approach and try to understand, what our clients' business objectives are, and we try to understand what their current state is from a technology posture is. So what are the legacy tools that they've got in place right now? What are their growth ambitions? What is gonna prevent them from achieve helping them achieve those growth ambitions? And then we sort of lay out a criteria for understanding, okay, who are the possibilities that might help them either leave their legacy architecture in place and and do a bolt on to newer technology, or we identify a path forward that, you know, involves slowly removing that legacy, technology. But we we talk through this with the client, and we under and we get them to understand what does the road map look like and then how we would chunk out that road map and reduce risk for them along the way, reduce spend, for them along the way, and just overall make sure that we are paying attention to their, you know, strategic objectives and their regulatory environment, as well as, you know, the industry that they're operating in. I think that is primarily the place that plays, is really just taking that empathetic approach, knowing that we operate in almost every single sector globally, and knowing really, really key, insight around regulatory environment, strategic objectives of an of an organization, as well as their technology posture and sort of taking that big lens and then identifying what the route forward is going to be. Yeah. That makes it. I'm curious. You kinda you mentioned sort of digital transformation at the enterprise level. When you see that type of modernization, do you is it more often than not that people are looking to do it, you know, pretty swiftly, like rip the band aid off approach, or are they sort of 1 1 foot at a time? Like, let's do this incrementally. Let's look at phase 1 and sort of, like you said, maybe it's getting bolted on to the side. Maybe there's some technical debt. Maybe it's more expensive to do it, you know, incrementally. But what seems to be, sort of best practice, or what do you what do you see more of these days within that? It's a really good question. I I think very rarely is it ripped the Band Aid off because when you're talking about digital transformation, I know it's a term that's probably often maligned at this point. It's just it's just transformation at this point. It's really hard to just cut over and make something new because the way that we look at everything, it's it's people, process, and technology. And if you're changing technology, there's a really good chance that you're changing process. And if you're changing process, it's gonna impact people. And so whenever you rip the band aid off or make that very, very quick change, you have to have a very, very robust change management work stream that's attached to a project. And, you know, being we're in a fortunate enough position that we've got technology consulting, business consulting, people advisory consulting. We bring this massive amount of expertise in large scale transformations that can sort of safeguard and risk mitigate the, the areas where it could get a little hairy. And more often than not, the technology isn't the hard part. It's the people part that makes it really, really difficult for adoption and for new process knowledge transfer and for change management. So, I guess, long winded way of saying, rip the Band Aid off to your detriment if you don't include a change management work stream. Yeah. Oh, absolutely. And, again, like, rip the Band Aid off isn't necessarily you know, it's just a 1 and done. It's it's still, like, how expeditious are you trying to be? It's probably it's always gonna be phased out Yeah. Or or done in phases, I should say. But, yeah, no. That that makes a lot of sense. I I like the sort of the people process in tech, more of a holistic view of, you know, how you approach these problems. Nemanja, I'm curious. So at Work and Co, you know, how do you how do you guys balance, like, the innovation and responsibility when you are selecting, you know, technology for for your clients? Yeah. The eternal question. I wish I knew. But joking aside, innovation, as you know, is inevitable in our line of work. It's impossible to be in technology and not to innovate, or else to be named the dinosaur by everyone else in the industry very, very quickly. And, we are where we are because we innovate constantly. There are a couple of ways. I identified 3 as the main equally important ways of balancing responsibility, which is proper planning. And I cannot emphasize this enough. We pride ourselves in a really, really thorough planning and discovery phase before we even get to, any actual engineering work where you can, mitigate these risks and, create strategies, about how you're going to implement. Steven said a wonderful thing, which is changing technology. Technology is simple. That's why I like it. Technology is very straightforward, and it's an exact science. Everything that comes as a side effect, as a consequence. Adoption by people, some cost fallacy, pushback by the clients' teams, those are the real problems to solve. And these are most often at least tackled during the planning planning phase. So a very, very comprehensive planning phase, then validating as a second point, validating the ideas we get to, through the planning phase via prototyping. 1 of our 1 of our paradigms at Working Call is, prototypes, not presentations. And I can't stress how amazing that is. Playing around with a new technology and making something work, discovering ups and downs throughout the journey, There's no white paper that can that can beat an actual working prototype and that can give you a sense and a feel about the community, about the usage, about the tooling. So, definitely, prototyping is the second point. And then, last but not least, agility in its purest form and in its purest sense, the context is the ability to rapidly adapt and respond to changes. Many times, these innovations, like if you balance responsibility with innovation, it's inevitable that you'll miss the mark quite a few times. It's really important to be agile, and it's really important to then change course, to have, an open, direct, and candid conversation with all the stakeholders and to course correct to something that's better for the the the work, the client, and everyone involved. So being truly being truly agile and nimble when hurdles inevitably come is what helps balance out the constant call of innovation, especially now when the newer the newer lineage of developers just rush to every new innovation because there's this appeal, And, it's really enticing to use cool new tools. So Yeah. I mean, as a as a developer myself, like, you know or in our entire team at Directus, it's like there's always this. It's like, oh, I just wanna try it out. You know? Especially because we're open source. People have this. You know, typically, open source is like nights and weekends, and it's like you can do whatever you want. And then when that becomes your day job, it's, you know, that balance is a little bit more interesting. You know, we're obviously very small, you know, had a full time head count of, like, 30 plus, but, Work and Co, a lot larger. And obviously, a lot even larger still. Nemanja, you mentioned sort of agile. I always used to kinda refer to that, as, like, a really important facet of of our agency, etcetera, but always, you know, mention the lowercase a so not to be confused with the methodology. I like nimble. Do you feel is do you feel like it's more important for for Work and Co, you as, as the agency? You find it more easier for you as an agency to be nimble, and and does that sort of align with your clients a lot, or are they a little bit, like, who where would you say the balance is there? Because I could imagine, you know, you you get your sort of things locked in, and you're ready to change at any moment, but maybe even after you've done run through some prototypes and you've gone through what things might look like, maybe they have more of a a set vision and they're not as nimble, once you get into the process? Or what what would you what are your thoughts on that? Yeah. III think the the word I like even more than agile is candid. I think it's really, really important to get to the bottom of why. Like, 1 of our partners, 1 of our founding partners, Joe Stewart, said when we did Virgin America, the clients know their business a 1000 times than we a 1000 times better than we ever will. There's always a reason for pushback. And as I said, it could be sunken cost fallacy. It could be the teams not being ready to adopt new technology. It could be because the technology is so deeply ingrained in the process, in the staffing, in everything that Steven mentioned. It it it's just really hard to pull out, like, a LEGO block and then replace with a nicer 1. So when things like this happen, when the other side, the the clients aren't as nimble, I think it's our responsibility as their partner to figure out why, and then to try to build a relationship and a sense of joint ownership. So the decision we land at is the decision that's best for the product and that's best for the work. I feel like very rarely is there irrational pushback. 9 out of 10 times, it's very good reasoning that's hidden behind business decisions and, people decisions. It's it's not as simple as it looks. That's why I like technology. Technology is super simple. Like, this is the perfect database to store this type of data, and that's where it ends. With business, it's much much more complicated. Yeah. Much I mean, the tech is is purely objective and that that at least removes it not removes it from the equation, but makes it an easier part of the equation. But I would say, you know, we talk about all these different intersections. There's certainly an intersection of people and tech. You know, specifically, when you're building out a project, that technology will be used by people. And, again, something that I'm aware of, 1 of the big reasons we built Directus was, you know, unifying you. This great shift from, like, the monolithic ERP systems to microservices was was amazing, but it also means, you know, those people might now have a lot more complexity in their day to day of, you know, 10, 20 different portals they log into and different APIs they have to, you know, go into references for, etcetera. So it's I I guess that sort of leads into the next question, which I'm curious, for both of you, your respective agencies. You know, how when you're really just getting started, how you do that initial sourcing of of tech, you know, for the stack of a project or for a whole company depending on the scope. Like, what is the key criteria you look for? You know, through the lens of the tech is simple, you know, you know, in a way, but the people in the process are are a bigger part of the of the problem to be solved, but also very interrelated with the technology choices. And open for open for either of you. Well, I think it I think it has to it has to start with business value. I I think that's the the most logical place to start. Inherently, I think you you have to go under the assumption that if if a client is engaging you, they're engaging you for a reason, that their business isn't where it wants to be. And they're either trying to streamline internal processes and backstage, goings on, or they're trying to enhance and improve the front stage experience for their customers. And so the only reason really to consider new technology or new engagement is going to be the, you know, the additive business value that the technology is going to bring. And so for us, I mean, Nemanja said it actually quite well in the in the previous in the previous question, where he's talking about, you know, there's there's always gonna be pushback, and there's always gonna be things that people are not telling you. And all of that is gonna come down to you, the client, or you, the vendor, working with the client, trying to establish trust in a relationship, and you can really only move at the speed of trust. And so the faster that you can develop that trust with the client, you're gonna get the whole story, and you're going to get the underlying reasons for considering a change. And that helps to understand how to move forward. You know, there's there's not a whole lot of rocket science here. We're talking about technology being simple. I think we often need to boil down business into more simplified terms where people just like doing business with people they like. And, usually, when you like someone, you're going to be open and trusting that they have your best interest at heart and that they're coming from a place of abundance that just wants to be helpful. And I think that's the benefit of working at is that I get to turn off, you know, this, agency owner cash flow mentality and turn on, well, how can I be the most helpful partner for this client? And I think that's really, you know, where it starts is truly understanding the the the place that they're in, the place that they wanna get to, and how new technology is going to unlock new value for them with the challenges that they're facing. A 100%. Yeah. And, like, absolute the idea that people wanna spend time with, do business with, whatever the the relationship is, like, they you people wanna spend time with people that they respect, that they that they like. You know? That you're gonna be interacting with people on a daily basis. You're gonna be getting good news and bad news. You're gonna have to have the, you know, the agility, and and with that comes, you know, the trust that's very much resonates with me. I I found that that was, 1 of the best ways to ensure really solid communication was just establish that trust, at the onset of even before you've, you know, closed the job. You know, when you're in the RFP state and you're trying to make sure that that you're, you're getting awarded that bid is be the most likable client. Like, they just want to have another meeting with you. Like, even just starting there is is is a pretty great place to be. It it's funny you it's funny you say that, because I'm probably gonna be giving away 1 of my, my own secrets here, but that's okay. I'm coming from a place of abundance and being helpful. But to your point, Ben, you'll always get like, every single agency pitch team, will get the question, you know, why should I choose you, in the presentation stage? And it's always someone who's, like, asking the question and then sitting back in their chair waiting for you to squirm. I have found that answering that question in a way that just sort of lays everything bare to that point and creates a foundation for trust is the reason why we've been successful in those stages. And, you know, my my template answer for that question, it it it's essentially look. Everyone you're gonna speak to is gonna have a great body of work and great case studies and a great portfolio. We do too. Everyone is gonna come to the table with a methodology and something that is going to help derisk the project. We do too. But what you're not going to get in everyone and what you are going to get in us is going to be a team that is advocating for your business outcomes and your audience, and we'll have arguments with you. And we will have passionate discourse about the best possible solution, but we're also gonna be able to come back to the table the next day and like each other and continue to work together and make your project a success. Yeah. And that that is, like, the respect. It's like that radical transparency. We're not just gonna say what you wanna hear. You know, if you gotta hear the latest trend of technology, like, yeah. Oh, I know that you're gonna be jazzed by hearing this. So, like, it's really about having the trust, that the can and the candor to be able to say what's needed to be said to to get that project. Because, again, if it's not successful project for them, certainly won't be for you. You're not gonna have the client, you know, as a repeat business. Yeah. It won't be a great case study, etcetera. Nemani, I'm I'm curious your thoughts on that that same question, you know, how, how you over at Work and Co, you know, find find that initial tech and what you're really, assessing assessing it against. Yeah. So, for us, the most important thing is to really truly understand our clients' long term value objectives. I think that's the fits really nicely into the narrative of business requirements often being a lot more complex than the tech ones. We make sure that we establish a vision for the experience that we're building for both the team and the end users, and then we work with the clients to determine the KPIs. After we are sure that we agree on what problems we're trying to solve, we can guarantee that we're not trying to use technology to dictate how we're gonna solve the problem, but it that it's the other way around, that we're gonna use technology as a tool. And then there are several critical criteria that we use to evaluate technologies. Number 1 is always efficiency and effectiveness in solving the problem. Not every technology is good at solving everything. We've learned about that with Clojure, for example, an amazing language who solve a lot of really complex data manipulations, not great at other stuff. And user base and community adoption equally important. Are there people that you can talk to when you hit a a wall? Is there a is there a lot of libraries? Is there an open source community? Are there people that are evangelists for the technology actively speaking and promoting their their their tech? And then availability of resources and documentation, of course. Once all of this finds a like, an average market that's good, we try it out. We either build the proof of concepts that I've mentioned, trying to solve specific parts of problems, or we use the tool to, work on an internal initiative we have. We do this a lot, where we have a bunch of internal internal tools, where we try technologies or stacks out that fit seem like they could fit the problem nicely, and that gives us firsthand experience in some of the newer stuff that we wouldn't feel comfortable trying out with clients immediately. It's an investment, but it's a well well worth investment. Yeah. A 100%. It's interesting too. I think you kinda led by saying, you know, focusing on on the long term vision, the long term solution, etcetera. What how do you quantify that? Like, when I was, you know, working through similar projects, everyone has a different idea of long term. Some people, you know, sit on a digital experience that's built for a decade, then they come back like, hey. It's not working because things got deprecated. It's not even supported or whatever. Other people have a very rapid, you know, iterative cycle. But, also, there's, like, strata to what you're building. You know, to what what we build for clients, there's foundational levels that can, you know, have the longevity to to survive and sort of support multiple iterations of a project. And maybe the facade, you know, the front end or what have you, maybe that does change and this that's part of the stack gets swapped out more frequently. But, you know, on the whole, like, what when you're talking about, like, long term vision, I'm curious I'm curious what that means, to you in the in that dialogue with your clients. In that sense, it means more whether the emphasis is going to be on like, long term vision for me particularly means scale and performance more than anything else. Like, how do we see the platform, grow over time? Do we see a huge surge in in the number of users, the number of visits? Do we see the data spiraling out of the the capabilities of the current platform? So we have a very honest conversation at the beginning about life cycle of technologies and stacks, about the the need to update libraries and platforms and the need to maintain as if you would maintain any other machine. The fact that it's software and that it's abstract does not remove the the reality of it being a machine. But the context there is more of a are we building a small tool for a discrete number of users? Do you see this growing? Do you see this expanding both in terms of people using it, the data living in it, and the number of features? Do you see your business expanding into other areas, out of which this part that we're building now will be a, foundational framework for or maybe a part of a larger system? All these things help a lot with decision making. Overoptimization is the root of all evil, said someone really smart. I can't remember who. But the point is you are not gonna build a an insane event bus orchestration layer with Kafka for an app that's gonna be used by 100, maybe 1, 000 of people. It's redundant and unnecessary and a huge waste of time. So aligning on on what the build is the build strives to be down the road, helps a lot with cost, helps a lot with effort, and with the the technology choices as well. Yeah. No. A 100%. You said over optimization never I also think that optimizing too early. I mean, there's there's all sorts of gotchas, you know, in there. But now I'm I'm curious. Is there an example, you know, that that you can think of that you've, like, you know, pretty recently where you maybe had some issues that you had to overcome with with a client in these in this decision process? Yeah. 1 of 1 of the examples that, comes to mind is working, with a client partnering to transform their legacy technical ecosystem, making sure that it can better serve the needs of their increasingly digitally focused user base. And then a critical decision point was choosing between building separate mobile apps using bespoke technologies like Swift and, Kotlin, or going through a cross platform mobile framework like Flutter that we really, really like or, React Native. And, the decision was complex. It involved a lot of a lot of moving parts. The existing team capability, their goals, their capacity, their performance, and that long term vision that we mentioned, which is how they see the the product moving forward. Also, security, a really, really important point. Yeah. So the way we approach it is we set the stage by really clearly defining the opportunities and challenges of all the approaches and making sure they understand the context and the impact each approach will take. We define proposed architectures based on the feedback that we got from them. Again, developed a lot of proof of concepts to show how different technologies on different devices behave when solving the same problem, and then went with a decision that I think all of us, the clients and us included, were very, very satisfied by and got a great outcome. And it was a it was not an easy process, I would. It was really, really tolling to get to a point of mutual satisfaction, but I think what got us there is a very close collaboration. And, again, I'm like a parrot now, but a lot of really honest candid conversations where you have to be really clear. Yes. This is 5% faster and better, but it is going to increase the development time 2 fold or 3 fold. Or maybe saying this is faster, but once you hit, 1, 000 or 2, 000 concurrent users, we are gonna start seeing problems. So having these conversations happen in real time and being ahead of the curve and making sure that all the angles are met greatly helps with Yeah. Situation with this. And a lot of knowledge that you as an agency who has gone through this process at different scales, different customers iterated through, you know, okay. We built this, and now here's version 1.1 or 2.0 and the adjustments we had to make make. There's a lot of, you know, institutional knowledge there that you can give to, that client and make sure that you keep things on the rails that requires that trust. You know, they they have to understand that you have gone through this before, and you can, you know, hopefully learn just like in life. You can learn from those mistakes before you make them, you know, whenever possible. Steven, how about same thing for you. Like, have you have you had, a project recently where you were sourcing that tech and it just there was some sort of challenge or issue that you that you ran into that you had to try and figure a good way to work around? I think there's always challenges and issues. Yeah. A more notable 1. Yeah. I yeah. I I think we have been doing or, about to conclude a project that is a, a commerce, transformation, retaining legacy ERP and then migrating, the entire experience off of 1 commerce platform to another. And, you know, someone told me once the the, really great analogy. The organization has been speaking French, for, like, years, for however long they've been using this commerce platform. And they know French, and it's second nature to them. And moving on to another another commerce platform, yeah, it does the same thing. It's still a commerce platform. It's gonna do cart. It's gonna do checkout, but it's in Spanish. And so now they have to think in French and then translate to Spanish. And sometimes the way that you've been speaking and the way that you've been working for so long, even though it's a very similar context, it's an entirely different language, and you have to learn an entirely different language. And so 1 of the things that often comes up in in these scenarios is a client essentially saying, you know, but I wanna do it this way. And there's a limitation of the technology because of the opinionated nature of that technology that's essentially saying, well, you can't do it this way. And so then we need to come together as, you know, vendor or service integrator and and client and have a conversation about what is really driving, you know, this request and what is really driving this requirement. And when you understand what it is, then you can identify maybe a way to work around that. And then what you what ends up happening is to to Nemanja's point, a real candid conversation around the value of that workaround. And so it's, you know, we found in 1 of the in what in this example that about 5% of their revenue needed to perform a function that they were requiring. It came from this, you know, servicing of a customer. And so do they really wanna spend, you know, AAAA pretty hefty amount relative to the overall project cost to incorporate something that's gonna take in 3 to 5% of their revenue when they could probably just live without it and then find ways of servicing the customer in a different way that they won't find an impact on. So I I think it's again coming to, you know, really ensuring that you've got future proof and scalable technology from several factors. You know, the technology's adaptability to the evolving industry standards or the regulate regulatory environment, its ability to integrate with other systems, and really the provider's commitment to continuous improvement and support. And we look at all of that and its potential to leverage emerging technology. I mean, we're all talking about AI these days, and, you know, Directus has also gotten into the, into the AI game as well. And then looking at those regular reviews and updates, the technology road map, all of that coupled with those candid conversations and trying to find POCs that are going to help create workarounds, but then evaluating the POCs based on return on investment, I think that's, like, the way that that we approach it, and that's the way that we go. And that's a relatively recent as of, like, 2 weeks ago example. Yeah. It's a it's a big 1, and it's it can be hard to kinda make those decisions when you want to be improving. You wanna sort of modernize every ask you know, every corner of of your business, your process, etcetera. And sometimes, like, the ROI is not there. And, you know, when is the right time to kind of remove that technical debt, that legacy, part of the stack? You know, or, you know, do you ever you know, do you just kinda band aid it, add infinitum until, the ROI changes or it just no longer functions or, you know, there's there's a lot to that. It's interesting, though. I think you both have mentioned sort of this idea of, like, being opinionated or unopinionated. I'm curious, you know, Steven, you just mentioned making something future proof, which I I always I'll always kinda throw quotes around air quotes around that, and scalable, which I think is a big part of being future proof. You don't know how you're gonna scale necessarily. I mean, in an ideal world, you don't know because you could think things are gonna go amazing, they go even better. But how do you ensure that the the tools that you source are future, you know, future proof. And, you know, when you're thinking of things like, you know, the words like unopinionated or opinionated, I think both have, you know, pros and cons. You know, does that tie into this thinking, this, like, methodology for for choosing the Oh, yeah. The the tech? Yeah. Yeah. I I think that everything that I just mentioned around, understanding the technology's ability to, incorporate emerging technology, its evolving nature with industry standards, as well as, you know, regulatory standards. All of that, like, it has to it it creates the the the foundation and the guardrails for businesses to be operating in. And selecting a technology that doesn't take into account those guardrails or those foundational aspects of the business operating environment, I think, is a surefire way to surefire way to choose the wrong technology. Do do you feel that, like, again, just do you feel that something choosing tech that is opinionated and follows those specs, you know, that compliance and just, like, checks those boxes, you know, out of the box, so to speak, off the shelf versus maybe a tool that's more unopinionated, that allows you to take those those paths when needed or if those paths change, if there's a new spec that's introduced to you. You feel like there's a benefit to either of those options, or do they both kinda have their place, depending? I think they both have their place. I I think it's gotta be fit for purpose. Like, commerce is a great example. You do want it to be opinionated to some degree. Like, you don't want to be messing around with the world's best commerce platform, and then find out that your conversion rate is suffering. So in some respects, like, if you want to maintain your legacy stack, but you want to change your commerce platform as part of your architecture, then getting the benefit out of that commerce platform, you're going to have to find a way to make your technology stack and architecture work with that platform, if you want to reap the benefits of that. So that's, you know, a very, very purposeful and intentional incorporation of opinionated technology. But then in areas where you don't really know what the end goal is and you have a good inkling as to how you can foundationally get off the ground very quickly with an unopinionated and flexible piece of technology, then that's a a really, really big benefit. So something like Directus is a really, really great place to start because most people can create a frame of reference around Directus as, like, a CMS. And so when you're, you know, doing any kind of project, most projects require a CMS. And so you can anchor onto that frame of reference, but then because Directus is so amorphous, it can literally be anything you want it to be or need it to be. And it's got a very friendly microservices architecture. There's really no sort of cookie cutter approach to what you're gonna use Directus for. So that's a a really you know, in my in my experience, that's a good example of leveraging opinionated architecture for what it's intended for and then leveraging something that's as unopinionated as can possibly be to help you grow to what's next. Yeah. And then, ideally, both sides of the coin have strong points of integration so that they work well together. Exactly. Obviously, you wanna, you know, mitigate as much negative space as possible because that's where, you basically just have to start building custom to kinda fill in those gaps. So if you can have things bookend nicely together, and and play both sides of of that, that's sort of the ideal state. And, you know, side side note, you we we spoke a week or 2 ago, and you had mentioned you used that word amorphous to describe direct us, and I ran back to the team, and probably end up in all sorts of our our marketing collateral. It was just like a a really great way of describing it. Similar to sort of like nebulous, but nebulous has this kind of like more pejorative, like, what are we? What is this? And amorphous is is is just a great term. I love that. Nehemiah, you you had kinda mentioned a second ago, I think it was like prototypes, not presentations. When you are, you know, going out and and sort of pitching to clients, may could you talk a little bit more about that? Like, I'm I'm so curious about, like, that process. Like, what does that look like? You know, very aware of, like, what a prototype is, you know, versus a more traditional presentation. But how does that typically go with clients, and and how do they how do they receive that? Very well. I think the first of course, that's never the first step. The first step is gathering requirements and hearing about the problem, aligning on what we need to solve and what needs to be tackled. As we're focused on products a lot, very often, it's a an exciting segment of, the the customer's business or a new feature or a new, new product within their ecosystem. Then we go back to the drawing board, and we build something that we we show the clients. And I think that leaves the best impression, by far, seeing something, work. And we have amazing, extremely talented designers that can, in a very, very, I would even say, absurdly short time frames produce amazing work. Once, once you see something that you only have in your head, in front of you on a screen, that helps immensely. I I have never seen I've never seen feedback after a a, like, a keynote presentation as I have after a couple of framer framer prototypes. Then the tech comes into play, and then we have a very, very thorough and deep, initial discussion where we try to understand the the tech team composition, the capabilities, the current infrastructure, architecture platforms, and everything that's there in order to better propose a solution. But, yes, the the prototype comes not as a first, but as a very close to first step, where it's the wow effect that, really brings it home. Because, we are visual beings by nature. And, that's why I feel like every developer, every engineer needs to I am let's put it like this. I'm com I used to be completely void of any sense of aesthetics. So math, math, math, then physics and electronics in in university. And then I worked through it because we are visual beings and to be in the line of work we are, which is digital, everything is very, very aesthetic, and people respond to, amazing inspiring interfaces. So, that's where I think prototypes are key. Again, seeing these ideas that we all talk about in presentations come to life is the same with features. There's a lot of talk about AI now and the capabilities of LLM and the conversational platforms. Seeing a happy path prototype often says a lot lot more than a bunch of keynote slides illustrating our general capability. Just seeing a happy pet alum consult you on which product to buy, I think it sends a really strong message about capability, preparedness, and the the the talent within the team. Yeah. Definitely, if you go into it with the mindset of getting that massive knowledge transfer, like truly understanding, you know, the problems, the root the root, you know, things that need to be solved, the goals, etcetera. And you understand the business, the team. Once you have all that, you know, over at work and co or or UI, like, I think then you can kind of jump into that. It's it's interesting, though. I agree. You know, humans are so visual. Like, the idea of, like, inspiring through, like, you know, pen to paper, so to speak, is huge. But at the same time, like, I started thinking because that that's how I operate. You know, I'm very quick to get in and start just divergently coming up with with UX, UI, like prototypes. And I feel like that conveys so much, so much more than a presentation if you have that, you know, the initial work ready, you know, informing that process. But, also, it makes me think of, like, books to movies. I watch a lot more movies than I do read books. I you know, just time wise. But there's this idea of, like, you read a book and we're also imaginative creatures. Does it ever backfire? Because when you kinda go in with a prototype, that's like the movie. Right? You're sort of saying, like, this is this is what this could look like versus a book, and it's like, oh, that's I read the book, and then it was so different in the movie. And I don't know how I feel about that. Once you've kind of gone that direction of a prototype, do you ever feel like you are locked in because they've seen it and it's like, oh, this this is what we want, and then it that agility, that flexibility becomes a little bit more difficult? That's where the the experience of years of pitching like this comes in really, really handily. We build prototypes to solve specific problems, sometimes even specific parts of specific problems. So it's not such a, such a heavy buy in or such a huge commitment. The prototypes often are, vital and instrumental at solving this 1 key thing. And, 9 out of 10 times when we do show a prototype, we know that that's the direction that's ultimately the best for the product. So showing a prototype solving that 1 key thing isn't completely selling you into 1 solution. It's a learning experience, and, it's articulated by us being a lot more diverse and potent prototypes that were selling us into solutions. Now it's a a good balance of both. You explain, show capability, demonstrate previous. As Steven said, we all have really nice case studies to fall back where everyone's impressed at how we solved really complex problems for really great really great clients, but then for specific segments or of specific problems, I feel like that's the sweet spot sweet spot for prototypes. Not to committing, but great at showing capability and putting like, giving a visual aspect to the solution. Yeah. Oh, I mean, a 100%. Steven, I'm curious. So when we're talking about, like, we're we're presenting to the client, you know, sometimes thing things backfire. When when a client comes in, maybe they already have preconceptions. I guess this could apply to to either of you, but they have a preconception. This happened to me a lot. You know, I I used to joke, with with our team that it was, you know, 1 of the executives, like, they had a niece that, like, worked for a company. It's like, this is the bet. Like, I've heard so much about this and, like, that is the preferred stack or tech tech choice. You know, I think Carlo had a, who just posted in the in the audience questions had a similar, you know, how do you manage client expectations when the recommendation recommended technology has a steep learning curve? I I think there's, you know, all of these sort of questions around how do you get past, you know, when there's tech that might not be a good fit for the company or it is a good fit, but you're just not aligned. And and maybe trust isn't quite getting you there. You have to really dive in and and, you know, sort of or cover that somehow and and help bridge the gap of, like, yes. I understand that this is, you know, the the latest, you know, hype train tech, or I understand that you've heard a lot about this this other thing from a family member or whatever it might look like. But any thoughts on that, like, how you navigate that? So many thoughts. I do like, I I just wanna go back to, Nemanja's comments about, prototyping. I I think prototyping has a huge, huge amount of value in the work that we do for clients. Ben, I'm I certainly don't wanna poo poo your analogy on, you know, books and movies, but I think the important thing there is that, people can either create their own context or the people that they are hiring as experts can help create a better context. And if you leave someone to read the book, then they're creating their own context. They're creating their own imagination. They're filling in the gaps for themselves. Whereas the movie is telling them, like, this is what it is, and there's no imagination here. There's nothing, you know, left untold. This is the story, and, you know, you should pay attention to to this story. David Kelly, from IDO has got a great quote about prototypes. If a picture is worth a 1, 000 words, a prototype is worth a 1, 000 meetings. And so, like, you know, IIII do love the idea of prototypes because it does create that on ramp to trust. If a client's got a problem that is, you know, in their mind, immutably solve unsolvable, then, you know, a prototype from a experienced and professional team coming in to, you know, help highlight how it could be solved with proof of concepts or prototypes that, like, that accelerates the engagement massively. It creates a huge amount of trust. It helps solve a problem. It creates business value, and it's 1 of those things that clients can easily get behind because, again, going back to people, like, doing business with people they like, the person who you're working with has to look good in front of someone. And if you're helping them look good in front of their boss, like, that just solidifies and galvanizes the relationship because you're solving a business problem that goes beyond them. So I'll say that on on prototypes. Well, I just and IIII do agree because, again, we're hired as agencies to it's a full service agency, typically. You know, you are delivering a full suite of deliverables. And I think the the book and or, you know, the the the story itself is 1 piece of that, but it's our job as, you know, on the UX side, the UI side, the all these different pieces to be the cinematographer, to be the director, to to kinda give them the entire experience. Otherwise, you know, you're leaving it up to them. And maybe they're they're great and they have some great visions, but you're also probably gonna end up with a roomful of people who are all interpreting things quite differently. And And then you're gonna be navigating the people problem of, okay. Now we gotta try and wrangle everybody to the same page. Yeah. So I I think the the way the way that that we try to solve that is really trying to be proactive, right from discovery. I there's 2 things that, I will do within my engagements every single time. The first is is, an exercise called the graphic game plan. And, it was initially invented by, Grove Consultants, And, I leveraged this sort of storytelling visual of, hey. We're all we're all in our in our car, on our road trip heading towards this destination. The destination is project completion. What is going to be the measure of success for project completion? And then we put everyone everyone, including our team, the client team, puts their measures of success right in the center of that target. Then around that, you've got primary and secondary objectives. What do we want this experience to be? How do we wanna feel when we're doing the work? All of these sorts of things, We get them up there on the target as well. Then in the car are gonna be all of the stages and tasks that we need to do in order to achieve our objectives and achieve our our measure of success. Below the car, there's these bumps. And those are gonna be the challenges that we're gonna be facing along the way. And then the wheels on the car are gonna be the success factors. If everyone gets into a room and starts talking about success factors, challenges, all of the things that we have to do, the resources available to us, the objectives that we're trying to hit, then everyone owns the scope collectively. There isn't 1 side that owns the scope. And when you both share the scope, that's when you avoid things that I lovingly call climbing Mount Death March, where it's the vendor that is figuring out the scope of the project because it was ill defined at the beginning while they're developing. And, like, that is just the worst place to be in. So that's the graphic game plan. And the second thing that I'll do is ensure that we have stakeholder interviews from everyone in the company that could say no even at the 11th hour on the project strategy and the project direction. Because the 1 thing that every project should try to avoid is the swoop and poop. And that's, you know, when you're at a beach having a great day, team's doing great job, and a seagull flies in, shits all over your picnic, and then flies away. And then you're Good luck. There. What's that? I've heard that's good luck. That's a good thing to say. Trying to make you feel a little better about it. Yeah. Only the only the people that, they get crapped on tell you that it's good luck. Yeah. Only in the metaphor. Yeah. So those are the 2 things that we'll do to make sure that we've got alignment, right from the beginning. And that is probably the most important thing. Because if you take a flight around the world, around the equator, and you're 1 degree off course, by the time you get around, you're gonna be 500 miles off target. And that's 1 degree of deviation. So better to get that, you know, that heading right on target right from the beginning. Yeah. Yeah. I mean, it becomes rocket science. I mean, you the the more off you are, the earlier you're off, that just kinda compounds and you you're scaling problems. So if you can mitigate that, that's definitely something to be very aware of, in that early process. Yeah. Nemanja, I'm curious. Do you have anything similar, like, where you you've kinda had to deal with this issue of people coming in with preconceptions or trying to wrangle, you know, someone away from this idea that really just wouldn't work, but they're they're just struggling to to see the vision and to have that trust. Yeah. More oftentimes than I would like. But, I think that, you can't win them all. Sometimes just having a having done all of your homework, having done an extensive discovery phase, having validated your assumptions, done all the prototyping in the world, shown capability, discussed caveats, her hearing the client out and hearing their reasoning, seeing that there is no greater mystery behind why someone's as adamant as they are about a certain technology or not adopting a certain technology, the conclusion might, in the end, be that it's someone's need. And, that's okay. What we do in these situations is that we establish a very, very loud and very clear communication channel throughout the process from the first meeting where things are we're an agency, and we eventually perform a service for our clients. So if you've exhausted all of your options and if there is no other way to argue your point, you just have to be very, very clear and very direct and to communicate very frequently what the risks and consequences of a decision you believe are is suboptimal are. So making sure that this 1 degree deviation that everyone knows that it's gonna be 500 kilometers by the time we get back and alerting date, like, an alarm clock every hour. Like, saying in every retrospective meeting or every time there's an opportunity to discuss technical depth or to discuss progress, just making sure everyone understands the consequences of the choices that we believe were suboptimal. 100%. As I said, you can't win them all. There's no way that everyone's always gonna be aligned regardless of how good your argumentation is. But I think it's our responsibility as partners to make sure that we alert to these consequences as often and as early as possible. Yeah. No. A 100%. And I think, again, when things go south, the best thing that can happen is to already have established trust. You know, they they understand why the communication is there, and at least then it's you know, you you can hopefully navigate, through the project or whatever that ends up looking like. But, yeah, I we've kind of mentioned that word so much. I it really, you know, going back to, I think, the beginning of this, Steven, you had said you can only move at the speed of trust, which I took a note of. I think that's I think that's an amazing, sort of, like, way to kinda think about this and highlights the importance of that trust and communication, and it connects it to something that's very real. Like, when you're building a project, you've you know, speed. Speed is important. You can't you when I was running my agency, there was kind of 4, sort of levers that you really had to work with, and they were all I I think there's even a website where you can turn certain ones on and off. It was speed, scope, cost, and quality. And, of course, any good agency is gonna take quality off the table and say that's always gotta be good. We're we're not gonna sacrifice that. So you have these 3 toggles that you can kinda, you know, choose to choose your own adventure. And it's great to know that trust is a huge part of of the speed of the process, because, really, in the beginning when you're figuring out the scope and you're, you know, setting up what the cost looks like, you just efficiency and speed is is the name of the game. You know, how can you get through and and help to establish that and help the client really understand what their options are, that you are the right vendor, or, you know, partner to help them get through this. And I guess it all just comes down to to to that trust. So, we we've said that word a lot, and that's I think that's we we could probably rename this episode into, you know, establishing trust and, you know, the importance of trust at the agency level. But, you know, we we we ran over time a little bit, which is which is always good. We didn't even get through through all of our questions here, or, you know, I think there was a few that were thrown into the chat. But, any final thoughts, Steven Steven or Nemanja? Nemanja, why don't you go first? Yeah. I was just gonna say because it piggybacks nicely off of what you've just said. It's not only trust, I would say, it's partnership. Like, 1 of the things that got me, when I was deciding whether I'll go into agencies and service work or whether I'll go into, like, building a product startup or something like that was agencies, at their core, help solve problems, and you can't help if you're in an adversarial position. I really every relationship that we've had with a client that was hugely successful and that brought a lot of, for lack of a better word, happiness to me after the resolution was when we were true partners. So it's not like we're warning you this will fail because you're not listening to us. It's like, how do we make sure that since these are the the axioms that we have to work against, we fail less as a team. Like, being a partner to our clients is, I think, a lost forgotten art. Sometimes we get into a mindset of us versus them. I don't think that's a good mindset for agencies or tech providers at all. We serve technologies is there to serve solve problems. And, like, at its core, what we do is we facilitate. We use amazing tools to change the world. So partnership and not pointing fingers. The name of the game for me. That's hon. I that's exactly right. Open, trust, you know, those are all key things, but really the goal of those things is to, establish a partnership where you're you're in it together because, I mean, you truly are at the end of the day. Yep. Steven, thoughts on that or, just, you know, closing closing thoughts? Yeah. I I mean, I, I feel like Nemanja and I drink the same Kool Aid. It's 1 of those things where, for me, there was a very, very defining moment earlier on in my agency life where I I really just took on this mantle of being a designer is the most important thing in the world, and I would tell my clients, you know, the overarching responsibility of a designer and and how we're, you know, empowered to create amazing tools. The bottom line is they really didn't give a shit, about my my little speech about, you know, design. And it really sort of came to a head when I started changing the language that I was using around the value of the work that we do and what we bring to the table. And it was speaking my client's language, being empathetic to what their needs were and how they were articulating their business problems. And it was all in the language of business. And so if you can get out of your own way and stop speaking the language of design or stop speaking the language of technology and speak the language of business and how the tools that you wield are going to help solve their problem in a way that makes sense to them, that's when you actually engender really good partnership and really good, foundation of trust. And so I think that was a a really key moment for me in my, in my sort of growth and learning, as a agency owner and now someone who's in the, you know, the big 4 consulting world. Yeah. Couldn't could have said it better. I I again, these are all just huge pillars in how you how you kind of establish and foster, those those relationships. And then again, the the benefit of that is then you end up working with these clients, over and over and over again, and they just become huge advocates, for not only the stack that you help them select, you know, which, you know, we're a great great in a great position to be chosen by such a great you know, by so many great companies, but also, you just get to, have that repeat business and long enduring, partnerships with with great companies. So excellent. Steve and Damania, this was has been an awesome chat. Again, probably, we'll have to, like, circle back and maybe think about another 1 because a lot more. Again, this is the, you know, the whole reason for me being here, was was how how to solve these problems within an agency and trying to find the right tooling. And it's not always direct us. It's not, you know, that's the name of the game is, you know, just finding finding the right tool for the right job, which is not easy, as we say in an hour and 8 minutes in. But thank you both so much for joining, and we'll be seeing you at the rest of Leap Week for everybody else who's who's watching now. Thanks so much for having us. Absolutely. Alright. Thanks, everybody.","4b21caf7-40e8-4f5a-b7b4-7d23c2aba06e",[80,81,82],"10147a57-dc26-4090-b5ea-d5ff4b089b04","a334f73f-c0c0-4021-8a9f-4f874eefea24","56797030-83a9-41f3-b194-791d0979c2d5",[],1782310050451]