The Domino server still represents the best value in the industry as an application platform. So why is the market clearly still losing ground on corporate desktop seats? More important, what can be done about it?

The problem isn’t lack of advertising – though that could certainly be better. The problem isn’t IBM’s website – I agree, it stinks in all kinds of ways, but that’s not what is causing problems in the marketplace. To think it is, is to think major IT decisions are getting made by CIO’s surfing the web to find out about the Domino platform. That’s just silly.

The problem isn’t the cloud either. The cloud is a distraction for enterprise collaborative messaging applications, not a real solution. Write that down and let me remind you in a few years that I’ve been saying it all along -- just like I said back in the late 90's that J2EE would never be the primary application server platform for the web.

The problem is, has been for years, and will likely continue to be for some time – the Notes Client strategy. Heavy clients are dead. 500 megabyte installs running their own JVM and massive frameworks have never been gratefully accepted even in sites already sold on the Notes client, and at new sites they’ve never taken off and are not going to.

Look at the value proposition at the server. Each version of the Domino server is faster, supports more concurrent use, makes better use of resources, is easier to manage, and is more robust than the version before. It comes with a full mail stack, supports several client types, data storage, indexing, rich security, authentication, content filtering, search, and support for several different programming languages. I can build custom, secure, individualized, collaborative applications faster and cheaper on a Domino server than you can on your favorite other program. I can do it every time. No question. I’ve done it over and over, often for orders of magnitude less than competitive bids. I manage one site that I built all the way back in Domino 4.6, and through all the upgrades and versions there is still nothing on the market that can win a competitive bid to be its replacement. I know – they try every year through an RFP process.

Now look at the rich client. Hey, IBM, 1995 called and they want their application architecture back. Installation is hundreds of megabytes and crazy amounts of memory. It has to run its own JVM (more than one in some cases) just to operate. Users report painfully long launch times on common hardware, and after all that – in terms of real business value at the desktop, users are not reporting any significant gains. The bread and butter applications that have entrenched the product in the enterprise by providing incredible value at very low cost have been entirely forsaken. There have been no significant improvements or modernizations to the core “Forms” and “Views” in years, and none are (reportedly) planned. What does it have now? Widgets, Gadgets, Gee-Gaws, and UI panel improvements – but only for the very most intrepid developers and only useful to leverage functionality that actually already exists elsewhere. In other words, if you’re a really top notch developer and put a lot of work into learning how, you can make the thing do what it already did in a much nicer looking manner.

But wait, you say “What about XPages?” – Well, let’s talk about XPages. In concept, they solve a fundamental design flaw in the way Notes applications are built. They give you an “Interface Based” way to develop and let the data be organized as the data needs to be. In practice, the implementation is classically over engineered. The goal of starting fresh to attract new developers is totally lost by burying the new functionality in the ancient designer client – itself a powerful and useful platform, but after 15 years of additions and layered functions is frustratingly arcane and highly resistant to novices. Even if it were somehow pulled out of Designer into its own installable tool, XPages turns out to be just another attempt to force J2EE development down the throat of a community that has rejected it utterly for most common application development needs. As a development environment, it is both over complicated and terribly immature by today’s standards. In ease of use and learning, it pales by comparison to both Visual Studio and the Eclipse Java IDE in which it is based. At least it can make applications on the web that look attractive – unless of course you want pixel level control over what your page layout is instead of a variation on “themes”, in which case you’re back to hand coding.

The question then, is how to make use of all that power and functionality offered by the Domino server, when the client tools are so mired in fifteen years of muck, and wrapped in a misguided, over engineered, disastrously buggy user interface? There are two answers to that. There’s what IBM can do, and there’s what we can do in the mean time.

What we can do, for now, is continue moving to the browser and in some cases to the custom application client software we build ourselves and tie to Domino through Web Services. We can use PHP running as CGI under Domino to create modern, attractive pages that still interact with secure, managed, indexed documents living in the server. We can hand code html and css. We can surface business content and logic through web services into lightweight applications built in Flex, .NET, and so on. In short, we can keep taking advantage of the security features, stability features, storage features, replication features, search features, indexing, and user agents that the Domino server provides, without forcing more bloat down the throats of our user base.

What IBM can do, if they grow up enough to actually do it (of which I see no real evidence yet), is build an entirely new client around the core framework that already exists. A client stripped down to its core services and built to be used as a way to surface data and business logic at the desktop without trying to own the entire desktop experience. IBM can at some point face the sad fact that the Eclipse framework, cool as it may be for super developers, has failed to provide significant improved business value to match its increased overhead in hardware, support, or developer skills.