Plugging into the Puzzle

I am a puzzle lover, through and through.  I love them in all shapes and sizes, from the complex mathematical puzzles that I face at my job to the “get the ring out of the contraption” toys that litter my desks and shelves at both office and home.  Even in my video game selection, I am a puzzle devotee – I will nearly never play an FPS title unless it contains multiple viable routes through a clearly delineated challenge (think Deus Ex or Thief), instead choosing titles like Legend of Grimrock or even the inscrutable Dwarf Fortress.

Some of my favorite puzzles aren’t ever designed to be puzzles, though.  One of my all-time favorites is reverse engineering – taking a compiled program, breaking down its internals and figuring out how they work.  It’s a lot like having a jigsaw puzzle where all of the pieces are blank until you connect two together – sometimes right, sometimes wrong.  You don’t really know what you’re looking at until you start connecting enough of those pieces together that you can begin to see patterns emerge.  After all, it ends up all being assembly code at this point, which becomes largely indecipherable to even the best minds when dealing with a large program.  The piece you’re looking at could be a trade-secret algorithm… or could be the code that draws a line underneath the menu hotkeys.  Figuring out which is which can be a slow and (in my mind) fascinating process.

One call. One jump. Modify a couple lines of code and all of that crap about licenses goes away.

Of course, reverse-engineering (reversing or RE, for short) has a lot of great concepts that you learn along the way – things like how your computer actually executes code, how memory and low-level CPU instructions work, and how people build programs in the first place.  That last part lends to one of the most “useful” functions of RE:  cracking software protection, no matter how it’s written.  See, somewhere in that great big pile of assembly or half-chewed virtual-environment code, there is ALWAYS some little instruction that says “Hey, this is a valid license!” If you can find it, you can patch so it always happens – whether a valid license is actually present or not.  It’s a fundamental requirement of programming – for as long as there is an x86 architecture and that executable file exists, it can be modified to bypass even the most amazing, convoluted licensing scheme.

One call.  One jump.  Modify a couple lines of code and all of that crap about licenses goes away (at least until the next patch).  It’s really no wonder that companies like Adobe and Microsoft want to move to Software-as-a-service (SAAS), right?

Let’s think for a minute about Adobe, which has a lot more at stake in this change than Microsoft does.  News has finally filtered out that the company plans to ditch its entire “Creative Suite” and move to a monthly (or yearly) license for its software, which will automatically validate and update itself to the latest versions so long as your subscription is current (and prevent you from using it altogether should your subscription be discontinued).
 
There are a lot of upsides to this as a consumer.  There will be no more having to plan upgrades or wonder if you’ll get the newest features of Photoshop or Premiere.  Everything will be current, all the time.  You’ll have access to subscriber resources that site-licenses don’t provide, because Adobe will be generating enough continual cash-flow to keep it rolling.  Best of all, instead of having to wonder where you are going to come up with between $500 and $2000 for the industry-standard software that you may only need for one or two quick things, you’ll be able to buy a month of access and then move on. This same benefit applies to people who just want to keep their skills current in that industry-standard software – buy a month, take a little refresher course, be up to speed the next time you’re posting for a job.

Will an online-only Photoshop stifle innovation?

Of course, there are a lot more upsides for Adobe with this model.  The company gets a comfortably predictable amount of monthly revenue from the licensing, allowing cash flow for future development.  Since new features don’t have to be “held back” until the next version to produce upgrade sales, development can move at a more organic pace.  The low cost for a single-month purchase means people who want to use a Creative Suite product but don’t need it long-term are more likely to toss a few bucks at Adobe to get the industry-standard software for their job rather than relying on other software or methods.

And, lest we ignore the obvious, a self-validating and self-updating executable will make cracking an utter nightmare… in fact, most likely, it will make no long-term sense in effort vs. reward.  The casual user will be better off paying for a cheap subscription than investing time into cracking it.  When a little bit of time investment saves thousands of dollars for a casual user, it’s a no-brainer.  When all it will save is $20, well… is it worth all of the effort and risk to find a working crack?  Any likely method to crack software like that comes with immense downsides (local caching, rerouting host tables, no updating, etc) anyway.  At some point, the hassle outweighs the benefit and the convenience of piracy is lost.

The same can be (and has been) said about Microsoft’s drumbeat toward Office 365.  Unlike Adobe, however, MS has a much larger application base that has a variety of storage and security concerns – it’s not surprising that they have backed off from the idea of killing the perpetual license.  Don’t get me wrong – Office 365 is a smart product, but running it alongside instead of in-place-of the standard Microsoft Office Suite for a few more years is not only good business but practically the only sane decision.  MS has mission-critical applications for a lot of businesses – applications which exist as a perpetually FREE (as in beer!) license in the open-source world through the continually advancing and improving LibreOffice.  People running systems on secured networks (as my office does) will be forced to convert if this change happens too suddenly.  Though Adobe has to compete with the likes of GIMP and a few other free tools, users of these know exactly how much they lack vs. the beauty and convenience of Photoshop et al.  LibreOffice, on the other hand, is a fairly consumer-friendly shift that MS will not want to push users toward examining more closely.

Microsoft is just as eager as Adobe to move online-only.

Whether it’s done this year or “within a decade”, it’s clear that these application suites have a lot of benefits to both users and creators by moving to a subscription-based SAAS model.  However, they ignore one very key component of what made each of them so successful in the first place – both suites are tremendously extensible, and many that use them for business applications (read:  those who actually pay for this stuff) take advantage of that extensibility by purchasing plugins and add-ons to enhance their productivity and workflow.

Why does this matter in the equation… especially enough to make it the focal point of an editorial?

Anything MS or Adobe puts in development can quickly destroy a plugin product’s market – there won’t even be anyone on “old versions” that could still use it.

Well, developing software that “piggybacks” on other software is a bit of a challenge in its own right.  See, first, you have to have the idea for the needed feature and feel comfortable that it’s not already coming in the next minor revision update.  However, you also need to know that the code base (the software you’re writing to work with) is stable, meaning only very minor revisions and changes will occur to the product.  This prevents your plug-in from having its own bugs and crashes because something in the base program has changed.  Third, you have to be able to rely on having access to certain parts of that base software – for instance, its user interface features, so you can add your plugin to the menus appropriately.

The more SAAS that these suites become, the less that any of these requirements is possible.  Development on the base code will happen as MS or Adobe see fit, and they will require no notice to third-parties.  Features will be deployed as they’re prepared instead of as major revisions, which means anything MS or Adobe puts in development can quickly destroy a plugin product’s market – there won’t even be anyone on “old versions” that could still use it.  The more frequently MS or Adobe put in enhancements and bug fixes, the less stable the code base will become – turning the act of coding even safely unique ideas into building a house on shifting sand.  Finally, the eventual migration to having things be more server-side than client-side means that these plugins will eventually lose their ability to plug in to anything at all, requiring software vendors to develop full self-contained programs that may be “compatible with” the suite instead. 

The ability to apply third-party additions is a huge part of why these products were ever so successful to begin with.

This may sound like a minor quibble, but third-party plugins and developer relationships are incredibly important.  Big ideas don’t usually happen from inside Adobe or Microsoft… they’re bought from successful third parties and migrated into the base products in future versions.  New plugins and add-ons are released all the time that transform these huge, basic software suites into targeted workflow tools for the individual companies that purchase them.  For example, Photoshop on its own is largely useless to a professional photographer – it is so powerful and expansive that it takes too long to do simple tasks.  However, there are a ton of plugins tailored to each type of photography that transform it into a tool many would never live without.  Microsoft Word in a largely digital-document office is hindered by not supporting the standard PDF file, but Nitro and Adobe both have add-ons that build it into the workflow.  Businesses that live on Excel spreadsheets oftentimes have complex plugins and modules for business logic.  The list goes on and on.

The ability to apply third-party additions is a huge part of why these products were ever so successful to begin with, and the new software model poses some tremendous puzzles for their developers.  We’re not just talking about who has what rights or how they’ll be protected and enforced here – we’re talking about the end of being able to reliably build these types of tools altogether.  Would you want to spend months developing something just to see it show up in a revision you didn’t even known was coming?  How about writing something that calls a function that gets changed due to a minor, unannounced bugfix, causing you to need to rewrite/recompile/redistribute?  And what about the eventual goal of moving many of these products server-side altogether, providing the subscriber access via a Web browser or limited client portal with little in the way of client-side execution?  How do you “plug in” to THAT?

Software-as-a-service has many aspects that need to be considered… but in the wailing and gnashing of teeth about purchase vs. lease and what license we’re actually paying for and what our rights are with it, we’re overlooking a piece of this puzzle that is more important than we give it credit for.  Large industry-standard frameworks become that way because of their extensibility and adaptability into various types of workflows – when you take that away, you are eliminating most of why it has become the standard in the first place.  Even if you don’t directly use any third-party plugins yourself, many of the features that have become part of the software started out as bolted add-ons from a third party trying to solve a missing feature.  Do you think Microsoft or Adobe will spend the money on all of the developers required to target all of the different splinters of 5% of the market here and 3% of the market there?

I’m not sure which is more of a puzzle – how small developers will cope, or how software like this will ever keep advancing without them.  But, with two major suites less to reverse or write add-ons for, I guess I’ll soon have a little more time to ponder it.