Delegate Roundtable: Point Solutions or Platforms?
In this Security Field Day delegate roundtable discussion, led by Tom Hollingsworth, aims to dive into “security overload,” where professionals are burdened with an excessive number of disparate security tools. The core of the discussion revolved around the fundamental question of whether to prefer point solutions—specialized tools designed for a single purpose—or integrated platforms that consolidate multiple functionalities. This debate stems from the common experience of needing dozens of tools for a single task, leading to management complexity and inefficiency.
The participants presented compelling arguments for both sides. Proponents of point solutions emphasized their specialized nature, allowing for the “best tool for the job” approach and often offering superior capabilities for specific tasks. However, the downside recognized was the challenge of integrating these numerous tools, leading to potential data silos, increased management complexity, and vendors sometimes deflecting responsibility when issues arise. Conversely, platforms were lauded for their potential to offer a unified experience, streamline vendor management, and simplify hiring expertise, particularly appealing to senior decision-makers due to perceived cost efficiencies and reduced operational friction. Yet, concerns were raised about platforms often failing to achieve true integration, resulting in functional gaps or even hamstringing overall capabilities due to inflexible dependencies.
The conversation also encompassed the economics of security tools, the role of open source versus commercial solutions, and the critical aspects of identity, authentication, and authorization. The “build versus buy” question was a recurring theme, with the understanding that while open-source tools might appear “free,” they often come with significant hidden costs in terms of maintenance and support, or even security risks. The discussion ultimately underscored that the choice between point solutions and platforms is not a simple binary, but rather depends on organizational maturity, budget, desired level of integration, and an awareness of the inherent trade-offs between specialized capabilities and simplified management.
Moderated by Tom Hollingsworth of Tech Field Day. Recorded live at Security Field Day 13 in Santa Clara, CA on May 30, 2025. Watch the entire presentation at https://techfieldday.com/appearance/security-field-day-13-delegate-roundtable-discussion/ or visit https://techfieldday.com/event/xfd13/ or https://TechFieldDay.com for more information.
Transcript
So let's jump into the topic for this here, Roundtable, because I don't know about you, but, uh, I'm, I'm suffering from overload when it comes to security. I have about 45 different tools that I have to use to do one thing. And you've probably seen this, right?
Like, go onto a forum and ask somebody how to do a thing, and they're gonna tell you, oh, somebody wrote this really cool tool, you should go download it and use it. Well, can I use it for anything else? Well, why would you want to?
It's just you're, all you're doing is trying to solve one problem, right? So then that kind of snowballs. And we get all of this problem where you have like 14 different tools to manage these certificates and 94 different tools to manage, uh, this, uh, you know, zero trust thing.
Well, that's a problem, right? Because if I have all these different tools to manage, then I have to, I have to remember which one to use for what. So what's the solution to that?
Oh, well, we're gonna buy a platform, so we're gonna include all of those tools together. Maybe they're good, maybe they're acceptable, but it's all one platform. So you just log in and you see one window, one single, I won't say it, but you all know what I'm about to say.
Um, but then that begets the question, why? Why, why do I need to collect all of these tools? Because I guarantee you you're not using all of them.
So I'm gonna open this up to all of our delegates, which do you prefer? Point solutions or platforms, but be ready to defend your answer. Um, I'll go first.
Sure. Why not Point solutions. I prefer point solutions, um, because I like the specialty that it brings.
Um, it's about having a, it, it's, it's just, it's just comparing two different things. There's specialty tools or there's broad tools. And I feel like platforms belong in the broad tool set.
They're trying to integrate many different things together into a platform. And, and maybe it's just a personality thing. I like to do this very specific thing with this very specific tool to get in and do the job, sort of use best tool for the job kind of approach.
You know, I think it really comes down to, sometimes it's a personality thing. It's like, what do you want? And then what does your company want?
Right? What are they willing to pay for? What do, what do they expect?
But me personally, I'm point tools all the way. Yeah, Tyler's got his hand up already. So Tyler, what do you have to say?
I think it's a build versus buy question, right? Um, you buy a platform if you don't want to invest in, um, building and connecting all of those tools together, uh, you get point solutions if you do want to invest in tying all of those things together. Mars, I agree with, uh, what's being said there.
At the same time, we have seen, uh, situations where we have close point solutions. When there's a problem, the vendors tend to contact each other. Having the platform, it would've been, uh, only one to point at.
So maybe a shorter time to resolve it. So like, from my point of view, it really depends on what we mean by the point solutions. Because if I have a really great point solution, but it hasn't been built from the ground up to share its data, integrate, have APIs, whatever that technical way of working with it across other tools, then it's a point solution that's just a silo that's gonna get more and more complex to manage everything.
You'll have to export data and load it somewhere. That's very costly. Complexity is cost not only dollars or currency or cost.
So I'd like to see if people use point to tool point solutions, but only if they can integrate with a platform or central something. So Andre has his hand up. I wanna hear what he has to say too.
So I was caveated with our next vendor, so you know that Tom, so I I I would say kind of in this capacity, right? I think as we look at a lot of the platforms, the problem with the platform is that we never truly get true integration, right? So you end up with these gaps and pieces that don't exactly do 100% of the stuff that we did we're looking for in the acquisition.
And that what also happens is, as you do make those integrations, if they're not thoughtful in nature, sometimes they actually hams stream the overall platform. I can't upgrade my analytics because my analytics is tied to this and this BU doesn't wanna do this because they want this feature. So sometimes, depending on how you build that, right, you almost tie yourself into a corner.
If you start with that, build an API focused from the onset and allow that flexibility, and I think, I think it can work. But when you begin to kind of do the, I don't wanna use the name, the combining with multiple products into a file, I think you kind of lock yourself into a corner. So think it depends on how you build that, Sir, I admire your optimism that they started out to build a platform from scratch with every tool they were ever gonna use, and they're never gonna integrate an acquisition into that platform.
You, sir, are an optimist and I love you for it. Mm-hmm. However, I have also worked in security and I know for a fact that every time you click on a link in a platform that opens a new window, that's because they still haven't figured out how to open that tool in the main thing.
And that's one of the problems that we have to deal with when it comes to point solutions. Unless you are referenced the XKCD with a little stub down there that's holding up the entire internet, unless you are one of those solutions, the odds are good that you're gonna get acquired at some point. And we've seen this for years, right?
Like Fernando and I every week get emails of companies that get bought because it's like, oh, well this, this company's not part of that company, which means for the time being, you've got two separate logs to two separate systems. But at some point in the magical future, you're gonna be logging into one system that still have two completely different UIs because they still have an integrated it, but they've got single sign on for both of them. And there's a challenge to get those things to work correctly under the best of circumstances.
And I, I called this out earlier at security field day. Microsoft said in their presentation that, um, they have, uh, that he said, uh, this, these tools are gonna look very similar to each other because it's all running co-pilot security on the backend. And I actually applauded them for that for them and said, the reason why that is great is because it means you've actually integrated the tools because they look the same as opposed to, uh, pick your favorite network monitoring system of choice and realize that, that they're not.
So do we face a problem where when point solutions attempt to evolve to a platform, whether they're, uh, the company is platforming them or they're being platformed into another company, does that create its own set of challenges and therefore reduce the usefulness of the tool? So I'll give you the counter argument, which is that all the research I've done says that decision makers, senior decision makers, want platforms and they want 'em for a couple of reasons. One is cost, okay?
Vendor management is very hard. Mm-hmm. The more vendors you have in a large enterprise, the harder it is to do when it goes, gets time to renew contracts.
And we've got different contract renewal dates, all that. So vendor management is hard. Getting people who hiring the expertise that can run multiple tools and can stitch the tools together to build versus buy argument that we heard is also extremely challenging from a corporate point of view.
So companies always tell us from the research that, that they want platforms. However, when they actually go and buy, they always find that the technical capabilities of the platforms are insufficient. So they end up buying a platform and then filling in with point tools and going back and forth and ping ponging back and forth.
And that the thank you for bringing up the economic argument, because ultimately that's what we are here to solve for. It's, uh, the, i I say that the patron saint of, uh, of platforms is, uh, David Ricardo, the economist in the 18 hundreds, right? When, uh, he espoused the theory of comparative advantage, right?
It was between England and Portugal. Somebody makes wine, somebody makes cloth, it's better if we trade, right? And ultimately, your job as a security professional is to help secure your organization and your organization is going to get more value out of you if you can focus on what's important to the organization rather than fiddling with the tool.
Right? So if you have 86,400 seconds in a day, right? Are you going to, are you going to spend your time tying tool one to tool two to tool three?
Or are you going to, okay, you know what, this platform gets me 80% of the way there, I'll use that. And then yes, the for, for the exceptions, I can use this, this, this, or that. So I, I, to me, it boils down to an economic argument about opportunity costs and 80% of the way towards platform.
And to Jack's point, some of the, the survey data we, we, we showed yesterday, there is a preference for platforms. It doesn't solve it, but 80% of the way there. Well, and I, I I, I like your point there on gets it 80% of the way there.
Um, because I think a, a lot of the time we get lost in, well, I can enrich this data, I can have more, I can do use a platform that gets me a hundred percent of the way there, but I don't always need that data. There's times where a bandaid is better than trying to rebuild the whole thing from scratch. Tyler, Uh, at what point do we start asking the, uh, commercial versus open source question?
You hit, you were three steps ahead of me, man. Uh, how many of us have, have thrown an open source IDS on a box somewhere and said, that's 80 per, that gets me 80% there. I don't need that commercial IDS because the open source one was a one line install script, it's done.
Mostly I don't have to do care and feeding. Maybe so Theory, hold that thought. 'cause I'm gonna, I'm gonna let Jack say something.
I'm gonna come back to that thought because you brought up something very important, Jack. Well, I was gonna say the, the open source and or point tool argument is why, uh, Richard Stein's, it harvest tracks all the cybersecurity vendors and there are more than 4,500 vendors with more than 10,000 products today, right? So that it's because there are so many different ways to solve the problems.
And so many organizations have either limited budgets or have the ability to do open source, and somebody takes that and goes commercial. And so there's just a tremendous amount of opportunities or both vendors and for people to explore different ways to solve the problem. And we are, but we are not unique.
How many restaurants are there? How many, uh, closing lines are there, right? So this rich tapestry of humanity means we have different choices.
To go back to economics, there is a, it, it doesn't sound well, but there's a concept in economic called inferior goods. Mm-hmm. Right?
And inferior goods are the goods that you buy when you don't have enough resources to buy something. All of us here, uh, early in our careers, we bought cheap food eventually some of us get better, some of us or, but the same thing applies to security. There are sophisticated products that are very, very high end.
There are things that are in the middle and different people need different things. I argue that the difference that the real debates that we have to have is platforms versus point products is one of those dimensions. The other dimension is, do we need something that is best of breed versus good enough?
Right? So, so there's a lot of, there's a bunch of elements that we have to unpack there. And I, I wanna go back to one of the things that Tyler mentioned.
Um, we all know that there's, there's two different kinds of freedom, right? Free in beer. Free is a freedom.
There's a third, isn't free isn't a puppy. Yes. And that is the part that I don't think a lot of people understand because Tyler, you're absolutely right.
Most of the time I don't have to maintain that package until I do. Now, who owns that? Well, if it's a platform that I purchase from a vendor, their support team owns it.
That's what I pay them for every year. That's why executives love platforms is because they can call somebody else to fix the problem. You as an open source guru now own that problem.
So that means that you have to go spelunking through every forum and discord post that you've ever seen to hopefully figure out, is this a known issue that I can fix? Is this a bug that somebody needs to write a fix for? And could that person that needs to write that fix be me And you have now traded monetary value for this product, for your resource cost.
So going back to Fernando's example of, we're not the only people that solve this problem this way. I would argue that restaurants have a different problem. 'cause you can't download a free knife.
But what if you worked in a restaurant and someone gave you a potato ricer and said, well, you need to use this as your garlic press and like 14 different other tools because we can't afford to buy you a garlic press. Then the person who's doing that would be like, yes, but why do I have to drag this potato ricer out every time I wanna squish something? There are reasons why we solve certain problems in certain ways.
And I think that this idea that it's free because it's open source is a misnomer because everything costs resources. Yes. The CFO thinks that money is the most important resource.
If you, if you want to teach that CFO why that is, hand them a, a pen two laptop that runs Excel 97 and ask them to do their job. And when they complain that my formulas don't work and it takes five and a half minutes for my laptop to boot and the battery last 38 seconds, remind them that it was free. So Tom, let's also not forget, since we're talking security here, there is a huge security risk with open source where an open source maintainer bought, sells out and sells their package to a malicious actor.
That's happened. That has happened. And it continues to happen.
Yeah. Right? And so your reliance on an open source where you're not paying for the vendor to maintain it, right?
Forget how much you pay for it. But if you're not, if you're, there's not a guarantee there that somebody, you have somebody to go talk to to support this thing and to prevent that from happening, then you're exposing yourself to yet more risk. And you, and you brought up the fact that sometimes maintainers sell out, but there is also the every possibility.
'cause we saw this last, was it last year, right? That someone can inject, embed themselves into the community and inject malicious code. And it just so happened that someone knew exactly how long it took to log into a system over SSH or we wouldn't have caught it, right?
And, and that kind of, but on the flip side, you know, I can already hear you typing the comment. SolarWinds should have caught that DLLA lot earlier. And I absolutely agree with you.
However, SolarWinds had a lot more people working for them than this project where, look, dude, if you're not doing anything on Friday night, 'cause you couldn't get a date, can you go ahead and check in some code on this to make sure that this login system works? I'd really appreciate it. Thanks.
I'll buy you a coffee. Yeah, Yeah. No, let's just be careful because yes, we had the, the XV tools, uh, example, but it's not as if purely, I, I don't like the, the, the, the, the non open source software have its share of problems too.
And, and then you are caught into, oh yeah, we're going to release a fix in V 13, which is three weeks from now. And, and three weeks is, is awesome because they used to be six months, but that's three weeks that you're hurting. So I, I, I agree with you that we have the open source problem, but uh, it's not that this commercial is the land of ponies.
Our online crew is championing its fit to get into this. So who wants to go first? Gentlemen, Tyler, you got your hand up?
Go for it buddy. Alright. Uh, you mentioned SSHI mean, uh, the reality is whether there's risk and open source or not, uh, open source underpins almost everything, right?
So yeah, anybody could sell out, anybody could insert themselves. Um, but that risk is there. Even if we buy a commercial product, those commercial products are using open source libraries and tools and they're building on top, they're part of the, the supply chain, they're still susceptible to, oh look, this tool that we use got compromised because their supply chain got compromised.
So I would make the argument that in the case of things like open SSL or open SSH, they have transcended the platform versus point product argument. And they have become a platform in and of themselves. They are building blocks for every other platform.
That's one of the reasons why Heartbleed was so devastating, right? Oh, we found a bug in open SSL well run what runs open. SSL Oh crap, everything.
And like we've seen this before with Linux packages, right? Like I can remember back in my day, there was a bug in open SSL when I emerged a Gen two box. And that was a week of pain trying to figure out why nothing would compile.
So we, we have to worry about those point solutions becoming infection vectors. We have to hope that they won't. And thankfully a lot of those projects have been handed over to the stewardship of people who are not just gonna disappear into the night, thank you Lennox Foundation for all of the great work that you do to make sure that our world's not gonna fall apart.
Because, you know, lib Gen C didn't the, the guy decided to quit. And so this kind of comes back to the whole point. Solutions only work as long as people want to support them.
And eventually someone wants to step away from this. You cannot be the person who's maintaining this bookmark server 25 years after it was installed. And I'm gonna call out a company for this problem, ladies and gentlemen, Google, and you're probably thinking to yourself, yeah man, I loved Reader Wave was awesome.
I'm not talking about those. I'm talking about the tools that Google people write to solve Google problems and then release into the wild. 'cause maybe it can help somebody else.
I'm gonna quote from Cloud field a four. We talked to LightStep, then Siegelman said something that has stuck with me for, oh God, what are we on now? Six, seven years?
He said, at Google we write tools to solve Google problems. Do not use our tools to solve your problems. Like you gotta think about this.
When they write a tool to solve their problem, they're talking about terabit flows that may have to move across the country. You my friend, have a small traffic engineering problem at a rural ISP in Montana. Yes, Google's tool might fix that, but please do not for the, for an instant belief that that tool should be modified to fix your exact problem unless you're willing to do the work yourself.
But then that maintainer leaves. And I actually had a briefing call with a company last year called Invariant, and they're a very good example of this. It's two gentlemen who were writing firewall code at Google and the project got open sourced.
So they left Google to pick up the project and turn it into a commercial, uh, platform. And I haven't talked to the guys in a while. So in variant folks, let's sync up because I wanna hear how things are going.
But one of the last time I talked to them, one of their problems was, is they were having trouble trying to figure out how to commercialize this. You know, why code's free, all I gotta do is download it and run it. So this is one of the other problems that the maintainers run into, and we've seen this from, uh, uh, HashiCorp, right?
We've seen this everywhere. Everywhere, yeah. Because I wanna take my project and I wanna be able to make a living off of it.
And I can't do that by hoping somebody's gonna sign up for my Patreon. Mm-hmm. 'cause let's be fair, Patreon for software developers is kind of boring.
So I'm gonna figure out how to operationalize this except now it's GPL, then I can't really do that unless I create a fork that is that code. And then I have to hope that Amazon doesn't come in and fork my code and offer it in AWS is a free add-on. And now suddenly I can't get anybody to pay for it.
So how do we solve the problem of me being de platformed by a company through my own altruistic nature to wanna make the world a better place with my tiny little tool? And Tyler's hand is up as I'll work after Tyler. Tyler, tell me I'm wrong, buddy.
If it's not obvious. Uh, I like open source. Uh, no, you're not wrong, right?
Uh, we, we watch, um, license, like if we build something on open source, we watch license changes for those things bite us Yeah. All the time. So it out outside of the risk of threat actors, um, there's a risk that just the, the business or the entity maintaining it decides, Hey, let's change the license and then the entire basis of the platform that we've built is now compromised.
Mm-hmm. Yeah. Um, Fernando, I was just going to comment that it's, it sucks, but we should understand that that's how the world works.
We're talking about a, a, a well understood problem called the tragedy of the commons. Mm-hmm. Right?
Once somebody, how, how does a community support something that they can all benefit from, but they don't necessarily pay into it, right? It's a, the, the argument I would make is that you come into this game with the right expectations. If so, if you, if you are behind an, an, an open source package, which, uh, similar to that, I'm, I'm very much per open source, but you have to have the right expectations.
Oh, I built this wonderful package. The package, uh, the, the, the, the, the tooling grew into this massive community that has, uh, users with all the right logos in there. Like we have people not, not endorsing, but you have, you have people from Netflix using this.
You have people from the NASA using this, whatever, oh, I'm gonna make a business out of this. Hold on buddy. Do you understand the reality of, do you know the game you are about to play?
Come, if you come into the game with the right expectations, that's fine. You can make a lifestyle business out of it. I'm gonna get the, uh, uh, I'll have a few customers, I'll have some maintenance contracts over it and I'm fine.
Oh, I'm trying to be the next $10 billion IPO company. Yeah. Hold your horses so know the game you're gonna play.
That's all. So I think, but from a platform versus point tools perspective, yeah, a lot of stuff is built on open source, right? Um, most platforms start out from, as you mentioned, the uh, either you start with a small platform or you start with, I have a collection of tools, I'm gonna put 'em together, build a platform.
That's a lot of companies. Do you look at Palo Alto Networks, right? Your CTO says that they intended to is their philosophy is we're going to build a platform of the best of breed point tools where the idea is for every single module, it is the equivalent of a point tool.
But you can't purchase it separately. You have to purchase it as part of the platform. Now, I don't know if the community perspective is they've succeeded on that goal, but that is the goal, which is to sort of bridge the traditional view of platform as an agglomeration of various tools that may or may not work well together.
And the best point tools that solve the very specific problems people want. Andre, you wanna jump in here? Yeah.
You know, and that, I think part of the challenge with, I say on the commercial side, a lot of times when, when there's tools that are built, unfortunately they go to the engineers and tell them to solve a problem. And an engineer's perspective of a problem is very different than the sales teams. It's very different than the actual engineers.
It's very different than the actual consulting engineers. So when we get a product most often from the engineer that's usually overbuilt over engineers, overpriced, and they're immediately looking to generate revenue on, on that product versus a specific like open source problem that's built to do one thing and do one thing well. And so when you combine those two worlds into one platform, you get the serious thing that you see most often.
Incap, Karen. Yeah. So my observation is from all this discussion is that we really haven't talked recently in this discussion about a security problem at all.
We're just talking about commercial businesses that build products and whether you want specialized or integrated and everything. So I find that interesting because I deal with this, this discussion outside the security world is too, like just data quality tools and things like that. And I, I'll come back to, I really do think the modern software services that we're gonna use going forward are gonna be highly, they're gonna highly prioritize integratability.
And I don't mean moving data around. I mean the ability to reach in and say things and read things to be very technical here. And that this is really the big question.
And, but if I bring it back to security, I think it's, you know, I'm not selling more widgets. I might be trying to save lives when I'm talking about security in a system or save people a lot of money. And therefore it's the how quick we can respond and whether having 15 dashboards is better for a better response or having an integrated dashboard.
That's my question, Fernando, up next. And then Mila, I'll Just be very thank you for, for expanding on this because one of the things that I, I, I called out yesterday on the, on the short presentation I was able to do, uh, is on the mental models thing, right? I talked about the Canfin framework and I talk about worldly maps, right?
And one of the thing, the thing I I love about worldly maps is that it shows you how a product evolves from Genesis to custom to commercial to commodity. But we didn't have time to get into it. One of the things is that once it becomes a commodity, it becomes a platform for the next generation of genesis custom con and, and, and on and on and on.
And that's fine, right? That's what we expect. That's how progress works.
That, that, that was the only kudos to widely match Me. Lou. Yeah, I think it's been really interesting listening to the different conversations.
I think in general this is very much like a technology issue. Mm-hmm. As what Karen had said.
This isn't necessarily a security issue. I think when I work with startups and small teams that are trying to figure out how to solve for security problems or GRC issues, for me, I'm always like, smaller companies are probably going to need to invest in some of these like point solutions to just fix the issue. Especially 'cause they might not be able to forward the platform solution.
So for me, I think it has a lot to do with the organization's maturity. Mm-hmm. As they grow and their budgets expand, I think of they will start to abandon those point solutions and go to the flashier platforms just 'cause they're more expensive, they offer more solutions and the team is also big enough to implement the new tooling.
'cause I've had issues where smaller companies have purchased platforms and they can't actually do the entire implementation 'cause they bid off way more than they can choose. So for me, I'm always coming from a place of like, invest in the tool of the technology that actually can fix the issue. And then also just be careful of scope creep of just don't get too many tools.
'cause I've worked with teams that have more tools than people and that's terrible. Skye and then Tyler. Yeah, I, I like what Karen said, and I wanna draw it back to security a little bit.
I think, um, there, there's a concern out there about at what point do you get, um, a platform that could stifle innovation or stifle, um, the ability to, um, evolve the platform. Uh, because you have to worry about those integrations if you're, you know, building a, a AEM platform that integrates with a a log store, uh, but then you also want a firewall platform or, or a, uh, a log analysis platform that can look at those. Um, but you need to go upgrade or modify a technology because those are shared resources.
At what point do you run into issues where you want to upgrade or you want to change a technology, but you're not able to do that because the platform is all integrated together and you can't really pull that out, be modular. All right, I'm gonna toss it to Tyler to give us a comment. Uh, one thing we didn't talk about is identity and authentication.
We're, if we're buying a platform, uh, you get a sync, you hopefully get a single source of identity and authentication in sso. If you're using a bunch of individual point products, you've got a whole bunch of different areas to manage identity authentication. Hope that this one tool that you bought even supports SSO or um, passwordless authentication, whatever your desired thing is.
And then when you talk about integrating now you've gotta worry about what are the API keys, what's the rback for every single one of those tools? And are you gonna be able to be granular enough to prevent building vulnerabilities into your custom built point solution? Man, if only I had enough time to open that barrel of worms that you just kicked over.
'cause I I know that that's a big deal. Fernando. No, I was just gonna say that, that, just thank you for Tyler.
The, uh, you, you mentioned identity and authentication. I would argue that the, the, the problem gets exponentially works, uh, worse with, uh, the next step, which is I authorization, right? What the authorization models look like in all those different point tools.
I'm an admin on this tool, but then how do I map that to a regular user on the other tool? And it gets confusing really, really quickly. So I think we'll go ahead and wrap it here because as you can see, this is a really thorny issue.
And one of the reasons why I've wanted to discuss this at Security Field Day for so long is because of the uniqueness that is Security Field Day, where it is actually very easy to create a point solution for a security issue and to project it out there into the world. And then you end up creating this kind of, um, ecosystem where you're reliant on a bunch of, uh, single use tools as Alton Brown calls them Uni taskers. And if you have watched Good Eats, you know how much he hates those except when they actually have a, a unique purpose.
And so I think that that's one of those problems that we have to solve, but we can't solve it by just saying, oh, well you need to write better tools or you need to collaborate with more people, or you need to open source everything and let other people sort it out. You still have to work inside of the, the pressures of ecosystems of companies as well as, as the political decisions. We didn't even get into that, but sometimes the platforms look the way they do because of political concerns inside of organizations.
So, I mean, there's probably more than enough, uh, content here to do like three other round tables. I wanna hear what you have to say though. I want you to leave a comment under this video and tell me what you think about point, uh, products versus, uh, platform solutions.
You know, what, if it's not, if you've had more to say than just a comment, write a blog post and send it to me because I'd love to highlight it to the rest of the tech field at community. And that is a great way to get yourself on a list, to be a part of one of these future delegate round tables.