Closing the Experience Gap
I've just been reading Paul
Roberts' comments about his SunRay workstation and reflecting on how
times change. A few years ago, all I heard from Sun colleagues as I went
round the world were comments about how much they hated surrendering
their Windows PCs and using SunRays and Unix. Now people are almost
universally thrilled by the liberation that their SunRay brings them.
There are always gripes, of course, but now people have got used to them
they've realised all the benefits that the thin client approach brings
to the office-based worker (including, as
Mary often comments, the home-office-based worker).
What's changed? Well, the technology is certainly more mature. The GNOME desktop has made the environment much more familiar and productive, and having whup-ass servers for the stuff to run on hasn't hurt. But essentially what's changed is that people no longer resent having something new imposed on them because they have actually tried it and found it delightful.
The thin-client vision was the early spark that has led to what David Berlind is calling the "uncomputer". Call it that or Web 2.0, or the read-write web, or whatever you want. The basic vision, though, of managing the state at the server while delivering a rich user experience, has been the same; all that has changed is that the gap between that vision and the experience of the average technology adopter is gradually closing.
Sun's bold experiment - switching all 40,000 or so employees to David's uncomputer - has shown that what really matters is the experience gap, not the technology. I hear this all the time as I travel the world and meet Sun teams in various countries. They tell me that the biggest barrier to adoption of desktop Unix (in whatever flavour you choose to use it, they all feel the same to the end user now) is not the cost - that's usually lower - or the software - that's no worse to migrate to than the next version of MS Office. It's the unfamiliarity, the experience gap.
Avoiding Disappointment
There's a common lesson that OpenSolaris, Glassfish, OpenOffice.org, Netbeans and the rest have taught me. There is definitely a lot of work involved in taking an existing commercial project and making it open source. I'd thus never do it lightly, nor would I expect it to be possible to always do it quickly. People who think you can just snap your fingers and - presto - the software is open source, are mistaken. But we'll be taking all the software we are able to and opening the source as soon as we can.
That's the sense of what I said to Peter Galli in the interview I gave him last week, which he's reported on eWeek. In an otherwise good report, there's a curious distortion added at the start of it. He says:
Those who hope Sun Microsystems Inc. will open-source all of its software products anytime soon are in for a big disappointment.
As the story goes on to say, exactly the opposite is true. We've already opened more source code than any other company in history, and there's more to come just as soon as we can make it happen. But we're not going to act irresponsibly. We have to make sure we know where every line of code came from. We have to make sure that a community can coalesce around the newly open code. We have to prepare the existing community (our staff) for the huge culture change that's involved. So I did indeed say:
"I am not going to allow us to do it too fast. We are not going to rush any of these things. This is not a token gesture. This is not the alphaWorks of 1999 where you throw it out and see if it sticks"1
So in fact those who hope Sun Microsystems Inc. will open-source all of its software products anytime soon are in for a treat. That's just what we'll be doing. Except, if I have anything to do with it, we'll do it right too, creating or joining2 transparent communities, establishing contribution-led, inclusive governance and using OSI-approved, re-usable licenses. No disappointment involved.
- No slur on alphaWorks here, by the way - it was started by good friends of mine while I was at IBM and its purpose was indeed to "see what would stick" so that IBM could then productise the ideas. Heady, pre-open source days. No idea what its mission is today.
- I mean that, too. The recently-announced Java DB is a distribution of Apache Derby rather than home brewed, for example.






