Hans Muller's Blog

June 2003 Archives

Why Java is not Open Source: One Cowboy's Opinion

How many pubs are there in Dublin? Parachute out of a plane over Dublin blindfolded. After you've landed, walk 10 paces in any direction without removing the blindfold. There's a 90% chance that you'll be within earshot of a publican, so order a pint. If the atmosphere doesn't suit you, just walk 10 more paces in any direction. You'll either be in another pub or the restroom. Either way, you'll know what to do.

My week at the GNOME Users and Developers Conference (GUADEC) concluded with a GNOME Advisory Board meeting. Bradley Kuhn from the Free Software Foundation (FSF) and I had the inevitable discussion about free software and Java. From my point of view, if you strip away the religious arguments and you avoid the legal swamp that surrounds the licenses that free software is bound to, what motivates the freedom fighters is a desire for control. It's a not a desire borne from megalomania, it comes from a more practical source - making software work. If you only work with free software, then when you encounter bugs or missing features you can fix them. You can change the code to suit yourself and you can redistribute it. I was lectured at some length about the counter example: if your Java application suffers from problems with the Java Runtime Environment (JRE), than you must work with Java licensee who provided the JRE to get a fix produced. You can redistribute the result. You must be patient.

It's interesting to think about what this difference means in terms of open source software (OSS). The fundamental dynamic with OSS is the tension between the community that controls the evolution of the software, and the possibility that a subset of that community might fork the code. The developer community doesn't want a fork because that would diminish or even eclipse their accomplishments as well as reducing the size of their workforce. On the other hand, evolving stable, working software requires a process that controls if and when contributions are incorporated. In small OSS projects this control might be vested in one or two hackers. In larger projects there's usually a hierarchy of reviewers and "committers" who are trusted to gatekeep the main code base. It's up to the gatekeepers to maintain the balance between the stability of the software and the stability of the community itself. If they fail to do so, the project will fade or fork.

The dynamics of OSS software are more unpredictable when many relatively autonomous OSS projects are combined into a large system, like GNOME or a complete desktop Linux distro. The tension that keeps the atomic projects together doesn't work as well at the molecular level. If OSS project B depends on OSS project A, the forces that ensure that A will continue to sustain B are social and sometimes commercial. Project A less likely to change in a way that would be incompatible with the goals of B if the projects have developers in common or community A views B's success as part of their own. Similarly, a common commercial interest can help maintain the synergy between the two projects. But what happens when the two communities aren't even aware of each other? Similarly, what happens when there's no social or commercial overlap between the two projects? Commercial projects are usually loathe to rely exclusively on synchronicity.

Like GNOME, Java is a large system created from independently developed parts. Java is not an OSS project for a variety of reasons (some historical), and one of them is the considerable importance of maintaining compatability across releases for all developers and all projects. There are three million (and growing) developers that depend on Java, and the Java platform is itself growing and evolving. It would not be possible to ensure that this growth and evolution was realized in Java implementations that were mutually compatible and backwards compatible with previous versions by relying on the bottom up guiding force of social and commerical relationships within the developer community. These forces work exceptionally well within an individual OSS project and they can be applied to systems based on integrating many such projects, however their efficacy diminishes as the size of the development community increases. Here's an example that illustrates the point.

Five cowboys are sleeping around a campfire. It's cold outside. The fire dies down and one of them wakes up and throws a few more logs on the fire. Temperature compatability is maintained and all the cowboys sleep happily. Three million cowboys live in a city served by a large hydoelectric plant. It's cold outside. One of them wakes up to find that his electric boot polisher has failed and, assuming that the power plant must be the source of his electrical problem, grabs a monkey wrench and heads for the power plant. While attempting to dismantle a high current distribution panel he's electrocuted and the short circuit knocks out power to the entire city. All of the cowboys catch cold.

I think that one of the primary reasons that Java is not an open source project is that given the size of the developer community, forks are unacceptable. In other words the millions of developers who build software on top of Java value its stability more than they value the right to get under the hood and fix it.

Sharing a Week With the GUADEC Generation

I'm here at Trinity College for the 4th annual GNOME users and developers conference (GUADEC) in Dublin Ireland.

Dublin Ireland time is eight hours ahead of PST back in Silicon Valley however I've mostly overcome the jet lag. Except from 1-2 PM every day when I feel like a narcoleptic. It's 1:30 right now and it feels like my brain is draped with a big hot wet wool blanket.

That was as far as this blog got on Tuesday. After failing to find a way to make both eyes focus on the screen at the same time, I stumbled out of the computer room to find strong coffee.

The computer room was the conference's social hub. As rooms go it wasn't terribly impressive: a big windowless room filled with folding tables surrounded by chairs, plenty of outlets on the floor, and a broadband ethernet cable duct taped to the table in front of each chair. It's hard to explain how inviting your own little space at the internet trough can look after you've been offline for a few days. The computer room was a magnet for the folks attending the conference. It was jammed all day with GNOME developers who were yacking and hacking and enjoying the camaraderie. It was here that I discovered some things about the conference and the GNOME community:

• They're friendly, they like to talk, and they really like to talk about the software. I'm shy and hopeless at making conversation however I found myself talking to all kinds of people about what they were building, what they planned to build, and (typically for me) about how Java might fit in.
• There's no point in finishing your GUADEC presentation before arriving at the conference. That's something that can be taken care of in the hours before you're scheduled to perform. Preferably in the terminal room, where you can procrastinate further by talking to me.
• Hacking on big systems that you're passionate about is fun, and both qualities are contagious.
• There's a clear hierachy among the developers. There are high priests, there are groups of trusted lieutenants, and there is the rabble. As a member of the rabble, I appreciated the fact that ones relative position in the hierarchy didn't seem to have any effect on the hobnobbing. Everyone made time to talk with everyone else.

Last week I spent the entire week at JavaOne and had a great time of it. One consistent theme that JavaOne attendees have fed back to the conference committee is that they want more technical content in the sessions. They want to see source code. This week I was at the conference (GUADEC) where code was king. The technical sessions were filled with developers hacking away at their laptops while the speaker talked about code and in some cases actually wrote code while everyone watched. Raptly. In one session the speaker ran a new (JIT) compiler on a small app and everyone watched attentively for several minutes while the instructions the compiler generated scrolled by in blur on the screen.

These are my people.

One of the most memorable keynote presentations of the week was given by Alan Kay, who appeared via a video link from his home in California. The average age of the GNOME developers I met at GUADEC was probably mid 20s and I felt very old, although not as old as Alan Kay. Alan's presentation began with an inspiring review of projects he'd worked on (or witnessed) back in the 1960s, including some great video of those old apps in action.

Ivan Sutherland's early 1960s "SketchPad" drawing application, which featured the first use of multiple windows (SketchPad3), still looks great. Users draw directly on the screen with a stylus and the app recognizes crudely drawn simple shapes and redraws them as perfect rectangles or semi-circles or rectangular polygons. Alan pointed out that this was the first object oriented system - a user could create classes of graphic objects, editing the class changed existing instances.

There was also a 1966 video of Doug Engelbart using a combination mouse/keyboard system to navigate around a little information tree. Response time was excellent even though the app was running on a 1/2 MIP time sharing system with 192KBytes of memory. Engelbart's goal was (is): "augmenting the collective IQ of groups of people". Still seems like a worthwhile goal.

These projects and more like them were intended to inspire everyone to build new apps that were atleast as capable as the ones built 40 years ago. Ofcourse there was an implicit dig in the call to action - we've lost the ability to craft small responsive apps even though we're now working with hardware that has 1000 times the capacity of what our forefathers had to work with. In other words, why does it take so much more code and computer horsepower to build high performance interactive data visualization apps then it used to? There are a variety of tired responses to such questions, some cynical, others self deprecating. The one that's not trotted out very often is the punchline to an old Bill Gates joke - "that was the demo". Great demos are a combination of technology and theater that deliver a little shot of adrenaline to the viewers imagination. The 1960s era demos we saw were certainly masterpieces, however they were still only demos. The difficulty of turning the vision those demos inspired into apps suitable for everyday use by everyone should not be underestimated. Hollywood had us traveling to the moon in the movies 40 years before anyone set foot there.

Bulding practical useful systems that deliver on the implicit promises in great demos is hard and it's time consuming. The GNOME community has done as much for Linux desktop computing and I can say from personal experience that it works like a champ.

Traveling Under the Watchful Eyes of the Big Brotherhood

I'm in Dublin Ireland this week for the GNOME Users and Developers Conference (GUADEC, pronounced "gua-dac"). It's a long way from Santa Clara California, not just in terms of hours and miles but in terms of queues and security checkpoints. Security has been tightened at airports by scanning luggage and people and shoes and by repeatedly checking one's boarding pass and photo ID.

Within the last couple of a months a proposal to enhance security at government sites by installing tens of thousands of web cams and deploying an army of eyeballs to watch them (from home!) has been widely reported. Most reports come with a subtitle like "Is this nuts or what?", however I have to admit to finding the idea intriguing. Despite 25 years of computer vision research, the human visual system is still the most effective way to distinguish an image of an intruder at the border of some restricted area from a deer or a tumbleweed or the wind and shadows. Webcams are cheap and, in theory, there's a Big Brotherhood Eyeball Workforce eagerly waiting to watch them.

Back in the 1960s Peter Graves' Impossible Mission force wouldn't have thought twice about penetrating a security system that required one to fabricate a photo-ID and a paper boarding pass. I can't imagine that modern bad guys would find the problem any more difficult. On this trip to Dublin, while I was waiting to have my papers checked, I thought about how one could apply RFID and The Brotherhood to the problem. RFID is "Radio Frequency Identification" a technology that's used for tracking individual products (like cans of beans) or packages or cattle. An inexpensive - about 5 cents - chip is attached to a paper tag along with a tiny anttena coil. An RFID reader hits the tag's antenna with a radio signal which powers up the chip and causes it to transmit it's unique 64 bit ID number.

So here's the idea. Make a digital photograph of every passenger when they first arrive at the airport and give each passenger a RFID transponder card. That initial check-in would be the only time the passenger would need to show their photo-ID, although aiport might make a photograph of that too, to enable a double check. Security people manning checkpoints with RFID readers would see each passenger's picture along with their ticket information. So passengers wouldn't have to repeatedly fumble for ID's and boarding passes. The passenger images would only be hours to minutes old, so checking would be much easier than eyeballing a 10 year old passport photo. RFID cards are cheap, likewise for database entries.

Once you've got a system that can passively identify passengers and is armed with a picture of every one of them, the job of watching would be easy to deploy on the net. The same eyeball army that might watch the fences at secure government sites, could also be employed matching faces at airport checkpoints or even on security cameras monitoring the wide open spaces within the air transportation system. Gadget freaks should find comfort in the fact that security guards could use PDAs (even their mobile phones!) to keep tabs on the flow of faces.

There are plenty of reasons why this would never work. The physical and software infrastructure problems are considerable. Although there's nothing fundamentally technically challenging about creating a system that stores ticket info and picture or two keyed by a dynamically allocated ID, it's easy to imagine the project being hamstrung by mundane problems like cabling, mounting web cameras, even getting passengers to hold still for a minute. And those problems pale by comparison to the privacy issue cyclone that such a system would inspire.

So I'm here at GUADEC and in case you haven't guessed, jet lag has me up early enough in the morning to record this lunacy. While I'm here, I hope to talk with GNOME developers about the prospects building more GNOME desktop applications in Java and for extending same in Java. The GNOME 2.2 release includes a bunch of new integration points for extending Nautilus and the Panel, I'm also hoping to develop a better understanding of how Java might be used in that context and with the venerable Bonobo component infrastructure. Java is widely used on Linux, more than any other language per a recent IDC report. In terms of Linux desktops, notably GNOME desktops, it's harder to say how prevalent Java is - since the whole point is creating applications that are not specific to any platform. By the end of this week's GUADEC conference, I hope to have a better feel for how well Java is working for GNOME.

Intersperse Savage Raid

I finally got a chance to wander around the JavaOne "Pavilion" trade show floor. If you trot out to the edges, you'll see that the Pavilion is flanked by huge arrays of tables covered by white table cloths and little isolated clots of laptops and sandwiches attended by glassy eyed hackers trying not to give in to jet lag. I like to start out at the edges because that's where the new companies are. In years gone by the edge was where the crazy ideas were, it was where the hackers who hadn't slept all week were, it was where the guys who wanted to get to the show floor interior started out.

This year felt a little different. The edges of the show floor seemed to fade into the sea of lunch tables a little more suddenly than in years gone by. Not to be denied the inspiring sight of some new Java desktop apps, I pulled on some mobile phone exhibit hip waders and headed back into the show floor interior. I only had an hour to check things out. I wasn't disappointed.

The Apple booth was impossible to miss with all the bright light glinting off the beautiful lexan cases and those gorgeous gigantic flat screen displays. There were big black racks of new Apple servers doing sentry duty at the booth's corners. The servers were looking very stylish with hip little rows of blue blinky lights. The lights were very very bright. In a pinch they could be used for Lasik.

Allen Denison, who's the Product Manager for OS X showed off a nice looking Swing app for adminstering RAID's called (this is pretty clever) "RAID Admin". There are some screenshots here. What's great about this Apple desktop app is that sys admins can also run it on other platforms, if they happen to be adminstering their systems from a lesser desktop.

Intersperse was showing a great looking JMX management console at their booth. A couple of months ago I ran into an engineer who claimed to be building a similar product and he told me that his JMX console was going to just target browsers. He thundered about HTML being "good enough" for building user interfaces as he scratched udpates to his todo list on a clay tablet. I would have loved to have shown him this product. Great looking Swing GUIs with lots of custom controls for displaying status and doing analysis in real time.

I also dropped by the VisiComp booth. VisiComp's "RetroVue" debugger was featured in a James Gosling JavaOne keynote a year or two ago. The debugger instruments class files so that all significant events, like method entry and exit, are timestamped and logged in a journal file. That done, you can debug backwards and forwards in time. In years gone by, the journal file for a big app might have been hopelessly large. Thanks to today's plentiful supply of big cheap disks, you can journal all you want. The RetroVue Swing GUI is looking better than ever however you'll want to get one of those really big Apple flat screen displays so that you can see everything at once.

Last stop before I had to dart out was the SavaJe booth. Last year SavaJe was showing iPAQ PDAs and other small devices running the complete J2SE stack. Web Started Swing apps like ThinkFree Office running on a device that you could toss to someone across a room! This year the SavaJe booth was inhabited by a herd of cell phones running more web started apps including email, chat, and a very impressive video player (Star Wars!). And you can make phone calls too. It's great to see how far mobile phone computing has come and the high res 16 bit color screen looked great. Inside these phones was an 300+ Mhz XScale CPU, 32-64M or RAM, and a SAN slot for a Flash card. Thanks to the market for high resolution cameras embedded in phones, we're looking at hand held devices with CPU, RAM, and even secondary storage capacity that's comparable to PCs from a few years ago. Run Anywhere.

Opening the Door to JavaDesktop.org

This work is licensed under a Creative Commons License.