Thank you for joining us today on the OpenStack Thunderdome. Now, for those of you who don't understand why this is a Thunderdome, we have here a cast of very shady OpenStack characters who want you to believe that what they're doing is the best way to do it and to give them your money. So, as I just briefly mentioned, the rules are that they cannot hit each other below the belt. If you do say an F-bomb, the foundation might have something to say about it, but you all have board seats, so that's not down to me. I'm just here to moderate this panel. So, we have Christopher McGown, Chris Kemp, we have Jesse from Bluebox, and then we have Alex Friedland, and we have Randy Byers. So, Jesse is basically the only one that really doesn't, I guess, can't contribute personally code to the foundation, but everyone else here is very, yeah, there's no ATC. I had six reviews, doing my part. What is code, actually? Wow, Jesse, did you outsource the Mirantis for the six reviews? Yes. All right, so. Is that possible? It's all the same, oh yeah, Mirantis code. So long as I don't have to write it, it's possible, yes. All right, so, my first question to this Motley crew is, how is your product distributed and why?  So, can we all agree that it's Randy's? Sorry, Randy. But Randy is now EMC's. Yeah, it's now EMC's, so. Good luck. So, for the first question, I think I'm gonna pick on Kemp.  So, we've done this because OpenStack is frankly very complicated. And Nova has eight or 900 config options you can set when you run it. And if you try to do this yourself, you'll end up having to hire a bunch of people who really know what they're doing, and then they'll need training from Mirantis and consultants from Mirantis. And pretty soon, you have months of work you put into a very custom OpenStack, and then it doesn't work with anything else.  If you just wanna turn something on and have it work and be as close to Amazon, where you pull out a credit card and you just start using it, we think we've got the best approach. So why is one of these? Where, Jesse, you gotta wait. Why is one of these? Stop on that. Yes, stop. So why is one of these other people's distribution wrong or shit, and why do you believe that? And then that person will then get the mic to be able to talk about what they really do and defend it and move on from there. Well, I think that knobs are useful if you wanna customize your deployment. And so I think we've got some great software which has some knobs. If you really wanna go all in and you're eBay or PayPal or a telco, you might wanna have hundreds of consultants and engineers working on it, and so we've got some people here that do that. And then Jesse hosts it. And so if you don't wanna own your own hardware and you don't wanna do anything, it's a good model. I don't know what Randy does, other than keynote conferences and go to Asia a lot. So I would say Randy. Well, apparently I have the world's largest retailer with a 22 rack proof of concept on 2,000 cores that's gonna grow to about 60,000 cores in the next several years. So as far as I can tell, what I do is I build the world's best production grade open stack systems that have ever been produced. Okay, fair enough, but. Excuse me. How does it ship? Excuse me, can you guys introduce yourselves? No. I have no idea who works for who. So that would help. Christopher McGown is founder and CTO at Piston. So they have their distribution. And Chris Kemper is with Nebula, their distribution. I believe he likes to be called Chris C. Kemp now. Ah, lovely. And unfortunately the first slide that would have had all the detail was a little bit wonky. It worked on the slide, but when we actually played it, it looked like this. Oh no. Oh yeah? Yeah, kinda messed up. And that's why we didn't actually get to show it. Jesse is a co-founder and CTO of Bluebox, which actually does hosted open stack. And then we have Alex Friedland, co-founder of NCEO of Morantis, which is services, subscription and also training of open stack. And then we have Randy of Cloud Scaling that was acquired by EMC. And you just heard that he's the one that's the only production grade distribution of open stack. And so you were going to, how awesome your stuff was and why someone else's was pants and who was pants. Also how it's delivered? So the way it's delivered is that we do an over the wire installation of the initial boot box. And then that box is the center of the control plane. And it bootstraps all the rest of the boxes basically with Pixie. So it's very similar to the way Nebula basically works except instead of putting our appliance in we bootstrap the first box by hand which then bootstraps the rest of the cloud. Why is yours better than say Pistons? Well, some of this is relative, okay? So I think that Pistons is a solution that's appropriate for certain kinds of things but I'm not going to pick on them today. I'll explain why in a second. And, but why I think that ours is better is that we spent a lot of time trying to not use pieces of OpenStack and methodologies of OpenStack that were fundamentally broken.  And if you use Neutron, you're almost certainly not gonna have a scalable network. So we do something else. We have our own layer three networking model that plugs into Nova networking and it scales very, very well. We've never had a problem with it. It's totally bulletproof. It's very high performance. You get maximum East West performance. And so as far as I know we have one of the few OpenStack distributions that actually has a very high performance network, right? It doesn't use the crazy Nova network single host, multi-host BS that was made by somebody who doesn't understand networking at all.  It's that every SDN on the planet is even worse. There is absolutely truth to what McGowan just said. I agree with that. But you don't strictly speaking have to use Neutron with an SDN. And unfortunately, the problem is, is that if you try to do networking as a service, like there's 20, 30 years of networking gear. You're gonna stick that all under a single API and a monolithic architecture. I mean, think about it. That's a fool's errand. But anyway, getting back to it. And then the second thing that we did is that we were the first to build a scale out control plane. So what most everybody else did is they did HA failovers. You had active passive on all the open stack services and your services. And then they did master election systems, which Piston and Nebula do, where you've only got one instance of a service for any time, but when it fails, you can re-instantiate it somewhere else. And we thought that didn't make any sense because then the control plane has to scale up. You have to make bigger boxes out of the control plane because if you run out of oomph on the APIs, that's your only option. So we built active, active, active, active, active. So we've tested it up to seven for this retailer. And we know we can get up to 30 theoretically.  Okay, so it's your turn, Christopher. Oh, I didn't get to say a bad thing. Touché. So I have a bad habit of running people over and I've tried to train myself out of that for the last seven years. So I'm not gonna, I'm gonna pick on the person that I like the most on the panel because I know that they won't like punch me later. So, Alex. I just wanna say that the main problem with the Miranda's distribution, other than the fact that they're a fantastic group of guys, is that the idea that there's zero lock-in is selling snake oil. Because there are pieces of OpenStack that are fundamentally worthless without plugging something in that creates lock-in. So if you get Cinder, you don't get block storage. Okay, yes, you can carve block device out of LVM on a KVM hypervisor. Nobody thinks that's block storage, right? Okay, that's why they're all using Seth, right? So the thing is, is that there's always lock-in in OpenStack and when you market it as there being no lock-in or the zero lock-in pure place solution, you're simply selling your customers bullshit and because they want that thing to exist and they're buying it, it sort of is a little bit misleading. Gosh. I have to respond now, right? Yes, you do. So the beauty of my position here is that I didn't understand the single word that any one of those guys said. Because I have no idea what networking actually means inside and the only thing I know is that OpenStack is good and we figured out this earlier. So we called Randy and said, Randy, do you have a project for us? And that's how we started in this business. Oh, you heard that. It's official now, yes. Randy is the father of, well, in some ways, Mirantis, yes. And so since we never understood what it really was, we just went to customers and said, we will figure it out with you together and we did that with about 135, is the last I could tell. And the distribution we built, we just took the information we learned from those customers and packaged it into a distribution and then we distributed basically for free. And so last I checked, we had 10,000 downloads this year and it's probably not a good distribution because of all the reasons that Randy suggested, but we have probably 20 customers in production with thousands of VMs. I think one was actually a keynote today. And some big telcos have announced that they're, like Ericsson announced that they're gonna use it and are using it to go to all of their telco customers. So I'm not sure how it happened because I'm not technical, but I guess these guys are right. So you can pick on Christopher then. Christopher, why is my bad? I'm used to picking on Josh. I actually have a thicker skin than he does. You do. So let's explain. So Josh McKenzie was co-founder with Christopher Episton and he's now gone to be field CTO at Pivotal Labs and that's why he's not here. So I've heard that you have a wonderful distribution because you have brilliant engineers and you've completely reinvented OpenStack. It's much better now, but it exists only in Episton box. Is that true? Not really. We have really intelligent engineers. So I'm the CTO Episton. Our product is actually a software platform that deploys cloud applications that we just happened to use to deploy OpenStack because that was the first thing we did. We were among the founders of OpenStack. Joshua was there with Chris Kemp at Nebula, the NASA Nebula project before even it was nascent at Rackspace that we were gonna do a thing. I was at Slicehost and when we kicked off the Austin summit in Austin, surprisingly, OpenStack isn't really good with naming if you haven't noticed. We were there. And we deploy our product via the internet. We download an image. You install it on a USB stick. You install that. It becomes a boot node very similar to Randy's where that ends up being the node that discovers other nodes automatically and then deploys via netboot, via pixie, hardened Linux distribution. And where we go different is not that we use master election to elect a single point. We use master election and our orchestration engine that is not in OpenStack to deploy all of the services everywhere. So we have a converged model where storage and compute and networking are all on the same hosts. And in so doing, we master elect only critical services. So things like the database need to be critical to the cloud. There needs to be one of them or there needs to be a cluster of them that deals with replication and insight. I have a question. Yes. If an attacker breaches one of the VMs and gets access to the underlying storage or breaches through the APIs and get access to underlying storage, does that mean that they can read the data of all of the VMs and the OpenStack database and the messaging cues? Not currently. We're using C groups to avoid that. If they reach all the way into the actual host metal and they're actually able to see the stuff data stored, does that mean that they can see all of the data? If they can see all of the data, if they get to the point where they can see all of the data, yes, they can see all of the data. Right, so the hyperconverged is effectively, you've squashed the control plane and the data plane together, so there's no separation. So if somebody wants to draw a line around it, put like a firewall between it, they can't do that, right? If I walk into your data center and walk out with your controller server, can I see the data? No, you would not be able to see any of the object storage data, you would not be able to see any of the block storage data, you would not be able to see any of the VMs because the control plane's in a physically separate rack. And it's isolated in the network. So we're doing software firewalling between the two networks, we prevent all customers, we have actually a VLAN segregation for the customer workloads, but if the customer or an attacker were to break out onto the bare metal, they would be able to access the things that they could access. So I'm enjoying this discussion. There's this whole book called the Opens Tax Security Guide, which we wrote and everything that it recommends you do, we've done, including everything these guys are talking about. In fact, when you have hardware, you can actually take advantage of the TPM support on the motherboards of the servers. We actually have a hardware chip that generates random numbers so that encryption actually works in a cloud the way it should, and you can do all sorts of things with key management, storing encryption keys on the hardware. If you take an approach where you plug it in, you turn it on and it works, you can make all these decisions and you don't have to have all these debates. Frankly, it's really important at this stage of the market where Opens Tax is so complicated. So we also have TPM support. We are actually shipping that in production. There was this small telecommunications company. I actually wasn't at the keynote so I have no idea if he actually spoke, but Marcus was gone, they're actually running TPM with Mount Wilson. All right, boring, boring, boring, my turn. Wait, wait, wait, do I have to say that your product is bad?  Oh, perfect, well let me educate you. Let me educate you on the right way to consume Opens Tax. So, Blue Box delivers private cloud as a service. That means each customer gets a single tenant Opens Tax installation that is deployed on Blue Box hardware in our data centers. It allows us to deploy the implementation today in three business days. By the end of the year, we should be within an hour. We handle all of the operations of the data center of the hardware footprint of Opens Tax itself, leaving our users to benefit from working with Opens Tax, not on Opens Tax. So, my good friend, Chris C. Kemp here, suggested that if you want to be like Amazon, you should use his product. Except the entire point of being like Amazon is that you're not buying a proprietary piece of hardware and locking yourself into something on premise. We're able to deliver private cloud that just works in a data center without hardware that you have to deal with without a proprietary box. So, Blue Box is like all of the downsides of public cloud with all the downsides of Opens Tax. No, it's all the positives of public cloud with all the positives of Opens Tax. And I don't know about you, Jesse, but I personally do have a credit card with a $100,000 credit limit, so I can just... Oh, perfect. Perfect, you should be buying his boxes all day long. Okay, wait, wait, wait. So, this leads on very nicely to who is your target customer? I'm gonna start there too. So, there are like 100 customers, the Fortune 100, that are perfect for Randy and for Alex. There are, I don't know who buys these things, but for everybody else in the marketplace, you've got Blue Box Cloud. We're private cloud for SMEs in the middle market. It's for those, again, who want the benefits of private cloud. You want data sovereignty, who want control of the platform, who want control of cost, but who do want those benefits of public cloud, OPEX, elasticity, time to market, open APIs. And so, we found that this was the best model to deliver a product that really was targeted towards that middle market customer base. We're selling to enterprises that are trying to transform themselves from being traditional IT into web and cloud developers and also to service providers who are focusing on that sort of market internal app development. And we're a private cloud vendor, not a public cloud vendor. So, some of the concerns from a security perspective, because they're building apps internally, aren't yet a problem for our customers. And Chris, Keb? We're really focused on Fortune 1000, but not the top 50. So, we're focused on companies that are probably using a lot of Amazon web services. So, our customers are some of the largest, the largest biotech companies in the world, the largest movie studios, the largest entertainment and web properties. Almost all the national labs use our systems. NASA JPL, these are all production, like paid customers. And so, they're folks that are not at this event. Our customers don't come to these events because they don't care about OpenStack, the details, they don't care about the implementation. They just want to have a private cloud and they want it to be reliable, secure, and they don't want to hire a single person to build it, manage it, or operate it. They just want it to be an appliance. So, I'll piggyback of the piston story. So, we sell to customers who actually transform themselves. The trying part will have to remove. So, as a result, there are kind of two tiers. The one are the upper tier of those who are actually doing it. So, we have the top 10 of the top 150 telcos. We have top 10 of the top 100 enterprises. We have top 10 of the top 50 web 2.0 companies and kind of goes across the board. And then, we also have a lot of customers who are doing it yourself for types. And a lot of those are just interested in OpenStack. They go, excuse me, they download our distro and they just work with it and we give them free support. And they call it and say, we actually love it and how much is it? And they'll go, so much and great, here's a PO. So, we kind of, you know, go for it. To interject, that actually isn't DIY, it's DI5KR. That's do it with 5,000 Russians? Nah, it'd be nice. Yeah, but no, the 5,000 Russians is the top 10 there. That's where they go. The DIY is actually, you do it yourself to the point where no Russians are involved, except on the support with an accent. But that works very well because we measure it every time with the customer satisfaction index and whatever and it's actually quite high even with an accent. But there we're measured by how many Russians were not involved in selling a PO and we're doing quite well there. I have an extra one for you, Randy. How are things going to be changing now that you're part of EMC with your target customer? They're not changing with the target customer. The delivery model will change, the target customer hasn't changed. And, you know, how many people have heard of Pets vs. Cattle? That's sort of cloud mean. Okay, great. So we like to sell to enterprises that understand that they want to get a cattle cloud, that they want that Amazon style experience because they're adopting DevOps and they're working on next generation cloud native applications. And if they're really focused on trying to make their data center cheaper or get rid of VMware and have a lower cost VMware, that's not really a good fit for us.  We just want you to turn on the tap and for it to come out and as much as you need to use and then you don't really think about it. You think, you know, more about the applications that are running on top of it. That's really our focus. And, you know, EMC is really interesting.  But it's turned. How about two months ago? Two months ago, it was starting to change. But that, we were talking a lot to them a lot more then. And the thing is, is that what's been very clear is that they really believe in the world is changing. If you look at, we've got a product deck that we show our customers and I've got source data from EMC and they've actually been using for about a year that shows that the net new applications, the more cloud native applications are growing at 10x the rate of the legacy applications. And, you know, that, I love that. You know, that's where I want to be, right? I don't want to fight on the hill with VMware because they own that hill. I'm just going to get tore up going up. But I want to fight on a new hill where I can be king. You know, Amazon's king in public, but nobody's really king in private. And so I generally think that's what OpenStack should be doing. That's where we focus and that's where EMC wants us to focus because EMC still, you know, VMware's part of the Federation still has a place, you know, and is there and we want to continue to make them successful but we think they're good for one thing and we think that OpenStack running on EMC gear is good for another thing. Okay, so that brings us to the next one. Then I'll start with you, Randy. Is OpenStack's velocity a help or a hindrance? Obviously it's helped you with the company being acquired but is it a help or a hindrance for your customers? The height velocity or the code velocity? Pick one. The height velocity is very helpful and continues to be helpful. I'm not sure that the code velocity is, it seems to be decreasing pretty dramatically, especially in the core projects and we're seeing it be slowing down, innovation rate slowing down. I think that we are sort of jammed up because we are under the illusion that we're gonna fix certain very broken parts like I named Neutron earlier. I'm gonna try not to name any more so I don't get nasty emails and phone calls from PTLs. But we need a- There's 22 of them now so you- If I can figure out who it is when they call me. So I think that the velocity of the code is in some ways it's slowing down is actually starting to be a help but that's only because I think people's eyes are opening. I don't know if people probably weren't here for the board meeting yesterday but in case you missed it, the technical committee came to the board and they said we finally get that there should be competitive projects. Like there can be more than one block storage solution, more than one object, more than one compute maybe even and we want your help to figure out how to make that a reality in the community and that's been a pet peeve of mine for a while because what happens is somebody implements a very broken solution and nobody else can create an alternative to it because it's not the blessed special version and sometimes if you're a good startup or you're a good software development team you build something, you realize you built it wrong and you just want to throw it all away, start again, take all the learning because the learning matters, not the goddamn code. I do not know what it is about developers who are so attached to the code, like code is easily rewritten. What's most important is architecture and the learning that you have that actually makes the system work. Do you think that the foundation is going to be able to represent even more innovation or more contributions that are coming in? Yeah, I mean, I think if we have a monolithic system where there's only one project in each bucket compute object block and all of those have to be integrated together tightly every six months, then that fundamentally falls over when you're nine, 10, 11, 25, 30 projects, right? I mean, it was good at two, it's a terrible idea now. If we act more like the Apache Software Foundation and we have a whole bunch of projects that are all interrelated that can be put together in various ways and there are groupings that we test and validate on some kind of cycle, then it's going to make a lot more sense and each of those teams can operate at different speeds. Right now we operate at one speed altogether and it's very tough. Technically we operate at one speed and then one of these things is not like the other speed. Swift refuses thus far to adhere to the every six months release cycle and it's actually been very good for Swift but for OpenStack as a cohesive unit, it does a lot of its things its own way and refuses to join the community. Yeah, but that cohesive unit is going away. Yes. That's what the TC just said, so. Yeah. Well, so let me. While at the same time, still enshrining Swift as the paragon of what everything should be doing. I don't think so. No, no, that's a bad. So let me add my two cents because we took the baton from Chris and Nebula who were a huge authors of OpenStack originally but now of this esteemed panel. Mirantis has actually moved as a number three contributor. We had 92 people contributing to OpenStack in the latest in June release. And if you look at Stackforge, we're by far number one with like 150 people and all of the innovation and some of the scandals that we've talked about actually got started by who here knows what rally is, project rally. Quite a number of hands. So we started rally because we figured that performance of OpenStack was not something that was up to the par. And also it was very, very difficult to convince people to fix problems in multiple projects at the same time. So we started rally as a project to kind of drive that. And as a result, then you could have, you know, built a use case that shows performance across the board and you could diagnose it to seven patches in three different projects. And you can do them as bugs and fix them as bugs without necessarily having to coordinate that. So that became extremely popular. Lots of people are using it. And when we try to incubate it, it got stuck with it's not your agenda, it's mine and I'm not gonna let you. And that's what caused this whole incarnation. I mean, that consternation. And that's why we're changing the governance. But going back to the original project question, I think the speed of innovation inside OpenStack and this code velocity is actually unbelievably fast. I happen to disagree with Randy here. Slowing down. You get to easily believe that. Slowing down. Maybe, but it depends how you measure it. I mean, there is a lot of feature innovation and there is a huge movement of OpenStack now into things that it hasn't been conceived to do. It goes away from just being IIS. And OpenStack is becoming a full stack slowly and the movement is starting up the stack with projects around it into the operational areas and the like. So not to disagree there, but OpenStack has always toyed with becoming a pass. Like at the very first summit, there was a guy, Eric Day, who was an employee of Rackspace who had built a queue as a service project and couldn't get people to get involved yet because it wasn't ready. So OpenStack has never been, oh, it's just the IIS. It has been we toy with the idea of becoming a platform as a service. It was originally conceived as being a platform as a service at NASA Nebula. And the fact that projects are proliferating in such a way that, wow, that's really hard to say. You want to jump in? All right. I want to just violently disagree with all of you and especially Randy. Safe harbor. I talked to Jesse. I must be doing something right. How many of you guys get the emails from Amazon about all the new services that they're offering, all the new Amazon AWS stuff, right? I get those. They're already a platform as a service. Yes, they're already a whole bunch of things and OpenStack is not. And so it really frustrates me when we talk about how we need three or four different competitive object stores or compute engines or when we can't even come close to keeping up with the innovation of Amazon. Amazon has figured this out. They have one platform, one system that they deploy at extreme scale. No, that's not true, actually. Chris, Chris.  Chris Brown, who was on my advisory board for four years, was lead developer for EC2. Out of everybody here, I have both insight into how Amazon works. And the way that Amazon works is that there are a bunch of independent teams that work on each of the different projects. Many times these projects are competitive with each other. Anybody remember SimpleDB, which was replaced by DynamoDB, right? And you can store your objects in DynamoDB if you really want to and it's based off of SSD. So actually, there's a high level overlap and there's a huge amount of innovation from Amazon and Google, because all the different project teams actually all innovate in different, they're not in lockstep, they all go at different rates and they're all doing their own things and they're very independent. So mostly coupled system. And so in aggregate, they get more throughput. You're missing my point. Millions of Amazon customers all use the same DynamoDB. They use the same S3, they use the same EC2. There might be different compute clusters around the world. Every OpenStack customer builds their own highly bespoke OpenStack cloud with a whole bunch of different decisions about the hardware they run it on. And that's great for a consulting business. I mean, having competing projects doesn't necessarily make that problem worse. Well, wait a minute though. So this is from an outsider who's not on the board or anything else. Do you know what I see? I see a lot of boys, and I know that they're go-coders too. I'm not disagreeing, but I see a lot of arguing about, my project is better and why, and most of the people who are contributing these codes and actually trying to make all these features have no ops experience at all. They've never run it. They've never run it and most of the people who are sitting in this room want to be able to run this stuff. Well, you guys treat it as a science project and as a frat house. People here actually have businesses to run on it. So, which of you actually solved that problem? So, you buy a box, you plug it in, it works. Or you buy ours as a service and it works.  OpenStack has what, 22, and official projects, right? And what did we hear at the keynotes yesterday? We heard over and over and over, stability, stability, stability. So, we've got this problem. We can't keep up, we presently can't keep up with Amazon's innovation, yet the core of the project is being rotting to some extent from a stability perspective because of these integrated releases. It's an interesting challenge. The other piece here that's fascinating is you've got sort of this marketing machine that is these releases and so every six months this new release drops and that means that every six months, customers will come and they'll say, are we running the latest thing? Because we read about it. When in reality, the latest thing may not have bits or pieces that you actually need in the environment. And so you've got this interesting duality between tracking that latest thing and all of us need to take that latest code and integrate it and make sure it works with whatever product we're delivering. But the benefit of whatever is in that release may not even be necessary. So, it's quite the six month release schedule is quite the challenge and it'll be interesting to see the way SWIFT does it if we can move to that model and we have competing projects. I think that will allow people that operate OpenStack to pick the best project that actually works, put the flag and the weight of each of our engineering teams behind that particular project and theoretically get more like Amazon in the way that they develop internally and thus hopefully get closer to the number of services that Amazon has. I also think we've got a little bit of identity crisis. Like, PaaS in OpenStack is the worst idea I can possibly imagine. We've got Cloud Foundry for PaaS. Let's focus on making a stable platform that something like Cloud Foundry can operate on. And PaaS is a particular one because you're talking about something that's designed to do a multi-cloud abstraction. And so, this actually- We had a boxing match on that before, right? We did, which was fun. We're still surviving. The good thing is that actually this whole thing is leading very well into the next section because we talk about the flexibility and the complexity because there's so many different projects and they're all competing and everything else, right? So, what you had mentioned earlier was you guys have dealt with a lot of the customers with the early Godfather of OpenStack Cloud Scaling over there. To help you with looking at customers and their operational problems and things like that. And to Jesse's point, six-month projects, let's look at, let's talk about Xerox. They spoke at Santa Clara last year when we had the OpenStack for the Enterprise forum. And they would, up on stage, loads and loads and loads of nodes, but they were very happy running on Folsom. Now, there's a lot of us in this room who would not want to run Folsom in a production environment, but you had Xerox who did. So, okay, they're running in every other. So, but the question is, there are some people that don't want to move up with those releases. So, what happens when it goes out of life? How do you know when to choose and what has helped with driving your decision for your distribution? For us? Well, first of all, just to give people an idea, today an average install that just does, standard customer takes under a day. I mean, in a normal environment, you have to do documentation and then things and training and all that, but OpenStack got to the point, speaking of, it's four years old and a normal customer on heterogeneous environment can get it up in one day and sometimes they can do it themselves. And the beauty of this is we don't want to be opinionated. I think the challenge that some of the early players in OpenStack ecosystem is they thought that they knew better than customers what customers wanted. And ultimately, we don't have a good idea of what the usage patterns are for OpenStack today. Going back, we kind of figured this out, but we have no idea how OpenStack is gonna be used and why going forward because ultimately, it's becoming a commoditized operating system for the new transition of a cloud and it will become a totally ubiquitous solution that can become an embedded solution for appliances, it can become a driver for somebody's loads in a different, as a service model and there are only so many people who can do what Amazon is doing and Google is doing for themselves so there needs to be an alternative that will drive all of that. So what we said is we're gonna listen to customers, we're gonna create a configurable option that even a not very sophisticated customer can use and then we're gonna embed it to people who are just gonna pull it through for whatever applications. And then eventually, we will make sure it can be upgraded, but if you don't want to upgrade it, you won't. That's life, right? And some people just not gonna upgrade, but then the danger you have if people don't upgrade to the latest version is eventually the stuff is end of life and support of it is gonna be a problem. So we have plenty of customers who kind of went that route and built franking clouds and it's working fine. But the problem with the franking cloud is that the cost of supporting a franking cloud is just gonna increase over time, right? And so if they wanna have the financial equation of supporting their own franking clouds, well, more power to them, but that's not where the business model is going. It's like a good business model though. Not really. For the 5,000 Russians? You know, we certainly couldn't raise the money we have raised if that would have been the thing because that doesn't scale, right? And the only reason we're able to raise money and continue to do this is because there is scale in the business model we're going after and the market is becoming vast. And if you ask my opinion as to where this is gonna go, I'll tell you, I have no idea because what we're learning every day by talking to customers is they have thought of ways of using OpenStack that I haven't envisioned even a month ago. And by the way, they downloaded my stuff and they configured it somehow and they told me what they did. And the marketing folks over there are like, oh my God, we have to build a use case. We had no ideas possible. So that's where I think it's interesting about this market. So there are tons of customers like that, yet there's a whole nother set of customers that say I just want the benefits of a cloud infrastructure with the security and compliance that comes with private cloud. And so what I really like about this panel, quite frankly, is we've got such a diverse set of options of how you can consume OpenStack, which is unique, it's unique to this technology offering. And so we've got something that works from whomever is looking to purchase it and that's really important. I think I'll say I once said that OpenStack was like the Linux of the cloud and no one runs Linux, people buy Macs, right? 98% of the computers run Windows, for God's sake. I mean, I think it's a powerful platform. A lot of people power a lot of things with Linux and a lot of people will build really amazing things with OpenStack. But I think if you want a cloud computer, if you want to really democratize this technology and have every company, every enterprise, it's gotta get really simple. It's gotta be simple enough for people here in Europe to sell it and install it and use it. And you've gotta go into work in the morning and log in to your email, which is gonna be a SaaS application and then log into a cloud and build things and design things and prototype things and render things and sequence genomes or whatever you do with it. And I kind of agree with Chris Kump here. I'm surprised to say, I was like, wow, we agree with each other. I'm actually, yeah. I kind of disagree with Alex. I think that the OpenStack distributions, the OpenStack products, we should be extremely, extremely opinionated. The fact that we're not opinionated has led to a proliferation of all of these projects, a proliferation of all of these competing drivers in the projects, none of whom have any sort of like mutual, they're overly complex. They don't share similar capabilities. You get an SDN in Neutron that does one thing and another that does another and they don't implement the basic, like I want an IP address or I want a port on this network. And very similarly, though not as bad for Cinder, I would actually go so far as to say we should throw Zen out of Nova, which is kind of heretical since Rackspace runs Zen, but they're the people who are building it. They shouldn't exist. You wanted to add something before I move to the next one? Yeah, I mean, actually there was a whole bunch of stuff queued up there. I'm gonna try to just pick one response. Do people remember IPsec and IPsec VPNs in the late 90s? Yes, absolutely.  Yeah. All right, and still sometimes doesn't. That is an example of why having the same software and having the same standards doesn't actually necessarily get you anywhere. What's really important is to test behavior and to be able to know that you've got the same set of features, functions and capabilities. That's why Defcore and RefStack and TepisTest are so important.  And once you do that, then you can have guarantees that every OpenStack cloud is not a snowflake. Now this gets to a fundamental problem, which is when people wanna DIY or when they're building their products, whether any of us up here are right or wrong, they make choices about the architecture and those choices fundamentally impact the behavior. So I'll give you some examples. If you turn on a VM on Amazon web services, you automatically get a public IP address. If you turn on an OpenStack, you do not. You have to turn on IP auto assignment. So if in your distribution or product, whatever you chose to turn down by default, you act like Amazon and you're more interoperable with them. If you don't, then you aren't. And that's fine. It's not about whether you are or not. Please don't open the Amazon can of worms on me. The point is, is that all of those choices we make since OpenStack can really be configured to be anything is what gets us in trouble. And we don't spend enough time talking about the architectural best practices, the right way to put things together. What should the baseline set of features be in block storage and object and compute and so on that actually matter? Do we need live migration or not? What's the use case for it? All of those things are missing. Instead, everybody kind of does it their own way. And then that's the thing that leads to there being no interoperability, to there being no place to, these things just not making sense and not having enough. But at the same token, that sort of opinionated thing gets us panels like this is why all of you are here. Like each and every one of you is actually here to listen to us yell at each other. And so this is going to be a yes and no answer. So we can take some questions before we boot it out the door. I will also get kicked out at this point. So is OpenStack boring? This is going to be awkward because Joshua McKenzie says yes. I say absolutely no. And it should be. And it's a problem that it isn't. I agree. Yeah, no. Unfortunately no. No, but it should be. Is it a solved problem, Randy? No, not even close. One day it will get boring and there's going to be a multi, multi, multi billion dollar industry. And all of us here are actually building it up. So that's a lot of fun. I hope it's never boring because I think that means we've stopped innovating. Is it a solved problem, Jesse? No. You can buy Nebula today, but OpenStack is a mess. You can buy Piston OpenStack today, but OpenStack as a whole is a mess. We're shipping IceHouse. We probably won't ship Juno for six months because there has never been an OpenStack release that has worked out of the box. And when it can, it will be. Any questions from the floor for our very cheerful panel who might want to punch each other in a few minutes? Actually drinks are on Randy at the Hyatt Bar. And the rest of us will be at the Meridian. I want to add one other quick thing just before we get to the final. So I'm actually leading a new effort called the Application Ecosystem Working Group with Tim Bell in the user committee. And one of the things we're trying to do now that we have a lot of EMC and Mirantis and Blue Box and Piston and Nebula Clouds out there, people are starting to build stuff on them. They're starting to build applications on them. We heard the keynotes. They're getting deployed in enterprises where people are trying to take passes. So we're actually having a session on Thursday. If you're interested in building an application ecosystem on OpenStack and if you're interested in interoperability between all the different products from the folks on the stage here, please come join us. It's on Thursday afternoon. It's the Application Ecosystem Work. It's a 90 minute working session where we're gonna have a lot of people there working on it. I'm gonna get a last one here then too. So I just wanna point out that the whole statement about Linux, like it doesn't ring true, right? Because the vast majority of servers in production are running Linux, right? So whether it's on your desktop or not doesn't make sense. But if you were to include desktops, then I think you should probably include handsets and Android as Linux and it's shipping, I don't know, a couple hundred million units probably every quarter. So if you added up the net amount of Linux out there it probably outweighs Mac and Windows put together ultimately, especially if you also look at ARM embedded devices. Linux had a benevolent dictator though. Yeah. The OpenStack Foundation doesn't have one. Yeah, that, we, yeah. You talked Linux, so I had to get in there. This feels more like the war between the unices almost before POSIX was invented, not so much Linux. And I'm not old enough to- We're all benevolent, but no dictators now. So thank you very much to our panel. We can, I'm sure we'll continue this on Twitter or some other form of medium. But yes, please come up. Yes. Yeah, yeah, I have a question.  What's gonna happen to all that innovation that we just spent the last four years building? Well, my answer is watch us, right? Because we just, you know, the shameless plug, but the talk of a few months ago was, will there be somebody who can stand up on this market but the big boys are jumping on? Will there be somebody who is a standalone who will be able to play and challenge the big boys? And a couple of weeks ago, we announced a hundred million dollar financing. And the message there was that it's possible for a small guy to be a standalone and there are people who believe that it's possible to stand against the big guys. And remember the reason OpenStack came about in the first place. I mean, it is a way for customers with heterogeneous environments to create an even playing field and lack of dependency from the big players. And that being said, a small player, a pure play OpenStack player is the one who can create that level playing field and allow to get some of the profit margin from the infrastructure stack over the long term. And that's the level of innovation that will enable all the innovation that's happening in the ecosystem. And I think that's what we need to start focusing on is how we enable quick and easy innovation for all the players who are not incumbents. Because ultimately that's what customers are looking for. That's will end up destroying the cost and will enable the exponential scale. And I think that's- Cut it off. Dude, I'm not done yet. No, look, liquidity drives investment. Liquidity drives investment. And so you're gonna, you no longer will see new distributions, but you'll see new entrants into the marketplace. You look at companies like StackStorm, you look at companies like Platform9. There are people in the space that are doing new different things. I think it's a wonderful sign for the industry. All I know is that the average enterprise is gonna have a very hard time consuming DIY OpenStack. I'm not talking about the LeanFord guys who are doing it now. I'm talking about the average guys who have a hard time running their sand. Whether it's Chris's model, any of these folks model up there, I don't know, but your average enterprise has to consume products, not science projects, and that is 100% certain. Yeah, and to your question though, it's a fair question. I mean, a hundred million dollars is impressive. We've raised a lot of money as well from some world-class investors, but we're all very small companies in the scheme of $100 billion market cap companies, except for Randy. Except for that, except for Randy. What exactly does a VP technologist do? It's a fair question. We're very early on in this, and I think there's still a lot of really big companies that really have to figure this out, and that might involve partnering with companies that are here on stage, or some really bold moves. We've already seen a few in the last couple of months.  So I guess I'm gonna change it. Alex is actually buying the drink, so I had completely forgotten that you had just announced your round. So congratulations, and now you're on. How much of the hundred million is committed? How much of the hundred million's committed? How much of the hundred million's committed to buying a strings, and also committed? All right, we gotta go, guys, we gotta go. How'd you guys? How'd you guys? Big hug, big hug. Thank you.


My name is Todd Mickelson. I'm the president and CEO of Converis and I'm really excited to share with you a major new product that we are launching today. If you've gone to our website, you may already know what we're gonna talk about because we released a press release and we turned on the capabilities on our website to expose what we announced in the first session this morning. But in summary, it's a new and exciting product. It's something that we've been working on in research and development for almost three years now. And as you'll see as we get into the session, it's really nothing short of a significant technological breakthrough in the area of truth verification. So let's jump in. Exactly 10 years ago yesterday, on March 7th of 2013, we founded Converis with the goal of being the leading technology provider for credibility assessment or what some referred to as truth verification. At the time we formed Converis, most solutions in the market, if not all, had at least one of these three issues. They were either unreliable, costly, or laborious. For many of the solutions at the time and even continuing today, some of those solutions have issues in all of these areas. Some solutions were unreliable because their accuracy wasn't much better than flipping a coin. The testing process wasn't automated and the results were left too much to human interpretation, opening the door for bias. Some of these solutions were and continue to be very costly because they all require an experienced examiner and specialized equipment in order to run these kinds of tests. Other solutions were and continue to be laborious. Because of the length of the time of the tests, the complexity of the testing protocols, the scheduling of participants, et cetera. So when we founded Converis, we did so with the belief that we thought we could really make a difference in this area because of the work that John Kircher and David Raskin and the other members of our science team at the University of Utah had done in the previous 10 years relative to ocular-based deception detection. In summary, if you're not familiar, lying requires more cognitive effort. In other words, it takes more effort to lie than to tell the truth. This increase in cognitive load, as referred to scientifically, causes involuntary changes in the eyes. And by developing technology that can monitor these involuntary diagnostic changes at the time we launched the company, we believe that we could deliver more automated and less labor-intensive solutions. Solutions that could be delivered via a computer that people could run without having significant training and experience in this area. So a little over a year later, three months later in June of 2014, we released our first commercial product, iDetect. It was really the first accurate, automated non-contact and fast solution in the market in terms of being able to take a test. What we felt is very, very quickly, iDetect tests take between 15 and 30 minutes depending on the number of issues that you're testing for, test scores and reports are automatically generated within about five minutes. And the accuracy of iDetect is between 86 and 88% depending on which protocol you're running. And test proctors, we call them proctors instead of examiners because really they can be less experienced individuals who are trained on how to proctor a test and sure that the test is going well. They can be trained in under a day. So since that time, we've seen a great adoption of the product. We have more than 600 customers in more than 60 countries that are running tests in more than 50 languages. Many of these customers are running thousands of iDetect tests every year. And if you are one of our current iDetect customers, we thank you for your embrace and use of the technology. And we look forward to continuing to support you in the use of iDetect and these new products that we're announcing today. In 2021, in the middle of COVID, we launched our second major technological advancement. It's referred to as iDetect Plus. It's really the first automated polygraph with iDetect Plus. You get all the capabilities and benefits of iDetect combined with the traditional channels and sensors and capabilities of polygraph. But you get this capability in a faster, less intrusive way. The uncomfortable blood pressure cuff in polygraph, which the pressure of that cuff must be relieved periodically during the test, causes polygraph exams to be longer. And if you talk to people who've been polygraphed, they'll say it's the most uncomfortable aspect of a polygraph. Well, one of the major technological advancements in iDetect Plus was this ability to replace the traditional blood pressure cuff with pulse transit time. Pulse transit time enabled us to automate a polygraph exam. You could still run it like a traditional polygraph in terms of advancing the questions, but the questions are presented by the computer. And we capture not only the traditional polygraph channels, but also the ocular capabilities that exist in iDetect. And that enabled us to get even better accuracy, where accuracy increased to 91%. So those were the first two, this idea of using ocular and then the coupling of polygraph sensors with ocular in a less intrusive way were our two significant technological advancements in the last 10 years. Despite the difference that we believe we've made in advances in accuracy, and being able to automate the test to make them shorter to enable people with minimal training to be able to use these products. iDetect, iDetect Plus and other existing solutions in the market still have some of the limitations that I mentioned when we entered the space and formed the company 10 years ago. Specifically, specialized equipment is still required for all of these tests, which significantly limits who can be tested. In other words, the test takers must go to a location with specialized equipment, or you need an experienced examiner or a proctor to take that specialized equipment to them. Furthermore, testing is limited and costly because with most of these tests, including iDetect and iDetect Plus, you need a proctor present during the test or an examiner must be present during the test. And although iDetect tests for single issue investigative tests are as short as 15 minutes in length from beginning to end, many customers and interested potential customers have said, depending on the circumstance and what they wanna do, that that's still too long. They are looking for something that will enable them to verify truth like on the identity of an individual, whether it's their actual identity in a five minute test. Another issue with iDetect is the protection of personal identifiable information or what's referred to as PII in situations like identifying verifying identity where maybe you wanna do so before you grant someone a new account online in a banking system. Well, you're not gonna take an iDetect station to them or have them come to an iDetect station. There needs to be some way for that organization to verify something like your social security number, your identity, your name without having to share what they're asking with us, without us seeing it and be able to do so in an online environment. So in summary, a combination of these limitations make it so that people can't take a test anywhere or anytime. And that's something that we've been trying to address in our research and development efforts for the last three years. So without further ado, I'm happy to say that we believe we've solved all of these challenges. And today I'm pleased to announce the release of the world's first accurate mobile app to verify truth. The product is called Verify and it is, as I said, an app. It's a mobile app for iOS or Android phones. It has out of the box two testing modes. It has a mode where tests can be self-administered. So you can open the app and take a test yourself without a proctor or without an examiner present. Or you can flip the app into a more traditional proctored mode where you use the device, much like you'd use an IT tech station to control the test, use the device to give the test, but you're sitting there watching to ensure that the person is being compliant during the test. In terms of accuracy, we are still tuning the scoring algorithms in one of these following in the third session of this conference. Dr. Kircher and Mark Handler are going to walk through a lab story study that we just completed for one of the two protocols that we're releasing and share the details of that accuracy. And you'll see in the details of that study that we are at about 80%, 79.2% when using a four-fold validation process, which shows that the model is in fact generalizable and it's not biased towards the data that we collected. And we're seeing this in these initial stages on tests that take less than five minutes to run. We're confident that in the very near term, perhaps in the next release, we'll be able to share even greater accuracy as we continue to collect more data and tune the way in which we're capturing that data so that it's at a higher quality and this gives us better measurements, thus increasing the accuracy. Because Verify is a mobile app, tests can be taken by yourself anywhere, anytime, and really in any language, right from your own mobile phone. We have ID Tech tests running in 50 different languages today, but it's only languages for which there is a text to speech voice that is available to be run in a standalone Windows-based environment. And by moving to a mobile phone with everyone using text to speech and speech to text capabilities every day, just to finally text and communicate via our mobile phones, pretty much every language in the world is supported and the voices are excellent. They sound like real humans and our flexible environment. So let's watch a short one-minute video to give you a first look at Verify and how we envision organizations and individuals using it to verify truth, whether it be about a person's background prior to hiring someone, whether it be verifying their identity, verifying whether they're a credit risk. So testing them for whether or not they lied about whether they've had other loans in the past from non-traditional lenders that they defaulted on, whether or not they lied about their income. And for other various claims, whether it be like insurance claims that are fraudulent or just really any claim could be a parolee who claims they didn't violate their parole and you wanna verify that quickly. So let me jump over to the video and we'll watch this one-minute video.  So let me stop sharing and relaunch this with computer speaker included. Okay, there we go. And try this again. Some apps can make your smartphone smarter, but Verify by Converis will make your smartphone the smartest of them all. With Verify, you now have the power in the palm of your hand to accurately verify truth in just five minutes. Verify is the world's first app that can accurately and quickly verify the truth about a person's background, identity, credit worthiness, claims, and much more. It validates the truth by measuring involuntary changes in eye behavior. Tests can be self-administered anywhere, anytime, and in almost any language or organizations can proctor tests. Verify is a free app for Apple and Android phones. Use Verify to screen new hires or evaluate current employees, confirm a person's identity or online profile, validate a credit history or documents or claims made about events, activities, accidents, compliance, and more. The way the world verifies truth has just significantly changed forever. When truth matters, use Verify. Okay, so hopefully that gives you a feel for what the product looks like. The apps are actually available right now in the Google Play Store and the Apple App Store where you can download them free of charge to your device and start playing with it. Let's shift now to what are the technical aspects behind the product and how it works. In summary, to make use of the app itself, all you need is... Yeah, buddy. So, I'm getting... Paige, you need to mute yourself. You're on mute, Todd. So all you need is a test link to run a test. Tests are associated with test links that can be created either in the Converis dashboard or via the Verify API. Test links contain pertinent information about the test itself. The exam ID, the test ID, the test creator ID, information about the servers from where when the user clicks on this link, it's going to go and retrieve the test template as well as the server from where it's gonna go retrieve the test questions. Where these test questions could be personal identifiable information that you don't want us to see. So you're gonna serve it up from your own server and it's just combined with the test template that comes from our server. These links contain information about the server to where the data will be uploaded, specifically the measurements that we will use to score the test. And things like the language and the locale of where you want the test to be able to be run. So I can create a test in Spanish, for example, send the link to you in Spanish. And even though your phone is configured to a default English setting, it will run the test in Spanish because I know you're a native Spanish speaker and I wanna give you a test in Spanish instead. So the idea here is that I can text you a link, I can email you a link and when you click on it, you'll be prompted to go, it will check to see if you have the app already. If you don't, it will direct you to the app store where you can download it for free and then it will launch the test automatically and you can take it from there. As I mentioned, apps for both Android and Apple phones are available today. The Android app will run on phones with the API 21. It's also known as Lollipop version five provided that the phone that you're using, which would be really any more recent phone has a screen resolution of at least 750 pixels. Lollipop was first released on Android phones in 2014. So the idea here is as we recognize that there'll be situations where people are running older phones and you still wanna provide a link to them where they can take a test. And so we need to run on kind of the lowest common denominator. The Apple app requires iOS 12. iOS 12 was first released by Apple in 2018 with the iPhone 10, but iPhone 5S and above technically is capable of running iOS 12. There may be some other limitations on certain versions of the iPhone up to 10 where that may not be the case, but for the most part, these apps will run on the older phones. And that was something that we really focused on to make it broadly usable. As I mentioned, there are two verified testing modes Verify test can be self-administered or proctored. There is an audio presentation of the questions. So the test taker hears the questions read to them. The test taker responds verbally. So you're not clicking with your fingers. You'll see why here in a moment. You're hearing the questions presented in an auditory way and you're verbally responding to those questions. And the microphone captures and records those answers. We currently offer both single issue and multi-issue test protocols. So if you're familiar with our IDTUK product, we had our RCT protocol, which was a single issue. And then we introduced the directed live protocol, which is single issue. And then we introduced our MCT protocol. In this case, we have a single issue protocol and a multi-issue protocol that allows you to test on up to four relevant topics, where one of those topics is used as a comparison topic, just like we have on our standard audio MCT, regular MCT and hybrid MCT protocols. The single issue protocol that we refer to as a V for, V for Verify 3R is in a final beta stage. As I mentioned, we'll share the results from the lab study that we just completed. We anticipate that before the end of March, we will publicize that it has been officially moved to a production ready stage. So between now and the end of March, you can use it, we think it's solid, but we wanna just collect some additional data in the field and monitor how it goes before we flag it as production ready. The multi-issue protocol is in what we call an early beta stage. It works from end to end. You can score a test and so forth, but we still have some additional data in that lab study to collect before we finalize the algorithm and the model for it. So the official word is it will be production ready sometime in April. If we finish collecting the data between now and then have scientifically validated it, then we'll make it production ready as soon as we meet that internal threshold and requirement. So in summary, both protocols are fully functional and ready for use, ready for beta testing immediately. We'll show some of those sample tests here in the live demos in a moment. Finally, as I mentioned, the actual testing time is five minutes or less. So that does not count the instructions at the beginning. If you have a longer set of instructions where you're describing the topics that you're gonna test the individual on, then that could make the test a little bit longer. And it also does not count the tutorial that we're gonna show you here in a moment that is about a minute and 10 seconds long. The tutorial would be required for someone who's self-administering or taking the test in what we call solo mode, where you just send a link to someone and say, hey, answer, I want you to answer some of these questions, click on the link and follow the instructions. So that's about a minute and 10 seconds long. Okay, well, let's go look at a demo. So I'm gonna show you a recording of a self-administered test. So a scenario where there's no proctor involved, where we've just sent, someone has sent a link to someone that is going to take this test. The video will start showing that the individual's already clicked on the link, downloaded the app and the test has started. Early at the beginning of the test, it goes into a tutorial, a tutorial that has animations in it and describes the ideal circumstances under which you should take the test. Like obviously you wouldn't wanna take it in a noisy room. If it's using verbal cues for responding, then that could affect the test. So in the video, we will transition from seeing the test taker hold the phone and starting that tutorial to the tutorial itself. So you can see it in a larger fashion on your screen and hear it better and then it will transition back. But it is an end-to-end test that we'll go take a look at right now. And then we'll show a live version of this in the demos at the end. Okay, here we go. This test monitors your eyes to determine truthfulness. Follow these instructions for best results. Take the test indoors and avoid direct light sources such as windows, TVs and computer screens, which can affect test results. Take the test in a quiet place without interruption. Sit comfortably and rest your elbow on a table. You need to hold your phone steady for about five minutes. Listen to instructions and answer verbally. Do not use earbuds or headphones. When instructed, remove eyeglasses, contacts are okay. Reading is not required. When instructed, flip the phone upside down with the back camera at the bottom, facing you. Position the middle of the phone level with your eyes. Hold the phone about a phone length away. You will be alerted if the phone is out of position. Don't cover the camera with your hand or fingers. The phone's light will be enabled during the test. Do not look directly at it. Look halfway up the phone right above the camera. This is a truth verification test. It will ask about three crimes. It will ask if you stole a cell phone from an office. It will ask if you stole $20 from a secretary's backpack. And it will ask if you stole a ring from a desk. You will now take the practice test to begin. Say start. Start. Remember to answer verbally. Regarding cell phones, I can see one right now. True. In regard to large screen TVs, I am looking at one right now. False. You have finished the practice test. To begin the actual test, say start. Start. This test is based on the idea that a deceptive person will have a difficult time answering the questions quickly and accurately. Some deceptive people answer too slowly. Other deceptive people make lots of mistakes. So if you take too long to answer or make too many mistakes, you will fail the test. If you do not hear a tone after you answer and you hear a time limit expired, speak up, or you will fail the test, you will now take the truth verification test to begin. Say start. Start. Regarding the theft of the $20, I am innocent. True. On the topic of stealing the diamond ring, I did not do it. True. As to the theft of the cell phone, I am responsible. False. With regard to stealing the $20, I am guilty. False. On the topic of stealing the cell phone, I did not do it. True. With regard to stealing the diamond ring, I am guilty. False. Concerning the theft of the cell phone, I am guilty. False. Chest completed. You can look at the screen now. However, do not close the app until the test is uploaded. Okay, so hopefully that gives you a feel for how the app works. Let's take a look at the actual verified test report that was generated from that demo test that we just watched. So this is the report, most of it, trying to get it to fit on one screen. You can see that the report not only gives us an indication of whether the person was credible or deceptive, but it also indicates the quality of the data that we collected. If the test taker had taken the test in less optimal conditions, such as, you know, a scenario that has bad lighting or loud environment that interfered with the microphone's ability to capture the answers, then that data quality score would be lower than the 95% that you see on this report. Obviously, we wanna know about the data quality because if it's really poor, that could affect our ability to measure whether or not the person was being deceptive. So we would take that into consideration in the score as well. Notice that we randomly take pictures of the test taker. This is on purpose. We actually, on the phone, compare digitally whether the same individual who started the test or the individual who started the test is the same individual who finished it. Later in this presentation, I'll show you options for not sharing this information with us because this would be considered personal identifiable information. And obviously a bank, for example, that's doing identity verification wouldn't wanna share this information with us. So we'll talk about how this is supported in a way where you can separate all this and still get the same benefit of knowing if it's the same person. Notice here in the report that we do give, just like in IDTECT, we give a credibility score on a scale one to 100 for each topic. And we make a definitive decision where 50 and above indicates that the person was truthful and 49 and below indicates that the person was deceptive. Or at least we detected signals that they were being deceptive. We also provide a summary of the unexpected answers. An unexpected answer would be someone who's answering in a way opposite of what we would expect. We would expect them to say, no, I didn't do it. But if they're continually saying, yes, we wanna know that because they may actually be confessing through the way they're answering. We also capture the number of unanswered questions. So if they just sit there and don't answer and it proceeds on to the next question, then we need to know that because that could be malingering or a countermeasure that they're applying, thinking that if I just don't answer, then I'm not gonna fail. And we may actually fail you if you let too many of those expire without answering them. And then finally, you'll notice that we have a category here at the very bottom left hand corner that says unrecognized answers. So we do have implemented into the product a way of allowing for variations of the same answer. So in this demo, if Daniel had actually said, yes, instead of true, we would have counted that as a recognized answer for true. If he had said no in place of false, it would have worked. And we also accommodate for situations where the microphone just doesn't pick it up, but yeah, we know they're answering. We noticed early on as we ran tests that when you say false, if you don't accentuate the S on the end, the microphone may think you said false instead of false. And we have the ability to expand the list of acceptable answers for each category based on the quality of the microphone and whether it can pick that up. And this applies for any language as well. So it can get smarter in terms of what it's hearing. Finally, you'll see that we include the pre-test instructions in the report. So you know exactly what the test was about. And we provide at least one example of a question for each of the relevant topics that we were testing on. Mark and John will talk about the formatting of these questions because they do seem a bit odd, but there's a reason for that. And I'll let them talk about that when we share the results of the study that we just completed. Okay, so what are we capturing? How are we detecting ocular changes in order to be able to generate a score, much like we do with iDetect and an iTracker? Well, during the test, we capture and record really the same or similar data to those data that we capture and process in a standard iDetect test. Specifically, these features or predictors are used in the algorithm to detect deception and generate the credibility score. And they are a pupil diameter, x and y gaze, blink rate, and some other proprietary ocular measures to detect deception. So the first four that you see here are the same predictors or features that we use in our scoring model in iDetect. Obviously, we have to detect them in a different way because we're not using an iTracker and I'll talk about that here in a moment. New to verify the accuracy of the data New to verify. So this does not exist in iDetect. Unless you're running iDetect Plus and you're using the polygraph channels through our Physiotracker, we are utilizing a vascular or a blood flow measurement. This is something that we're capturing through the camera on the phone. And you'll see in the study results that Mark and John share that it is actually one of the diagnostic features. It's not as diagnostic as pupil, but it is an additional feature or predictor that helps us know the person was being deceptive. Okay, so what happens during the test? As you saw in the demo, we have the person flip their phone to take full advantage of the better camera on the back of the phone. The camera on the front of the phone is more designed for selfies only. And if you get the phone close enough for us to detect sub 10th of a millimeter changes in pupil diameter, then it's blurry. You can't control the focus on the lens. You also don't have as easy of a way of turning on a light like the flashlight on the back to illuminate the face. And in some cases prevent some of the reflections that show up in the eyes where our eyes function more like a mirror that could interfere with our ability to find and measure the pupil. So we, during a verify test, the verify app video records eye behavior and movements at 10 to 30 frames per second, depending on the phone. The most sophisticated, fastest phones don't allow you to record more than 30 frames per second. So depending on the quality of the phone, we capture as many frames per second as we can. And then we take that video and we extract from that video each frame. And then we extract both a left and a right eye image from that frame. From there, these images are processed to identify and measure pupil diameter. The images that you see here on the slide show a four step process that we go through where we process and filter, in this case, a dark brown eye. We specifically chose a dark brown eye because it's really difficult to distinguish between the pupil and the iris. And you can see that as we apply these various filters, we ultimately get to a state where there's a clear delineation between the pupil and the iris. And we can basically count the number of pixels to derive the pupil diameter. If you look closely on these slides, these particular images that were taken out of the video have reflections to the left and right of the pupil in the iris itself. And so one of the filtering steps that we go through is to identify reflections that may make it difficult for us to identify the pupil and measure it. And we adjust the coloring of those reflections to be the color of the iris and allow us to still identify the pupil and measure it. Okay, from there, we identify the area of the scolera. The scolera is the white area around our eyes outside of the iris itself. The scolera is something that enables us to derive the X and Y gaze blinks and other eye-based measures. If you think about it, if I'm looking to the right, I'm gonna have more scolera visible to the left of my iris. And if I'm looking to the left, I'm gonna have more scolera visible to the right. So despite the fact that we are only using one camera, even though your mobile phone may have three cameras on the back, the mobile phone only uses one of those three cameras. It chooses the lens that's best for the circumstances. So unlike an eye tracker that has two cameras in it where you can more easily calculate gaze, we're calculating gaze through identifying and measuring the scolera around the iris. Okay, so let's move to use cases. Verify, as you saw in the video, the intro video helps organizations or individuals verify the truth about a person's background, identity, credit-worthiness, and claims, and pretty much anything else that you wanna test for. Eye detect is well known for its value and use in pre-employment screening and ongoing employee evaluations. In fact, probably 95% of the tests out of the 500,000 eye detect tests that we know about that have been run are pre-employment or ongoing employment screening. But verify enables organizations to streamline even more the hiring process by having applicants self-administer tests right after they apply online. So rather than having to invest time and money in scheduling an applicant to come to a physical location and to have a proctor give that test, although it would be a more accurate test if you're using eye detect, this allows kind of a pre-pre-screen scenario where you could send a link to someone immediately after they apply and do an initial screening that they run in a self-administered scenario. And for identity verification, verify could confirm a person's identity before tying it to a biometric or granting a new account to them or granting a transaction to go forward or giving them credit or giving them access to something. The beauty here is there's nothing worse than associating someone with an identity that's fake or fraudulent and then tying a biometric to it that they use going forward. The biometric is not really them. And now you're gonna perpetuate something that's invalid. It's especially bad if you were to hash this into blockchain where it's immutable and you can't change it going forward. So the benefit is that you can verify that identity on the front end and know that it is who they purport to be and tie it to a biometric and then use a biometric with confidence for allowing access or future transactions or whatever it may be. For credit use cases, regardless of where the person is, you can validate their credit history or verify their application details or the documents, verify if the documents they submitted were fraudulent. We have a large client in Peru that has an ID text station in 50 different dealerships, car dealerships used to be that it took two weeks for you to get a loan if you went into buy a car from them because they went through a lengthy verification process, including sending someone to your house and everything else because they don't have a central credit bureau and people get loans from other nontraditional sources. And they switched ID text, saved millions of dollars. But more importantly, they shortened that time to about four hours.  And the third issue, so this is an MCT test that they run is whether or not you submitted any doctor or fraudulent documents as part of your application process. Imagine micro loans now where you could go to more of a retail store, apply for a loan right in the retail store to get a flat screen TV or a couch or whatever it may be and they could do a loan verification there. Finally, with verify, you can verify statements about what we call claims but those claims could be an insurance claim. It could be an online profile. Imagine in a marketplace being able to see that someone has been verified relative to whether they are insured, licensed or bonded, whether or not they're a registered sex offender. If they're gonna come into your home to perform work you may wanna know that. Could be verifying parole compliance. They claim that they didn't violate their parole and you could quickly and easily verify that with verify. So let's look quickly at two examples here. The first is the hiring process that I mentioned where you could really streamline the hiring process by prescreening someone right after they apply for a job and the scenario by which this could be done and Russ and I are gonna demonstrate the actual implementation of this on a real site here at the end. But the idea is the applicant visits the employer's website, they fill out the application. The information goes to the employer system where on the back end they have a set of processes where in some cases they programmatically check to see if your address is correct, see if you have a police record, see if you meet the minimum requirements for education whatever it may be and if you do, they could programmatically generate a verified test and a verified test link which is automatically texted to you or emailed to you depending on the implementation. And when you click on that link, it prompts you to download the app because you wouldn't have it at this point, download it for free from the app store. You take the test, the data is processed and uploaded. So processed on the phone, uploaded to the Converter Scoring Server where it's scored and a report is generated from which the employer can now make a decision. They could potentially just extend an offer or you could use this to make a decision on whether or not maybe you wanna fast-track this applicant because they have all the right capabilities that you're looking for and they passed. And so you're gonna spend your limited time and effort with applicants on these more expensive steps of bringing them in and doing a face-to-face interview and so forth. Here's just a quick example in Mexico. Three different organizations that all have a turnover of 15% and you can see we're showing a scenario of what the estimated loss and costs are due to turnover, estimated cost in Mexico for implementing verify the number of people you'd have to test based on that turnover and an estimate of how many applicants for each job that you would test to fulfill that job. And you can see that there's a huge ROI, 850% to 1,700% on the money that would be saved by hiring better people by reducing some of the losses that occur by not properly vetting people or spending time and money on applicants in steps of the process that are more expensive. Okay, second scenario and we will also demonstrate this scenario using an actual implementation that's live. The scenario is a FinTech that implements verify for identity verification in a way where they can do so without sharing any personal identifiable information or PII with comparison. This implementation uses the verify API. So rather than going to our dashboard and creating a link manually and sending the link to someone, this is using our application programmer interfaces to generate the test link to send the link. And in this case to manage what we call data sites. Data sites are variable strings of information in your test that you don't want us to see and that need to be dynamic. So we'll show you a demo with that here in a moment, but the scenario is this, someone goes to a location and to fill out an application. In this case, the scenario is they're applying for a new account, could be like a new bank account. And they go to the FinTech's website where they put in their information in the FinTech website's form. That information would include some PII, like their name, their address, perhaps their birth date, their social security number, information that they definitely don't want to share with us or anybody else. That PII is captured by the FinTech and stored internally on their server. But at the same time, it's replicated or shared with an internal question server. So that's what we call a server that a customer manages where they put the information that they want to present in a test. In most cases, it's questions, but it could be part of the preamble, the instructions at the beginning in the test itself. Anyway, the information that they supply to the FinTech is also used by the FinTech to generate the verify test link. Separate from the FinTech's architecture that I showed you before, exists the verify server. This server has a couple of functions. One is it serves up the test template. So what's expected when someone answers the first question, are we expecting them to say true or false? We don't know what's being asked, but we need to at least know are we expecting them to say true or false? This server also scores the data after the test is taken. So when the applicant clicks on the link that's been provided to them after they fill out this form, iDutect is launched if they have it already on their device. If not, they're prompted to download it and then it launches. And at the time it launches, it will request the questions, including the PII, from the FinTech's question server. And simultaneously, it will request the test template from the Converis server. Both the questions and the test template, information are encrypted. So it's a requirement when this data is served up from the respective servers, it comes to the user's phone in an encrypted form, and then it is merged together, the test template with the questions stitched back together on the phone to provide a unique personalized test to the applicant that they're gonna take on the phone. So the applicant takes the test as you saw before, and then the data at the conclusion of the test, specifically the measurements are, and how they answered, are sent to the Converis server for scoring. At the same time that happens, the applicant's photos that you saw in the test report, and any other sensitive information, it could include a customized consent acceptance that's digitally logged at the time they click on the consent in the Verify app. All of that information gets sent back to the FinTech question server. And then at that point, the FinTech uses the Verify API to request the scores and the information on how the person answered the questions from the Converis server to assemble it with the questions and any other information that was set up to the phone from the question server. It's assembled all together to generate a report, an interim report for the FinTech. And anyway, that's how it works. So we will demonstrate this functioning from end to end here at the end, using this exact scenario and data sites and the API to server.lum. So in summary, Verify is our third and latest technological advancement like IDTECD and IDTECD Plus. Verify validates truth by measuring involuntary high behavior. It's really the first accurate, and that's the key, accurate mobile app for truth verification that exists today in the world. Verify enables organizations or individuals to verify the truth, as you've seen here about a person's background, identity, credit worthiness, claims, and much more. The best news in all of this is it is available today. So it's officially released. The protocols that I talked about are in a beta form, but they are functioning and the application and the technology behind is production ready and available. So in conclusion, after 10 years and with the addition of Verify to the Converis product suite, we believe that we're addressing all the challenges that I teed up at the beginning that existed when we first founded Converis and went to work on IDTECD. Whereas 10 years ago, the available solutions were unreliable, costly, and laborious. Well, laborious in some cases, the solutions didn't have problems in all three of these areas. The Converis product suite now offers a complete, accurate, cost-effective and a set of simple solutions. And anyway, if you're not already a customer, we would welcome the opportunity to support you in deploying any of these Converis solutions that are now available. So with that, that's it for me.