Episode 204: Commanding the Digital Battlefield: TAK’s Revolution in Public Safety with Ryan McLean

Published 2024-03-21

Topics: TAK & Mapping, Artificial Intelligence

Episode notes

Let's talk TAK (Tactical Assault Kit) ...

Hello Smart Firefighting Community!

Welcome to another episode of covering real world innovations via interviews with fire service and technology industry experts that empower YOU to develop your very own Smart Firefighting strategy!

In this episode:

How TAK transforms public safety with shared awareness and strategic visualization

Insights around how TAK speeds up high-quality decisions for tactical end users

How open-source and AI advancements are setting the stage for the next evolution of TAK

Hear from Ryan McLean - the Director of TAK Product Center .

TAK (Tactical Assault Kit) is a tool that provides shared awareness and helps visualize the relationship between friendly forces and targets. It was initially developed for the Air Force but has recently been adopted by other services and agencies.

Ryan discusses the concept of information dominance and how TAK enables tactical end users to make high-quality decisions faster than their adversaries. He emphasizes the value of TAK for public safety and law enforcement, encouraging them to consider using TAK and highlighting the importance of hands-on experience to understand its benefits. McLean also explains the total cost of ownership of TAK, emphasizing its lower cost than licensed software.

So click play now to find out what he has to share!

Head to www.smartfirefighting.com to discover how SFF accelerates innovation for emergency responders, to find out when our next event is, or review our curated resources!

Facebook | Instagram | Twitter | LinkedIn

Chapters

0:00 Kevin's intro
0:51 Ryan McLean of the TAK Product Center joins from Carmel, Indiana
1:14 TAK 101 in Ryan's words
4:20 The Air Force roots of TAK and how the vision evolved
10:50 Adoption across services and what holds it back
15:23 What open source means for TAK and for entrepreneurs
23:14 Kids in the background
24:27 Cybersecurity and the role of the TAK community
29:20 TAK continuous delivery and information dominance
32:07 Why public safety should consider TAK and how to start
38:41 Acquiring versus delivering software
40:55 What success looks like for the TAK 2030 roadmap
45:44 AI and machine learning in TAK
51:36 The TAK Offsite events
55:04 Ryan's parting challenge on the data problem
57:13 Closing
58:21 Outro

Questions answered in this episode

What is TAK and what does it do?

Ryan McLean describes TAK, the Tactical Assault Kit, as a tool that does one thing really well: getting shared awareness in front of the end user. It excels at friendly force identification and target correlation, visualizing the relationship between where friendly forces are located and where they are trying to go or what they are trying to accomplish.

Hear it at 2:07

How did TAK originate?

Ryan McLean says TAK originated after a friendly fire incident in Afghanistan in December 2001 involving a GPS device issue. An Air Force combat controller, retired Chief Master Sergeant Al Yoshida, was tasked by the Secretary of the Air Force to solve the problem and make close air support safer and more effective. This led to experiments starting in 2002 that eventually became TAK.

Hear it at 4:44

Why is TAK open source?

Ryan McLean explains that TAK went open source primarily to comply with export control restrictions so it could be distributed through the Google Play Store to partner forces. To include AES-256 encryption bindings in a government product, the product must be mass-marketed, and since the government cannot sell it, the only option was to open source it.

Hear it at 16:26

Is TAK free to use?

Ryan McLean clarifies that while there is no license cost for TAK software because it is owned by the government and funded by taxpayers, there is a total cost of ownership. Users may incur costs for devices, infrastructure, add-ons like imagery, and equipping a formation, but there is never a recurring software license fee.

Hear it at 32:43

How can firefighters or public safety personnel start using TAK?

Ryan McLean says the best way to learn TAK is just to use it. People can download ATAK or iTAK from the commercial Apple App Store or DISA App Store and start using it to figure out if it is right for them.

Hear it at 32:43

Transcript

Machine transcript of the published audio. Names may be misspelled and some sections are missing.

Ep 204 transcript

Commanding the Digital Battlefield: TAK’s Revolution in Public Safety with Ryan McLean

Speakers: Kevin Sofen, Ryan McLean

Source: Whisper medium.en machine transcription of the published Podbean audio (no original transcript found in Drive), lightly cleaned. Speakers were separated by voice clustering and then checked and assigned by hand at every speaker change. Gaps where the model returned no usable text are marked [inaudible m:ss].

[0:00] Kevin Sofen: Welcome to the Smart Firefighting Podcast. Kevin Sofen here, where we cover all things related to the future of smart technology for first responders around the world. Please enjoy the show and let me know what you want to learn about next. Today we talk TAK, the Tactical Assault Kit, with Ryan McLean, the Director of the TAK Product Center. Ryan shares insight on how TAK, originally developed by the Air Force, now revolutionizing public safety by providing unmatched situational awareness and facilitating rapid decision making for law enforcement and emergency services. Enjoy this deep dive in the TAK as we explore the challenges, cybersecurity concerns, and the promising future of TAK, including its expansion through open source and integration of AI and machine learning. Enjoy. Good morning, Ryan. Welcome to the Smart Firefighting podcast. How you doing?

[0:55] Ryan McLean: Hey, Kevin. I'm good. How are you?

[0:57] Kevin Sofen: I'm doing well. Where is Ryan located today in the world?

[1:00] Ryan McLean: I am in a suburb of Indianapolis, Indiana called Carmel.

[1:05] Kevin Sofen: My in-laws live right around there, so I think next time I'm down there, we're gonna have to get a coffee or go for a walk on the Monon.

[1:13] Ryan McLean: Easy day.

[1:14] Kevin Sofen: Yeah, so I've been following some of the work that you're doing, and I think the fire service now is continuing to hear this little kind of tidal wave that's growing around TAK. In the fire service, there's a lot of conversations around what is situational awareness? How do you develop situational awareness? And there's all these different tools to help create data, display data, and ultimately help first responders do their job more effectively. But TAK is something that most people associate with the military, and I know there's been a lot of evolution over time in terms of how this can apply towards public safety. but for most of our audience, I would say a lot of them don't really know what TAK is at all. So to start, I would love to hear kind of a high level TAK 101, what is TAK in the words of Ryan?

[2:07] Ryan McLean: Yeah, TAK is kind of in the Linux model. It does one thing and it does it really well, which is to get shared awareness in front of the end user. And so you can kind of break that one thing into two categories, your targets and your friendly forces. And that target, in the military sense, it could be a true prioritized lawful target, but in the kind of the civil use or civilian sense or the federal government sense, it doesn't have to be something you're prosecuting. It's something you're going after, something you're trying to achieve. And so it could be a wildman fire. It could be just a waypoint on a route. It could be any one of a number of things, but where you're trying to assess the relationship between where friendly forces are geographically located using geospatial tools in relation to where you're trying to go, what you're trying to get after, what you're trying to accomplish. And so TAK really excels at visualizing that relationship. And we would say that in a nutshell, TAK does two things, friendly force identification and target correlation. And if you can do those two things, You can do close air support and fires missions in the military, which close air support is one of the highest risk types of engagements that we conduct, one of the highest risk missions in the DOD because you've got aircraft and fires, you've got munitions going through the battle space at various speeds from various locations and you're trying to correlate what friendly forces are against targets and achieve some objective. So it's a very dangerous mission. you can do friendly force identification, target correlation, which TAK allows you to do, you can do a lot of other things too. You can do personal security details. You can do wildland fire fighting missions. You can do personnel recovery. You can do other things that just have nothing to do with the military, like paintball and airsoft. You can do hiking in these kind of nice offline tools that we publish so that you can take the target correlation from the Air Force identification capability kind of anywhere. That is what TAK is and does.

[4:20] Kevin Sofen: And you mentioned that it has its basis and roots within the Air Force, and I would love to kind of hear you expand upon it of beyond the maybe the identification, the correlation is sort of the foundation of it, but what kind of prompted the initial concept of TAK, and how has that vision evolved to meet the changing needs of the different users?

[4:44] Ryan McLean: Friendly force identification on the battlefield is just inherently hard, really hard, because as militaries have evolved over the centuries, like the formations have gotten bigger, they operate over bigger geographical areas, and you're trying to achieve effects faster and so you're relying a lot more on correlations of targets that are done, maybe not by you personally. You're relying on sensors and other people are relaying points to you so you can execute these missions. So as modern warfare effectively evolves, that core task of friendly force identification, target correlation has gotten exponentially harder. So even Desert storm where, you know, that was kind of our first, you know, modern post-Cold War, you know, military engagement, force on force engagement, our fratricide rate was astoundingly high. It was actually close to a quarter of all casualties in the US forces were actually fratricide. So, that was blue on blue in some form or fashion. So, there were, you know, kind of big strategic constructs put in place to really mitigate the risk of fratricide, to see some of those concepts be used in the global war on terrorism in the early years of that. But even with these strategic whole of DOD approaches to friendly force tracking, target correlation is still inherently hard as well. So there's a practice site incident in December of 2001. So as part of, I think when we hear Task Force Dagger in Afghanistan, 2001, we typically think of horse soldiers. The horse soldiers, ODA 595 was one of the elements as part of Task Force Dagger, but there were other elements as well. They were in north of the country, and there were other elements in the south of the country by Kandahar. One of those elements, it was an American Green Beret team escorting Hamid Karzai's force into Kandahar. They were trying to retake the city, establish a US presence there so that other objectives could proceed. Well, there was a B-52. Keep in mind, B-52s typically were not used for close air support. That was kind of a new invention, a new application of force in Afghanistan. But B-52 was on station and there were two Air Force combat controllers attached to this Army Green Beret team. They were using a new piece of technology for target correlation called a dagger as a new GPS device. Pretty common and actually kind of old technology nowadays but 20 years ago 20 plus years ago is new so when you took the batteries out of the dagger and you had a target position displayed and it programmed up on the dagger gps it's like a three line lcd display took the batteries out powered it down powered it back up the position would populate would be your position so there's a conflict there and the user experience because you were looking at the target position now you're looking at your own position but fog of war you're trying to correlate targets in friendly force identification. That led to a really unsafe situation where in the fog of war, the right bomb came off the right aircraft, cleared by the right personnel on the ground, but ultimately went to the wrong location, led to several friendly force deaths. These combat controllers in the Air Force on the ground were injured. So one of them was tasked by the Secretary of the Air Force to go solve this problem. Hey, make the Air Force really good at close air support, make us a lot better, you know, faster, safer, more effective at this mission. So that individual recently passed away, retired Chief Master Sergeant Al Yoshida, but he was a friend to everybody in the TAK community because he was the genesis of the TAK community. So he partnered up with Air Force Research Laboratory and several program offices starting in 2002. And that led to a number of experiments that led to actually some program offices being stood up in the Air Force. One of the experiments was in 2007-2008, Air Force Research Laboratory said, hey, we could do something with this new technology, which is the smartphone. So it was kind of a leveling up from, you know, where the old Palm pilots had been previously, thanks in part to, in large part, to where Steve Jobs had really conceived iOS in the Apple, you know, iPhone product line. And then where Android and some of these, you know, third party manufacturers were taking the Android operating systems. They said, we can do something with this. They proved it. They said, we can put a map on a phone. And so operators like Chief Yoshida were really instrumental in guiding that early development. And the short story is that the Air Force actually kind of eschewed it early on. The Air Force said, this isn't the right tool for us, but the Army said this could be useful. So they had a napkin sketch, the way all good requirements start, and they said we could take this tool and we could start integrating our robots with it, we could start integrating our drones with it, we could start integrating even our canines with it, and so they started using this. They did a combat evaluation and figured out that this is actually pretty useful. It's got some kinks, got some wrinkles, but it's got enough potential, and the rest is kind of history. So now it's kind of this joint force tool where there still is no requirement, there is no centralized program or budget for it in the DoD, but it is sustained through a coalition of the willing. We're funded by several program offices and inter-agency partners. And we exist at the product center to make sure that the next release of the TAK suite, the TAK software suite is always better than the last. But it does have its roots in the Air Force and kind of found its way into the other services because it just solves that fundamental problem of from the force identification target correlation. And then we take what we believe is a sound architectural approach, a rigorous engineering approach to make sure that's extensible, people can integrate other sensors and radios and all kinds of other things into it and that's kind of where you get the real value of TAK is where you start connecting it and so then your whole battle space starts to become connected in a secure way and so on and so forth. So it's a really a multi-layered story but it comes down to the Air Force having a problem and the Air Force using technology to solve that problem then making that available to the Joint Force.

[10:53] Kevin Sofen: Well I think the proof is in the putting in terms of the value that it is bringing and as it continues to evolve, but I find it particularly interesting that you said how it is a joint force effort with no requirement, which to me oftentimes you can hear something doesn't have requirement, it's sort of like, well that will probably die on the vine. Having said that, it still seems like there is continuous, and maybe not as fast, but sort of different types of adoption across the different services from fire law, EMS, DOD, but how is adoption now and sort of what's kind of holding back adoption or what's maybe accelerating adoptions across a different user base?

[11:31] Ryan McLean: Yeah, if you look at our TAK 2030 strategy, there's no mistake that the number one theme that we're pursuing is the testability and deployability of the products. Because, to your point, there are just inherently, DOD being a highly bureaucratic organization with policy on top of policy. On top of policy, a lot of compliance requirements to ship any software, there are a lot of blockers that would really preclude you from doing any business inside the DoD. So what we focus on, first and foremost, is a predictable release cadence for the products. We always make sure that the products are being released on a schedule that people know when they're coming. And then beyond that, we make sure that what we're shipping is, you know, it meets a defined quality standard. We're making sure that there's a robust kind of test matrix that we're applying to the products, making sure that they are kind of gonna live up to that quality contract with the user. And then, as part of that contract, we're always in a position ourselves to make sure that we can fix things very quickly. The barrier today is that the DOD has so many policy requirements, compliance requirements to what it means to ship software. Program offices are really forced to try to meet all those requirements. And so where we're releasing a patch for ATAK, let's say the flagship product every day, almost at this point, at least every two to three days, those patches are not making their way to the front lines. And it's because of those really strict compliance requirements. So what we try to do is work across this really complex compliance space in the DOD and the federal agency space. And we say, okay, what are those friction points upstream where we're literally building the source code into a deployable installable product? What are those friction points that we can sand down little by little so that it's easier for you, the person who's trying to get some package and paperwork package put together or convince the IT overlords for lack of a better term, that it really is a safe product and kind of the test and safety people that it really is a suitable and effective product. What are the things that we can do upstream of the program offices to make sure that it can get to users in a fairly rapid fashion? We don't ever want to be creating like a cognitive burden on the end user. Like I don't think we ever want to be like shipping huge upgrades on a daily basis. Like that's really hard to do on us engineering wise but it's also really hard for the user. What we want to be able to do is just respond very quickly if a thing breaks or if a thing doesn't work expected from one release to the next. Cause these products are complex. They're very highly integrated under the hood, and they have some impressive capabilities, so there's always room for things to go wrong. We have to make sure that we're in a position to fix things really quickly so that these groups downstream from us that do deploy product, that do maintain products for actual end-users, they can deploy product fixes really quickly as well. That's what we see as the pathway to maximum combat agility in Modern Warfare and Future Warfare is not who can kick out the biggest feature the fastest, which that's always nice if you can achieve strategic or tactical surprise like that. But really, can we put every user downstream of the TAK product center in a position to always have a better product than they had the day or the week prior? Can the software they're using be just a little bit better? Can we make that decision loop for them just a little bit faster? And so there are a lot of compliance things actually that go into making that possible, but the DODs and federal government's self-imposed compliance requirements, that's the biggest barrier to the continuous deployment of the TAK products today. But we made a lot of progress in sanding down a lot of those friction points, so I'm bullish about that future.

[15:23] Kevin Sofen: Yeah, man. Well, this stuff doesn't just happen overnight, and I heard you say a few times the term agility and also listening to the different end users and feel like whether it's in business or the government, a lot of times when you actually listen to the end users and you're customer and user centric, usually good things happen, and I saw on the TAK websites and your LinkedIn talking a lot about engaging and working with end users to make the products better, to how to continue to enhance the architecture, the features, and I think about it too, just the, if you allow the open, free market to work on something, oftentimes it leads towards success, or whether it's the power of the internet, the power of the people, just open source just usually leads to better things happening. I'd love to know what does open source mean in your words and what would be your message to entrepreneurs and people that wanna find ways to take something that doesn't exist in TAK and bring it into TAK or build something new to help enhance the TAK overall ecosystem?

[16:26] Ryan McLean: Yeah, open source, that is our third priority as we look through our themes of execution TAK 2030, looking to the end of the decade. I think it's important to start like why we actually chose open source and it's counterintuitive, I think. At least when I first came into this seat about three years ago, the team had just open sourced ATAK Civ, the civil use version of ATAK a year prior and there were no other open source products. We have always treated TAK inside the federal government as a government open source software movement. So within the federal government, it's so easy as a program manager or as an engineer to say I don't trust what people would want to do in my product so I'm not going to let them in and that just kind of leads to these just stovepipes upon stovepipes upon stovepipes. So that was a really good decision that Air Force Research Laboratory personnel made from the very beginning with TAK. We're going to treat it as a Gauss or government open source software movement. There are other projects like that. I think ATAK being a mobile product and kind of the first of its kind in that regard, has really cemented its place as a model government open-source software project. But then there's kind of the public open-source aspect as well, you know, like on GitHub, you know, truly open, accepting pull requests from the rest of the world. That is a challenging environment to live in. And just to be like completely honest, we have not mastered that. We are still learning how to do that well. And frankly, it takes capacity, it takes effort, it takes muscle going into that to do it well. The reason we went open source to begin with was actually to achieve a different end. So when we work with our partner forces, when our operational customers in the tech world work with partner forces, meaning forces from other countries, it's really important, it's really valuable to extend that network in a secure fashion to those partners. if we're going to be running on TAK and our people are going to be advising, assisting other partner forces in whatever country, we'd really like for them to be able to use TAK as well because that puts their dots on our maps. And if we want our dots to be on their maps, that allows that to occur. And then we can create a really nice and correlated combined or coalition friendly force picture, you know, operate together. But it's, yeah, it's really hard to also put like DOD software in the hands of partner forces. And so there's been a lot of emphasis over the years on creating this civil use variant that actually is assessed by all the appropriate compliance bodies in the U.S. government, like Department of State and Department of Commerce, to say, yeah, this actually, this is not export-controlled technology. There's nothing in this software that, you know, is inherently Department of Defense that we should be restricting. So we put a lot of work into making sure that ATAK-CIV and the general architecture of TAK allows us to pursue that end of putting TAK in the hands of our partner forces. So we wanted to release it through Google Play Store. The catch there was that because ATAK employs very specific encryption bindings tied to the AES-256 encryption algorithms, that in and of itself has export control restrictions attached to it. Now, everybody all over the world uses AES-256. There's no question about that, but if you're going to bake it into a product, you have to follow some strict compliance rules. So the general rule there, and this is funny because we kind of like learned something new about our own product. The rule there is you have to, if you're going to include these encryption bindings in your product. you have to mass-market the product. But for the US government, we can't really mass-market it. We can't sell the product. It's owned by the US taxpayer. The source code itself is unlimited rights. The taxpayer has literally funded the bill for all of it and we can't sell it to people. So the determination there was well the only recourse you have is to open source it. So I think when people see ATAK-CIV and now TAK Server and in the future other products in open source, there's probably a natural assumption that we did it to invite contributions, whereas really it was actually a means to an end. It was a step on the path to getting it in Google Play Store so that as a kind of a defense-led product offering, we could, in the name of great power competition and integrated deterrence, we can make these products available to people that need to operate alongside our forces. And all they have to do is go to Google Play Store and ATAK will pick up their language setting on their phone on the Android device and say, boom, I'm going to put it in French or modern standard Arabic or one of seven other languages. So what we're trying to do is kind of meet the other side of the open source coin now and figure out how do we actually harness the power of the community because we're a fairly small organization and we probably are not being honest with ourselves if we say that we're going to be the only organization that, you know, DOD-wise, if we're the only ones that are contributing to the tech products, we want to facilitate good, strong contributions to ATAK-CIV and TAK Server and the other products down the line. But we've learned that there are some fundamental kind of retoolings that we need to make on the platform side. Like how do we accommodate merge requests from the average, you know, US citizen or anybody in the world? We get pull requests on GitHub for TAK Server and for ATAK-CIV. ATAK-SIB is hard to maintain because it is a fundamentally different set of continuous integration workflows than we employ on our own GitLab instance. It gets into some tooling differences, but I think what we are finding on TAK server is that now we have established a much better pattern for upgrading TAK server distribution in open source. Now we can keep TAK server pretty rigorously up to date with at least the latest tag that we're releasing on tech.gov. We see pull requests there. Most of the time the pull requests like updating database packages, those tend to fall right in line with what we've already done upstream on get.tech.gov so we can just close out those pull requests. It's a little bit of duplicative work. You'd like to not see that because duplicative work implies inefficiency of work, but we're seeing that the open-source community, the few contributors that we've seen in TAK Server on GitHub, they're very much in line with where our head's at with continually modernizing the product. There's an ideal in-state there where people are actually contributing to the same source code baseline that we're maintaining and they're able to add new features or resolve bugs because we're getting good at publishing. Hey, here are our problems, here are our work priorities at the bug or feature level.

[23:14] Kevin Sofen: No worries. Kids being alive and making noise is a sign that they're alive. I've had certain podcasts where people say, hey, if the kids aren't making noise, that's a bad sign.

[23:33] Ryan McLean: Yeah, that's accurate.

[23:35] Kevin Sofen: I take it those are your kids?

[23:39] Ryan McLean: These are my kids. Yes, these are my kids.

[23:42] Kevin Sofen: How old and how many?

[23:44] Ryan McLean: five and a half, two and a half, and then number four is due in April.

[23:47] Kevin Sofen: Dude, snaps for that, congratulations.

[23:50] Ryan McLean: Thank you, thank you.

[23:52] Kevin Sofen: You're officially in zone coverage. I know once you go from two to three it's a big deal, but now, you know, it's just like all is lost.

[23:59] Ryan McLean: Yeah, we're not getting a lot of sleep these days. I think we probably look back at like one night in the past three months where it's like, I feel rested this morning, and that happened just last week. Anyway, back to...

[24:12] Kevin Sofen: I was gonna say, you looked really good, you know, you look refreshed and you got that daddy glow.

[24:18] Ryan McLean: Yeah, thanks, yeah. So, I think I was rounding out the TAK Server thing, but yeah, do you feel like the point is complete on open source, do you want me to?

[24:27] Kevin Sofen: Yeah, absolutely, and I think on the contrarian side, and not necessarily contrarian, but just the other side of, while open source is great, the other side is the cybersecurity threats. And you mentioned this was not necessarily something that we had to worry about from an export standpoint, but there's obviously always the concern of cyber threats. How is the TAK infrastructure developed to maintain that robust defense against these different vulnerabilities and what role does the TAK Community Center and what role does the community as a large play in this effort?

[25:02] Ryan McLean: Yeah, so the products themselves are always maintained on, like literally the source code is always by design maintained on infrastructure that the government provides, government maintains. And so when we're doing this today, employing a, I'd say a rigorous approach, a rigorous architectural approach to the cybersecurity of the environment itself where these products are maintained and so I think it would be bad practice to get into the specifics of how we're doing that, but from a general architectural approach, like you can look at the DOD DevSecOps reference design And that effectively is our playbook for how we have re-architected, kind of rebuilt the plane in flight over the past year and a half, and are now starting to realize the benefits of that approach in our production landscape, i.e. TAK.gov itself. So things like, you know, like how are we architecting our, effectively our cluster-based deployment pattern for the environment itself? How are we limiting blast radius around different services on the platform? How are we now very close to rolling out kind of a fully embedded zero trust solution. And I'll pause there as well to like, I wanna make sure people understand we're not like, we're not waving our hands and saying, boy, we hope this is a zero trust solution. We've actually put quite a bit of research into this, good practices across the Department of Defense, what zero trust actually means like going through and kind of shredding the Office of Management and Budget, the DOD CIO, documentation industry, presentations on zero trust models, zero trust solutions. And so when I say we're implementing a zero trust solution, there's a little bit of added burden to the end user, but what it provides for us is it's down to that atomic level of information transmission, the packet. The packet itself really will be very soon. Every packet you transmit and receive with the TAK platform environment, double encrypted and authorized in real time at time of transmit and receipt at the target service, whether that packet is actually authorized to be consumed by that service or transmitted back to you, whether you're an end user or a service. So I'm very confident in the approach that we've taken architecturally at an engineering level with the, we call it TAK platform 2.0. TAK platform 1.0 was really just a collection of services that we deployed as applications inside the TAK.gov domain. TAK platform 2.0 takes that to a whole new level and ensures that at a packet level, literally every packet that's transmitted and received to, from, and within the TAK.gov developer tools environment is not trusted unless it explicitly is trusted based on some very dynamic and fine-grained policies in that environment. So that's the long short story of how we're making sure that the products themselves always have the highest integrity and so then beyond that, it gets into the supply chain of the products as well. So we do have a number of third-party and open-source dependencies. We don't have any proprietary dependencies in the products, but the third-party dependencies that we do pull in, now we're starting to also investigate how can we ensure that the products themselves are, we can say they're of high integrity, not just because we're assessing them at build time, but we're also assessing their supply chains. The supply chain integrity of the TAK products is also very critical to us. It's a really complicated space because you're getting into graph theory and many different transient dependencies and it really gets down to how are you mapping those artifacts and how are you mapping the dependencies among those artifacts. I would say over the next six to 12 months, the TAK community can expect that we'll be able to provide some authoritative attestation as to the supply chain of the products as well. We've taken that on. Nobody is requiring that of us, but we know it's something that we just responsibly need to do, be able to tell people, like, hey, the supply chain for the products is not just what you're getting in your hand or on the desktop, like it's secure, but like, you know, these products are built in a trusted way, or at least we can characterize pretty faithfully any known gaps, any known kind of risks that we're maybe pushing out as well.

[29:20] Kevin Sofen: Yeah. Well, I appreciate your due diligence and comprehensive overview of that, and obviously that's an important factor for DOD, FHIR, whatever agency may be using it, but I think Some of the words you've said I've really enjoyed from the word agile to the word continuous, and I saw on the TAK 2030 Roadmap Initiative, there's the phrase TAK continuous delivery, the future of information dominance. You've kind of already alluded to some of this, but when I say TAK continuous delivery, the future of information dominance, double click into that. What do you mean by all that?

[29:55] Ryan McLean: Yeah, information dominance to us at the TAK Product Center is really simple. It's about the end user. It's not about some ethereal concept of operations. It is literally can the tactical end user make high quality decisions just a little bit faster than whatever their adversary is. And so like quite literally we, you know, in the wildland fire sense, like the public safety space is, I would say a first-class citizen in the tech world. We've seen public safety users to include wildland fire users really adopt TAK and do great things with it in a way that works for them. But if you're a firefighter, you want to be able to make decisions about that fire line just a little bit faster than that fire line is evolving or a lot faster. But if we can be a little bit faster than the wildland fire target, the fire line, or if we can be a little bit faster than let's say that enemy force, if we can have a little bit better data and make decisions a little bit faster by transmitting information a little bit faster. That is the root of information dominance. I think you heard it in a packet-level discussion. We always want to reduce that problem space down to the most atomic element possible. Because if you get any bigger than that atomic level element, whether that's the packet, whether that's the end-user in a formation, you're quickly getting into a space of complexity where it's very hard to assess, Is the change I'm making actually producing a tangible difference or a tangible improvement? So if we boil down information dominance to that atomic level where the problem can be solved, it's literally the 18-year-old with the rifle in the combat sense. And are we giving that 18-year-old with the rifle the information and the visualization really that they need to make a better decision than the adversary that they're facing in the moment when they need it? when they need it, and so that's kinda where TAK shines. But it's, in that sense, no different than that 18-year-old smoke jumper who's jumped in with their team and is trying to rapidly characterize both where their team is and where the fire line is. The problem is, at that atomic level, no different in either case.

[32:07] Kevin Sofen: And it's apparent that TAK has a lot of these use cases for more than just the soft C2 community, for more than just the DOD, Air Force, Army community, but I think there's still a lot of, oh that's TAK, that's government, that's military stuff, that's not for the fire service, that's not for law enforcement. What would you say to firefighters, fire service members, public safety, law enforcement included, about why they should maybe consider TAK and if they wanted to kind of crawl, walk, run into TAK, like how to go about even, you know, what's the first step in ground zero for that?

[32:43] Ryan McLean: Yeah, I mean the best way to learn TAK and just figure out what like, whether it's actually right for you And it may not be, if we're being totally honest here. But like the best way to learn TAK is just to use TAK. I mean, I'll tell that to anybody from, you know, the lowest ranking private in the military, or, you know, the lowest ranking guy at the firehouse, all the way up to senior officials in the department of defense, you know, senior civilians, general officers. But we've actually seen people take us up on that. Like at really senior levels, they will go grab ATAK or iTAK from the DISA app store just to learn it. That's really cool. You can see the most recent example is literally at the three-star commanding general level. I won't say specifically whom, but we got feedback. They heard about TAK and they can get it the same way that they're private and their formation can, which is through either the commercial Apple App Store or the DISA App Store, and they can just use it. They can figure out whether it's right for them, its limitations, how they need to see it evolve. But that's step one, is just get it. get your hands on it. And that's always been a strength of TAK is the model of like, don't wait for all the, like don't wait for all the compliance criteria to deploy a fully fielded and sustained solution to be met in order to get a product into somebody's hand. And like, it's the same thing you read and like the book leads startup, like get product in people's hands, even if they're going to use it to do like a real thing to like create value or the mission or whatever, just get it in their hands. They're going to give you honest feedback and you can pivot off of that. So ATAK has always kind of been a minimum viable product and I'm not sure it's ever graduated beyond that. I'm not sure it ever has to because that's kind of where our heads are always at. But we always want people to just get their hands on it and then figure out whether it's right for them. And sometimes it's not going to be. And we see that regularly, actually. It's not the right thing for them. We're like, that's cool. We're not here as the government to make a profit, we're here to keep experimenting on this model of what can we do with friendly force identification target correlation for you. And then beyond that, why would you actually want to stick with TAK? If you're on the fence between TAK and another product, I think there are a few things to consider. One is the total cost of ownership is going to be lower. I think we've seen a poor assumption been made over the years that TAK is free. And that's an erroneous assumption because you look at the total cost of ownership and you can break that down into three categories, price, cost and value. And so if you look at the price of TAK, it's actually going to be free because there's no dollar figure attached to it in the Play Store. The first place you're going to encounter the price of actually using TAK is just in the cost of the phone you're using or the laptop you're you're using which is generally you know either yours you've already paid for that some cost or some device that your unit is provided for you in which case you're not actually paying that price to get hands on the app but then maybe like TAK Server if you're paying for like you know kind of a recurring cloud bill or you're you know you're buying some you know edge compute hardware or you know on-prem hardware generally the infrastructure price associated with TAK is a sunk cost because it's typically runs on infrastructure you already have. Now, as far as the cost, there is a cost of kind of that full in solution, like, especially if you're going to like go pay for like some of the more exquisite imagery solutions nowadays, like you can get on demand imagery and it's something you can pay for, you can, you can, you know, click zip, ship it down into TAK and use it there's some kind of add ons, like if you're going to bring in, you and other new things that enable TAK, or if you're just going to equip on whole formation with it. I think you start to see the cost of TAK at not the individual level, but at the organizational level where you're going to decidedly equip a group of users with TAK. So there is a cost and it's a non-trivial cost. But I think the total cost of ownership long-term is lower just because there's no license cost for the software. That's kind of the big difference between TAK and anything else that is proprietary, maybe. There's no license cost for the software. It's owned by the government, so the bill is footed by the taxpayer. And as such, there's never going to be a license cost to the end user. By the way, if you're paying for TAK, if you're paying a license cost for TAK, you're probably doing it the wrong way, so hit us up. But anyway, yeah, that's like value, like value, again, price, cost, and value is really the value of what you get from TAK. What is TAK providing to you? And the value of TAK is best characterized as Metcalfe's Law, where Metcalfe's Law was kind of invented in, I think, the late 50s, where it says the value of a telecommunications network, this is back in kind of the AT&T, you know, Southwestern, Bell, whatever days, the value of a telecommunications network is proportional to the square of the number of connections in that network. And so, that's kind of where ATAK really makes it to money for you is where you see all those blue dots or multicolored dots called Skittles on the map. That's where ATAK becomes valuable to the unit that's using it, the organization that's using it. Because now you have all these other connections that you're not having to go maintain like ATAK, TAK Server, iTAK, WebTAK, WinTAK, whatever. They're kind of maintaining those connections for you provided some communications pathway. And now you're able to do things in a highly coordinated, shared awareness, shared understanding fashion at the edge where you're actually solving problems comes back to that 18 year old with a rifle or that 18 year old smoke jumper, they're able to make high quality decisions. So that's kind of the value part of it, but it is not free, it's free to get, it is not free to maintain because there is a cost of ownership, but overall the total cost of ownership, you know, business decision wise is going to be lower than licensed software.

[38:41] Kevin Sofen: Can I, as I was researching your LinkedIn a little bit, I saw you talking about just the total cost of ownership in different capacities, but also this terminology we use from acquiring technology versus delivering technology. And again, there's, nothing is free, granted the software license to the end user for tech is quote unquote free, it's funded somewhere else. But then there's all these other nuances, but this whole terminology between acquiring, and ultimately the point of delivering success, delivering value. Just kind of a quick riff on Ryan's point, acquiring versus delivering, why is that terminology important and how does that tie into the whole TAK user experience?

[39:24] Ryan McLean: Yeah, that's a great question because acquiring versus delivering, if you think you get a free trial license for a product today and let's say your unit finds value in it and you want to equip 12 or 2,400 other people with it's like, well, that's, that's a very fair commercial value proposition. And so that's the point at which a company would say, okay, like it's not free anymore. You found value. And so we want to charge for a valuable product, which it's fine. Like that is, that is the nature of a capitalistic society in which we live. I think the difference about TAK. is the product that you acquire and the product that you're going to be, you know, maintaining in production or kind of across your device fleet, across your group of users. The product that you have in six months or 12 months or however long with TAK, it's going to be the same product. You know, there's not that paywall, there's not that freemium model. Sure, there are like hardware components, there are API keys that you can buy for things like routing services, weather services and whatnot. But as far as like the base application, which is very capable in and of itself, there's nothing that turns off, you know, with the expiration of a license period. And so that's like, you kind of get that same standard of quality in a year or two years with TAK as you get the first day you pick it up. So it's, if anything, it gets better over that time period, but you're not actually paying for it to get better.

[40:55] Kevin Sofen: Yeah, thanks for that context and agree that there's a lot more hidden under the hood in terms of all these various costs, but also again, just in terms of what do you actually get by acquiring it, by receiving it, by after being delivered. So one other thing that I kind of wanted to end with here was you've read through this TAK 2030 roadmap, you've given a lot of good context about all things TAK, but the roadmap, I mean, it's 2024, that's six years from now. What does success look like for you, for TAK, and this initiative that you really spend a lot of time on, and maybe kind of say it in the eyes of the different users, what does success look like if TAK executes on this 2030 roadmap, and the TAK Product Center delivers on this roadmap, what does success look like?

[41:44] Ryan McLean: Success looks like every single user of TAK, whether it's in the Department of Defense, agencies, regional, state, local, public safety, law enforcement, any TAK user is always able to be on the latest release of the TAK product and have zero question that app is going to be bulletproof, is going to function reliably, is going to be better than it was the day before or the week before. We have to be a lot better at aggregating telemetry, for example, about the application about the data that comes out of TAK. Very few people in the Department of Defense or in the federal agency space have actually begun to tap into this oil field of TAK data. Nobody's actually recording. I say nobody, almost nobody, but the same argument like nobody on the collective is actually aggregating runtime telemetry data that tells us things like, hey, I noticed that these plugins are running and the frame rate is dipping 10 percent or from 60 frames per second down to 50 frames per second or lower, and that's not a configuration we're going to catch upstream at tech.gov at build time, but it's a condition that I would like to know about to make the product better. We're never going to be able to test every exhaustive plug-in configuration that is an extraordinarily complex space of not just applications, but workflows through those applications, but users know what they need and users are going to configure the devices with an E, I would like to be able to ensure that the user always has a really high-quality experience with TAK, regardless of what combination of tools and plug-ins they're using with the TAK applications. I'd say by the end of the decade, we really should be complete masters at the TAK Products Center side of how that data is being harnessed and how we're using that data, almost exactly the same way a commercial modern technology company would that is not encumbered by DoD processes would be using telemetry data from modern commercial highly utilized apps to drive improvements to those applications. It's really hard to do that in DoD today because we really have a highly bureaucratic and highly stove piped information space. In other words, I cannot really give a safe landing space today without a lot of prior agreement and due diligence and rigor to an army infantry soldier to like, hey, why don't you just pipe that data back to tech.gov? No, there's actually a really high compliance barrier that I would have to meet to be able to do that. And we're trying to figure out like, how do we do this in a way that like is within the bounds of our organization that we can promise and commit to, but also is not going to put data in an unsafe place or put it in a place where it's at risk. You want that data to really be at zero risk because you don't want that data to be compromised at some point. But then you've got to be thinking about what is the right kind of data to capture? What classification do I capture the data at? The data space of TAK is really complicated and complex. And that is kind of where I would see us specializing in a way that few DOD organizations have been able to accomplish over the remainder in the decade. We're great in DoD at meeting feature level requirements. I say great in the sense that's what we kind of exist to do, ship features that meet requirements. We're really good at designing a requirement, but man, we are terrible at aggregating data from production runtime environments and figuring out how our software products in DoD, not just TAK, but in DoD in general, are actually behaving in those production environments and making good product decisions based on that data. So to come back in six years, that's probably where we're going to be, is making product-level decisions based on the trends that we see from users using our products.

[45:44] Kevin Sofen: Well, I'd be remiss not to bring up this next question. I kind of forgot about it until you started talking about some of the challenges of capturing and transferring and synthesizing the data in different ways. And frankly, this next question could be an entire hour-long podcast itself, but in this strategy, you did mention the integration of artificial intelligence and machine learning. In some capacity, I'd love for you to riff on a little bit, how do you envision those technologies enhancing some of the different challenges and obstacles that current and future tech users will face?

[46:13] Ryan McLean: Yeah, when you set your sights on anything AI, I think it's important to be intellectually honest and ask that first question, okay, well, like, AI and, you know, That's the decision side of machine learning, which is the prediction side, which before you do either thing, you have to be really good at not just capturing data and creating good quality training sets of data, to then go train algorithms and train models. But you actually have to be really good at understanding what's in that data space itself. When we look at the data space of the average TAK user, There's a lot of well-formed, highly contextual data, and I think what we would ultimately hope TAK is doing for the end-user is obviating and eliminating a lot of those manual workflows they have to do today. AI in TAK is not sexy. AI in TAK is where can you take all these little tiny workflows that add a couple extra clicks for the end-user, and make TAK a little bit smarter so that end user, the number of clicks they have to do to achieve any common workflow, it goes down. Obviously, we need to be measuring that. It's hard to do that today. We can plan the apps for that, but getting that data all the way back to the tactical edge, maximum coverage of the user base, like I already mentioned, that's a hard problem. But that is where we see a lot of the AI, if you will, emphasis in TAK going. The artificial intelligence of TAK should be still focused on that atomic tactical end-user level, the 18-year-old with the rifle, the 18-year-old smoke jumper, the 18-year-old police officer, etc. Are we allowing them to make better decisions faster? If we're doing that, the North Star is right on. But that is where tech and AI is also pointed. But to do that, we have to get better at the data game, we have to get better at prediction, and eventually we'll get better at decision aids, which are the artificial intelligence of tech. Now I will say, we've also gotten some pretty cool steep peaks. So we took a few of our engineers and partners in our ecosystem out to what's called the Bravo Hackathon 1.1 or 3. Get it out of the way, binary language. So this hackathon was amazing. It was 600 US citizens from across the DOD, federal agencies, and even just people not affiliated with the DOE at all. It was hosted by the DOD Chief Digital and Artificial Intelligence Office, the CDAO, and we went out to Hawaii actually because that's where a lot of the kind of the U.S. kind of great power competition preparation is going on. So we went out to Schofield Barracks and hosted this wonderful event and there were some tech players there and we saw some really awesome innovations come to light around large language models and TAK. And there's a long way to go before these things are truly viable to the end user. But I think what we're starting to see is LLMs or large language models, you know, they're kind of the very early stages of an artificial general intelligence. Like the plumbing is already there to take advantage of these things in TAK. And what I mean by that is very specific. If you go into the contacts tool in TAK, if you go into the contacts tool in TAK and see what's there. It's a list of skittles. It's contacts on your TAK network, people that you can chat with. The innovation there was very simple. Let's put a plug-in on TAK server such that the LLM, regardless of what that LLM is using the chatgpt API's, let's just make the LLM a con- on your TAK network. Think of how amazing that is to the average user on the TAK network. If you think like kind of a year down the road, assuming some sustained investment, being able to chat with another contact using the exact same muscle memory that you have today as a TAK user to chat with somebody else on your network. Of course, you say, well, that's cool like if I can chat with somebody, but like what's that actually doing for me? Well, the obvious extension of that is what richness can we bring to the exchange of that information between the TAK user through the contacts API and a large language model, potentially an artificial general intelligence in the future what can that thing do for me? What can that entity do for me on my map? Can that thing, can that entity start giving TAK information that can instantaneously be plotted on my map? Can it predict things on my, sorry Kevin.

[50:55] Kevin Sofen: No worries. It's staying in. That's part of it's part of the authenticity.

[50:59] Ryan McLean: Okay. All right. Fair enough. I mean, yeah, that's authentic. Yeah. So, like, can we make the artificial intelligence package in whatever form? Can we make it start to behave as part of the TAK network? You know, going back to that Metcalfe law, can we make connections that go to that LLM part of the value proposition of Metcalfe law? We can improve the value of the TAK network through artificial intelligence now, where artificial intelligence is doing what we expect it to do, create actionable information for the human being, but where you're accelerating the ability of that human being to make decisions.

[51:36] Kevin Sofen: Well, Seb, I heard a fellow colleague of mine, Bart van Leeuwen from Amsterdam, he's been sort of involved in artificial intelligence way before it was called artificial intelligence. You had a phrase the other day that said, The road to AI goes through IA, through information architecture, and if we don't understand how we are doing the simple tasks before we try and offload the tasks or the cognition to AI, we're wrongly mistaken in terms of how we are going to use AI to solve our problems, but I liked how you phrased it as that really if AI can help us save a little bit of time, if AI can help us offload some of these basic task, it can automate certain aspects of the workflow. Great uses of AI, but assuming that AI or machine learning, all these fancy buzzwords that you see across the internet, it's a slippery slope. So I'm excited to see you and the other roadmap come to life, and I think the one thing I wanted to touch on before we finish off here is the TAK events, the TAK offsite events. I know I've seen a lot of buzz in social media when those happen. I know there's one coming up in July. Could you touch on this quickly? What is it? these events and why should people consider attending?

[52:45] Ryan McLean: Yeah, the TAK offsite is an annual event that we host. We've hosted it since, I want to say 2011 or 2012 was the first one. Started off as a couple dozen people in a room talking about where we wanted to go, what different programs we're doing with TAK across the federal government and the DOD. And it's grown to this large-scale event, 600 people. That's kind of what we budget for nowadays. Hosted in a big conference room, big ballroom typically a hotel. The TAK Offsite is meant to be a government-focused event where federal government entities are sharing information about what they're doing. It is a highly collaborative event where, you know, I guess you can call it kind of a, you know, kind of a full contact event. Like, people are doing a lot of networking there. They're hearing about things like, oh man, I didn't know that was going on in that program office. And so, you see a lot of connective tissue form. You see programs strike up relationships with each other that didn't have relationships. So it is the 9th, 10th, and 11th of July this year, the Denver-West Marriott. I think registration will open up fairly soon. We give first priority to our bill payers, the TAK configuration steering board members. And then we kind of gradually open that up to the federal government, to partners across the state and local government spaces. And then as we have space available to the general public, U.S. persons. But people should expect government programs to be talking about government things that are going on. I think that's just part of the signature of TAK is it's always very emphatically led by the U.S. government. We think that's very important for the U.S. government to be seen as leading this movement and that we're not simply creating a requirement and a contract and outsourcing it to an industry partner. We're very intent on continuing to lead the TAK movement from the U.S. government side to that, it's very easy for people to fall in on us and say, you know, we're doing this, keep up and we'll make the product better together. That's what the TAK Offsite is. And then we also hold cadences throughout the year to plan kind of the next release of product. But those are, those are typically smaller events with a fairly small audience. So yeah, TAK Offsite 9, 10, 11, July 2024 in Denver. And we are really excited about this one. So go to tak.gov slash events

[55:04] Kevin Sofen: for more information. Yeah, that'll all be in the show notes. And I hope to someday make it to one of these TAK offsites. I think, Ryan, if you have other people that you think are some of these TAK advocates, TAK ambassadors, TAK enthusiasts that are leading TAK, I'd love the opportunity to talk to them in a virtual setting or at some upcoming trade shows. So pass that along. And I guess if So if it closes out here, I'd love any sort of final mic drop of sorts, you know, any sort of, or if you have a quote or a question or a challenge that you could leave us with here today, what would that be?

[55:37] Ryan McLean: Yeah, let me think on that for a second.

[55:40] Kevin Sofen: I mean, I just threw a total monkey wrench at you.

[55:43] Ryan McLean: No, it's cool. It's cool.

[55:45] Kevin Sofen: But you've been handling it pretty well with kids running by you, so it sounds like you can handle it.

[55:47] Ryan McLean: Well, I'll go back to the data problem. The place where we need the community's help is in understanding the data and how the data should be used. I would love to be able to, for example, publish Jupyter Notebooks on our GitHub project, fully open source that just allow people to start drawing simple conclusions from the data. If you're listening to this and you have a penchant for data, for taking the really good contextual databases, config files, etc, that are just naturally pumped out at runtime. We need your help. We need your help exploring that data space. That is a really great open space for open source contributions in the TAK world today. Help us understand what matters in the data from the end-user perspective so that we can start bringing those data-driven conclusions into the TAK products. And Kevin, that's a really tactical level ask, actually. I have no grand, ethereal encouragement to offer people because people are just innovating so rapidly across the tech space today. I don't think people need that encouragement from me. I think if anything, a problem statement is really helpful, which is we need help with understanding how to open source the data space across the tech ecosystem.

[57:13] Kevin Sofen: Right on. Well, I'll make sure we chop that up and continue to spotlight and amplify that message because you're doing a great job as a tip of the spear here, leading the TAK Product Center. And frankly, I'm excited to help create some other ripple effects here to amplify all these voices. And shout out to some of those other, the first person who got me on the TAK, AJ Johansson out in Corona. He was a, you know, TAK is the way. Mr. TAK, you know, kudos to you were the first one that got me on thinking in TAK. And I also know that another gentleman, Ken Rehbehn, who's really involved with it and other colleague, Alex Gorsuch, who's really been the pioneer. So I thank you to all of them and leading me to you, man. So it was really an insightful conversation and I look forward to just continue to build and support and empower the entire TAK community and especially the TAK community within the public safety and in fire service community.

[58:04] Ryan McLean: Indeed. Well, thanks so much, Kevin. This was just a lot of fun being able to talk about this stuff. And you asked great questions, so well done, sir.

[58:11] Kevin Sofen: Thank you very much. Well, I look forward to the next time we cross paths And until next time, have a good one.

[58:15] Ryan McLean: All right, cheers.

[58:16] Kevin Sofen: See you. Thank you so much for listening to the Smart Firefighting podcast today. If you enjoyed what you heard and got any value, please drop us a rating, leave us a comment, or reach out to us on social media. Have a great day, and together, we can advance the future of smart firefighting.