Why the change of CEO at CodeGear?

CodeGear has a new CEO. But why? There’s the usual bland stuff in the press release:

Today we made a change to the leadership team at CodeGear.  Jim Douglas is joining as CEO of CodeGear.  Jim will be responsible for driving CodeGear to the next level, building on the solid foundation and momentum achieved by the CodeGear team under Ben Smith’s leadership.

Departing CEO Ben Smith has a blog entry that is no more revealing.

Judging by comments on the Borland newgroups, developers are fearing the worst. The problem: a change of CEO is a sign of instability, when CodeGear customers need reassurance that their preferred tools are in good hands. I didn’t see any previous suggestion that Smith’s appointment was intended to be short-term.

To make matters worse, there are signs that both Delphi for PHP (see here) and Delphi 2007 (see here) were released too quickly – especially Delphi for PHP. Strategically unwise.

There’s still nothing to touch Delphi for native Windows (if you don’t need 64-bit). And tackling PHP tools is a great idea. But in a difficult market the company cannot afford many slip-ups.

 

The search for the new client runtime

Some interesting posts recently about the connected client wars:

Ray Ozzie interview from Knowledge@Wharton.

Commentary from Ryan Stewart – subscribe to his blog if this stuff interests you, and it should.

Commentary from David Berlind

Why a new client runtime? It’s because of certain desirables:

  1. Designer freedom – think multimedia, effects, custom controls.
  2. Zero deployment – It Just Works, not ardous setup routines with weird error messages.
  3. Web storage – most data belongs in the cloud, it’s safer there.
  4. Local storage – for offline use and performance.
  5. Cross-platform – for all sorts of reasons: Apple resurgence, Linux desktop improving, inherent client agnosticism of the Web. Windows-only doesn’t cut it.

I’d add, and this is a techie point, an XML UI. XML makes huge sense for defining a user interface. Think of the history here: in the beginning we had text (DOS etc). Then we got pixels (Windows API), supplemented by arcane ideas like dialog units to make it vaguely scaleable. Then we got layout managers – Java’s AWT and Swing. Fundamentally right but awkward to code. Now we combine XML and layout managers – easier to code, better for visual designers. The best yet.

I dont care as much about the language. Java, C#, JavaScript (ECMAScript 4.0, ActionScript 3.0) are all workable. Just-in-time compilation is important; but all of these have that.

Of course the new client runtime is an old client runtime. Flash, transmuted with Flex and Apollow. Microsoft .NET, transmuted with WPF and given some belated cross-platform appeal with WPF/E. And not forgetting Mozilla XUL, which ticks most of the boxes but lacks the marketing effort and tools that are making waves for Adobe and Microsoft.

In some ways this looks like a battle that is Adobe’s to lose. It has designer hearts and minds, runtime deployment, cross-platform all sewn up. That said, I really like WPF; it has been mostly lost in the Vista fog but will emerge; maybe Mix07 will help (now sold out, apparently). Good WPF apps are amazing; and Microsoft has armies of .NET developers out there, and a great tool in Visual Studio – but stumbles on (5) above.

Watch this space.

 

Technorati tags: , , , , ,