Tag: hannover

There once was a product called Hannover…

<rant>

Once upon a time – think 2006’ish – a complete revamp of a product was unveiled. The revamp went under the codename Hannover after the name of the city it was unveiled in. The revamp was to blow competition away and make the supplier of the product rule to World with the new product platform, new technologies and all the amazing stuff the client would be able to do. And it was amazing. It was like magic and provided access to new and amazing features and exposed great API’s that allowed developers to build sweet apps to bridge the gap between the proprietary world of yesteryear and the new internet era. It was built on a proven open source source platform and built using a proven industry standard programming language that many developers knew. It could be said that the language was the Lingua Franca of its time. To make it even better the client would be backwards compatible and run all the apps of its predecessors – like all the way back to the very first version of the product from the good ol’ DOS days. In many ways it was almost too good to be true.

It did however also not quite turn out the way the supplier had hoped. There was a problem with all this goodness. Not in the product. Not in the ambitions. Not in the chosen platform. In many respects it was a good idea, a good launch and the product delivered in most – if not all – of the areas it had promised new and amazing solutions for.

The problem was in the application developer support. They failed the product. Or maybe more to the point – the supplier failed the developers.

For the last 5-10 years nothing much had happened on the platform. Sure the platform had adopted JavaScript and Java and sure it had brought incremental improvements to the appdev experience. New feature here. A new simply action there. But nothing massive. But now the supplied threw this completely new way of developing apps on the market. The change was so massive and all the supplier would talk about was all these new capabilities – why wouldn’t they? Problem was that they had lulled developers to sleep with histories of declarative programming and how visual programming and laying out elements on screen was enough. One client to rule to them all. Simple actions and formulas to solve complex issues. But then all of a sudden developers was expected – from one day to the next – to grasp component development (called JSR 168 portlets at the time), data coming from different backend sources, UI threads, async programming, regex’es and low level widget development.

I’ll go out on a limb and state that the product was a failure. Sure customers migrated to the new client but many hesitantly. And it took a long time. Many never reaped any of the benefits of the new platform and ended up jumping ship.

Some developers did make the jump however as they were real developers. But many did not. It sounded too complex to them and it was. It didn’t align with the World they knew. They were business peoples trained to be developers – not developers by trade which was really a requirement. They chose to ignore the revamped product and all the features it brought. So all the good effort, energy, time and money put into product fell by the wayside. Sure it was used by some (including yours truly) but for many it was never adopted. So sad…

But why is this important and why am I writing it now?

Well to be completely honest it’s just a brain dump of thoughts. I find it interesting as time passes how often I see the same pattern reappear. Different products, different ways they try to reinvest themself and different results. In my opinion completely reinventing the way things are done in a product without making absolutely sure you either address the new message to the right audience or make sure the story is complete when told is due to fail. Of course some products are better than others and some suppliers are better at listening than others. But it’s interesting to watch.

But boy that Hannover product could have ruled the World if the supplier had been better at preparing developers beforehand and making sure they got on board.

</rant>

Disapointing news on the timetable for Hannover – release date pushed back?

I got quite disapointed when talking to a former IBM colleague of mine yesterday when he said that the public Hannover beta had been pushed back to 2nd quarter 2007 and the gold release pushed back to end 2007. From comments on Ed Brills blog I had gathered that a public beta would be available start of November 2006 (60 days from 1 September 2006) and from other discussions online that the gold release would be available mid 2007.

Does anyone have any credible info as to release dates? We need some solid information to tell customers.

Calendar interoperability

While listening to Inside the Net episode 29 podcast I learned of calconnect.org which is “The Calendaring and Scheduling Consortium” (Quote: “The Consortium is focused on the interoperable exchange of calendaring and scheduling information between dissimilar programs, platforms, and technologies. The Consortium’s mission is to promote general understanding of and provide mechanisms to allow interoperable calendaring and scheduling methodologies, tools and applications to enter the mainstream of computing.”)

In the podcast Scott Mace is interviewed and mentions calconnect.org where they recently got seven calendar systems to talk to each other. Interesting Lotus Notes/Domino and Microsoft Outlook/Exchange is included in the test using CalDAV.

This is very interesting. Would this be too late to fully incorporate and support CalDAV in Hannover/Domino Next?