In a recent post regarding Oracle’s Java lawsuit against Google I mentioned the Chinese proverb, “May you live in interesting times.” In the tech industry, this lawsuit certainly makes things “interesting!”
One question swirling around this suit is, “What effect will the outcome of this suit have on mobile phone OSs?” Not to sound too conspiratorial, it’s probably valuable to take a “follow the money” approach to this question. Here’s a quick analysis of the platforms and how they may benefit (or not) from this situation.
Google — Let’s dispense with this quickly. Even on the high end of conspiracy theories, Google really doesn’t have much to gain in this situation. The very existence of the legal battle will have a dramatic impact on the software industry’s investments in Android.
Apple — The iPhone has been a huge success for Apple, even with its self-imposed support problems. But Steve & Co. know that Android is eating their lunch (Android’s Mobile Web Consumption Share In The US Is Surging, iOS Share Dropping) Oracle and Apple aren’t exactly direct competitors — Oracle is incapable of Apple’s user experience and marketing capabilities, and Apple can’t be bothered with such back-office primitives as databases, ERP, etc. Seems like a great match, right? If Apple and Oracle are in league on this “lawsuit to beat up Google,” how does Oracle benefit? There’s the (potential) Java benefit directly, but that doesn’t require or need Apple. I doubt this is the behind-the-scenes reality, but be on the look-out for some kind of co-marketing campaign.
Microsoft — It’s pretty clear that Microsoft needs all the help it can get in the mobile space. The Windows Mobile platform has been a laggard for years (which is an eternity in the mobile market). Mobile phone and computing trends indicate that, at best, Windows Mobile whispers “Don’t forget about me. I’m still here!” Apple and Android together are the dominant, uncontested players in the mobile and tablet markets. Is it possible the Microsoft is in league with Oracle in order to put a big dent in the Apple-Android duopoly? Microsoft’s Windows Phone 7 platform was released to production this week and, IMHO, is a Hail-Mary attempt at getting back in the mobile game. In order to become a major contender in the mobility race, Microsoft has to succeed on many fronts, including getting mobile app developers to choose .NET over Java. Raising FUD over Java’s future, licensing, etc. would certainly benefit .NET. But…Oracle and Microsoft would be very strange bedfellows – very!
IBM — This is the obligatory inclusion of IBM. ‘Nuff said.
RIM / Blackberry – Really? I’m not going to spend much time on this possibility. It seems to me that RIM’s market share is rapidly dwindling and they really don’t have anything to offer Oracle.
Symbian — Who? Yes, Symbian is still used by some mobile phones. They have even less to offer Oracle than RIM does.
Oracle — “What?” you ask. “How could Oracle benefit in the mobile space? They don’t even play in the mobile space.” Right, but that may be the point. Just as Microsoft is trying to re-enter the mobile space, Oracle needs to get in, too. Maybe RIM or Symbian are working with Oracle and plan to take Oracle into the mobile space. “Pretty thin” as Sgt. Murtaugh would say.
VMWare — Now that we’re in “pretty thin” territory, I’ll bring VMWare into the picture. We already know that it is working on virtualization solutions for mobile devices, and it put its money on Java by acquiring Swing. VMWare made a good strategic move in partnering with Salesforce.com on VForce. Could it be promising Oracle inclusion in its mobile plans in exchange for freedom to use Java + Swing in all arenas?
So, where does that leave us? It seems to me that Apple and Microsoft stand the most to gain in the mobile space by Oracle’s suit against Google. Between the two, Microsoft seems to be a less likely bedfellow in this scenario. But then again, do you remember when Microsoft kept Apple alive in the ’90s?
Dana Blankenhorn has an interesting article on ZDNet today, Open source benefits from 7th circle of Apple hell. He recounts a trip with a friend to an Apple Store in Atlanta and says, “Three hours later I realized that Apple is back in the same box Steve Jobs put it in over 25 years ago.” Intriguing comment!
The friend’s iPhone was on the fritz, after waiting for more than one-hour in two separate lines at the Apple Store, Dana’s friend wisely gave up on the Apple Store. Fortunately, there was an AT&T store nearby and resolved the iPhone problem by … selling Dana’s friend an Android phone! Dana says, “A half-hour or so later my friend was a happy Android user, asking me if I wanted an iBrick.”
He goes on to say that Apple’s support model, particularly through retail stores, doesn’t scale. Apple’s “insistence on complete control meant it couldn’t meet demand.”
I tinkered with the first public beta of Microsoft’s new Lightswitch application development tool. Here’s a few initial thoughts:
Lightswitch makes it very easy to access data in pretty rich ways. Business people who are not developers will be able to unlock corporate data in ways that would typically require a developer or significant knowledge of querying tools, etc.
Lightswitch is easy, approachable, but there’s still some learning curve involved. Layout Items such as Vertical Stack, Horizontal Stack, Text and Picture, and so on provide rich user interface capabilities, but how long will it take users to learn how to use them properly.
Data access is very easy — maybe too easy. Just point Lightswitch to an existing data store and go!
Relationships to data are automatic or easy to assign. The features around these relations are very good — Master-Detail screens are super easy.
There’s no hard deployment requirement for Lightswitch apps. Yes, it requires Silverlight, etc., but you don’t have to deliver it into an IIS farm, etc.
OOPS! Businesses must realize that all previous points add up to the potential for major train wrecks with data. For example, data relationship features make it easy to create Master-Detail screens, but cascading deletes are just as easy.
Businesses should take great care to ensure that all Lightswitch application development runs against TEST data. Far too many companies ignore or skip this Best Practice, but they may suffer seriously if they aren’t careful.
Protect data at the database; not in the app. Again, this is a Best Practice for software design, but I wouldn’t expect business people to be in tune with it. DBA’s or data owners must protect production data and provide matching test databases (identical schema, data domains, security, etc.)
Don’t prototype and expand. People will be tempted to take a Lightswitch application’s generated code, turn it into a full-fledged Silverlight project and then build from there. Don’t! Is it possible? Probably, but it’s also possible to climb stairs to the top of the Empire State Building. I suspect future versions of Lightswitch will reduce this gap (a la creating OCX’s with VB back in the day)
Lastly, I did run into several bugs — not unexpected in an early beta. One example the product team may be interested in has to do with changing screen layout in non-debug mode (Ctrl-F5 from VS2010) results in
Error: The last change wasn’t successfully persisted. Please shut down the running application. Error: Change cannot be persisted because KittyHawk is not running under debug mode.
Companies’ major attraction to cloud computing is for cost reduction. No big news here; reinforces what we knew. Ability to implement solutions more quickly seemed to be a distant second attractor.
Companies’ major hurdle is security. Again, more reinforcement than news. This meme continues to interest me because I believe cloud security (or lack thereof) is driven more by appropriate architecture and implementation, and less by whether the system is cloud-based or not. Who owns the data seemed to be the second biggest hurdle.
Again, if this topic is interesting to you, I encourage you to check out Gartner’s site to replay the webinar.
I have a confession to make: I don’t use Java much. There, I’ve said it. You’ll have to take this post with whatever grain(s) of salt you determine.
I’m a software developer who works primarily in the Microsoft technology stack. Many years of C#, .NET, etc. in my history, and now Azure is my main focus area. However, I’m very interested in Android, so lately I’ve been tinkering with it and considering building an app for the marketplace. Isn’t it interesting that a cell phone OS is the pull for me to get into Java, GAE, Eclipse and even Linux? But that’s probably better saved for another post.
Consider the case for Android developers: The up-front costs for Android development is almost exclusively hardware. You need a development workstation and, eventually, Android devices for real-world testing. Linux, Eclipse, Java and Android are all free. Well, for now.
What happens if Oracle gets its way in the Java suit against Google? Would Google continue giving Android away for free while paying Java royalties to Oracle? These questions clear the fog a bit in terms of the suit’s potential impact. And those impacts have already begun. Many developers are now forced to take a wait-and-see approach to Java-based projects, including Android projects.
So it seems that Java-based or -oriented projects, big and small, are losers in this equation. Who are the winners? Will Oracle be a winner? They may well see a revenue upswing, but it will drive many away from Java. Will IBM continue it’s Java investments? That leaves Microsoft. Will Java developers migrate to .NET?
“May you live in interesting times.” – Chinese proverb
Who wins market share from #Oracle’s #Java suit on #Google? #Microsoft? #IBM?
The Rymer/Hammond post lays out Oracles options after acquiring Java. I agree with them when they say that Oracle chose to “Supercharge Java as a money machine.” The other option? Reinvigorate Java as an OSS leader.
Although it’s impossible to predict what will occur in the Java development community, I do think it’s clear that Oracle’s suit against Google will drive many formerly Free OSS (FOSS) systems to For-Profit OSS which would be better named OSSINO – OSS In Name Only.
If you’re using the ASPNETSimpleService sample for investigating Azure’s August release of AppFabric (currently in AppFabric Labs), you might like to know a simple change to enable more action claims.
The sample provides instructions for creating the necessary ‘reverse’ value for the ‘action’ claim in an ACS Rule Group. But what happens if you have more than one ‘action’ claim in the rule group (either by adding or by reusing an existing rule group)? The sample breaks and renders WebException, (401) Unauthorized. What gives?
The client app retrieves a SWT from AppFabric’s ACS and passes it to the web service. The web service (implemented in the sample’s default.aspx) verifies that the SWT contains the ‘reverse’ value of the ‘action’ claim. Unfortunately, the sample expects the SWT to look like:
This SWT will work fine. Notice the claim “action=reverse” at the beginning. If you aren’t aware (I wasn’t), multiple values of an claim are combined and separated by commas. So, if you have another value ‘translate’ for the ‘action’ claim, the SWT will look like this:
And that makes sense. Why include multiple ‘action=<value>’ sections? One simple change to the sample enables it to handle this situation. Around line 90 of the sample’s default.aspx you’ll see
// check for the correct action claim value
This bit of code is requiring that the actionClaimValue (which comes from the SWT) EQUALS the expected value (requiredClaimValue which set to ‘reverse’). In the second SWT above, the value of actionClaimValue will be “reverse,translate” which do not equal “reverse”
Simply changing Equals to use the Contains method fixes the sample. Based on this situation, I don’t think using Equals is a good idea for your apps. Contains is a reasonable alternative, but you may want to use a more rigorous practice.
I wish Microsoft would code Parse to handle this case more gracefully. I guess it seems like just a little thing, but when you’re connecting to the cloud tracking down problems like this takes too long.