Ares is in public beta and I’m not going to pretend I found it smooth going. No doubt it will be fine after a little patient learning. It is amazing, with drag-and-drop visual interface builder, code editor, source code management, debugger, and logging.  Microsoft’s Internet Explorer is not supported in any version; you need Mozilla Firefox 3.5 or higher, Apple Safari 4.0 or higher, or Google Chrome 3 or higher.

The online IDE uses a bit of Java but seems to be mostly HTML and Javascript. If you try to launch the application, you need a Palm emulator running locally, but you can preview in a browser without any local dependencies.

In order to try Ares, you have to sign up for Palm Developer Center. As part of the process, it appears that you have to give Palm permission to charge fees to your PayPal account, which I disliked, though membership is free for the time being. Of course you hope that any fees will be more than offset by the steady chink-chink of income from your app sales.

Is this the future? My immediate reaction was to be very impressed; a little further in and I was greatly missing the comfort of Eclipse.

Still, this stuff will get better; and the idea of just browsing to an URL to continue development is compelling.

Related posts:

1. Amazon FPS – is this the micropayment revolution?
2. Google’s new model of app development
3. eBay insisting on PayPal only in the UK

It is a good read, as you would expect from Thoughtworks, a software development company with a bias towards Agile methodology and a formidable reputation.

The authors divide technology into four segments, from Hold – which means steer clear for the time being – to Adopt, ready for prime time. In between are Assess and Trial.

I was interested to see that Thoughtworks is ready to stop supporting IE6 and that ASP.NET MVC is regarded as ready to use now. So is Apple iPhone as a client platform, with Android not far behind (Trial).

Thoughtworks is also now contemplating Java language end of life (Assess), but remains enthusiastic about the JVM as a platform (Adopt), and about Javascript as a first class language (also Adopt). C# 4.0 wins praise for its new dynamic features and pace of development in general.

Losers? I was struck by how cool Thoughtworks is towards Rich Internet Applications (Adobe Flash and Microsoft Silverlight):

Our position on Rich Internet Applications has changed over the past year. Experience has shown that platforms such as Silverlight, Flex and JavaFX may be useful for rich visualizations of data but provide few benefits over simpler web applications.

The team has even less interest in Microsoft’s Internet Explorer – even IE8 is a concern with regard to web standards – whereas Firefox lies at the heart of the Adopt bullet.

In the tools area, Thoughtworks is moving away from Subversion and towards distributed version control systems (Git, Mercurial).

Finally, Thoughtworks is Going Google:

At the start of October, ThoughtWorks became a customer of Google Apps. Although we have heard a wide range of opinions about the user experience offered by Google Mail, Calendar and Documents, the general consensus is that our largely consultant workforce is happy with the move. The next step that we as a company are looking to embrace is Google as a corporate platform beyond the standard Google Apps; in particular we are evaluating the use of Google App Engine for a number of internal systems initiatives.

A thought-provoking paper which makes more sense to me than the innumerable Gartner Magic Quadrants; I’d encourage you to read the whole paper (only 8 pages) and not to be content with my highlights.

Related posts:

1. ThoughtWorks Mingle: is JRuby always this slow?
2. Salesforce.com + Google + Adobe Flex and AIR = New Internet platform?
3. Programming language trends: Flash up, AJAX down?

This is a fairly obscure feature, and I’m fairly surprised that it was included at all, but doubt it’ll be of use to the vast majority of current and future Silverlight developers out there. Like the html control, it’s a crutch, to allow developers that want to use Silverlight a way to leverage existing investments. The mantra I’ve heard out of the Silverlight team is to focus on unblocking customer scenarios (scenarios they cannot unblock themselves) without compromising the overall feature goals (like keeping the runtime download small) … it’s an edge case feature that doesn’t affect Silverlight’s over all "Cross-Platforminess".

The idea that COM automation is merely an “edge case” surprises me, even though I also recall it being described like that at PDC. Access to COM automation gives a Silverlight desktop application on Windows substantial extra capability. At PDC program manager Joe Stegman showed how Silverlight 4 can integrate with Office, sending data into an Excel spreadsheet: an example with obvious value for real applications. I also heard developers at PDC discussing how they might wrap up a Silverlight application with a COM DLL, creating an application which in effect has full access to the local operating system. Although Silverlight cannot access the Windows API directly, there are no such restrictions on the COM DLL, so the combination means that pretty much anything is possible.

Let’s also bear in mind that Microsoft’s Brad Becker is on record saying that one day WPF and Silverlight might simply become different .NET profiles. He told me this at Mix earlier this year; and said a similar thing to Mary Jo Foley at PDC:

Some day — Microsoft won’t say exactly when — Silverlight and WPF are going to merge into one Web programming and app delivery model that, most likely, will be known as Silverlight, Brad Becker, Director of Product Management for Microsoft’s Rich Client Platforms, told me this week

If Microsoft is contemplating such a thing, then clearly full access to the native features of Windows will have to be possible.

I am not entirely negative about this prospect. Even if you are only targeting Windows, Silverlight has a lot to commend it: a small runtime, easy setup, and options for browser-hosted or desktop deployment. If you have ever wrestled with the Windows installer or tackled a failed .NET runtime installation you will like the simplicity of running a Silverlight application.

Nevertheless, with version 4.0 Microsoft is changing its Silverlight story. It is no longer a pure cross-platform play; rather, it is a runtime where some features are cross-platform, and others Windows only. Microsoft calls this developer choice; I see it as evolving into the inverse of Sun’s aim with Java. Sun tried strenuously to guide developers towards cross-platform, but provided a way out – via Java Native Interface – if absolutely necessary. Microsoft will provide cross-platform where we really need it, but make it easy to slip into Windows-only development in order to get some nice feature like a location API, or Office integration.

I see this as an advantage for Flash, because developers know that Adobe has no incentive to prefer one operating system over another – except to the extent that minority platforms (like desktop Linux) tend to receive less investment.

Personally I think Microsoft should at least provide a way for Mac users to get similar benefits – perhaps by implementing something like the native process API in Adobe AIR 2.

I also think Microsoft will have to get real about Linux support. It is wrong that Microsoft will cheerfully state:

Silverlight 4 runs across all platforms and major browsers

as it does in the “Fact sheet” handed out at PDC; while leaving Linux implementation to a third-party process uncertain in both features and timing. Here is the reality of cross-platform Silverlight, in a screenshot taken seconds ago from Linux:

Right now it is a two-platform play – admittedly, the two platforms that matter most, especially in a Western world business context, but never forget that Google Chrome OS is coming.

Related posts:

1. Silverlight: developer win, designer fail?
2. Silverlight 2.0 is released, Eclipse tools for Silverlight announced
3. Intel gets into the App Store game – but where does Silverlight fit in?

In other words, the free part is the core IDE plus a few features; the commercial edition adds a lot of value for most users.

CEO Sergey Dimitriev remarks:

Open source has become the mainstream, and we continue to embrace it as an exciting challenge. In brief, we’re not changing direction — we’re moving forward.

IDEA is an excellent and popular IDE and last time I looked I found it more productive and enjoyable to use than its obvious alternative, Eclipse. I imagine that IntelliJ is hoping to strengthen the community and availability of add-ons for IDEA, as well as attracting new users.

Although this is welcome news – and I’d encourage any Java developer to try the product – it would be interesting to know more about why JebBrains is taking this step. Borland’s JBuilder was once highly successful, until the free Eclipse offering eroded its market share. Seeing how important the add-on community was in Eclipse, Borland belatedly issued a free JBuilder and sought to make it an alternative IDE platform for third parties, but by then it was too late. JBuilder was discontinued and a new product of the same name appeared in its place, built on Eclipse; it is still available but is now a niche product. I’ve not got any up-to-date figures but I’d expect JBuilder’s market share to be tiny now.

Unlike JBuilder, IDEA has remained popular despite Eclipse. Comments on stackoverflow, for example, show how well liked it is:

Eclipse was the first IDE to move me off of XEmacs. However, when my employer offered to buy me a Intellij IDEA license if I wanted one it only took 3 days with an evaluation copy to convince me to go for it.

It seems like so many small things are just nicer.

The problem is that the free Eclipse, or free NetBeans, or free Oracle JDeveloper, are good enough to get your work done, making it hard to compete; and I am not sure whether the addition of free IntelliJ IDEA to the list is a sign of strength or weakness.

My guess is that serious users will still want the commercial edition with its many additional features, so this may not be as radical a step as it first appears.

Related posts:

1. JetBrains OMEA going free and open source
2. Sun’s Jonathan Schwartz makes the case for free and open source software
3. Borland’s JBuilder-on-Eclipse emerges

In order to participate as a developer, you have to sign up for the program, which will cost $99 annually though currently it is free. An interesting twist is that the developer program is a component market as well as an application market. Write a cool component, and you can get paid whenever any application that uses your component is sold. Intel handles all the business details, for a cut of course.

Intel is supporting two operating systems, Windows and Moblin, Intel’s Linux distribution. Your applications must be one of the following:

• Native Windows (I am not sure whether .NET is allowed)
• Native Moblin
• Java
• Adobe AIR

A puzzle is that Intel’s press release makes several references to Silverlight as a cross-platform runtime; yet although there is a Linux version of Silverlight, called Moonlight, there isn’t any exact equivalent to AIR for desktop Silverlight and I am not clear how Silverlight fits in any of the categories above. I may be reading too much into this; but perhaps all will be explained when Silverlight 4 is unveiled at PDC in November? Here’s what the press release says:

“Using Silverlight’s cross-device, cross-browser, cross-platform technology, developers will be able to write applications once and have them run on Windows and Moblin devices – expanding the reach of Silverlight applications to more consumers, regardless of whether the device they’re using is a PC, TV or phone,” said Ian Ellison Taylor, general manager, Microsoft Client Platforms and Tools.

Note that despite the above quote, Moonlight 2.0 is still in beta, and no current phones include the Silverlight runtime.

Apps must be delivered in one of the following forms:

• .msi (for Windows*)
• .jar (for Java*)
• .air (for Adobe® AIR*)
• .deb (for Debian Mobilin/Linux)
• .rpm (for RedHat* Linux)

All applications in the store are subject to Intel’s approval (called validation):

The validation process checks your code for suitability for the Developer Program, licensing and legal issues, and some basic functionality.

Here’s the checklist. Note this requirement:

Runtimes and technologies the application can support can only be any of the following: Moblin* Native, Windows* Native, Adobe AIR*, Java FX *, and Microsoft* Silverlight*.

Hmm, Silverlight again.

Intel gets 30% of your revenue. You can also market components and if your application uses a paid-for component a share of the revenue will be paid to the component vendor. Free applications and components are also permitted.

I really like the checklist – I wish all desktop applications conformed to some of the requirements. Like this one:

The application will completely uninstall when desired, and leave no garbage files behind.

are great to read.

You can sign up here, though the SDK is not yet available.

One curious facet of the program is that although it is specifically for the Atom, in most cases your application will likely run fine on other processors. I am not sure if Intel will do anything to ensure that only Atom-powered computers use the store.

In May I posted that we should get ready for more app stores. This is really coming to pass now, with Adobe’s offering which I mentioned yesterday, Nokia’s Ovi, as well as others for Android, Palm Pre and so on.

Related posts:

1. Microsoft brings Silverlight – not Mono – to Linux via Intel
2. Hands on with Intel Moblin
3. Nokia Maemo, Intel Moblin gives way to MeeGo

Here is what I found interesting. First, there’s a shift towards Linux and Apple Mac in the desktops developers use for Eclipse. In 2007 it was 73.8% Windows, 20% Linux and 3.5% Mac. In 2009 it is 64% Windows, 26.9% Linux and 6.9% Mac.

This is echoed in deployment platforms too (client and server). In 2007 it was 46.5% Windows, 36.6% Linux, 1% Mac; today it is 40.5% Windows, 42.7% Linux, 3% Mac.

Those surveyed were asked what other IDEs they used. I noticed that Microsoft Visual Studio and NetBeans feature fairly strongly; I also noticed that Embarcadero’s JBuilder is hardly a blip on the chart – intriguing, given how popular this used to be in the pre-Eclipse era.

The most popular code management tool is Subversion (57.5%) followed by CVS (20%). For build tools, Ant (33.4%) and Maven (18%).

Here’s an intriguing one: I often hear that Java is only successful on the server. That presumption is not supported by this survey. 23.4% said that desktop client apps are the primary type of software they are developing, compared to 30.2% server, and 24.7% web or RIA apps.

The preferred app server is Apache Tomcat (34.8%) followed by JBoss (12.7%) and Websphere (6.9%).

The most popular database manager is MySQL (27.7%) followed by Oracle (27.3%). That’s 55% for Sun+Oracle, of course, though bear in mind that many of the MySQL users are likely attracted by its free licence.

Before drawing too many conclusions, bear in mind that it is a small sample self-selected by people willing to take the survey; apparently it was also featured by a German technology site which resulted in a larger response from German visitors.

Although it suggests a declining use of Windows – which is especially plausible given the trend towards web applications – it does not prove it beyond the Eclipse community.

And next time – how about using the same questions, which would make it possible to identify trends?

I’ve also written about Eclipse here: The Eclipse Conundrum: can it grow without hurting its contributors?

Related posts:

1. Eclipse, WebSphere winners in latest Java survey
2. Survey ranks developer tools, and reveals what developers care about most
3. Oracle, JDeveloper and Eclipse

It is possible to build a successful business around open source software. Zend is doing it with PHP; Red Hat has done it with Linux. These are smaller companies though, and they have not tried to migrate an older business built on a proprietary model. A further complication is that Sun is a hardware business, and although open source is an important part of its hardware strategy as well as its software strategy, it is a different kind of business.

Maybe the strategy was good, but it was the recession, or the server market, that killed Sun. In the end it does not make any difference, the outcome is what counts.

Reading the official overview of the deal, I see lots of references to “open” and “standard-based”, which means nothing, but no mention of open source.

The point of interest now is what happens to Sun’s most prominent open source projects: OpenOffice.org, MySQL, Java and OpenSolaris. Developers will be interested to see what happens to NetBeans, the open source Java IDE, following the Oracle acquisition, and how it will relate to Oracle’s JDeveloper IDE. These open source projects have a momentum of their own and are protected by their licenses, but a significant factor is what proportion of the committers – those who actually write the software and commit their changes to the repository – are Sun employees. Although it is not possible to take back open source code, it is possible to reduce investment, or to start creating premium editions available only to commercial subscribers, which already appeared to be part of MySQL’s strategy.

I presume that both OpenOffice and Java will feature in Oracle’s stated intention to build an end-to-end integrated solution:

Oracle will be the only company that can engineer an integrated system – applications to disk – where all the pieces fit and work together so customers do not have to do it themselves. Our customers benefit as their systems integration costs go down while system performance, reliability and security go up.

says CEO Larry Ellison, who also says nothing about open source. This will involve invading Microsoft’s turf – something Sun was always willing to do, but not particularly successful at executing.

The best outcome for the open source community will be if Oracle continues to support Sun’s open source projects along the same lines as before. Even if that happens, the industry has lost a giant of the open source world.

Some good comments from Redmonk’s Michael Coté here.

Related posts:

1. Sun reflections: open source but not open development?
2. Sun’s Jonathan Schwartz makes the case for free and open source software
3. UK lagging rest of Europe in open source adoption

Nowadays very few Mac/PC users have any idea where any program is executing.

And why should they? Users want stuff to just work, after all. Bloor says more clearly than I have managed why RIA is the future of client computing. He emphasises the cost savings of multi-tenancy, and the importance of offline capability; he says the PC will become a caching device. He thinks Google Chrome is significant. So do I. He makes an interesting point about piracy:

All apps will gradually move to RIA as a matter of vendor self interest. (They’d be mad not to, it prevents theft entirely.)

Bloor has said some of this before, of course, and been only half-right. In 1997 he made his remark that

Java is the epicenter of a software earthquake, and the shockwaves are already shaking the foundations of the software industry.

predicting that Java browser-hosted or thin clients would dominate computing; he was wrong about Java’s impact, though perhaps he could have been right if Sun had evolved the Java client runtime to be more like Adobe Flash or Microsoft Silverlight, prior to its recent hurried efforts with JavaFX. I also suspect that Microsoft and Windows have prospered more than Bloor expected in the intervening 12 years. These two things may be connected.

I think Bloor is more than half-right this time round, and that the RIA model with offline capability will grow in importance, making Flash vs Silverlight vs AJAX a key battleground.

Related posts:

1. Tim Bray’s contrarian views on Rich Internet Applications
2. Why Rich Internet Applications Matter
3. John Resig makes the case for standards-based Rich Internet Applications

It does sound as if Google is not talking to Sun as much as it might. Still, let’s note that Google has good reason to omit certain classes or methods. App Engine is a distributed, shared environment; this mean that some things make no sense – for example: writing to a local file – and other things may be unacceptable, such as grabbing a large slice of CPU time for an extended period.

Salesforce.com addressed this same issue by inventing a new language, called Apex. It’s Java-like, but not Java. The company therefore avoided accusations of creating an incompatible Java, and conveniently ensured that Apex code would run only on Force.com, at least until someone attempts to clone it.

Google’s approach was to use Java, but leave a few things out. This FAQ gives an overview; and the article Will it play in App Engine lists common frameworks and libraries with notes on whether they work. Given that languages like JRuby, Groovy and Rhino work fine, it’s clear that core App Engine Java is not too badly damaged. The big omissions are JDBC (because you are meant to use the App Engine datastore, which is not relational), and Enterprisey things like JMS, EJB and JNDI. Google is nudging, or shoving, developers towards RESTful APIs along with its built-in services.

Will you be able to escape App Engine if you have a change of heart after deployment? I’d guess that porting the code will not be all that hard. Perhaps the biggest lock-in is with identity; you could roll your own I guess, but Google intends you to use Google accounts and supplies a Java API. Microsoft is ahead of Google here since it does support federated identity, if you can get your head round it: you can authenticate users in the Microsoft cloud against your own directory using Geneva. The best Google can offer is Directory Sync; though even that is some protection from identity lock-in.

Java support on App Engine is actually a vote of confidence in Java; if what is good for Java is good for Sun, then Sun is a winner here. That said, just where is the benefit for Sun if companies host Java applications, built with Eclipse, on Google’s platform? Not much that I can see.

Related posts:

1. JavaFX – just for Java guys?
2. Salesforce.com, Apex and Web 2.0 vendor lock-in
3. UK job stats show Java decline

Over the years since then I have regularly and steadily heard them saying: "We need something that is more immersive, more responsive, more interactive". Every time without exception that somebody said that to me, they have either been a developer or a vendor who wants to sell the technology that is immersive or responsive, or something like that. I have not once in all those years heard an ordinary user say "Oh I wish we go back to before the days of the web when every application was different and idiosyncratic … ".

In further gloomy news for advocates of Adobe Flash, Microsoft Silverlight or Sun’s own JavaFX he adds:

I suspect that the gap in the ecosystem that lies between what you could achieve with Ajax and what you need something like Flash or JavaFX or Silverlight to achieve is not that big enough to be terribly interesting.

I think there is a lot of truth in what he says, and I still regularly see Flash applications or Flash-enabled sites where I wish the developers or designers had not bothered. Nevertheless, I don’t go along with it completely. I’m typing this post in Live Writer, a desktop application, when I could be using the Wordpress online editor. The reason is that I much prefer it. It is faster, smoother, and easier to use.

Another example is Twitter clients. I use Twhirl though I may switch to Tweetdeck; both are Flash (AIR) applications running as it happens outside the browser. I’d hate to go back to interacting with Twitter only through web pages.

I agree there there is some convergence going on between what we loosely call Ajax, and the RIA plug-ins; Yahoo Pipes apparently uses the HTML 5 Canvas element, for example, using this Google Code script for IE support. I’m glad there is a choice of RIA platforms, but I don’t see either Flash or Silverlight going away in the forseeable future.

It’s worth recalling that the RIA concept began with the notion that a rich user interface can be more productive and user-friendly than an HTML equivalent. I’ve written a fair amount about the legendary iHotelier Broadmoor Hotel booking application which kind-of kicked it off – and I’ve interviewed the guy who developed it – and it was undoubtedly motivated by the desire to improve usability. As far as I can tell it achieved its goals, which were easy to measure in that online bookings increased.

Multimedia, rich visual controls, Deep Zoom, offline support, pixel-level control of the UI; there’s a lot of stuff in what we currently call RIA that is worthwhile when used appropriately.

Another twist on this is that RIA is enabling a more complete move to web applications, by reducing the number of applications that do not work either in the browser, or as offline-enabled Flash or Silverlight.

Still, Bray is right to imply that RIAs also increase the number of ways developers can get the UI wrong; and that in many cases HTML with a dash of Ajax is a better choice.

I think the RIA space is more significant than Bray suggests; but his comments are nonetheless a useful corrective.

Related posts:

1. RIA (Rich Internet Applications): one day, all applications will be like this
2. Why Rich Internet Applications Matter
3. UI design patterns for Rich Internet Applications