Editing capabilities of those output formats of MSI, App-V, and MSIX.
Currently we just add in the products, package the apps, clean them up a bit, and we can provide a console then that people can do their own cleaning up in the advanced console that we’ve got to edit the MSI. We can’t necessarily edit the App-V or the MSIX yet. We have got some editing capability of MSI already, but we want to be able to prove in Q3 absolute editing capabilities.
There’s a few people that we do talk to in, there’s a company in Finland that actually have all of these API controls already, to be able to do editing within MSI and App-V. It’ll be DLL control that either we’ll have to OEM or Nick is probably going to try to reverse engineer his own way of doing it. MSIX, of course, is similar but different editing files. App-V uses XML format. MSIX probably uses a mixture of JSON files and XML. There’s a bit of work for Nick and the developers to unpick how we’d be able to provide a console for people to edit, and re-save these files back out again. It just provides a little bit more depth of features to the product, rather than it just being completely flat automation, it’s binary, is it going to work, or it’s not. It gives them an extra level of, well, it didn’t quite work, and I don’t want to send it to a packager, but I know I just need to change this one little bit. At least, now, we can offer them that functionality, that they’ve got editing capabilities to be able to change minor little changes to, at least, move things on, rather than delaying an app to be completed.
Interviewer: Has the file itself?
Interviewee: Yes, the actual MSI file itself we can open up. It’s like a database-style file. The App-V one is similar, but it’s split a little bit more because of user settings, and MSIX is, again, a different format. This will be the output file of the automation. This will be opening up that file, editing it, could either drop like a new file into it, or registry change, or a user setting of some sort, and then re-saving the file back out again in a controlled fashion. Maybe, even at that time, I’ve not got it on here, but really at that time as well, it’s not displayed on here, but at that time, we’d probably, look– Well, I’ll rewind a bit.
Everything in MSIX, because it’s new, everything in there, in MSIX, has to digitally signed. It’s just how MSIX works. App-V and MSI don’t work in that way. You have to manually digitally sign them. As part of that particular piece, every single output, we’d use the sign tool, we’d use the way that Microsoft do it for MSIX. They’ve got very special ways that they digitally sign files as well, just to make things a little bit more robust and secure. Everything coming out of the editing capability, everything that’s saved out there, we’ll add into it, digitally sign in the file content.
Like I say, it happens by default with MSIX anyway, but the other products will add that in, and it’d be quite simple to add that in. Now, the 3.9 launch thing is a bit subjective, and I don’t know the other guys’ view and feelings on this. It’s something we’ve always wanted to do. Other companies have tried at this, flopped, some other companies have tried it and it works, but if we can get it working and get it working right, it could provide a pretty good revenue stream for very small companies, small to mediums.
At the moment, all of our marketing strategy, all of our push, drive and contacts that we have, and people we talked to, really pushes enterprising down to get the biggest bang for our buck, pretty much. If we look at the bottom, or even small companies, mid-size, and are double way, if we was [sic] to launch an Azure cloud-hosted, it doesn’t necessarily have to be, but the way I’ve split this out is, we’d initially go for an Azure cloud-hosted solution.
We’d have two particular top-end modules that run off of there, which will be for people to sign up and literally just upload content of something they want packaged in whatever format they want it, then output it back to, whether it’s MSI, App-V, MSIX. They could upload as setup.exe file, or just drag and drop a whole load of files and folders, and say, “Okay, I want this back as an MSIX delivered file,” and we can go off in the background, it could churn for automation, and then spit back to them to download the MSIX, or MSI, App-V file that they wanted, and utilize in their organization to distribute around.
Likewise, they could upload an app that’s already packaged, or even just one that needs to be packaged or installed. It doesn’t have to be a certain package, it can just be just something they want installed, just so they can actually sign, test and check, that they can test the app against a specific bill platform. The Azure frontpage would simply be upload your content, select the format you want it packaged and downloadable in, or upload your content, and select your type of machine, what operating system you want to test it against, and then they’ll be presented with machine to be either used and test the app on.
Then they’ll be able to close it out, and understand that the app is going to be okay on a certain platform. That’s the idea behind that, to help customers get apps packaged or tested out. If that makes sense. The–
Interviewer: Just one second. The last two sounded like you weren’t really sure that’s going to happen. Are we okay to write about it publicly?
Interviewee: Well, I don’t think we need to worry about those ones particularly immediately.
Interviewer: [inaudible 00:20:19] 2020 roadmap, it would cover all back to each one and talk about–
Interviewee: Maybe yes. Maybe take it to Q2. We leave Q3 and Q4 out. It’s only because I know Tony’s always been really keen on doing it. I’ve always really wanted to do it. It can provide a nice little revenue stream of– Re-package any app could very simply be 50 bucks an app, rather than 100 if you buy capturing, you have it on premise. It can be 25 bucks an app. Could be 20 bucks, could be 10 bucks now, whatever. That part goes for the machine, expose it back to you. You use it or not, there’s no obligation, we’re not tied to the fact it didn’t quite work as expected, you’ve only paid 10 bucks for it.
I don’t know where it’s going to devalue us as a company, that’s the bit that we know we need to talk about internally as a company is something like this is going to devalue our proposition for actual product, is it we can start get a bad name that we’re actually we throw stuff up there and get it back because it doesn’t even work. Because a lot of apps can be like that. That’s why some people have crashed and burned when they’ve done this before, [unintelligible 00:21:35] got a product called Optimized. They use it on prem, but predominantly, they were trying to do a cloud-based talk.
There’s a company that’s been going literally for about 10 years called Zieptz. Z-I-E-P-T-Z. They’re out in Australia or New Zealand. They’ve been doing this stuff forever, and you just fire it up in the cloud, and some of the packages- someone manually would package it, then you’d go and download it. This was saying just as automated. These Q3 Q4 items– Well, sorry, the packaging editing capabilities definitely going to happen. The 3.9 and 4.0 stuff might not. It depends on Tony’s view really, he’s always wanted to do it. That’s why I did it in there.
I left it out until late in the year just because we got so much other stuff going on and need to get done. Then the final one, the version for the major release would be a multi-tenant version that is actually almost like version 3.9. It’s treading the water to see what interest we get from people wanting to do package testing and app testing. Then version 4 would leave a host on a zoo or AWS, because the way capturing stores using [unintelligible 00:22:57] it would work on any platform type.
The virtual machines it’s been up, but what I mean by major release multi-tenant is that we could actually start managing people’s packaging requirements, for multiple companies. There’s companies already in Romania from SCC, that’s a UK based company have a packaging factory out in Romania. They just literally have a database of 20 plus different customers or even so getting to it that we’ve been speaking to. They isolate the separate request- package request, separate customers, but they will actually do the packages for them. We automate them.
The ones we can’t do, we could spill off to a service provider or have our own packages do them in the background and edit them and fix them and send them back out to be downloaded. Some companies already do this, but don’t do it very well. Some companies already do this and just have manual people behind the scenes. What I am suggesting here is that we do it for many customers, 90% automated, and the 10% would either have to outsource it or would have to get our own packages to do the stuff that doesn’t work.
Q4, we have the major 4.0 release planned. It’s going to be this, but stay tuned for further details