 Hello and welcome to another episode of the collab talk podcast where we discuss the convergence of technology business productivity and collaboration culture. My guest today is Aaron Amy, Microsoft MVP, the CEO and founder of Raven DB. Welcome, Aaron. Thank you. I'm really happy to be here. This is a great topic. We've talked about collaboration in the broadest sense and everything around it, but I love talking about community building specifically. So community as a cornerstone and building business on open source foundations, which, again, given your background, given what you focus on, but you're also an MVP. I mean, you know, so that's like, that's perfect because I work in and out of the Microsoft ecosystem as well. And it's always interested to interesting to look at the comparisons of what I see around Microsoft community building, and then my past, which is, you know, open source and IBM working with rational software 25 years ago, you know, building up community in both of those areas and see some of the differences. But why don't we kick things off first or introduce yourself more fully talk about what is your company? What do you do? What does your company do? Okay, so my name is Oren. I've been working on software development for 25 years at this point. For the past 50 years or so, I've been working on Raven DB, which is a document database. It is written in C sharp. It has a really good link provider C sharp driver. And the whole goal of revenue B is to be a really boring database, something that in the same sense that may you live in interesting times is a Chinese then have a boring database is a really good blessing because it means that you don't have to deal with all of the minutiae of be this mismatch or data complexity or have to spend all day figuring out why my system is so you can just get things working. And that's what I aim to do with revenue B. The reason it even exists is I used to be a database consultant, specializing in warms of the connection models. Think about think about the hibernate entity from work and link to sequel, those sort of things. And I got so tired of seeing people fall into the same pitfalls each and every time doing really, really stupid things. It's time done again, not stupid people really, really smart people who will focus on doing, oh, I need to get this feature out of the door and they basically fell into a hole that would suck a lot of time, performance and effort to fix. And I created revenue B because I really had this idea, what if I could fix that. And he tells us that you cannot fix that in the or m level, you have to build an actual database. So that has been about 15 years ago, so I started longer than that because I started thinking about how I can do that in 2007. And it's interesting because I did not and I cannot emphasize that enough. I did not want to create database. I was forced to do that by this burning desire, this need to get it out of the door. I remember being walking up at the middle of the night, staring at the ceiling and having this minority report like episode where I'm seeing different components fly around and combine. I know how to make it work. Like, I don't have the words of expressing the level of inspiration that that gave me and drove me. And at the same time, being in the database is a huge amount of work. And speaking as someone who has paid the mortgage using the database for a while, I have been absolutely stupid to do that because this is such huge task. And one of the things that I even very early on I realized this is a huge task. So I have, so I did something that I was very proud of and I decided, okay, I cannot get it out of my head. It has to go. I have to spend the time in actually working on that. And it turns out that this was more than a full time job. I was working eight hours a day on my normal job. And then I would spend the whole night hacking on RevenDB. And I would spend more time on RevenDB than any other because it was such an amazing experience and drive and whatever you want to do that. But at some point I look at my financials. I said, hey, that's a problem. You know, I'm not getting paid for that. So I came up with an appropriate solution for that. And I like to call it the stop-low function. So at what point do I stop before I lose the shirt? Okay, so I sat down and had the business plan. I had an up kill and it says, okay, I'm going to invest this amount of money, this amount of time into doing that. And I have to be able to make money so, you know, I can eat. And this is the point where I would be able to rest and say, okay, I've done my best. I cannot make it work for my financial sense. I have to put it aside. That was my stop-low function. And it turns out that people really, really like that. We like the database. They were willing to pay me to build this database. And I've been doing that professionally for quite a while now. At the same time, one of the things that I think is really interesting, RevenDB is an open source project. It's released under an OSI approval license. You can look at the code. You can modify the code. You can deploy the code or distribute it yourself. At the same time, I have to be able to pay for that. And that is a really complex thing to do. If I want to bring some current events into this podcast, then consider the XZ fiasco that we just had, where a critical vulnerability was added maliciously to a well-known community project, simply because there is one maintenance and he's tired of doing maintenance for the last 20 years or so. So when someone volunteered to do some ground work, he says, yeah, sure, go ahead and do that. And apparently if you spend two years doing something, then you get some trust. And that is a bad vector for supply chain attacks. A similar scenario was with OpenSSL, where there was the help lead attack. And people realized that, you know, here is this library where the entire world is based on. And there are two guys doing maintenance on that basically because they feel like it. That's not a sustainable model for something like that. And that I think happened a decade ago or something, because I cannot remember at this point. But that's actually really an important issue when you think about how we start your software today. Because in almost all cases, you're never going to build software starting from, you know, a blank C file in the C compiler. That's it, and you build everything from there. You're going to have components. You're going to reach out for what is there, whatever this is on Nugret or NPM or PIPI or whatever. So most of those things are going to be open source and to a large extent, you want that this is highly desirable. But at the same time, who is paying for that? Who is paying for ongoing care and maintenance? With GitHub, we have a really nice feature that dependable that tells me that, oh, here is, there is some vulnerability in some tertiary dependency that they have on some NPM package in a project that I last touched 10 years ago. So I'm not touching that. I'm not going near this thing to just even figure out how to build that on my machine. Means that, oh, I don't have Node 6 anymore. I don't know where to find it. So there is an actual ongoing course on ensuring something that will happen. And that is a huge issue, both from a community perspective and from an industry perspective. Yeah, there's, you know, having been not non developer, I understand a lot of the issues though with open source project having participated in, you know, going back in 25 years ago, was on a board with the global grid forum and trying to so with the standards bodies that was, you know, working with a number of the different companies here is one, I mean, always was always grateful for the various the sponsorships, meaning large companies that would donate time so they were paying for employees to go and give time to a lot of these initiatives that helps. I mean, it's, it's great when you find altruistic people on their own time just out in the community that are trusted that have been there for a while. It's, but you also need to have, you know, these participants from sponsoring companies that want to. They have a, you know, an interest in seeing, you know, these efforts move forward and be successful and be safe to help fund those things. It's funny, it's there's always, again, you get the purists that are in open source community that are like, we don't want corporations, we don't want to have these big brands and things that are in there. It's like, you know, who do you think are the people that have the time to have the effort, you know, to put behind it. It's a mixture. It needs to be unbiased. It needs to be neutral. It's, it's a huge issue because if this is a label of love, and for most people, the, the, I don't know how to say that the ideal, the best scenario for open source contribution is that you do it from a position of love. That's amazing. And okay, sure, that's the best thing ever. But at some point you have the maintainers and they need to be able to, you know, it and they need to be able to manage their time and effort and who wants to write yet another integration test. Or, or I need to make sure this works in a dotnet standard to to and that's annoying because there's missing API or whatever. And I now need to make sure that they have reproducible build or any of the. Married level of choice that you got off that. And if you look at open source in general, in general, you can typically divide them into few categories. I'm going to go right now, the case of personal projects, or I want to build something. And this is not something huge like my blog engine or something like that. And I'm using that to learn. That's great. I'm not touching that. We're talking about stuff that actually get used by other people. So either this is a byproduct of something that they do for work. For example, maybe I need to have really good authorization library. So I would write that and I needed for project. And I would write it and it fits my needs. And I would make it open source because they were not. This is not my core competency. Maybe someone can use that. Maybe someone can make it better. That's fine. Take that over the long call. And that's a huge problem because now there is the community that you get around this product around this team now has an issue. I don't need this to be a genetic. I need it to fit my specific scenario. So either I tell you go and fork the project and or I start accepting outside contributions and lose some control of the project or something like that. At the same time, if I'm the head of the project, I still need to review code and still need to maintain it. Oh, I need to make an addition to the code. I have to take care of scenarios that I don't actually have. But I have, but they're your summer, but I still have to take them on themselves. One of the things that people may not realize for open source project is that, oh, you're asking for my code or maybe you even ask me for copyright assignment or something like that. When an open source project accept your codes in most cases, they also accept ownership on that over the long haul. And this can be an enormous burden to bear for many projects. And now we are talking about, okay, how do I make money out of that? And people try to say, oh, if I'm looking at open source project and money, that's like diluting the value or something like that. But at the end of the day, if you want to have a professional developer and the attention and care that needs, you have to pay for that. Otherwise, you know, going back with, I created this project for, this open source project for this scenario that I have. But now I move from building, you know, retail application to healthcare. So I'm not longer maintaining the barcode scanner, whatever it is that I used to do before. I don't have the time for that. And now you may have taken a dependency on me. And now you get into a really, really bad place where even if you wanted to pay me, I may not be able to. I don't know, it depends on the jurisdiction. But for example, in Israel, if I'm a full-time employee, and you want to pay me outside of that, it's a major hassle. I have to go and get an accountant. I have to get- Possibly legal approval. You know, I'm right. I'm even leaving aside the fact that my job may need to approve that. Just the bureaucratic hassle of being able to issue an invoice and report to the tax authorities. At one point, and people may severely underestimate the complexity. Like if you send me money, I have to be able to show that that money was sent for a commercial variable. Because otherwise the bank would assume that you're sending money for drugs. And I would have to prove that this money is not for drugs. Not for drugs and crazy stuff like that. So the cost of actually getting money, if I'm already employed, is actually much higher than people expect. So, oh, I cannot just, you know, wire you $500 or whatever, and you can spend an evening or two hacking or something. That leads to, okay, if this project needs to have actual money behind that, how does it actually gather this money? And now we have a few options. One of them is the foundation model. So the classic one would be the Linux foundation Mozilla. Right now a small foundation that exists is the Z-GlangWitch Foundation. And they're basically saying we're getting sponsorship from a donation or something like that, and we will hire people to do that. Z-G is a really nice new language. It looks amazing. It has very nice capabilities. And one of the incidental capabilities that it has, it is a really good build engine for completely different reasons for the core competencies of the project. Many people choose to use Z-G, not as the language, but as compiler for C-project or C++, because it's making it easy. And if you think about it, okay, now we have people who are, you know, paying $50,000 as a company to basically to have a good build engine. But the core of the foundation, what they want to do is I want to be in the good language. So totally different mindset. And in the end of the day, if people are paying money for you to build a build engine, that would have a major shift on the direction of the project. Some reason that Mozilla makes most of the money from Google sponsorship and things like that. That's a huge aspect of how things are working. I'm just going to say this. A lot of people that, again, the purists out in the open-source world that get upset when Microsoft or some other major company forks a solution and goes and builds things. Because it's like, well, like anything, you have to look at, if I'm not, if I'm waiting for Microsoft to build and extend because I'm interested in certain integrations and the path that they're going. But I have the same problem with the open-source that I'm waiting. Does somebody have the time? Does somebody interested in, you know, building out the functionality that I want? You have that problem either direction. To a certain extent, one of the, it used to be the case if we're going back 15, 20 years ago, it used to be the case that Microsoft has a blank policy in open-source. And if you wanted to have something from Microsoft, then they would have to build it themselves. If you remember, it used to be the enterprise library, which would curate all sorts of interesting patterns from the open-source and give them their blessing by issuing basically code droplets that you would use. Basically, it was like open-source, but for Microsoft and that's about it. And that caused a huge amount of problems and a vulcanization of the community because if you were, if you wanted to do the best thing, you would go and use the open-source projects because they were the most up-to-date, they were the fastest most capabilities. And if you were tied to the Microsoft Dragon, then you would use the enterprise library, which was typically in terms of patterns, behavior, et cetera, would be at least a couple of years behind the two, three-year cycle. Right. Yeah. Yeah. And it was also tend to be a lot more cumbersome and enterprise and all much of other stuff like that. But the weight of the Microsoft branding on anything was so huge that it basically choked the open-source community. And even to this day, if you look at the login interface and DI interface, it used to be a really vibrant community. I was part of it in .NET around dependency injection containers and inversion of control and all sorts of stuff like that. And now we have the iService provider that is provided by Microsoft and almost everyone just use whatever is in the box. And I think that we lost a lot of capabilities and experimentations and everything like that just because, you know, okay. Microsoft did it, it's sufficient for our use case. It may not be the best thing, but, you know, we did with that. And that's it. And the issue of Microsoft issuing something like that and then basically killing the community around that. And again, entity framework is a great example of that. I used to be in the hybrid project and the entity framework basically competed with that with a lot bigger resources. And that's a problem. And the other hand, okay, now I have an owner, a known owner for this project. But if you have an enterprise library project today, then you're in a very bad place. If we look at the history of Microsoft in terms of a civil light and light switch, and I can, and a XAML based technology that I normally would rather to keep track of and things like that. That's not a good place to be. And then you have the huge shift with .NET in particular of moving to open source model. So I have called right now that I wrote that is in the .NET SDK. Minor bug fixes mostly and things like that. But I was able to narrow down the, here's the problem. Here is the fix. Here is the pull request. I did whatever dance you needed to do in order to get it to properly apply. But it worked. And that is such a huge shift, such a major difference that I cannot express how much it is except when I'm comparing that to how it used to be. So let me give you an example. In 2008, so 2007, there was a bug. And the bug was that if you ask, I remember that because it was such a ridiculous thing, if you ask the bull converter, whatever can convert to bull, it would say yes. If you call convert on full, it would draw. So it's a bug where it would accept basically any string. And that's it. Okay. So here's how you fix it. You open a bug in something called Microsoft connect. I don't remember if you remember that I still have nightmares where bugs would go to die. I don't know if anyone looked at them. Because for that particular bug, someone, I assume that an RDA or MVP or something like that, made someone look and it was closed as one fix because of backward compatibility issue. And I was like, such a ridiculous thing, such as an opaque process that you have no communication with who did it. It was typically weeks or months after you actually made a report. And even if you had actually generated an issue, really sure. Oh, I remember there was one time if you did the for loop on a particular framework, then you would get the wrong G cycle and it would create another first exception. I remember looking at this issue and again, I'm talking about 15, 20 years ago, looking at this issue and having my fate in C sharp basically being shuttered because of a jigsaw. Because what those things happen, you can have bugs in the just in time compiler like today, you know, yeah, all the time. But. Okay, yeah, we they so much of this point we says, oh yeah, this is about this is the problem. Here is the issue number for that. And it would be resolved in next service back in six to 12 months. Oh, you if you really, really want, you may have a hot fix. But you have to have a support contract and talk to us privately and justify what you want. Now, if I'm working on open source project, I cannot rely on these hotfix, because I don't know if my users would have that. So at that point, I would have to go and find a walk around somehow. And versus today, first of all, I'm talking to the actual people who is writing the code. And we're talking about me, I'm talking about anyone on github that talks to github slash dotnet slash runtime. And you get to talk to them, you get to pick the brain, what, what, what about this, what about this. I have a problem. I don't know how to solve that. They would give me an answer about, oh, here's a few things that you can try that may shed some light about what's going on. And the reason these metals is that, oh, they don't have a solution for me. I can go and fix that. And I can carry my own version of the framework until that gets resolved. And I've done that in the past running on the custom version. And that is really kind of amazing when you think about it, especially because that's how it's supposed to be. But again, going back to business and open source. So the model where like dotnet where you have a project that is wholly owned by Microsoft and it's released as open source and they maintain the development team for that is not something that is broadly applicable. Think about what do you need to do in order to be a member in the G team for Microsoft, the level of knowledge and expertise that you need. So those are not people that you can just find off the street. So you mentioned IBM and sponsorship and hiring people to work on those projects. And it works. It's a viable way of doing that. I think that the creator of Python, who's Van Guido, but I cannot pronounce the first name, used to work for a long time for Microsoft. And again, as the benefit of the data for Python. But again, that is such a limiting factor because you cannot make that into a, you couldn't get Microsoft to spot us every open source project in the world. That's obviously not even for them. Of course, I was using an example too is that they're selfishly going to pursue what makes sense for their products. This is something, another aspect, though, of the open source world that I feel like sometimes need it. I find myself explaining to again, on the purist side, have some interactions and to user groups and other things is that, you know, software companies, anybody who's in business, like at the end of the day. You, you talked about your own experience. You need to pay your bills. You there's, so you're going to do things you're going to shape like features that you prioritize may be driven by customer demand. So it's increasingly important to look at even an open source initiatives to take you from voting members to look at what should we prioritize what directions should we go, what we should go work on. You're not always going to find somebody who's so altruistic to say, yes, I will go and build that for you and move in that direction. They're like, no, they, they all have, for the most part, selfish reasons for doing that because it impacts their own job, their own products, their companies, you know, initiatives, those efforts. And so, you know, we're all, we need to be data driven to some, some level of what our customers want and build out focus on those things accordingly. Again, my company is looking for certain features, we may then go and sponsor some of our engineers to spend time in these open source projects to dedicate your time. But, but let's let's talk about this. Let's talk about what I think is the biggest problem with open source in general. Let's say that you have a project, the project is a, you know, it's not a huge, you know, multi billion project, but it's also not a small one. And you made a decision to utilize some open source project. Now you realize that there is something that you're missing and you want to have that. And at that point realize that, hey, I'm not sure that I can actually do something like that. I mean, let's say that you have a team of C-sharp developers and this project is written in Scala. The amount of time that you're going to have to spend to train your people, force to understand how to work with Scala projects. And then in order to understand this particular project, how to optimize that and what's going on is insane. So you only do something like that only for, you know, the core of your business. Like many, many companies would have, many big companies would have a team that is, I'm expert in the Linux kernel because I need to be able to go and debug and sometimes go on and something like that. But how many experts do you have on the, let's say the ZFS file system? Okay. Also a pretty foundational thing. And if you have a bug there, you won't be able to have an owner, you know, a parent, somebody you can complain to. And at that point you realize that the model of open source breaks from an individual contributor perspective, contributing to open source is almost always good for a couple of reasons. You are working with typically highly talented and skilled people. They would give you feedback on what you're doing wrong. And that can jumpstart your own capabilities to huge extent. You have a proven portfolio that you can point to. Hey, I wrote this piece of code and you're using this piece of code. Why the hiring? There was this classic example of someone who couldn't brew on auto or something like that. He failed an interview because he felt something, he said, you have standardized on the tool that I wrote. And you're telling me that I'm not sufficiently smart software developer for you to hire me or something like that. So from a branding perspective, from a gold perspective, everything open source is great. It's a great opportunity for more junior people to go and kind of cut their teeth and build that brand. But also have experience with much more complex solutions than the smaller tools, the thing that you build in school. So it's a great way to very quickly ramp up and into that enterprise software space. So let's talk about the aspect of school. When you write code for school, you typically write code that is well defined, short in scope and throw away. I haven't been able and I've been trying to push for that. I haven't been able to get a single university to make their CS department take the degree basically and have them write a single project for the entire thing. So they would have to maintain that and refactor on something like that. Well, that's why a lot of schools that will take on legitimate clients like outside real world companies that come in and they realize they're working with students. But they say, look, we don't have the ability to go hire really expensive engineers on this project, but maybe they're also looking for out of the box more creative solutions. And so it can be good on both sides. But that is a lot of coding programs like these, you know, six month coding schools, they do that it's built around real world client projects. I always say that for, you know, one of them I'm a huge advocate, my background is more technical project management. I'm really big on for enterprise software, especially pilot pilot pilot. And one of the things that the mantras around piloting is don't go pilot on well defined throw away fake projects, pilot around a real team, a real project, real, you know, deliverables and budgets, things around that. So that you have a true sense of whether the solution you're looking at can, you know, fill that that gap fill that need. But it's, it's much the same. And in the sense of growth from process project moving from students. Most of our projects, most open source project where you actually have the chance to go explore something would be something that have been using production that has been around for a while really have a weight around that. So here's the mentality concern. Here is the legacy craft that we have to support this older versus the money so realistic code basis and realistic problems and in many cases stuff that you wouldn't get to experience until much later in your career. But this is for the individual contributor. And then amazing scenario, let's talk about what happened for a company. And for company, the problem with open source is that I want to pay. I want to have an owner I want to have support I want to have someone to point the finger says it's on you. And the business model of open source project is not great. If I mentioned the foundation project earlier, and this requires that you manage to solicit enough contributions enough donations to try to make so sustainable. I think the pattern model may be able to get something there but still highly suspicious of how you can actually make it work. And then let's say that you want to have an open source project and your model for a pain for that is to sport. And many opposite projects are based around that so we offer the project as is and then if you want to run it in production if you want to have to have mommy and daddy that you can call in case something break then you pay for support. And the problem with that model is that it is not easily sustainable. And people would only buy support when they actually needed to think about the case of if I could buy my car insurance after I had a car accident. Which means that if so the car insurance company would very happily send me a car insurance for a car for accident, they would just price it to be higher than the price of a car. And that's what ended up happening in this model because everyone just called me at after the isn't happened and then I have to spend a lot of time and effort what happened how to resolve that something like that. So this becomes really expensive. It also become. It creates perverse incentives. Let's say that they have an error that people can make in my software. And it cause the support incident. Well, if I'm making money to support catching. I don't have the incentive to want to fix that. And then you get to other support models, the redhead model, where they provide packaging support, which has auto following itself. But the redhead model is pretty much the only company in town. Almost I cannot think of any other company that have been successful with in the same sense to try to do that. And that means that this is not something that can be easily replicated if at all. And then you move to things like, oh, what happened if I charge you for hosting this as a service. And then you have two options, either not enough people are using you. Or Amazon is saying, oh, that's a nice service you have there and it's open source. I'm going to host it. And if you look, you can see terraform and elastic search and MongoDB and many other projects that have had to change their license. From an open source or a sample of license to something else, typically BSL or something like that, which are no longer open source projects. Specifically, I have to make money somehow. And that's a huge, huge aspect. So when we talk about the open source and community in general, one of the things that we have to ask ourselves is. How do you get, how do the maintenance of these projects actually make money? Whatever this is through sponsorship, through a company, whatever there is a foundation or something. And it's funny that I'm saying that because if this is something that you rely on, you want to know that this is actually something that is viable. By the way, it's also perfectly accepted to say, oh, I'm going to use this project. And if necessary, I'm going to take ownership of that for my purposes. That's the beauty of doing that in open source. But again, if I, if I have a bug in Babel, which is a JavaScript package that I believe. And then, and I need to fix that, then I'm probably going to find it easier to just pay someone then trying to understand what it is, how does it work and what's going on there. Yeah. But it just was thinking to, you know, going back to me, I'm trying to remember how long ago it was where the battles over Linux, and, and the various support models for that but it basically come down to your points like the organizations that were heavily involved in all the open source said, it's like, look, we're spending a lot of money, a lot of time, like we need to, we're spending a lot of support time around this. So we have our flavor of Linux that has this support model, but you've got to pay for it to get that. Again, you get the purists that were angry and I think everybody else that understood that it still has its ties to but it's now branched off. It's a separate product. It's a separate entity now. And there's benefits to that and there are, there are downsides to that that it's not a true open source effort. I'm interested to know, like with you as a, as a startup founder, you talked a little bit about, you know, in the beginning how people started asking, they, you know, they heard about it, they found out about it, they wanted us to pay you money for it. You needed to set up around it. How have you leveraged community to build out your own business other lessons to be learned in, in leverage open source. Much of the gold in revenue being adoption has been through wall of mouth through blog community stuff like that. When one of the things that I decided to do very early on with revenue base to say, hey, this is open source project. And so in terms of pricing model, you have the pay for support, open core model and all sorts of other stuff like that. I decided that I'm going to treat the model as we're in fully open source project. There is no open core. Everything is out in the open, but the soft when you install the software, which is go and get a license. We have a committee license. And if you want something more than that, you go and purchase a, a license for, you know, like you would do for commercial software. And you can, I mean, the source is out there. You can go and says, oh, I'm going to disable the check. And that would mean that you would have to run your own deployment of revenue because we will not be managing that supporting on something like that. And that, I think, has been a huge impact on adoption because it also makes sense in the way that, oh, I know that I'm paying for software. I'm paying for a word processor. I'm paying whatever I'm paying for outlook or Google Docs or whatever. Organizations have no problems paying for software. But asking for donations. This is actually huge issue. If I want to, if, oh, you want to donate money. Sure, we have a donation funds for that. Here is the list of 3000 requirements that you have to deal with. Or your organization, the Netherlands, but I need you to be father one, three C, which is, I think tax designation in the US. Right. In order for you to be able to accept a donation. Right. Yeah. But if you are a company and you just send me an invoice, then I just throw that into my expensive. I don't need to think about it. So a lot of that is actually around how you model things, how you understand how businesses consider money. And most businesses have no issues and are very well used to actually paying money to get stuff. But they will not be paying money for all because I, because I like that. They need to have a reason to do that. And the moment that you give them both a reason and a commercially accepted way of doing that, they would generally have no problem with doing this. And that is a huge aspect here. Well, I know that there's, there's a lot more as we were talking about before we started recording, there's a few different conversations that we need to have. Maybe next time we see each other in person around this, but, you know, or and I really appreciate your, your insights into leveraging open source and community in general. We'll have to do something where we'll talk specifically around your role as an MVP, what you're doing in that space, a different time, different day. But for folks that do want to find out more about you get in touch and contact you where are you most active in social work and people find you. I have a blog at il.com slash blog. I would throw the link in here so you can see that. And I also, if you want to see where what I'm actually working all day, then go to revenue.net and take a pic on that. It is, even if I'm saying that a really, really cool database and I think that we manage to get the hustle out of your database. Excellent. I just point out to that, I think it was, you know, in Dilbert, that Dilbert in the sidekick, you know, the, you know, the answer to any question of, you know, what should we do with the product was, well, we can build a database. The boss is the boss pointy here boss is like, you know, why is your answer always build a database is like, well, we just like building databases so it's the one, the deal that I really, really liked was we need to build a no secret database. I hear it's the best thing. And you hear it doesn't know what he's asking for. And then you then you ask, what color do you want it says, I think purple is nice. I think I do remember that one. I'm going to have to go look those up down. Maybe I'll post those in the blog. If I could find them. So, or I really appreciate your time. Thank you. Thank you very much. You've been listening to the collab talk podcast, new episodes are published weekly and you can find us on Spotify, Apple podcast, I heart radio and most other podcast platforms. Thanks for listening.