Go Ahead, Write Your Own Licensing Solution and While You’re At It, Write Your Own GL Software

It seems like every week I get into a conversation like this:

Me: “So how do you make sure that your customers are staying compliant to your software licensing terms? For example, if you have a user-count pricing model, how do you make sure only 30 are using it?”

Producer response: “Well, we built this little counter that we keep in the database and every time someone logs in, we check against it.”

Me: “So, you wrote your own licensing solution. Did you consider going to Flexera or other licensing technology providers to get this?”

Producer response Engineer: “I looked for some open source stuff, but it was so easy, I just did it. It took like a few days.”

Producer response Operations: “Yes, engineering just threw it together at the last minute. We don’t like it because we have to manually do this, but we can live with it.”

Producer response IT: “Yes, so and so from R&D put something together. I have no idea how it scales, but it seems to work. We just go talk to so and so if there is a problem.”

Producer response Product Management: “Yes, the developers took care of it. I have to go talk to them because I don’t know if it’s really counting correctly.”

Producer response Finance: “Yes, our R&D took care of it. It was so much cheaper than going with you guys.”

Alternatively, if I go to an existing Flexera customer I get into a conversation like this:

Me: “We’re coming out with this great approach to protecting your IP in virtualization environments.”

Producer response: “I bet that’s an extra charge. I wonder if we can just write our own?”

Me: “I think you’re asking the wrong question.”

In the early to mid-90’s when I worked with a large number of software producers, I would occasionally encounter “we wrote our own GL” with some shrugs. Of course engineers can write licensing technology, just like they can write GL accounting software, but SHOULD THEY?

Here’s my case for why software producers shouldn’t develop their own licensing technology, just like they shouldn’t write GL accounting software (and wouldn’t dream of it):

• Software licensing is getting more and more complex and changes rapidly
  • Environments are changing: new operating systems, new browsers and new hardware. How many flavors of Linux are there? Windows 8 sandboxing? Is Android here to stay? How big is the market share of Apples OS X?
  • Deployment models are changing: IT is virtualizing data centers, so can’t rely on specific hardware; mom and pop can’t handle IT requirement; they want SaaS;  government and their vendors sometimes can’t have internet connectivity or even access to USB
  • Pricing models are changing: no more lock to the device or floating licenses, now it’s “named user, device independent”, “draw down to zero”, “allow them up to 100, then charge every month”, “after 1 year, they cannot use the software”, “counts are going to be based on multiple parameters”
  • Geographies are driving new behaviors: large enterprise “all you can eat” models for a few trusted global companies, treat China/Russia/Brazil as hacking heaven so be casual hacker proof
  • Users are more connected and more technical: connectivity means they want the licensing process to happen invisibly (“don’t bother me with that”) and more technical means they understand that it’s not rocket science to make it “invisible”
• Back-office integrations must be considered
  • Gone are the days when licensing was just something an engineer just threw in the product. Now IT, Operations, Customer Service, Customer Experience, Channel Management, Legal and Finance all need to make sure that this is (a) supportable (b) efficient/nice user experience (c) scalable, will it support product releases for the next 3 years (d) meets revenue recognition rules (e) helps ensure that customers renew, etc.
  • Product Managers and others want to get data about downloads, licenses generated, etc. so that they can data mine and become smarter, better aware of how customers are behaving, what they are using, and how fast they are adopting, etc.
• It’s going to be so much cheaper if we do it ourselves
  • Right, just like writing your own GL accounting software is going to be cheaper
  • Most of our customers do buy vs. build analysis and it comes to “Flexera is either break even with homegrown or, over time, cheaper after X years”
• The opportunity cost isn’t zero
  • If R&D and IT are all working on implementing a homegrown solution, what are they not doing?
    • Upgrading to the latest version of GL accounting software?
    • Adding new capabilities to your products

So back to my question – they COULD build it, sure, but SHOULD they?

• It’s going to be more complex than they think
• It’s going to change faster than they want
• It’s going to have a broader impact than they dreamed

What other reasons are you still using homegrown software licensing?

Read related blogs on why your should partner with a software licensing and entitlement management expert.

• Top 10 Signs Your Homegrown Licensing is Broken
• Why Producers Need a Proven Commercial License and Entitlement Management System to Support the Full Software Lifecycle Process
• Why Salesforce.com Isn’t Suited for Complex License and Entitlement Management Processes