On Eclipse, Java and Rich Client Platforms

Given the attention I’ve been giving to network/services based approaches lately (1, 2, 3, 4, 5, 6, 7, and there are still more) it may come as a bit of a surprise that I track rich client happenings as well. I do believe that network applications and rich clients are headed in opposite directions in terms of adoption and growth, and that network applications will continue to erode the installed base of rich clients (as they have in email and CRM, for example), but at least for the forseeable future there will be tasks that require a little more client side horsepower.

Enter Eclipse. One of the areas where we’ve been watching the project most closely is in their progress towards becoming more than just a shell for development plugins with their rich client efforts. We’ve thought this was a big deal for a while now, but it still seems to get – strangely – very little attention.

The more I think about it, however, the more I agree with something I posited a while ago: Eclipse will be competing with Java. On the face of it, this is a rather absurd notion given the fact that Eclipse is in fact based on Java, and while it supports other languages, it is still far and away most closely aligned with Sun’s creation. When I asked the Eclipse folks whether they’d heard this mentioned as a concern before, they said that I was the first and only person to raise it. So maybe I’m just being silly.

Consider, however, the rich client landscape as it exists for enterprise developers today. The traditional approach was simply to design natively for Windows, eschewing cross-platform support because there were no other platforms – on the desktop – that needed to be supported (yes, I’m oversimplifying). While that hasn’t changed all that much (at least stateside), IT departments are at least looking to keep their options open these days, meaning that cross-platform is very often back in as a requirement. So in addition to the dominant native Win32 or .NET development paradigm we have language/platforms like Java and, perhaps, Mono/Python.

So those are a few of the players. There are others that could be included, but that’s besides the point. All of them, I think, face a clear and unambiguous threat to their desktop significance. It’s clear from where I sit that these would be rich client players and their respective platforms are going to be increasingly squeezed by the network services like Salesforce.com – at least in terms of enterprise applications. Yes, the software-as-a-service contenders lack a credible, mainstream solution for the intermittent connectivity problem, but as the US finally catches up to the rest of the planet in wireless connectivity I expect many of those issues to decline. And no, they’re not suitable for every task, but who would have thought 5 years ago that they’d be able to capably handle CRM?

What we have then is a few players fighting over what I would characterize as a shrinking pool of enterprise rich client developers and ISVs. Eclipse and its rich client ambitions are yet another mouth to feed in a hungry household. In that respect, Eclipse – should its rich client project take off – could negatively impact all of the above players. Interestingly, Eclipse could – despite its close ties to the language – hurt Java’s desktop ambitions the most by poaching developers to its platform, as opposed to straight up Java. It’s like the baseball MVP voting every year; having two candidates from the same team, as the Sox consistently do in Manny Ramirez and David Ortiz, ends up making both players non-factors in the vote.

Of course, you could look at it the opposite way, and say that an Eclipse takeoff would float all Java boats, and to some extent I agree. I very much doubt, however, that Sun would subscribe to that notion.

So what do you guys think? Am I crazy?