Questions from the audience? [INAUDIBLE]. Wow. Nice short Q and A. [INAUDIBLE]. One of the questions that came out earlier from talking to the group right there. There was one for Amy, who is not here yet. OK. So the second one was really talking about usage pricing and metrics that make sense and how this is really a key issue. I think one of the interesting dialogues would be, what are the metrics that make sense in each of your industries? And why are they the right metrics? I think the why they're the right metrics was really some of the focus I heard earlier. Anybody want to go first? This kind of ties into something we chat about the compliance enforcement piece where I think it's really understanding the organic use cases of your customer, in terms of figuring out the right metrics for pricing. It's really interesting. We just had a chat in the hallway here earlier with a gentlemen. Some of us are dealing with legacy software that had some different coattails to it. Obviously some of us have some much newer or current applications. But really understanding the organic use cases for the customer I think is key. We found, in our case, looking at how we price. Are you just chasing competitors? Or how are you leaving money on the table? Or are you asking too much for something? I know in the case of some of our analysis we looked at maybe we had too much of an emphasis on hardware, which is starting to be kind of commoditized, versus the real value for us, which was our software and where we should shift cost kind of back and forth. And I think another kind of untapped area to look at is around maintenance and support. I think companies traditionally get into a rhythm of just having a percentage of list price or some kind of combination thereof to figure out formulaically what the maintenance and support agreement ought to be. But I think you've got to think about, in terms of the development life cycle of your product as well and the stages of evolutionary, are you actually kind of indirectly pricing your product correctly through your support agreements? Just another facet to think about. [INAUDIBLE]. [INAUDIBLE]. Yeah. I feel, with respect to usage, that Aspera kind of has it easy, because as a transfer product we can say bytes transferred and maybe if we had a reflection of how fast they were transferred. I don't think customers are going to quibble about that too much. I think some other vendors where it's harder to attach usage to what the value to the customers is is tougher. But I think you need to zero in on. Our thinking is bandwidth. That was kind of in the vein of value to the customer. Bytes transferred over the network, again, is in the vein of value to the customer. So I think you kind of have to look at it that way, which is a little bit of what Dave said. Anybody else? Yes. So just to add really more of the same from our perspective, value to the customer is a lot about the number of devices and hosts that our customers want to monitor. So it made sense for us to tie that in. It's pretty standard in our industry for monitoring software that that's the way that things are priced. We've just sort of fallen in line. I guess whether it's the best model going forward, only time will tell. And we'll continue to talk to our customers to see whether there is a better way that they'd prefer us to do it. But it's certainly working at the moment. It's certainly working with a lot of our MSP customers who want a variable model, which we've built in. So as they bring new customers on, they'll be monitoring new hosts, and they're happy for us to charge them for monitoring those additional hosts. Conversely, when they round down the number of hosts, they want to see our costs round down as well, because their revenue's reducing and their cost needs to reduce as well. So we've built that flexibility into the model. So the numbered device monitor seems to make sense for us. Yeah. Since Amy's not here, I'll pretend that I'm Amy. Just make sure that, first of all, what you're monitoring and measuring is something that the customer understands-- which goes very directly to what everyone here was saying-- and it's linked very directly to the business value that you're generating. If what they're looking for is a device monitoring solution, then monitoring, counting the number of devices makes sense. Counting the amount of virtual RAM that the monitoring solution is using would not make sense. Think about what is the business problem that you're solving, and then they can see that the more of that business problem that they're solving with you the more that they're willing to pay. And therefore, if you can find a way of making that something you can count then [INAUDIBLE]. I don't think any two companies really can be counting things exactly the same way. Actually, it's interesting that you brought that up first, because I was thinking-- and I had a couple of people that's been here, especially Matt back there, would remember-- about a year and half ago when we had LicensingLive, we had a big debate around usage and whether anybody would ever actually use it. Right? Because we talked about research-based models that the vendors have had, we have had, but the adoption had been so slow. It's amazing how fast it's growing, the adoption by the ISPs themselves. The other thing that I was going to say, to your point, Alan, one customer I think we'll talk a little bit about tomorrow in one of our sessions is that they did because they do project-based software. So in that case, their customers use them for certain length of projects, and then they're done. So there are peaks and valleys that they have to make sure that they're measuring correctly as well comes into play. For the people who have implemented licensing software or put in licensing mechanisms and controls, did you go through any kind of an ROI exercise? ROI's pretty good with top-level management. They love to see numbers. So if you've been through that at all. So we did. It's a great way to make the argument. There's a lot of IT assets that people will ask to deploy and there isn't any ROI on them. There's certain functions you've got to do, like manage your HR assets and records. There's regulatory reasons you've got to do stuff, right? With this, there actually is a clear line of sight, though, to ROI, typically. And what we had done internally in making our argument or our case for change was looking at qualitative and quantitative metrics both in terms of the analysis. I think qualitative works if you've got good quantitative to back it up. It's a good balance. And there are certain intrinsic things I think you do have to figure out with the hard numbers. We were moving from an environment were we were processing entitlements through our ERP, which a lot of companies have done or done in the past. Especially when you're starting out, it's kind of a convenient thing to do. But you have to start processing things like $0 orders for sales to make good on licenses or to regenerate keys or to do entitlement transfers. And so we looked at what is the cost to process a PO in our company. How many of those are we processing? How much time did it take from the field? We looked at metrics not necessarily having to be financially either. We looked at, in the case of NGS, NetApp Global Support, where a customer calls up and they need a key regenerated, what was the turnaround time to get a new key in that customer's hands? That's a critical metrics. Not financial, but it absolutely goes down to the intrinsic value we provide the customer, in terms of value case for improving support costs with our support organization. Be creative about how you're looking at it. There's probably a lot of other metrics to talk about. I know folks who have got some ideas too here. No. Add to that? No? We didn't. Other? Question. Hi. I've got a couple of questions, one for Rob. I was curious. You rolled out your licensing, entitlement, and delivery strategies. Did you at any point consider software protection as part of that strategy? And if so, why? And if not, why not? All right. So software protection in what sense? As opposed to licensing As opposed to licensing. Yeah. To prevent reverse IP and that kind of thing. To be honest, no, we didn't. I don't remember us having that conversation. We sort of leapt straight to licensing, as that was going to resolve a whole bunch of issues that we had. So that was the answer. It was staring us in the face. Let's just crack on and implement it. So there was just no concern with binary tampering or anything of that sort out in the field? No, because of where w were coming from. So we were coming from a completely open source model. So there were no binaries. It was open source. It was out there anyway. It is something we are going to have to look at as we start to develop more of our own IP in the product that is protected by the licensing. So not something historically we were concerned with, but there will be a greater risk as we move forward. And we'll need to look at that. OK. Yep. Makes sense. And then just a quick one for David. Audits are generally considered invasive and disruptive and, in general, horrible in the past. But now, as you mentioned, more and more of that's occurring. More enterprises are being audited. Has it gotten to a point where it's now acceptable practice, in other words that the software vendors can approach enterprise and say, yeah, we want to invoke our auditing clause and enterprises now have people and processes in place generally to say, oh, yeah, talk to so and so and he'll get this thing arranged for you? Yeah. So when we were booting up our program, we are looking at different peers here in the Valley. There are some really interesting best practices around this. I think once it gets to a certain level of maturity you see organizations where sales is actually gold on true-ups in addition to do business so that there's the right kind of balance, so you keep the sales reps from going too native on some of the accounts. There are, I think, some interesting kind of opportunities of getting this started. But I think you really have to look at, when you're doing that, think about the brand of your company and the character and that feeling that the customers get doing business with you. You want to maintain that. In fact, maybe in some cases you want to even improve it in the audit process. But everybody's been audited. Either the sales reps may come in and do a self-certification, which we had there on the slide there too. You see that pretty frequently. If something comes bogus out of that or you don't get a response back from the customer, you send in Mr. Nasty-- you send in Brian and Stewie-- and figure out what's going on in the account. But generally you see a two-stage approach is pretty common, where it's kind of an open, friendly thing. Hey, we're here according to the contract. Generally you get a response back from the customer. Occasionally you have to go to that next level or that next tier to get the information that you're looking for. The other thing I'd caution on too is to look at your risk profiles and make sure that you're coming in with a focused manner. If you want to come in to put a node sniffers across the entire architecture of a customer's IT environment, you're going to get a lot of push back for that. For us, we went in like a laser and said, look, yeah, we sell 50 pieces of software. We're here to look at 5. And we're here to look at them over here. It's kind of like US Customs, right? You come into the country. You got 100 pieces of luggage. They may look at 4. They don't make you take all your underwear all over the airport. Well, sometimes they do. But you can be smart about it as well and not be too invasive and get what you need. If your name is Prakash Panjwani, you get pulled over every time. Other questions? Russ. One of the other questions that has come up-- I think, David, you touched on it in your presentation, but I think probably, Thurston, you've had some experience here as well-- is really when it comes to the phone home telemetry type issue, what are some of the considerations you've included in your deliberation, and specifically as it relates to the potential for legal conflict with privacy laws in various locations around the globe? [INAUDIBLE]. Oh. Do you want to--? [INAUDIBLE]. Sorry, then we'll go ahead. So we probably coming from the same place. We've got our storage controllers in medical services companies. We had to be careful to not send certain header information back that could have any kind of a suggestion or hint of pointing to a sensitive record for a customer. So obviously there a regulatory impact that we've got to be very sensitive to. But transparency's important, right? For us, we don't have some locked binary file that goes up where you don't know what the payload is. For us, it's really transparent. There's a text file. You can look at the log as it spools up and then phones home. So there's really good transparency. The customer can turn it off when they need to, or turn it back on selectively when they need to as well. And that's helpful. Giving the customer some level of control and then seeing an absolute benefit in making the connection has been part of our secret sauce of getting such a high rate of compliance in the phone home capability. But yeah, there are certain cases where you've got regulatory issues. You also have issues where you're maybe selling into certain parts of the government or a certain type of banking sectors where it's basically blacked out data center, in which case you want to look more at what are the software asset management policies. And they tend to have much more strict software asset management policies where you can do self-certification with an account. And there are certain ways you get data out, but it's obviously a lot tougher. Did you want to add something to that? Yeah. On the audit question, it's almost a little bit embarrassing on our side. We're not doing much auditing on our customers. One reason is, of course, a, they're not able to install software their own. Second thing is we have to entitle the license for them. So that's not really much we are doing on the audit side. So we do not have onsite, phone audits, or remote audits. But as soon as we will move to the cloud side or the self-installing side, that might become really hot topic then, probably. Yeah. For the purposes of this question, I think it's not just about auditing. It's about the usage of information from a business intelligence perspective, product development, et cetera, and just the gathering of that data. [INAUDIBLE]. To use the data how they're using our product, that is definitely something we can use internally. Also we sometimes get it dump of the database to really improve our products, especially if they have an issue which is not reproducible with our database. We ask them to get dump of their database. But of course, we have to treat the data we receive from them very security, and every employee who was working with patient data has to sign a special paper that he's not giving this data outside the company. And sometimes even data so the patient names will be vanished out, so it's kind of real data, but it's fancy names. Yeah. Hi. I'm Chris, here from Aspen Tech. So we do require usage logs from our customers. So one thing we do provide is a masking tool that the customers can run, so host name, machine name, and IP address. But they can mask that. Questions? One of things that it seems people are always struggling with is trying to isolate or shield pricing and packaging from licensing. I think a lot of people in this room have probably experienced where six weeks before our GA or something, hey, there's a new way to create a suite, or we want to charge for a new feature, or there's a new bundle or something like that. Would any of you say that you've kind of achieved that sort of layer of abstraction in a way? And how have you done it? Or are you all vulnerable to a late pricing decision, basically, making you change stuff on the product or on the entitlement system or both? I would say with us it's a work in progress, and we are vulnerable. However, I mentioned that our model is usage base with kind of tiers with customers paying overage. So in the vernacular of SafeNet, that's called a post-paid usage model. We heard rumblings of the management team and product management saying like, well, maybe we want to do a limit where the product stops working at that limit. So we went and implemented that, even though they didn't really construct any products that way. So we have that gun in our arsenal. That's handy, but that doesn't mean they can't cook up other things where we haven't armed ourselves for it. The other thing we need to do that I highlighted earlier is we need more of the product componentry to be asking from SafeNet if it should be running. So with the two license models and more of the product asking for its feature determination from the central source, I think we'd be in reasonably good shape. My big fear is that somebody wants to start counting or asking about a feature that we haven't done that for. So every time they do that, we got to crack open the product at least a little bit. It shouldn't be bad, but we're going to have crack open the product a little bit to put it in. If Thurston goes to 210 features, he's got to have 10 micro development efforts to go put those 10 more feature checks in. So those are a little hard to predict. And I think maybe it's a little bit of nirvana to think that you'd have-- unless you instrumented every inch of your product, somebody might throw something at you where you have to have engineering go do something. One word, roadmap. We've put in a multi-year roadmap of where we're taking licensing and the product and where we want to take packaging as well and also to help people understand that every package attribute doesn't have to have a key. You only have to have a key where you want to help provide a lock for backstopping compliance enforcement issues, right? And it depends, I think, on the level of software you've got or what markets you're in. If you're up the street here, Symantec, and you want to put in antivirus mixed in with something else and something else they you have at the shelf at Fry's, you just shrink wrap the boxes together. If you're a large enterprise like us, IT solutions obviously it's much more difficult. We had a problem where, before I got here, they made some packaging changes. And they were mixing and matching some features and not understanding the interdependencies in the product. So I've got this sticker I took off the newspaper, and I've got it on my whiteboard at work. And it's Skip's Tires. Buy three snow tires, get a fourth free. And we're not selling snow tires. You need a long line of sight when you're making any of the structural decisions for packaging or licensing or entitlement. These are not things that we can turn on the dime and put together. I just encourage you to have transparency in your organizations. Put the roadmap out there. Understand where the inflection points are in your product to control or manipulate or steer licensing. And then have a transparent discussion about how that fits into the business plan and the roadmap over time. And then you have something to grow into. But it's tough. I sympathize with you if you get pressure to do this at the 11th hour. It's just fraught with fragility and problems to do that. Thank you, [? Dean. ?] All right. Just one other thing I had. We started off with Alan talking about, jokingly, I know, if you have a cloud strategy, you have a social network, and then your mobile. And interestingly, I was thinking I don't hear much about mobile. I think, Chris, you had something around mobile on your [INAUDIBLE] slide. So just to comment or any of you to say when you think about your product specifically anything from a mobile perspective that you think you would do differently? Or is that even playing into your strategy at this point, mobile systems, if any, or application-wise, even? I know you had something on that [INAUDIBLE]. We offer mobile. And running our mobile development is one of my other jobs. But one of the things that we do in mobile which I really, really wonder about is we make mobile apps, and then we put them in the app store or the Google Play Store for Android, and we charge nothing for them. They're free. You can't use them unless you pay us a premium on the server. So to use our mobile apps, you probably saw a key called Mobile Enabled under my features. So you pay us on the server to use mobile clients. And I think, OK. Right now that's OK. Because a customer is not going to download like a million mobile clients, probably, and run with our enterprise software. But what if some customer showed up that had an opportunity to use 100,000 clients that we maybe sold them for $2? That kind of like mobile math gets really interesting really fast. So I do think about that a little bit. Right now, for us they're free. They're licensed on the server side. But sometimes the stories you hear about how many clients people sell do make you wonder about maybe putting a small price on them and kind of using the alternative model of charging for that particular client versus giving them away for free. That's a very good point, mobile. I completely forgot about this in our presentation. Just recently-- I think it was one month ago? Or two? One month, yeah-- one month ago we released an iOS app for the iPad on the patient management side. So what it's actually for is the doctor can walk around any hospital with his iPad an look at patient data, schedules, and whatever's due for this patient. And we are doing actually the same thing. So everybody can download it for free. And our vision is that every time he connects to the database just it will be counted as one. However, at the moment our current licensing provider-- so we're not using SafeNet yet for the current version-- doesn't offer this functionality. So we will move with our next product release over to SafeNet. And we'll do a little bit of a professional service together with SafeNet that the web services for these rich internet applications will been enabled, then, through SafeNet as well. So online check out, but as well if he goes offline that the license will be still counted as one on the server. And if he reconnects, then he's still using the same one. So we are just handling it with our internal server level. But the software for download is for free, then. Thank you. All right. Final chance. All right. So before I wrap it up, just a few thank yous. First of all, I want to thank our speakers and the panelists here. [AUDIENCE APPLAUSE] Thank you. I would say really high quality content. Actually, some of the folks in the hallway mentioned that as well. I think it's been a tradition, and I think this here even surpassed that again. So we definitely appreciate you guys taking the time and being here and sharing your experiences as well. Thank you. I want to thank all of you in the room for sticking through it. As usual, your feedback is always welcome. There will be mechanisms as well, but certainly feedback over a beer always helps, right on the spot. So you see any of us from SafeNet and anything you want to see different next time around, definitely let us know. I just want to acknowledge our team, as I said earlier especially Marcy and Donna there, but the whole marketing team and the rest of folks who pulled this together. It's never easy to get all the right pieces aligned. And I think I mentioned to some of you that we continue to balance the high-level content with the size. We've learned over time that too large doesn't help. So we try to keep the engagement at certain levels and sort of maintain the content at the same level. So it's been quite a hectic job by those folks, and I definitely appreciate it as well.
Prakash Panjwani and Russ Hubbard lead an expert licensing panel discussion featuring software industry thought leaders Rob May, Thorsten Gerden, David Welch, Alan Zeichick, Chris Markle, and Dave DiMillo.