I absolutely agree, totally great answers. I love those three points of standing on the shoulders of giants, simplifying and standardizing, those really resonate with me. But we've got a couple of questions from the Discord, I'm just going to go through some of them.
So one from Qabs says, are any of these tools open source and do you have any write-ups on the plugin architecture setup? Thanks for asking. So we do get this question a lot, hey, are you going to open source this? The answer I can give you is that there have been discussions internally, there are no current plans to open source this framework. However, as I've shown here in this talk, the setup of such a platform is not too difficult to do. And please feel free to get in touch either on Discord or on Twitter, we can connect to you or set up a chat to see how we can, you know, create some more ideas.
Cool. I mean, those of you keep hitting them up on Twitter, maybe they will open source it if enough people get behind the idea. We've got another question from Vasili saying, that's a lot of plugins, how do developers decide what's worthy of being a plugin? Well, that is the really awesome thing about how the team has designed the plugin system. The plugin system is anything that solves your problem, right? Like, at a certain size, like, really, you cannot just top down say, like, use this plugin, don't use that plugin, use this one. I mean, you probably can, if there's like, security problems or like, specific things you have to enforce, right? But in the end, like every developer at, like what I call the edge, right? They're out there building and solving problems in their area of business, right? So they are going to be the ones to know best what tools they need, right? We've got developers who picked up React query or something like that, right? And that might have solved a really great problem for them in their area of the org. No one's going to tell them, hey, like, actually, you should be using this plugin instead, right? It's a very much like, hey, I found a tool that works for me. I want to actually bring it back, you know? And I made a plugin, and I want, you know, and I'm going to tell other people about it. So it's very organic process. Another example of this is, you know, the usage of, I remember one of our, one of our developer product engineers brought in MirageJS because it solved the problem they had locally, you know, and that actually solved like, you know, other teams came out of the woodwork saying, hey, this is awesome. This solves something that we've been running up against as well. Like you have to understand at a certain organization size, like it's hard for developers to find each other, right? And you're nodding your head because I'm sure you felt the same way too. And when I first joined, you know, most of my career, I've worked at companies of maybe 200 people or less, you know, maybe a 50 person engineering team, everyone knows everyone else, right? But now I'm in a company with, you know, over a thousand engineers. It's very difficult to know what everybody's doing all the time, right? So, that's why having these like tools and the ability to extend your architecture, but to do it in a safe way and to allow it to scale is so important.
Definitely. I love that bit about finding people. The number of times I've gone through Slack threads, trying to find the owner of something. It brings back dark memories. Another question we've got from Bear Man saying, are there any headaches or have you evolved any rules of thumb around versioning your internal plugins across the microservices? Thank you for asking that question. Obviously, it's not all like daisies and roses, right? The challenge is, I think, with versioning, right, like is, are the universal problems of versioning, right? When you bind things together, right, like when you say like, hey, like this plugin must work with this version, you're going to have some incompatibilities because some people are not always going to be at the latest versions, right? There's going to be some debugging problems, right, when our platform team has to jump in and help another team and realize, hey, actually what you're using is this older version that had this edge case bug, you know, and it took a long time to find that bug, right? And that's kind of why we've developed this migration story. Like we want to make it as easy and as frictionless as possible to get your system moved up to the latest version, right, like that should be the easiest thing ever to do, run a few commands and boom, you're there. In practice, it is more, it obviously is more difficult. Everyone's application is going to have some strange part of its surface area that's going to require a little bit of manual work, and so I would say a lot of our issues are also around the cross compatibility of systems. So you'll have plugins that depend on other plugins, and sometimes those plugins have certain assumptions about how the world works that you have to like hammer out, you know, and so that's another reason why we kind of pin the versions of all the plugins together, so that we can guarantee and like put a stamp of approval like this version is guaranteed to work across other versions of the same platform.