5 Years Time

Speaker 0: Hello, everyone, and welcome to community question time. This is actually the third one that we've done, since I started actually. But I'm really excited to be inviting our founders here, to give you the chance to ask about Directus, the company behind Directus, the future, the vision. And, don't don't give these guys any slack. Don't give these guys any slack.

Come come with what's on your mind. We are a very, very transparent bunch, and this is one of those times where we open the floor. Just as we are kicking off, would you 2 like to give just a brief, description of your of your roles here?

Speaker 1: Sure. Yeah. That's easy. I'll go first. I am the CEO and founder of Directus.

I created it originally 20 years ago in 2004. It's been exciting the last couple of months, and we can finally say it's been around for 20 years.

Speaker 2: Indeed.

Speaker 1: And Rich joined, 8 years ago, something like that. Oh, yeah. He's our colleague. Introduce himself as cofounder, but that's my my role, I guess.

Speaker 2: It's awesome. I'm, Greg Van Zonthe, CTO and cofounder. So where Ben created the platform in 2004, I feel like I created the platform in 2016 instead of again.

Speaker 1: You you actually create the platform. I create, like, an idea with, like, a like, a a mock up or more

Speaker 0: based on

Speaker 1: what you

Speaker 2: did. So we've we've both co created the platform in 2016 that I think is the way to describe it.

Speaker 0: Yeah. This iteration of it at least.

Speaker 2: This iteration. Yeah. Exactly. Yeah. Exactly.

Yeah. So I lead the technical crew in the technical sort of implementation vision.

Speaker 0: And so for those few people who are in the chat, the point of this, event, I suppose, is that we run it periodically, and there's a chance for it to you it is a chance for you to ask, any questions that are on your mind about the wider project. That could be about the company. It could be around the future of directors as a project, or anything else really. So do pipe in. I've got chat open right here.

I'll keep looking at it, and I will be facilitating those questions. Yeah. So, Ben, in the chat, I have to admit yesterday, I was so confused because I thought you were you were this, Ben. Yeah. That makes it makes way more sense now.

Speaker 1: So, while On that note, I had a, sort of a strategic, call yesterday. We were coordinating a call and there were 4 Bens on the call. I I my name's Keith. It was like, there was 5 people on the call and 4 of them were Bens, which seems pretty rare. Yeah.

Speaker 0: That's a bad

Speaker 2: thing I'll ever face, luckily.

Speaker 0: How did you how did you last names?

Speaker 1: No. Because there's 2 Ben H's. So, yeah, it got it got slippery, but, no, it was it was fine.

Speaker 0: You managed to to make it work and didn't promise to do anything on behalf of others. So there you go. I'll put the screen. Yeah. Which one?

So, yes, once again, please do come with questions. But, before, you know, there are any asked, I wanna kinda ask about we just launched the marketplace beta, and I wanna talk a little bit about, Ben, your, your narrative that you use around the 3 legged store and how the marketplace fits into that and how the marketplace is actually a really critical part to the success of our project going forward?

Speaker 1: Yeah. No. That's that's a fun one to talk about. I mean, it's I I I'm obviously a big fan of metaphors and initialisms, acronyms. I I'd say that this one is more of it's not an acronym, but they have, like, the idea of a backronym where you have the thing first and then you sort of retrofit the, the metaphor afterwards.

I think this is sort of that. Like, we knew that there's 3 big pieces to the to the company. And then this idea of a of a stool, like a a milkmaid stool, I think is what they're called, which has 3 legs. The idea is that they don't wobble because they have 3 legs. So it just kinda it's a nice visualization.

Yeah. Of course, you want a nonwobbly product, a nonwobbly team, and a nonwobbly company. So the 3 pillars that support us, we start obviously with the core software. That's what, you know, Rich and I have been working on for for the better half of the last decade. And that is the key to everything that we're doing.

But, of course, you need to deploy that and we need to make that as easy as possible. It's great to self host, but we wanted to create our cloud service, that offering. That was the 2nd leg. We have a single tenant cloud, a multi tenant cloud, and, of course, looking at all sorts of deployment options. And then the 3rd leg you know, the 3rd pillar of the company has been, sort of this if if we we have something called the 80 20 rule.

It's really important for us to make sure that our software doesn't get bloated. We don't try and do too much and become like a monolithic system. We're trying to balance between sort of the the really the nice aspects of monolithic, approaches and then the microservice approach, which is great, but has a lot of complexity. We're trying to find that balance. And in this 80 20 rule, we say that the core software should satisfy 60, 80% of what you need, hopefully, really quickly, instantly.

You point us at a database and you get it.

Speaker 0: But, of

Speaker 1: course, you still need to develop your full solution to a 100% and extensions and configuration and, you know, all these other pieces, your custom logic and code, that's the last 20%. And it's great to give people the modularity and extensibility of our core software. But, you know, doing that in isolation isn't nearly as much fun as being able to build an extension, send it out into a marketplace where our huge community can browse those extensions, learn more about them, maybe have ideas they didn't even know they had. It also motivates the maintainers of these extensions who are now seeing like, oh, wow. This is really popular.

I'm getting all these downloads and installs and I get some visibility. It gives them more of a motivation to keep pushing and working on the, their projects, their extensions. So the Marketplace is the 3rd pillar, core, cloud and and Marketplace. And this is what really helps us get more, inspiration for use cases of the platform and get to a 100% faster. Again, leveraging not just our core software but everything else the community is generating, around the world.

Speaker 0: Right. I have a thank you for that, by the way, Ben. So, right, I have a question for you. So earlier today, you, published a blog post called what we considered when building a marketplace, and I've actually just pushed that into the little, live highlights thing at the bottom of this page. Although I'm watching the page over here and it's not appeared, so your mileage may vary, but it's on our blog.

And, some of the really early feedback that's coming about the marketplace right now today has been around this, What word am I looking for? This balance between giving people the raw power to make their own choices versus limiting the ability for something to go wrong to either stop foot guns or to look out for people's security, stuff like that. This is ongoing. This is a literally ongoing thread that's happening in Discord right now. It's been really busy in our marketplace beta channel.

But I wondered if you could talk a little bit about how you perceive the balance between flexibility and, you know, control versus a duty perhaps could even be the word to keep people safe and happy?

Speaker 2: Yeah. I mean, that's a great question. So, this is a topic I could easily ramble on for 2 hours. So let me try to

Speaker 0: Well, I'll I'll I'll pull you in in 5. Yeah. You have one. Go. Sure.

So so

Speaker 2: the first so the the first little bit of back information that is required there is, like, where does an extension even run-in the first place? Like, where do you ship that code, and where does it run? So I've seen platforms, Shopify comes to mind, that run it off off-site completely, and everything is webhooks back and forth. Other platforms, they they rely on sort of Docker containers and try to isolate it that way. In our case, we've made the decision early days to say, okay.

For extensions you built yourself for your own project, you can just tap into whatever you need from the whole system. You're basically just full access. You can do whatever you want, because you're the one creating these extensions, and therefore, you can trust yourself not to do anything stupid. That's that's sort of

Speaker 0: In theory. In theory. Theory.

Speaker 2: Right. That was sort of the original security model of extensions because they were sort of meant for, like, you know, you built your own hook to to extend your copy of directives. Right? When it comes to this marketplace now, we're making it super easy to install stuff made by somebody else, right, on both cloud or self hosted. It doesn't matter.

It's all the same. But that now means that you no longer really know what's going on under the hood. Right? So for extensions in the previous paradigm, they can access effectively anything. They can access anything in the database, anything on your local machine where you're running direct is because you can, you know, access the file system, the network, any of those pieces, which then also means that if that's the thing you're installing from somebody else, at that point, all bets are off.

You know, anything anything can happen. And that is, for extensions developers, really nice because you can do whatever and make it really cool. But it's for extension consumers, really scary because you really just don't know what you're up against. Right? So the the balancing act that you were talking about, the question that we have to ask ourselves is, like, when it comes to a marketplace, on which of those two sites are we gonna sort of lead?

Right? Are we gonna say, well, the marketplace is just completely open ended. All bets are off. Good luck. Save yourself.

It's at your own risk. Or are we gonna say, well, you know, now that you're browsing it through Directus and installing it through Directus as the end user, you have a certain expectation of trust of, like, oh, what is presented to me here in this marketplace, I can install and use knowing that it won't blow up my whole project or send all my stuff to some malicious active third party or mine a bunch of crypto or something. Right? So for this initial release, we're erring on that side of, you know, user trust and security first. Right?

So we're saying, by default, we're relying on the sandbox model that we implemented, by saying anything the extension wants to do upfront in static file, it has to define the stuff it needs access to. So it's like, oh, my extension wants to talk to this exec third party API. And then, therefore, the extension can now do it through a couple of methods that we give it. Right? But, therefore, the for the end user, there's a very clear contract of this is exactly the stuff that the extension can access outside of, you know, the information that's passed in through a Hooper filter or something.

And that is you know, it's it's an in it's a very tricky balance as you've seen in that marketplace beta channel, for which thanks for the folk listening in. It's always fantastic to have those discussions. Because now the question becomes like, oh, but I really wanna import, you know, I wanna import libraries to do stuff with the file system, or I wanna use third party SDKs that might not use fetch or use some other networking thing, and now those don't work, which is definitely a tricky balance. Right?

Speaker 0: Yeah.

Speaker 2: But right now, we're really erring on that side of user trust and security first and then seeing, okay, where are the improvements in that sandbox model to to unlock all of that power again, so to speak, to get it back up to that that almost full power nature of of the extensions model.

Speaker 0: And I think that's part of it too. I think this, it's really easy to look at, the sandbox x SDK and look at marketplace and the decisions made there and completely link them. Okay. The marketplace doesn't do x. That's an issue.

But maybe the issue and this was actually the core the core, friction in here with these 2 competing narratives. 1 around marketplace doesn't let you install x and the other saying, well, actually, it's just that you can't build x using the sandbox SDK. And that's a solution which also honors the security model we've created. Another interesting thing though, that you said, which I will agree with and challenge, if I may, which is once you once we are providing the interface to browse and install the extensions, there is a contract to a degree that those things are trustworthy. That isn't the case in every, open listing marketplace setup.

You can blow up a WordPress installation by installing a DUD plug in. So as a decision made, I will agree with you by saying I feel the same way in documentation as the reason that I will resist, at least for the time being, AI generated code snippet examples because because once it's provided through our interface, it's it's ours.

Speaker 2: I I think the WordPress example is a really, really good one that has come up in the research with the team around the subject as well, of course. Because if you install, WordPress yourself on your own server, it's completely free. Like, the old bets are off, it's do whatever mode. Right? If you use wordpress.com or, like, the hosted equivalent of, you know, a WordPress installation, now there is way more constraints in place.

Right? They only

Speaker 0: is that?

Speaker 2: Some of the yeah. It it's, like, for the same reason. I I I of course, I don't know the internal decision making there, but I'm assuming it's for the same reasoning that is, like, you know, you're using, you know, WordPress in a sort of controlled environment that you're paying for. You need to be able to trust that this stays alive. And then the stuff that you're installing is trustworthy and will work the way you would expect it to.

Right?

Speaker 1: Again, like, there's the self hosted versus our cloud and having to make sure that we have things really tightly scoped in cloud. But we have a multi tenant cloud and a single tenant cloud. A single tenant is our enterprise. And peep, those customers can upload custom extensions. So they do have workarounds, but we do have to make sure when you're sharing hardware in a multi tenant configuration, you know, noisy neighbors and making sure that people aren't, you know, scooting over into other people's projects.

We have to keep that really tightly tightly scoped.

Speaker 2: That too.

Speaker 0: That's also that's also, of course, a decision in how we implement extensions. You know, we spoke briefly in in the past internally about different models for even offering extensibility. I believe Shopify might be a platform where as an as a extension or plug in, I'm not sure what word they use. Author, you host an external service, which is that you host it one instance of it. And then each of the instances can plug into that.

And then it's a little bit the risk is different because all you're making is external HTTP requests. So there is also a decision in our implementation.

Speaker 2: Contract model then. Right? Because you know the request going to the extension, and you know that the output is in a certain format that you're gonna work with. And whatever happens in that black box over there, you don't have to care about anymore because it's hosted off-site. Right?

So it's a different model, with pros and cons of their own for sure.

Speaker 0: So there's a question in the chat around, will third party modules ever be available? I think we're getting a little bit into, like, the weeds, and I want to pull that, if I may, into the marketplace beta channel where we can have, like, a more meaningful back and forth around the answer to that and the nuances of that. And thank you to Benny for kinda stepping in and giving, like, a cliff notes answer, but we can talk more about that, of course. Still on the marketplace. And by the way, I will keep going with questions until we run out of time for absence of other questions in the chat.

So please do do come with them. But, talking more about the marketplace, Ben, I'm curious about how you talk about the opportunity that the marketplace brings when you're talking to potential customers, our board, our investors, people people with that level of, you know, stake in the director's project, because where it is today and where it may be in the future may not be the same. I'm kinda curious how you talk about that.

Speaker 1: Yeah. I mean, there's a couple different things. I think one is, the moment. You know, Directus has a lot it's like a back end as a service, which you it's just a database. You can do anything.

You know, there's so many use cases. So, how do you give people inspiration for what it could be used for? Because I I kind of imagine it. Directus is like this big warehouse of opportunity and and potential, but people come in through one door, like one Google search or one, you know, thinking of what the platform is, whether that's a headless CMS or back end as a service. And then I think similar to something like Airtable, you know, they have 10 1,000 templates and all these, you know, options for what you can do in their sort of spreadsheet service.

When you get into, like, a data service, I think that our marketplace will offer the same amount of like eye opening of you come in. It's like, oh, I'm gonna go get some extensions for making my content authoring experience better. What is this? This is like a stock you know, it's for the stock market or this could be, you know, anything any off the wall example that somebody came up with for their edge case. Now you're thinking in your head, oh, I do something similar.

I wonder if I could manage that data and direct this and kind of unifies a few more systems. You know, reduce that complexity and cost. And, of course, the answer is usually yes. You can manage that in Directus, but it takes that sort of eye opening moment. And I think the marketplace is a great place to explore that potential.

So that's one thing that comes up a fair amount. Another one is keeping things unopinionated. In a lot of our decks and the way we talk about Directus, we use the word unopinionated or agnostic. Again, we've built platforms that you know, Directus powers things for Fortune 10, Fortune 100 companies, you know, millions and millions of downloads, tens of millions. And you have to support their stack.

You have to support their skill set. You have to support their languages. And I think it's easy to start making decisions early on that impact and restrict that flexibility for people to use their make their own decisions. And especially when we're looking at emergent things like AI that are so powerful, and you can you can really integrate and people are putting them right into the core software. Sometimes that might make sense if you are being more, opinionated in your in your builds.

But we wanna make sure that we stay flexible and agnostic. And so for things like AI or things where you have to put in a proprietary API key, all that just makes sense in an in a marketplace because you can start to say, okay. This is this flavor of this functionality and you can go use a paid service or a free service. You can, you you know, integrate whatever you want. So I think that's a nice escape hatch to build in third party service integrations without us as maintainers saying this is, you know, we're we use Discord internally, you know.

But obviously, lots of people use Slack, you know. You start to have to start making decisions. We wanna keep that as open as possible for as long as possible. Extension for us to do that.

Speaker 0: A question we're good. A question for you, Reich, kind of leading on from that to a degree, and actually a comment I saw in the community, I think, yesterday or the day before that peaked my interest in in preparation for this event. Someone said, you know, oh, I would like this functionality that doesn't exist today. Someone says groovy. You can build that as an extension, not an issue.

And the response they had was, you know, cool. It could be built or provided as an extension, but this feels like the kind of thing that should be available in the core software. And at the same time, when we've spoken recently, I know one of your upcoming, you know, or one of your motivations generally is actually taking some of the core functionality in directors today and explicitly removing it from the core and providing it as an extension. And I'm curious how how you feel about this and and what the basis is for that thought. What does and, Benny, I see your question there.

I have one more bit of context following on from this question, then I'll ask that because I think there's a bit more, to it. How do you feel about that? I think people expect that they get a call that that is more capable, but we have this extensions model and you're trying to even slim down the call. So could you talk a bit

Speaker 1: about that?

Speaker 2: So the one of the technical challenges is that we find ourselves trying to build a thing that can do anything for everybody everywhere. So, therefore, what do you include? Everything. Right? That is sort of the slippery slope that you find yourself in.

So what we're sort of aiming to do now is, like, the code base of the, you know, the direct to its internals is turning into a bit of a bigger monolith because we have so many individual features and parts to it. So the strategy there is gonna be twofold, is 1, to modularize the code base. So if it's included around, it doesn't matter as an extension. It's just, like, to keep the individual responsibilities as modular as we can just for maintainability. And then the second part is, yeah, asking the question, what, you know, is Directus versus what is, you know, the the complete package that you can get with different extensions in Nextiva.

Mhmm. So, for example, if you look at interfaces, we have, I think, 3 or 4 different WYSIWYGs, you know, 1 in JSON, 1 markdown, one edited JS, 1, tiny MCHTML 1. And you can ask yourselves, like, do you need all 4 for every installation for everybody out there, Or do we just ship with 1 and then have the other 3 available just as opt ins through a marketplace? Right? And that feels like a fairly logical progression to me, especially now that we have a marketplace where you can easily install those pieces.

The same would go for things like layouts, right, where it's like a Kanban layout or something we ship out of the box now. Might might be relevant for some, might not be relevant for others. Maybe that just becomes, you know, an easy opt in through through a marketplace instead.

Speaker 0: Fascinating. I never use the Kanban view. It's I've seen others use it, and it looks fantastic. Just a bit it's a great example. I don't use it.

So why is it shipped in every project?

Speaker 1: I think things go in both directions. I think what Rich said is is absolutely correct. You know, not getting bloat, making sure that we can really keep the core a core, and then everything else is sort of the spokes of that hub and spoke, concept. But it also could go the opposite way. You know, Rich and I have talked a lot over the years about, you know, what community pull requests look like and how that affects us as a team trying to maintain like reviewing them is, you know, we've tried to formalize it and say, go through this process before you, as an outside contributor, just send us code because it's a lot of work to review.

Those are usually very opinionated, going back to keeping things unopinionated. We try to do our job on, like, the vision side of the the company to distill specific features that people request that are very price specific to what they need. How do we distill it down to an agnostic functionality? How can we make a core functionality that will work across all these use cases but that satisfies what that person was trying to build. So instead of doing a core pull request, what I'm getting at is extensions are a great a great way to pitch that.

If you wanted to build an awesome extension and say this this could be great core functionality, We might not be able to have the time and resources to review core PRs and all that. You can build an extension. If it gets critical mass, we would love to have conversations. If it doesn't make sense to go into core, maybe that's the way it happens. So some things will get pulled out of core and made extensions, and then some things might turn from extensions into core functionality.

I think the key there is being really cautious. You know, there's some of the big the big 3 players, that have been sort of caught taking really, really powerful community built applications and then, like, just stealing it, ripping off and building it into the, like, no s or something like that. And then the little developer who had this really great idea never gets any credit or anything. So how you take a community built extension and move it into core where we're gonna help maintain it and build it, but credit, you know, the the author and how do you do that, you know, financially or whatever that looks like. There's a lot of nuance there to figure out.

But, hopefully, you know, we got a pretty awesome community. I think we could work to make the platform what it needs to be and then have the extensions be what they need to be. And that I don't know if that's gonna be one of the questions that you have. It actually it came up, Benny had it, like, where do we see the platform?

Speaker 0: Have hang on. Hang on. I have I have some context. I have some mega context here. Hang on.

I think because I I think that's a necessary context. Just to tie tie up that question, though, there is something else that's really worth noting, which is Directus is a Swiss army knife, a chameleon, what however you wanna frame it. It's such a powerful tool that can be used for so many different cases, so for so many different use cases. Sometimes when people come in and think, oh, that should be core functionality, they're thinking through the sliver of use cases that they want to implement. And what we have to consider is, again, that that bigger picture, every user in every use case does this make sense as core functionality.

I think that's a nuance where there is a slight difference in perception as maintainers versus users, community members, customers, and so on. So I think that's interesting. So the question of where do you see directors in 3 to 10 years, I think there was just a tiny bit of additional context, if I if I may ask right perhaps to just briefly, like, cover, which is today, Directus' data abstraction engine and, indeed, the setup of Directus is that you connect it to 1 SQL database and some asset storage and we present an interface for that one database and asset storage. But this there is ongoing work to perhaps change that change that makeup of what directors is. And I think before jumping into what we see directors be directors being in 3 to 10 years is just a brief just like a teaser even, you know, the work will happens in public, but a teaser of what that might or what this what this mad scientist project may result in because I think that influences the question that Benny asks.

Speaker 1: Sure. Yeah. I mean, first and foremost and, like, Kevin's just sliding back the velvet curtain. Like, tell us tell us talk about all the things that we're doing behind the scenes.

Speaker 2: Yeah. So, I mean, first and foremost, we've seen the the database landscape sort of diverge quite a bit. Right? So when, I mean, when I just joined the project, then it was a long time ago, but it was we just we only supported MySQL 5.6, I think it was at the time. And that was it.

That was the only thing I ran on. Right? And that was enough at the time because it was really people needed a database. You had MySQL. That's that was just the name of the game.

Right? There was no other real the the rest of it wasn't up and coming enough yet. Then when we rebuilt that in sort of the current paradigm that you're seeing, we were like, okay. Well, let's try to abstract that out to just be SQL so it becomes any SQL database instead of just MySQL. Because there's some differences, but they're generally similar enough where we can just say, okay.

I'm just gonna support any of those SQL databases. Right? Then now, you know, early 2024, we're seeing more and more sort of SQL like or SQL compatible ish, vendors show up left and right that are getting increasingly popular. You know, think about PlanetScale or Snowflake or or those types of services, that are, you know, not always directly SQL compatible, but also very close enough to a point where it's like, why wouldn't it work? Because, you know, the paradigms are the same.

So part of the the first exercise was thinking about, okay, how can we include those in sort of our SQL support as well? So it's SQL like, but then we have certain features that work, don't work maybe. And then while we're designing that, the question really became, okay, what is just a data source in the first place? Right? Because what is really the difference between, a structured REST API versus, a relational database versus a data warehouse that stores stuff relationally?

At the end of the day, you're all talking about, you know, data in in a very similar format in all these different sources. Right? So that is really what we started focusing on at that point, with how can we abstract that away in a format that is this is getting a little technical now, but that is a declarative base. So you can declare the data you wanna get out of it, then have a plug in ecosystem that is fetching that information from individual vendors, and then get it back in a known format. And that is really the data abstraction project.

Right? That'll unlock, you know, a bunch of other interesting angles that we never thought about before just by approaching it in that direction. But that is that is really the the the core. Kinda go back to

Speaker 1: the core principles of the company is, you know, taking sort of expanding, from MySQL to Postgres to, you know, down the SQL line and now continuing to distill it down. Like, that is part of this, like, vision team is how do we continue to be less opinionated? Like, there's other data stores that people use. It's great to quickly support something like CockroachDB from a distributed side. But, you know, the data lakes and all the, sort of LMs infected.

Like, there's so much that we could be managing and sort of make those part of the marketplace. You know, how do we make those atomic units of connectors for different data store, data stores that are available? Like, it's great to have the browse, manage, visualize on the app and API side, but we also have to think of the data coming in and how we can improve that over time. And Rich didn't even mention the the f word in that, which I'm surprised.

Speaker 0: It was I was about to do it. I was about to do it too.

Speaker 2: To go now. 3, 2, 1. Yeah.

Speaker 0: Oh, I thought I thought we were about to. I thought we were gonna do it.

Speaker 2: I'll I'll continue that train of thought too because it it started with what is a data source. And then the second piece to that big thing is, like, where does that data live? And the answer is it lives in all sorts of places at the same time all the time, for good reasons. Right? So we've seen a lot of piece like, a lot of software try to sort of synchronize it back to a centralized place and then manage that and then try to use, you know, integrations to get it synced back out.

That has been historically, you know, very popular. We're seeing some tools, pop up now. They're trying to sort of get that data connected through GraphQL specifically because you're dealing with known schemas on both sides. Excuse me. So the question now became okay.

If we have this sort of very agnostic declarative data fetching engine that we're building, how does that tie into federating the big f word, across those different data stores at the same time? Right? So as if you're declaring one data structure to come out of it, but the data is like, the underlying data itself is just stored in different places, how can we get that out efficiently, and return it in the way that you need it, rather than having to treat it as disparate data sources.

Speaker 0: And in reality, like, people do sync data back using directors today. They'll have a primary database, which will be the thing they connect, and then we'll use our automation features code or no code, whatever that may look like, to bring in and sync data from then, you know, additional sources. Because And, again,

Speaker 1: perfectly valid because, I mean, think of the systems that have just gone offline in the last 48 hours. Like, big systems go offline. It's nice to have sort of a local, like, your own database synced where you can still pull that data in and you've got the results.

Speaker 0: That. Yeah. Yeah. I know I didn't thought about that.

Speaker 1: Talking about. Like, you can't always pull it in and say this is we talk a lot about single source of truth in the database. That's what we manage. There's no direct as magic that happens in between. It's the database.

That's the magic. We give you access. But one database isn't enough usually. We manage all types of data. When you look at something like customer data, you can have your customers in Stripe.

You know, you have it in HubSpot or Salesforce. You've got it in probably some sort of relational database for your SaaS or whatever you're building. And you've probably got some thrown over in, say, cold storage and a data lake. You know? All that customer data needs to be accessible so that you can find the value.

But you can't just pull it all like, those services are all used in different ways for a reason. So managing the data where it lives in situ is important. And the only way to really do that is through that, not the 4 letter f word, but the 10 letter f word that are able. And that's why it's so exciting. I counted.

Speaker 0: Yeah. He sat there counting. And we now know that's what was happening in the last few minutes.

Speaker 1: Anyway, so it's pretty it's really exciting thinking of, like, what is the future of, you know, data in because we can argue so much on the data outside or the IO. Yeah.

Speaker 2: The other thing is, exciting to me there is because it becomes a declarative system, we know what the output format is, and we know what the input format is. So it also means that getting that data from one place to the next becomes, you know, a a possibility now because the data format coming out of Salesforce is now gonna be compatible with the data format going into a HubSpot. Right? Because we sort of, convert it and and handle it in the middle at point, which is exciting

Speaker 0: too. Before I swing around to the actual question, which I think required that context to a degree because I think it is a, a mental model shift, you know, for those who think about directors and what it is capable of. I think talking a little bit, you know, looking to the future, I think is was important to ask that question. The only other thing I will add to all of this, not that I wanna dig deep into it, is all these different data store types have characteristics, as Ben said. They have characteristics and strengths and weaknesses.

And there is a I I don't know I don't I don't know if any of us know the answer to it right in this moment of of research and development. But how do you take advantage of the strengths of all of these data store qualities, rather than trying to make them all fit into one box? Or do you have a box that actually makes sense for all of them to fit into? You know, the way that you look at document databases and access those and the strengths and the weaknesses are different from a relational database. And so there's like, big brain, big brain thinking beyond beyond me.

Speaker 1: Rich has obviously the the real answer to these questions. You know, the entire engineering team is working through solving that very difficult problem, but I think there is no answer. There's no silver bullet for how you, like, solve this problem. It's a balancing act, and you have to really think through exactly what you wanna accomplish. You don't wanna end up with, like, the lowest common denominator.

You know, nobody wants to take the power of Aurora or Postgres, our cockroach, and say, oh, you have the power of SQLite because we're gonna support all these, and so it's that lowest common denominator. Exactly. But we all there's also the idea of progressive enhancements. There's things you can do with extensions of some of these databases, that give you more, like, geospatial capabilities. And if you don't have that installed, what happens?

So there's so many things to consider. I think Rich and our and our engineering team are doing an amazing job of trying to solve those so that we can have the best possible experience in sort of a progressive enhancement way. But, yeah, there's I don't I I'd be blown away if Richard's just like, oh, yeah. The answer is Come on.

Speaker 0: Well, the answer is we've got 21 more minutes.

Speaker 2: It depends, as usual. A lot. Yeah. I mean, the way we're solving a lot of those issues now is by the the declarative model. I've mentioned it a couple of times, but that has really helped a lot in this where we're saying we wanna get data set a, and we wanna nest dataset b based on these values.

Right? So it's kinda like defining a joint, but we're not defining exactly a joint because we're defining it in the declarative way, and it's not the SQL query. So, therefore, now in in a document data store where you don't really have native joins most often because it's, you know, in the design model, at least, depends on what vendor, of course. But then now we can say, okay. For the vendors that do have sort of a native joining capability, we can use it.

For those that don't, we know what dataset to fetch on the left and right side and stitch it together. So for a lot of the features that we can implement sort of, like, an in the middle fallback that still allows you to do it, it's just gonna be a little bit the performance characteristics are gonna be different. Right? I think the second big piece, and this is something that has been true from the start, is that we don't wanna have any proprietary data model requirements for any of these data stores. So, therefore, even if, what would be a good example?

I mean, the geospatial thing, I think, is a good one. If you have very, very specific geospatial querying requirements that only exist in that one vendor, at that point, use that vendor for whatever that integration is that you're trying to build in. Right? So it's like we can manage and show you the the, it's that same 80 20 idea. We can show you all of the information.

We can support, you know, the vast majority of those filtering capabilities and the editing experience that you need for to show, like, to build a direct as that or something similar. But if for your end project, you have a hyper specific need that only exists with with an extension in that one sort of database type or something. Great. That's where the nonopinionated data modeling comes in, and then it's just like, please just use that. Right?

Speaker 0: So that's very techy, like, where where we're going. It's very like hopefully, those watching live or on demand are like, wow. That's, you know, that's big. So with that in mind, because I do think that was required context, I'm gonna ask both of you, and I'd be interested in you answering separately almost to a degree. Ben, whether you see direct us in 3 years to 10 years, how would you be describing it in in the ideal world in that time period?

Speaker 1: I mean, hopefully, I don't have to describe it. Hopefully, in 3 to 10 minutes

Speaker 2: Very good.

Speaker 1: Oh, yeah. Not directors, obviously. Everybody who doesn't use that to manage their data, and connect it and democratize in all the fancy marketing words? When I read the question in the audience from I think it's from Benny. I actually because we were talking about marketplace, I was thinking marketplace.

And I was gonna start talking about, you know, how we can elevate the community through allowing them to, you know, monetize their own extensions. And what a cool way for them to have, like, side hustles or primary hustles, you know, where they can, build all these awesome things really easily. That's the purpose of, you

Speaker 0: know Yeah.

Speaker 1: Optimizing developer experience for extensions. They can build easily, you know, with some great idea and then just quickly turn around and start, you know, selling it or giving away for free or whatever that looks like. So I think that was something big that I wanted to kinda touch on is how can we, you know, originally, this platform, you know, 2 decades ago, I think Rich was 8, and it was really just me. And I expanded to a few other people. We worked on it.

But then Rich came in. It was the 2 of us. You know, a 2 person open source org flying out and talking to huge companies and just super excited. Then it expanded through some financing. We were good at like a team of 10.

Now we're a team of like 30. And that's amazing, but you can only scale a company so much. And what's so exciting is you've got the maintainers, the company, then you've got the contributors, and then you've got the broader user community. And it just it gets so big where you get into 100 of thousands of people. We have to continue to focus on how we can embrace all of those people and have them contribute to this platform.

The extension marketplace is a huge part of that, bringing everybody in and just kind of having this network effect of learning what the platform can do. Again, I built it for my own myopic ideas of, like, this is what my agency needs, and it grew to be more than that, because the idea is broader than that. But I think we still have a lot to learn about what we can do with this platform that is fed from the community. So I don't think I I would not want to know what Directus will be in 3 or 10 years. I think it's the most exciting thing is that we get to work with such a huge community to figure out what it is, you know, every day, every month.

I think that the breadth of of the platform is such that there's so much potential to be a lot of things. There's also the danger, you know, the double edged sword of if you try to be too much, you know, too fast, too furious, what are you? You know, that can be slippery as well. How do you market that?

Speaker 0: For sure.

Speaker 1: Talking about yeah. It's it's anything and everything. So, I think just really, you know, judicious growth and trying to understand, like, what is it now? What are we next? Whilst having, like, some fun, like, divergent ideation around what it could be, in the future.

This is a real this is a real, like, non answer. I'm, like, skating all around, like, what people thought I'd wanna do.

Speaker 0: You said it, not me. You said it, not me.

Speaker 1: Long story short, I think that if my ideal would be that it is in we'll say 10 years out. Like, that's an absurd amount of time. But 10 years ago, I was saying the same thing. In 10 years' time, I would hope that we are still completely true for the ethos of of an open platform and all the things that that brings. You know?

The open source, the openness, the radical transparency. As a company, as a product, I hope we are still as open as we are today or even more so. And I hope that the platform is so recognized, as being a leader in whatever we have become at that point that people are just like, dude, that is there's a factor that is an amazing platform. They took the long road. You know, at that point, I'll be saying it's 30 30 years in, which is that's kinda crazy.

Speaker 0: You'll be fully gray.

Speaker 1: Well, well, yeah, we'll see. I hope I'm in heaven. Yeah. The goal would be just to be, like, this is the preeminent solution. That is the de facto and not resting on our laurels.

Not saying like, oh, yeah. We made it. Like, going into that cruise control, which happens a lot. But continuing to try and stay agile and nimble, like, always trying to, like, push the envelope. Like, what is next?

I think you can't plan for that. You know, I I I've made a joke a lot about every time I say the word future proof, I will always throw air quotes around it because you don't know what's coming. A couple years ago, nobody knew that generative AI and all these different emergent trends were gonna be what they are. We We don't know what's gonna be coming in the future. So, Yeah.

That's my my answer, not answer.

Speaker 0: That was good. I'll give it to you. Pass. B plus. Right?

Speaker 2: I really hope we could start selling ice cream as to the point of the check. We're going to be an ice cream.

Speaker 0: And then we'll rest on our laurels. Cruise control all the way, baby.

Speaker 1: No. It's just audience. Someone had mentioned that we could become an ice cream company, which

Speaker 0: not not that fun.

Speaker 2: No. I think, realistically, I think, I hope directors can get to that point of ubiquitousness where it's just the obvious starting point for basically any project that deals with data by definition, any project. I think that the current strategy of treating it as a sort of the core platform being a a very modular foundation on which you can build on with extensions. You can build together the ideal x management platform for whatever you need to build. Is really just an exciting sort of way to get the future proofness.

Right? Because at that point, it's like, oh, now if an LLM becomes the data source, that can become one of the building blocks, but the foundational thing doesn't have to pivot. Right? It's like, to be fair, explaining what that pivotal thing is has been the challenge. So I think in the next 3 years, one thing that I'm really excited about is to just help people with that sort of onboarding and understanding of what you can do with it to which, you know, marketplace is a huge thing.

The templates we've been discussing in the future release will be a huge thing for that, where you can just get started with a sort of one click of, like, oh, I wanna use it as a blank. Bang. You know? Click a button and you go. I think that'll help the adoption that sends a lot.

But, yeah, really, that that place for your big notice in the data space, I think, is a really achievable 10 year plan.

Speaker 0: If I may, I know it was a question for you too, but, obviously, I run developer relations. Right? I come with a very developer focused lens. I think about the developer user, but what I hope to be the case is actually not related to that audit. Because I think that's I don't wanna say a given.

I don't wanna be cocky, but, like, I think we are this fantastic developer tool. We're a fantastic tool for everyone, but what I really want is people who don't deem themselves to be technical enough feel like they can have ownership and access over real data and be able to glean whatever they need from that data. I think that, you know, we talk about our mission being to democratize data or make it more accessible across everyone in the organization, and I think that that is that's the thing for me that, like, I'm most excited about. I still think to a degree today, we lean a little more if it was a spectrum of, like, fully technical to developers don't know it's there at all. It's not for developers at all.

I still think we're probably leaning a little heavier towards the developer side. And that I think as time goes on and I think extensions are a big part of this, we can start to to just be be, you know, a more ubiquitous tool to use the word you use, but not just for developers. Yeah.

Speaker 1: To get back on what you just said, Kevin, I think if if I was looking at like the grand, like, decade out sort of landscape. But if we go to like the it was like 3 or 10 years. In 3 years, I've talked a lot to strategics and VCs, like, just companies in general about around where we might be in a shorter time frame. I think that's exactly right. Right now, we are developer tooling.

It almost requires an engineer to provision, set up the hardware. Like, there's words that peep normal people wouldn't even they're like, Kubernetes. I don't know. What are you talking about? You know, downloading from Docker.

But I think 3 years out is a reasonable time frame, to start looking at addressing the business user or the nontechnical user, directly. I think right now, the onboarding experience, the documentation, everything is framed around supporting and enabling engineers and developers. And I think a couple years out, there is, like, a next big milestone where we can transition. So, of course, continuing to support that, but also enabling the nontechnical users directly end to end. So they

Speaker 0: Exactly. Exactly.

Speaker 1: Compose them together and work in that solution and never even have to engage with the technical side, which is another bottleneck removed. And then quickly on Rich's point, I think what's really important there is the openness, that that we were kind of talking about earlier. So Rich was, kind of talking about how never mind. I I'm completely lost. It was basically, like, all the boiler plates, like, we were talking about, like, what Directus is as being this ubiquitous framework.

And if it's coming, it's going. It's like, it's almost it's almost. It comes Every time I sleep, like, cough.

Speaker 0: Some of them are like slice.

Speaker 1: People think I'm over here, like, grabbing. I'm just, like, trying to cough. Anyway You should be. They're they're just cough. Anyway, yeah.

There was there was an idea there. It's it's loud.

Speaker 0: Another question that came into so did you get it? No.

Speaker 1: I said back to you, Kevin.

Speaker 0: About it. Thank you. Thank you very much, Ben. We're we're we're giving up on that, divergent thinking, dabbing vision. I I can see it's still really bothering you, and you're trying to go into the depths of your memory.

If you get it, stop me. We can roll back around. Well, then the other questions was, well, in that time frame with it

Speaker 1: I guess. Yes. Yes. We were talking about, like, the openness of the platform. I wanted to kinda clarify the goal.

We were saying, like, okay. You get started with Directus. Like, it should be ubiquitous. It should be but it shouldn't be the full platform. We're not trying to be everything.

I think the goal would be to be sort of like a standard where we stay open and you use the tools that you wanna use. We're not trying to replace everything. We're trying to give you this foundational layer. And I think that's sort of the boiler plate when you're an engineer and you're sort of building. It's like, oh, you know, I use this all the time.

That's the first thing I do when I get started building my thing. We're not trying to build it for you. We're not trying to be the end all be all solution. We wanna make sure that we stay open. So any tools that you wanna hyper specialize with or that you wanna build or etcetera, we wanna work with those tools.

We can't do that by saying, Directus does it all. Like, come to us. We'll help. We'll do all these different things. We just wanna open up more possibilities and make things go faster.

And I think that's just a general mentality I wanted to clarify. You know, 10 years out, I'm not trying to say, like, everything will be built on Directus, but maybe Directus will be part of the, the suite of things that you're using, and it'll help make it more efficient using one of the many things that we'll hopefully be offering, you know, that far out. Point of clarity. And at

Speaker 0: the end. No. No. No. And to be fair, that very mentality, actually, for the audience out of interest, is the reason our our current hackathon at the time of recording is payments.

There are so many ideas that came out of it, and one of them was ecommerce. But there's so there's so much nuance in ecommerce as a as a, yeah, as a set of solutions that you would need to extend Directus in many ways in order to make it happen. Is it possible? Absolutely. But are there also excellent tools out there already that do the suite of ecommerce from end to end?

Also, yes. So where do we sit there? Well, we are the we are the champion. We are the the cheerleader of this the specialized solution you have, and we can further enrich, you know, your operations, whatever that may be. And that's why it scoped down to payments.

It went from ecommerce to payments, just out of interest for the audience. It's very much that. Can't be everything to everyone at a 100%. One of the questions that came into chat was, but not but, but, like, will it still be open source? And I feel like this is the 3rd community question time we've done, and in all, the the first one, our license, you know, change had not yet happened.

But in the last one, it was basically the whole hour long discussion. I think we are maybe, Ben, if you give a quick summary as to, like, the the the journey and maybe the future and and where you think we'll land with this. But if I may just, seed, I think we are a really interesting business, if I may say so, because I think we are one of the I don't wanna toot our own horn, but, like, one of the pioneers in what, like, sustainable open source looks like post open, whatever that whatever the phrase is and ends up being, where you don't have big corporate backing. Like, you're not react inside of Facebook and so on. So I wonder if you could talk just very, very briefly about what we are or how you think we are and how that might influence the industry and where we

Speaker 1: make sure. I wanna mention a second ago, like, 10 years down, I would hope that we're still honoring that that ethos. Like the idea of open openness. And the reason I'm not saying open source is because I think it's also important to be very clear in what you are and honor the history of the terms, and the definitions of the terms. We I was talking with Bruce Perrons yesterday.

The he was on one of our live, event yesterday about you know, he's the the founder of the open source initiative, the cofounder. They have clearly defined with ten rules, like, what open source means. Our license strays on 1 or 2 of those, slightly to build makes sure that this is sustainable. And so, you know, immediately, you have to acknowledge that there's a little asterisk there. I still believe that we are open source.

We're open source effectively for the vast majority of anybody using our software. Other people might say it's source available. There's post open and an idea that Bruce is is, sort of promoting. There's lots of things. So whatever the term is, I think the most important thing is that we stay true to again, I'll just use that word ethos, but like the idea of staying open as software.

The code the source code should still be available. The community should still be able to go and and contribute their feedback. You know, you should be able to use the software, obviously, in development for free, in production for free, but there needs to be a give and take in terms of making sure that it is sustainable. We talked at length about it on the GitHub discussions and a number of different events around how can you make sure that you hold these big corporations accountable when they extract so much value software and they aren't contributing to the open source. You know, what through development, through testing or, you know, financially.

So we're gonna continue to figure out the best way to do that. And just like with our license change about 10 or 11 months ago, we're gonna do it with the community because this is all us trying to figure out the best path forward together. So yeah.

Speaker 0: Yeah. No.

Speaker 2: I I think the the it's it's to your point, Ben, it's the ethos of open source since the funding issue, which I think has been becoming incredibly clear across the ecosystem for open source projects at scale, that the funding needs to come from somewhere, and that is either gonna be a big corporation, owns it, funds it for mostly marketing purposes that most of the time, or, you know, you you find some other solution. But the post open source movement is very interesting and seems to very closely align with the licensing as we've sort of, now identified it for our own project.

Speaker 1: Yeah. I think I mean, really, what it comes down to, if you're trying to describe what we're trying to do is we're trying to be fair, and we're trying to honor what we said we would do since the beginning. Of course, there's always gonna be, you know, the the the handful of trolls out there. Everyone has a different different definition of what is fair, but we'll just keep, you know, honing in on on what works. One thing I will say is I think it's important is hold us accountable.

This is live and it's also being recorded. You can hold me to this in the 3 or 10 years into the future, but hold us accountable. Everyone should be held accountable for what you say in the past and what you're leaning toward. You know, we're just trying to do the right thing. You know, that's that's a difficult thing because everyone has their own opinions of what that should look like, but hold us accountable.

If you think we're doing things the wrong way, if you have other ideas, that was, I think, the success of our license change is we said, here's the problem. Here's a few solutions as we see them. Comment on our solutions. Give your own solution. We just have to find a way through this.

But if you think that we're straying, you know, I I used to love Google's little tagline of what was, like, do no evil or something like that. And then when that went away, replaced with, like, some longer POCs or whatever, like, that was a a bummer. Like, I wanna still have as clear of a mission and vision. I wanna stay true to that. And the only way to do it, whether, you know, whoever, you know, whatever this company looks like that this into the future, the community needs to we know the power of, you know, that amount of people.

Just hold us accountable.

Speaker 0: Lovely. Thank you. Thank you both for joining me for this hour. For those who are tuning in, live, this will be available on director's TV in about a week. So it'll be act it'll actually a new tile community question time.

So very excited for that. Do check out all the other shows we have here, and we we will continue to run community question time every few months. So, if you have questions, awesome. We also have the company channel inside of our Discord, which is intended for this very purpose. Come ask us difficult questions, not about the director's project, use all the other channels for those, but about the company behind directors.

We're a very we're a very open bunch. So, yes, thank you very much once again, Ben and Reich. Thank you to everyone for tuning in, and until next time. Bye for now.

Speaker 1: Thank you, Kevin. Thank you.