Tag Archives: adobe

Adobe Creative Cloud, Microsoft XBox One and the New Age of Hacking

The first half of 2013 has seen some significant announcements from some of the biggest tech players out there; Sony revealed (sort of) their plans for the PS4, Adobe announced that their Creative Suite products are going in the cloud (aka Creative Cloud) and finally Microsoft revealed their competitor to the PS4, the XBox One.

The interesting thing about the last two is that there’s the need to connect to an internet based authentication system on a frequent basis to validate the software/configuration (to be completely validated by Microsoft, but this appears to be likely).

Adobe’s Move to Cloud – Competitors Start to Gain Share?

In the case of Adobe, their Create Suite product is still installed on the local machine but they now have the ability to push smaller updates to their products, whereas before it tended to be “big bang” approach. Adobe are charging consumers $50 per month to access this service which gives them all the Adobe Creative Cloud products (Photoshop, Muse, etc.) – thus removing their multi-tier, one-time upfront payment product matrix approach (Design, Design Premium, Production Premium, Master Collection versions). Once subscribed, the user has some great features available to them – some of which were available to them previously but in a more fragmented, less integrated fashion.

However, $50 for the casual user may be a price barrier for Adobe; Over 2 years, one user would pay $2400 for the service (a little more than owning Creative Suite Master Collection); however, unlike the old pricing model, the costs continue (but so arguably do the updates, product features, etc.). More casual users of the toolset would then argue that they could have paid $600 for access to (say) Photoshop and now their costs are exponentially higher for a service they only want 15-25% use of. This would then create a market opportunity for others (e.g. Corel Painter) to step in and provide a migration path including an ability to take existing PS Plugins and continue to use them. In this scenario, Adobe would significantly lose share of the consumer market and possibly gain additional business users who are enticed by (a) not having to pay for something they possibly use personally as well as professionally (b) costs are spread over a continuing cycle which could be easier to justify/expense.

XBox One’s Kill the Hacker Approach

For Microsoft, it is claimed the XBox One will expect to connect every 24 hours – possibly for the same update push reason as Adobe, but also because Microsoft are probably trying to combat the hacked systems out there that allow people to play pirated games (Both XBox and XBox 360 can be hacked relatively easily and there’s no shortage of pirated games). It also means they can control the use of used and borrowed games – effectively removing the used games market for all but the big players and stopping friends sharing their legally bought games, as each game is tied to a user ID. It will also be interesting to see how this affects services such as GameFly and Redbox – both whom allow the renting of games.

All it needs is one Service

There’s an old saying that goes to the effect of “the more you try to grip a grain of sand, the more it slips away” – and this is true for technology. Think of all the product launched with security and protection built into them and think how many have been hacked, cracked and/or broken. The answer is most, if not all of them to some degree – and this is exactly what will happen here.

Simply put, if a product needs to connect to the internet to validate, it’s going to send communications out. These communications can be intercepted and re-routed to another service pretending to be the authentication service which sends back a “All is OK” signal. Now this may cripple some of the features of the product (e.g. updates, access to other services by the vendor), but people are already accepting that (XBox 360 hacked consoles can’t connect to Microsoft services otherwise they get banned [but there are ways to fix them]). Additionally, if the costs of owning a legal copy are such that owning a crippled copy that is workable for free or a significantly reduced charge is acceptable then folks will use that service. All it takes is one provider to offer an authentication service priced for volume subscriptions….

What’s the Solution?

Companies looking to create more adoption and disuade piracy should look at Valve’s Steam platform. This service has continually shown how consumers will happily adopt a system that is priced fairly and yet still offers an extensive service. Yes, there are still cracked versions of software that bypass it, but it also has a pricing model that increasingly negates the hassle of using cracked software – I’ve even seen others posting on forums as such.

Adobe should consider a tiered approach to their Cloud offering (I suspect they are, but are waiting to catch the early adopters and business users with the premier pricing) and Microsoft need to consider that they are not the only player in the market, so should take a pragmatic approach – e.g. You can install games for a period of 24 hours (for example), after which it either has to be licensed to your ID or deleted.

Or they can try to grip the market and let consumers slip away.

Adobe and the future of Flex

On the 15th November 2011, Adobe effectively announced that it no longer saw Flex as a long term going concern and would push it into the community/open-source domain (semantics aside), as it realized that HTML5 combined with comprehensive Javascript libraries such as JQuery were the future. There was mixed reaction from the Flex community, covering both positives and negatives of this announcement, but after the dust has settled what does this really mean for Flex, Adobe and the community?

It’s a beautifully ugly thing

I’ve always had mixed feelings about Flex as a platform; on one hand I found the to be much elegance and simplicity of the architecture – XML for layout; Javascript-u-like for code seemed a fantastic approach, particularly as it opened up the possibility of writing your own Flex app without the need of a $$IDE. However the delivery through what is basically a Flash container always concerned me as it limited the available platforms (no need to rehash why Flash/Flex doesn’t run native on Apple mobile devices).

So Moving Off Flex Is Good?

Strategically speaking this is the right move for Adobe; Using HTML5 + JS….

  • Removes the run-time dependencies of Flash
  • Creates a wider base of developer community
  • Standardises on technology/architecture
  • Adds more pressure on the less compliant browsers to man-up (Internet Explorer – why are you even still here?!?)
  • Allows touch-capable mobile devices able to consume applications

However there are still challenges:

  • We’re back to the browser inconsistency world; implementation of HTML5 is not standard across all browsers
  • There isn’t yet one “go-to” Javascript framework implementation or standard

So there are still a few key open issues that need to be solved, buying Adobe some time to continue to support Flex with a view to moving folks to the next big platform. Once could argue that there needn’t be one Javascript framework as we’ve all managed fine for some time – but to have a reference implementation that is open and standard (as possible) would be a great thing.

Should Adobe Acquire?

If I was Adobe I would be deep in discussion already with the likes of the folks who make JQuery, mooTools, 960Grid, etc. with a view to acquisition. These Javascript frameworks have built a reputation of quality and capability which has made many developers lives so much easier.

JQuery would undoubtedly be everyone’s first choice as it has gained popularity in the community and has many extensible attributes and add-ons covering both User Interface elements and mobile device support. However, I cannot pass up an opportunity to mention and often overlooked framework which came out around the same time as JQuery and in my personal opinion, has a some architectural advantages (though cool architectures don’t always make happy users) …. I refer to MooTools. You can draw many parallels between mooTools and JQuery, although the former takes a hit in terms of adoption. There are many “versus” articles out there (here, here, here) for you to make up your own mind. I speculate JQuery will win if only for popularity.

Adobe did try their own framework of sorts (Spry) with limited success; partnering with a JS Framework might be a good first step, but without acquisition or co-ownership they lose control of the roadmap. Producing their own framework might be a bit late in the game, so it stands to reason that obtaining a popular and well supported framework such as JQuery with its’ vast community would be the best thing to do.

So What’s Next?

I foresee a roadmap to a new Adobe application which will allow the creation of HTML5 applications in replacement of the Flex Builder product. It will be a hybrid that takes MXML (layout/UI) and ActionScript (action / code)  and (somehow) compiled /assembled into an HTML5 app. We’re likely to see an announcement over the coming months.