CodeMeter Cloud Pilot Phase: The Birth of a New Product

The Background

CodeMeter Cloud was first envisaged around four years ago. Wibu-Systems’ Corporate Technology department was expanding and looking at how the use of licensing systems was evolving, and they came to an interesting conclusion.

CmDongle and CmActLicenses were still needed, of course, and will continue to be needed into the future, but workforce mobility was mushrooming and the need for real time flexibility becoming apparent. Thus, the concept of CmCloud was first developed.

Of course, Wibu-Systems already provide an ultra-secure dongle-based licensing system that allows for network-based license access, and a slightly less secure software-based license that allows for a degree of portability. But as customers grow and evolve, so do their environments and the requirements of their licensing systems. CmCloud was developed to keep customers fully flexible.

The Pilot Program

At Wibu-Systems, it is very important that we develop solutions that customers actually want. We have never felt that we should simply build products and then explain why a customer should buy them: Rather, we always strive to understand from our customers specifically what they need, why they need it, and what their challenges are, and only then do we develop the software to cater to their requirements.

Most seasoned software professionals have been in projects where features were developed for software and then never used by customers. Sometimes, this happens because customer requirements were not accurately translated into features, sometimes because the features are just assumed: “Well, this is a great idea. Of course people will need that!” I have even known occasions where developers were working on a part of the codebase and decided themselves to add a new feature, because they felt it would be useful in the future.

Essentially, what we are talking about is writing code that does not have a verified use. This is a bad idea for a number of reasons:

• In any modern software environment, all code has an effect on other code and this can introduce instability: Why take the chance?
• New code always costs money to implement, which must ultimately be passed on through higher prices.
• All code needs support, documentation, and maintenance. This simply adds cost to the software and thus should only be undertaken if it is indeed used.

The purpose of the pilot program was to ensure that we at Wibu-Systems understood exactly what customer requirements would be. This was not just from the narrow-minded perspective of what a customer specifically wanted, but rather to understand their environments to ensure that we could anticipate future problems and address them early.

The Pilot Process

We developed a standard process when engaging with a pilot customer. This ensured that we would not miss anything important, but it also helped us refine the process, so that, as new customers came on board, we were able to anticipate any questions they might have and answer them before they were asked.

Setup

As product manager of CmCloud, before I could engage with customers, there were some preliminaries that needed to be addressed. Obviously paperwork needed to be completed, such as the standard Wibu-Systems MNDA (mutual non-disclosure agreement), though this was already in place with existing customers.

Four dongles were created for each pilot customer, each of which replicated only a part of the function of the regular FSBs in use. These were set with different encryption certificates to the customer’s original FSBs. In effect, it treated them like new customers and thus could not compromise their original secure setup.Then there was dongle creation, and here is where it gets interesting. Security is of supreme importance to us, and as such all customers are allocated their own FSB (firm security box) that provides the encryption capabilities the customer will need for protecting their software and generating their licenses. This is so complex and secure that Wibu-Systems itself cannot generate licenses for customers’ software, but we needed to do so in order to test the CmCloud solution.

• One to protect the software – sent to the customer
• Two to create licenses for the software – one for the customer, one for Wibu-Systems
• One to create the underlying certificate used by CmCloud – for Wibu-Systems

Of course, it feels odd to create four dongles for a dongleless licensing system, but these four dongles will be replaced in production with the company’s own FSB and only used to create licenses and protect the software. It is not needed for end users.

First Contact

The initial contact with the pilot customer was typically performed via an internet meeting and always included me and Dr. Bjoern Grohmann, Head of Corporate Technology at Wibu-Systems. We would explain why CmCloud had been developed and then give a demonstration of its use. Bjoern had written a simple visual application and was able to show how usage could be controlled remotely and in real time through CmCloud.

The easiest way to understand this is typically through the use of license quantity (LQ), which, in this environment, sets the number of times an application can run concurrently before CmCloud prevents startup. With LQ=1, only one instance of a licensed application can run at any particular time, while LQ=3 allows three instances to be used simultaneously. Obviously, other standard Wibu-Systems licensing metrics can be used in a similar manner, e.g. expiration time or license quantity. It is easy to see how licensing models can be built up around this structure.

Subsequent Meetings

I wrote a document explaining how to get up and running with CmCloud and always sent this to the pilot customer. Thus everyone was able to use CmCloud without any problems and as product manager this is particularly important to me: the software should be as easy to use as possible, since any problems that can be ironed out at an early stage.

Initially, we tried to have meetings every fortnight, depending on the availability and wishes of the pilot customer. After a while, this dropped to the occasional email to ensure they were happy and not stuck on anything.

Feedback was encouraged at every step of the way. Positive feedback is always welcome, of course, but constructive criticism is even more important, since this is what we need to improve the software - the whole point of the pilot program!

Feedback

The Good

The following comments are all 100% genuine and accurate, though clearly any identifying information has been removed since security is paramount.

"I really like this. It looks very cool.”

"And it looks very good. Actually I can use <one of our major products> as usual...A first performance test looks very good.”

"Very happy that it integrates so effortlessly.”

"…the concept is really promising … finally a real solution for licensing in virtual environments.”

The Bad

During the pilot phase, we discovered areas where CmCloud did not deliver exactly as the customer needed. We diligently logged these requirements and prioritized them, since the whole point in writing software is to provide what customers want.

Proxy support needs improving” was probably the biggest comment we received. With so many different types of networks with so many different implementations of proxies on so many platforms, it is a particularly hard problem to solve; but, because we were able to get this feedback early, we were indeed able to ensure CmCloud worked smoothly in proxy-restricted environments.

Variations of “I’d like some license reporting” were also recorded. It might not sound like it, but this is actually a huge product in itself, since “reporting” can involve a multitude of different nuances. For a while, we had been aware that a reporting element would likely be needed, so it was actually a very positive thing to receive confirmation of this. Thus we have been working on a reporting provision, for example, that the customer can see how many instances of a particular license is in use at any time. More enhancements will follow.

"We need credential management for large customers” was also a popular requirement. This is again a huge topic – one that warrants its own article – but suffice it to say, this will be provided.

The Ugly 

Nothing to see here: the software proved itself to be resilient and performant.

Conclusion

I think it is fair to say that the whole pilot program continues to be a huge success (we are still taking new pilot customers on). I have always found it to be of the utmost importance for customers to be able to talk directly to me about the products that I manage, so that I can personally understand the reasons for any pain: in that way, I can get problems ironed out more effectively. From a personal perspective I feel the pilot program was a huge success, because I was able to chat informally to pilot customers and get to know them a little better.
CmCloud is due to be released in December. Thanks to the invaluable feedback I received from our pilot customers, it will be better than it would have been and, for that, I want to thank them all.                                               

KEYnote 38 – Edition Fall 2019