I had written up a long, comprehensive and timely set of thoughts about what went wrong with Google Wave, but WordPress ate it so you’ll have to take my word that it was awesome and instead put up with this rather late and significantly shorter thought.

There are lots of opinions around about why Wave failed, and they show that it was a combination of a lot of factors from poor UI, inexplicable purpose, unreliability and simply combining too many technologies that didn’t always fit (e.g. people don’t always want what they type to be shared immediately but real time collaboration was forced on them). Certainly I experienced most of those downsides, but the thing that really drove me crazy about Wave was it’s primitive support for notifications.

A little while back Charles Nutter posted about his progress at getting the JRuby bug list under control:

Roughly around September, we crossed an important threshold: 500 open bugs. They dated as far back as 2006 (we moved to Codehaus in 2006), and across the entire release sequence of JRuby; there were even some bug reports against pre-1.0 versions. From September until about mid-January, we worked to keep the number of open bugs below 500. Sometimes it would peek above, but we were generally successful.

Believe it or not, it’s been almost exactly 2 years since I kicked off LiveWorks! as essentially a skunk-works project to get some of our internal experiments out into the open so they proved useful. As it turns out the bigger success has been the weekly hints and tips that we started adding a few months later. Unless one of the migrations has messed up the dates, the first tip was a simple overview of how to integrate EditLive! that Rob wrote. I still regularly refer people to that article.  Since then we’ve posted a new article every single week without fail.

Antonio Cangiano:

In theory I could have been disappointed. After all, my visit didn’t fix the problem at hand, my expensive laptop seemed to be good as a door stopper, and repairing this thing could potentially be less advantageous than just buying a newer unit. Yet, as I arrived home, I told my wife that my next laptop would definitely be an Apple.

The reason for this is that I saw a genuine effort to help me out, an unheard level of care for the customer and an willingness to do what’s right, even if it costs the company some money. The whole experience was very positive and I felt that the premium cost of Apple’s products is easily justified by this kind of support.

Michael Krigsman sticks it to Nick Carr and includes an interesting assertion: that how good software is can be decided by how much revenue it drives:

Nick, please let the market decide whether enterprise software is “good” or not. There’s a simple metric for measuring this: it’s called revenue. Just for kicks, compare the revenue of enterprise companies, such SAP or Oracle, to consumer-oriented firms such as Twitter (click to follow me).

The conversation around enterprise software goes on, with a couple of good responses to my last post that I want to highlight. Firstly, ddoctor (aka Dylan Just who recently started working here at Ephox) in the comments:

I’m thinking of making this one of my career goals – making enterprise software not suck.

Then you’re very much in the right place – that’s what we do…. He goes on to give some very good advice on designing good UIs, but it misses a key point that I was trying to make in my last post:

Technology is a funny thing – we spend so much time and effort trying to make things as simple and efficient as possible for our users that we sometimes lose track of the big picture and wind up making things worse. This is particularly a problem when developing components for other’s to intgrate, rather than a product that ships directly to end users. When another developer is between you and the end user a few fairly unique dynamics come into play:

Alex Iskold has an interesting article “Rethinking ‘Crossing The Casm’” which asks how to maintain the interest of early adopters in the face of such an overwhelming number of new products:

According to Wikipedia in 2006, Tom Byers, Faculty Director of Stanford Technology Ventures Program, described “Crossing the Chasm” as “still the bible for entrepreneurial marketing 15 years later.” It is certainly a powerful and proven theory, but it does need to be adjusted. The fact that so many things are thrown into the market changes things. Early adopters are enticed by new things much more often today than 15 years ago. Expanding on how to retain the early adopters would be good thing to do in the next edition.

As of next week I’ll officially be a product manager instead of an engineer. I’ll no longer be spending my days coding and for our core products I won’t be allowed to make changes to them. I will however be doing a bunch of prototypes and smaller integrations of our products etc so it’s still a hands on role.

Obviously I need to keep my general technical skills really high so that I can quickly whip up prototype integrations and stay on top of new technologies etc. For general technology issues like that I’ll probably need to be more on top of things than I am now, and I’ll wind up working in a much wider range of languages and with a much wider range of technologies. Definitely interesting stuff ahead. What I’m not sure about though is how in touch I should keep with the Ephox development team and how they are going about developing our products. I clearly need to know what the new features they’ve added are, but I’m not sure how much of the implementation details I’ll need.