Hello again.
As promised I want to pick up this blog from the ‘Activation’ path we’re already going down. In a sense, activation is almost the middle of the software delivery chain in my view of the world. Incidentally my view of the world is shaped by many inputs: Microsoft’s licensing experience, deep interaction with customers that depend on licensing to help them run their business and some of the great accomplishments of all those individuals and companies that are out there doing business today.
Activation first enters the picture somewhere between the distribution of your software solution and the sale. The details of what activation means to your business should be well-defined before this point. From a life-cycle perspective this is where you begin to customize the end-user’s experience. The questions you should be asking are; “What controls do I have at this point?” and “How should I apply them?” At one level, there’s no easy answer. Besides a complete answer must include a good understanding of the business dynamics you are attempting to influence and how you will use an activation model to take your business in the direction you want to go.
Then there’s another level – the technical level that digs deeper into how activation works. That is where I am taking this blog today.
Activation models number in the thousands. But in the end analysis they all have a few things in common. One of the most controversial, but necessary functions of activation is the concept of binding. Binding occupies the base of the activation model at the technical level. Because many other operations in binding and licensing (the business dynamics) depend on the binding method used. It's no accident the method used to bind the license will typically be considered a fundamental business decision as well as a technical implementation. The most common method of binding to use for activation is machine binding. Machine binding has been around for decades. It has evolved to a state where it is today because there’s been no better option in the PC world. (Although it is worth mentioning that there has been no lack of trying: http://www.cdt.org/privacy/issues/pentium3/). Some of the other licensing models include binding to specific users, user pools, credentials, specific hardware devices, and some combinations thereof. By and large, machine binding is the most prevalent form of binding today. It is not uncommon to see some implementation of machine binding in every model of licensing.
Business imperatives have established machine binding as a crucial component of activation. This is because there must be something to activate against that can be readily validated. It wouldn’t be useful from an enforcement point of view to permit activations that bind to nothing. On the-other-hand, privacy considerations are real-world issues that require careful contemplation by each one of us and the industry as a whole. (Binding with personally identifiable information is another topic for another day.)
Machine binding, in the state it is in today, has an entire host of problems that range from the strictly technical to the more practical problems that revolve around user behavior. We’ll be looking in depth at the technical component today.
To bind a license to a machine, there’s an intrinsic need to derive a ‘fingerprint’ of the machine. This fingerprint should be unique – to a degree. This requirement almost always requires selecting machine-level constants that can be added to an algorithm. The goal is for this algorithm and the choice of constants to reliably reproduce the same result over a period of time. The fingerprint that results from this initial calculation, will be stored somewhere and used by some component of the licensing system to determine if a software license is permitted to run on the specified machine.
Almost all machine binding solutions today use some form of this approach to correlate licenses with a particular machine. The good thing is that everyone is doing it. The not-so-good thing is that everyone is doing it just a little differently and having very different experiences. One software publisher told me that this was the worst part of his job.
We’ll see why that is in a moment.
One of the challenges of machine binding is the fact that there is no standard for hardware manufactures to apply when they ‘ID’ their hardware. Even if there was, the hardware supply chains are so complex it is doubtful that the hardware vendors they contract with could apply the standard consistently or in a reasonable time-frame. Then there’s the matter of which hardware components to choose. At some point, you have to feed your algorithm the constants you will use to calculate the fingerprint. If the constants you choose fail to give you anything useful, then the fingerprint will become less unique – but not necessarily useless. So nearly everyone mixes something else into the formula to make the fingerprint a little ‘wider’ so all future comparison can be more reliable.
The initial fingerprint is then used as a constant to evaluate drift. Drift is the natural evolution of a machine’s hardware state. Hard drives fail and get replaced. Hardware upgrades are common these days. Hardware additions are a necessity for many popular applications. Components are replaced more frequently as machines become more reliable. Even if the physical hardware remains the same, it is quite common for a firmware update to change the identifiers for a hardware component. The result is that the fingerprint will change over time. This drift is used in the evaluation process that determines tolerance. Tolerance is the answer to the following questions:
• What will be allowed to change without invalidating the machine_ID (or device ID) binding?
• What can’t change without invalidating the machine_ ID binding?
• How many times can allowable things change without invalidating the machine_ ID binding?
• How many times within a certain interval can things change without invalidating the binding?
And there are at least a half-dozen other rules that are applied generically. In addition, certain publishers have even more constraints and conditions they choose to apply to the tolerance algorithm.
For nearly every rule in the tolerance algorithm you will be able to find real-world scenarios where the rule has adverse consequences. For instance, a rule or set of rules may cause the binding to be declared invalid where such a declaration isn’t warranted. This is certain to result in the wrong customer experience. It is not uncommon for such a rule to have severe consequences that range from angry customers to public outrage. Just as often is the case where the rule is too ‘lax’ and it enables something to be activated that shouldn’t be.
It’s important to recognize that the rule itself may be fundamentally solid, but then the rule must somehow negotiate with all the other rules and this in itself it very difficult to ‘get right.’ It's also a common technique to give more weight to one rule over another.
When you add in the earlier reviewed problem of unreliable constants (hardware IDs), then the combinations become incredibly complex.
If you hear of someone that has solved this problem, you are probably hearing part of the truth. What has happened it they have the right technical solution in place for their situation. However, there’s also another variable in there that isn’t as apparent but perhaps is the most critical. There’s the issue of enforcement tolerance. Enforcement tolerance is the level of pain you are willing to endure yourself or to put your customers through. The pain is somewhat governed by the behaviors of your user base. This is balanced with other business factors such as, how much revenue might be lost if the machine binding is relaxed and too many casual users are not activating within the business scenarios you have defined. Reducing the enforcement tolerance means a tighter machine binding, which is certain to inconvenience legitimate users after a certain threshold. Increasing the enforcement tolerance will result in the proliferation of users that are successfully activating below the threshold of acceptable use cases.
When we go back to what the publisher described to me was the ‘worst’ part of the job, he was speaking about getting everything in perfect harmony. For him and his team, it was a never-ending thankless job. Too harsh, and he was getting flak from support and sales. Too soft, and he was responsible for the company not being able to recover revenue. He said he learned to always err on the softer side. This ensured that support calls were kept to a minimum and he did not drive good intentioned customers away. I often hear the phrase: "Keep the honest customers honest" when the topic of enforcement comes up.
Our plan of record is to innovate in this area based upon the feedback we are hearing. One of our goals will be to ensure that our software publishers don’t have to understand exactly what’s going on under the hood to get the best possible activation experience for their products. This will require some considerable work and a fair amount of risk. We know that this is what you expect of us and we are looking forward to this challenge.
Terrence Nevins – SLPs Program Manager: (For the entire team)
We’re just finishing up our SP1 push and it should be out soon. I do have ton of activity to catch you all up on since I last blogged. You could probably figure this out from the silence. This particular blog will have an external focus – because it’s mostly about you and your reception to the product. We took a team to Barcelona, Spain for the European launch of SLPs. Tech Ed had over 4,000 attendees. We spoke to many of them in our 4 booths.
We had the chance to provide interactive demos, answer some very good questions – technical and non-technical, hand out lots of cool items, and meet very interesting people doing very interesting things. As a program manager in a product group, there is almost nothing more critical to my success than having the experience of being in the same space as you, the customer.
Some of you came to Tech Ed looking for answers to some hard technical challenges you are facing. Some of you came merely to find out what the next big thing is. What I found rewarding was some of you were really glad we were there. You had a mission to get some information about some aspect of our product.
At least a few dozen of you said that having some form of product activation or code protection was one of those things you were on the lookout for. I’m hoping that everyone that needed answers from us was able to find us and get information to take back to their colleagues and management teams.
The question I am hoping you are asking yourself is, ‘How many of those customers could meet their objective with SLPs today?’
Surprisingly, many of you found that we have enough features and functionality in our current offering to get you well on your way to meeting your requirements. This is not always the case with Microsoft 1.0 products as we are all aware of. This was no mistake on our part, but it also wasn’t a cakewalk either.
The next question I imagine you are asking might be, “Should I be looking more carefully at SLPs?” or…. “Am I missing something here?”
I’ll attempt to answer this question by group-profiling the set of customers that indicated SLPs was a viable solution for addressing their software activation requirements. The way I intend to do this is recalling the conversations I had with customers where they had already thought about what they needed and we simply said: “Yes” we can do that today.”
Here are the profiles:
If you are a software publisher (large or small) today and need a tried and tested means for distributing your product to the mass-market as a trial version – Tech Ed attendees confirm, SLPs has this one nailed.
If you are a software publisher (large or small) today and you need to know how many customers are using your software in-the-wild – Tech Ed attendees confirm, SLPs has this one nailed.
If you are a software publisher (large or small) today and you need a trustworthy mechanism to turn those trial users into more committed users (like get paid for your software!) – Tech Ed attendees confirm, SLPs has this one nailed.
If you are involved in an enterprise development team and you require the benefits of SLPs activation *(activation-explained later) – Tech Ed attendees confirm, SLPs has this one nailed.
If you are involved in enterprise development and you’d like to get detailed feature usage about your deployed applications – Tech Ed attendees confirm, SLPs has this one nailed.
For each of the above scenarios (and certain combinations of these scenarios), we were pleased to find that we can meet your expectations.
There were many more of you that were brave enough to come to our booth and ask, “What do you do?” I group these into three categories:
· Those that had some interest in ‘licensing’ or code protection
· Those that wanted the free stuff we were handing out and were just being polite
· Those that really wanted to hear if they were ‘missing’ something
With the exception of the middle category above, we couldn’t jump right into what our technology can do for them without understanding something about their business. Like most technical people (and I consider myself one) we tend to jump right into the technology because that’s where we feel most comfortable and empowered. But on the surface, SLPs is less about technology than it is about business.
Licensing is not a technical problem. Activation is not a technical problem. Feature usage is not a technical problem. Each one of them is a solution having roots in the business of software.
It comes down to this, SLPs can be a major component in your quest to have more control over your software business, but it is up to you to establish what your business problem is.
Here are the top takeaways from Teched and several other customer events regarding the business need software publishers and development teams have:
· True Up. This one is at the top of the stack. True Up (though not always called this) is the ability for two parties to agree that software usage falls on one side or the other of target. Mostly this is the recognition that a customer of an ISV is using more product than the contract allowed for. Nearly everyone I’ve spoken to in the context of ‘True-Up’ have confirmed that customers will compensate their vendors for this inconsistency (True-Up).
· Cost Justification. Producing software is a costly endeavor. ROI at a macro-level is no longer sufficient for budget planning. Executives are demanding more qualified and quantifiable metrics for costs associated with the lifecycle of a software product.
· Trial Conversion. For those that publish commercial software for the masses, getting a trial into a potential customer’s hands is a huge challenge. Making sure that the customer has every opportunity to evaluate what you have to offer is part of this challenge. In the end, you want to motivate customers to make a purchase decision.
· Enforcement. Simply put, this is the implementation of controls that will prevent or restrict the usage of software features/functionality based upon some formula or criteria. This dynamic has the most potential to become extremely complex very quickly. Some enforcement models I have heard require no less than a Visio diagram to communicate. Others like ‘Copy Protection’ are far simpler to describe. However, even this can get complex.
· Enablement. Enablement is the term we are using for business models that are beginning to emerge. This is quickly gaining momentum. One example of enablement is the ‘pay for use’ concept. This addresses many of the shortcomings that some of the enforcement models promote.
In my next blog, I’ll begin to go deeper into each one of these areas and attempt to drive some clarity into the business needs that might suggest an implementation to lean one way or the other. I’ll do this by sharing some real-life scenarios with you. * And I'll go into some depth on activation.
Terrence Nevins – (for the entire team)
We shipped three days early. Not a record here at Microsoft, but somewhat of a rarity in the world of software. It takes just a tad bit more effort beyond declaring code complete, test run completion and final signoff. When there's a service involved you get a chance to do a whole heck of a lot more work before you get to call it done. It's roughly the same things customers will go through if they decide to host our server... with a few notable differences. We get to do it first. Which means we are documenting, double-checking and back-tracking at a constant rhythm. Some things go faster than you expected - and others go slower. We had about 16 machines to get ready for the pre-production and production system. Loading software for the basic platform which includes virus protection and monitoring solutions. Of course before this there was sizing the right capacity and ordering. And in conjunction with putting all these machines into service was the chore of configuring for remote access, naming the servers, associating workloads and about a dozen other pre-requisites.
Since this system was never before put into production we decided to take on an extra chunk of work and do some load testing on the PPE and production system. We we're pretty certain that our app would behave as good or better than our test lab runs. "At least on paper it should," we rationalized. But you can't ever be too sure. We wanted to validate our network settings and load-balancing. As it turned out, this was a good decision. We had to make some tweaks here, and some tweaks there but at the end of the day we were able to top the numbers we saw in test. This level of confidence would have been extremely hard to come by if we hadn't taken the challenge to push for some solid metrics.
Good teamwork is essential. Mature attitudes that focus on getting the job done is the key to making a stressful period of time more interesting and rewarding. You can help drive this specific attitude by creating the right challenges. No one wants to be challenged to meet a deadline that can't be matched without sacrificing quality. However, meeting a quality bar and a challenging deadline are what constitutes interesting. The Ops team made a conscious effort to beat the date and in doing so built some time into the plan to ensure that we wouldn't have to drop quality or confidence. When things started getting tight, we were able to point to this plan, modify it ever so slightly and bring on extra help from the dev and test team. We didn't have to ask the dev or test team to bail water out of a sinking ship. It was more like we needed them to help us pitch more sails because we were bearing down on our destination.
I can write this success story almost two weeks after the event because I have the data that we all did the right thing. The service is up. It is still up. We have not had any outages and we are now getting through the backlog of work items that always crop up towards the end of the ship-cycle. A mature team of professionals is something to watch -whether it's a sports team, steelworkers sixty stories up, air-craft carrier personnel during a flight-ops or a pit crew. It's a whole other feeling however, to be a member of such a team.
Part of any product launch at Microsoft is taking your product on the road on the day you release or shortly thereafter. A group of us attended and exhibited at Software Business 2007 Conference. http://softwarebusinessonline.com/ -- I can't say enough about the interest in this service and the topic of licensing in general. I'm sure the marketing team will cover this on their website www.microsoft.com/slps - but I just want to say that the enthusiasm by ISVs. partners, and publishers for our solution was a nice reward for all the long days and nights.
Terrence Nevins - (For the entire team)
We got the server bits shipped. This is good news for those customers out there that want to run a licensing service using our unique technologies. Think about it... you can make a business providing the licensing services that software developers can use to recover lost profits. Or you can run a licensing service that you have full control over. There's a number of business models that make sense and each one of them has the potential to impact the bottom line. It's interesting to see the polarization in some customer segments when they begin to consider 'becoming' a service or becoming a customer of a service. The decisions are not always clear. What is clear is the fact that we offer choice. Choice is a positive thing for customers.
The SLPS team chose to break up our shipping milestones to make the release more manageable and perhaps more sane. Ship often will always mean ship smaller. But the 'first' time a product goes out the door the effort is measured in tons. A version 1.0 product will always be a big ship effort. In order to get enough useful functionality into a modern enterprise class software product you have to expect that it will take a monumental effort that is some part blood, sweat and tears. It's not just the code -- it's working with light specs (or none at all in some cases), balancing the demands of product managers, getting the support channel primed and ready, business reviews, legal reviews, user education reviews, design change request reviews .... to name a number of the not-so-obvious ones.
However, nothing comes close to the test effort. Starting with a build and a build notification process. Then there's the BVTs -- the validation tests that tell us if the build's even worth picking up and installing. If you're shipping version 1.0 the details of test will become ankle and waist deep at times. Test harnesses, smoke tests, unit tests, stress tests, test suites, ... so many moving parts and each one of them vital. Testing ideals always proclaim that testing should begin before the first line of code is cut. Yeah...right! (Just like coding shouldn't start without a complete spec or at the very least fully vetted use cases.) In real life you're adding testers long after the code has started. They begin their assigments weeks behind schedule. We have a great test team here in SLPS and one of the best test managers I've worked with. These last few weeks of ship mode have demonstrated the ability for the team to get behind their testers. We're getting caught up and we can see our ankles now!
We're bringing this one in on schedule. Beginning October 1 there will be a Microsoft hosted SLP Service available. In addition, you will have the option of downloading code protector as well.
We'll be keeping you up to date on the latest team progress as we start hitting our upcoming milestones.
[Terrence for the] SLP Services team
It's been cooking for the better part of two days now. (Stress tests) Just got an e-mail from our ever optimistic default release manager. Dilip Pai. Last week about this time we had some memory leaks and some other hard to debug issues that were preventing our stress run from completing. Dilip's our test manager so he's the last one to touch the running product. Test can't finish before Dev and everyone will always look at test and say, 'So when can we ship?' -- Dilip calmly saying, 'When we meet the criteria.' That, my friend, is exactly how it goes down.
I can remember back to the time -- not too long ago -- when the idea of a stress run was getting everyone you could find to log in over lunch, cross your fingers and if it's still running, out the door it goes. It wasn't just the apps that were bad in those days, Windows couldn't stand up to a strong breeze.
Product groups all have stringent stress requirements and criteria. It's typically defined long before the code is started. With each and every major version - the criteria becomes more demanding. We've all come such a long way.
It's more predictable now than ever -- we've got a solid platform (WS 2003) a great database (SQL Server) a fine application server (IIS) -- but still, there's a truckload of code sitting on top of all this that *we* (SLP Services) build and maintain. The stack is less fragile - thank goodness - but your expectations of us have also grown.
We'll be doing our part to exceed those expectations, today, tomorrow and for some time to come.
I feel a mini-ship party coming on tomorrow. Couldn't find a better Friday to wrap your fingers around a few cold ones and head out early to start the three day weekend.
Terrence
Very few events in my work life match the euphoria leading up to the RTM stamp. I know very well why this is. It's got something to do with being a valued member of team that values its members. Not shipping a software product for over a year is probably the worst thing a manager can do for retention, morale, quality, work life balance and all the other items that validate the 'worth' of a team and bond individuals to their mission.
Shipping -- It's where you and all your other team members prove their competence and commitment. Difficult decisions must be made. There's constant reminder of the cost involved with slipping. (I won't even go here.) You start the process with so much 'cash' in your hand and quickly find out it won't go as far as you thought. The technical skills can compensate to some degree -- the soft-skills MUST kick in. It's more than being able to negotiate solutions.... it's about being able to summon up a vast quantity of customer empathy and applying it to each decision.
'Customers' is a loose term for all the people that will experience consequence for a decision that you make. Customers -- sure, the ones that actually pay for the product or service. But there's so many more to consider -- marketing, sales, customer support, resellers, and the all important end-user!!!
This is when a great team shines. You get three or four (or more) people in a room and start whacking at the bugs before you. Everyone gets a say. Sometimes you 'win' - sometimes you're 'won-over' - sometimes you realize the cost is not worth bickering over. Other times you all look at one another and say: 'This one - we simply have to take...ouch!' No guilt, no shame, no blame, no games... just stay focused on the customer and be willing to consider your colleague's point of view.
We're at ZBB -- Zero Bug Bounce. A term we use to say we're nearly ready to declare our Release Candidate. Bugs we swat are staying down. Regression is zip.
We know we have a winning product and service that will very soon be in the hands of customers. We know it’s not perfect. You'll let us know that over the coming months, I'm sure. What we do know is that it is 'Optimal' -- That means that you will have enough features and functionality to reliably start using it to meet your business objectives -- soon! Enough of the right things at the right time. That's 'Optimal'
More next week as we get through the final stages towards our goal: RTM - Release to Manufacturing -- Like any good story or song -- there's a perfect blend of tension and release happening in Microsoft SLP Services.
Stay tuned,
Terrence Nevins (the mouthpiece for SLP Services Business Group)
Software Development should be a rewarding experience...
We've been heads down working on the 1.0 version of the Microsoft Software Licensing and Protection Platform. Small team, lots of work, incredible opportunity and the chance to help the 'rock stars' that make the Windows platform a rewarding choice. Windows has rewarded users with choices for workloads as versatile as games, enterprise servers, mobile devices and top end-to-end business solutions. This has made the platform a rewarding choice for ISV's, Partners and Developers. But not without some struggles and challenges.
That's where you come in. This blog is your blog. It's up to you to make us more nimble and responsive to your need for more information and guidance about how to go about getting your rewards. For sure, it's going to be a team effort to reach a unified goal.
MSLP has a unique position in the Windows ecosystem. Our success is directly related to your success if your success depends on combating privacy and protecting your IP. (Intellectual Property) This also means we have a responsibility to help you make sound decisions so you can begin to claim your reward. We don't have all the answers to the questions that have been asked by you and your colleagues - at this point it's safe to say we don't even have all the questions! But that won't stop us from pursuing the solutions that will enable you to be rewarded.
We think you deserve to get rewarded for your skills, talent and investments. We're software professionals too. We think we should be rewarded for our contribution as well. I speak for the entire SLP team when I say that our idea of a reward is to see that you're rewarded.
Visit our primary information portal, find out how to get rewarded and join the team. http://www.softwarepotential.com
Terrence Nevins - Program Manager: Microsoft Licensing and Protection Platform
Welcome to the Software Licensing and Protection Services Team Blog!
In the coming posts you will be able to learn more about the Software Licensing and Protection Services Team and the cool products that we are working on.
Our goal is to enable software developers and publishers to gain positive control over the distribution and use of their software intellectual property through easy-to-use protection tools and software licensing services.
Our first product, SecureLM is already available and you can find more information here: http://www.securelm.net.
