Hans Muller's Blog

Open Source Archives

Parading Out of the Open Source Door

June has been a record breaker for new open source projects at Sun. The projects ambling out the door this month have run the gamut from new initiatives like JDIC, JDNC, to longtime J2SE stalwart Java3D. And standing in the doorway is the great hulking giant Solaris, of which our president Jonathan Schwartz has said: "Make no mistake: we will open source Solaris". At today's opening JavaOne keynote Jonathan also let it be known that Project Looking Glass was similarly poised to pass through the open source doorway, just as soon as some final (unspecified) details were ironed out.

So now perhaps you're wondering what all of this implies about Java itself passing through the same door. Of that I can tell you with absolute certainty: I have absolutely no idea. My goal is just to remind those of you who of depend exclusively on blogs for news, a little about the significance of the Looking Glass and Java 3D projects.

One way to explain Project Looking Glass is to take stock of the obvious. For some time now nearly all new PCs have included general purpose CPUs that can execute billions of instructions per second. Right next to the fire breathing CPU there's usually a separate graphics processor that can render 3D scenes of enormous complexity at frame rates well in excess of what you'll find at the local cinema. With all this power at our disposal, why are we viewing a desktop GUI that requires little more than an efficient implementation of an early 1980s BITBLT graphics library? Of the many possible answers to this question, the one that Looking Glass is intended to explore is this: we still don't know how to take all of that potential and turn it into a desktop that makes using a computer easier. It's time to start experimenting with the possibilities and Project Looking Glass is a software laboratory for doing just that.

Project Looking Glass is based on an extension to the X11 server that combines the contents of top level windows from conventional X11 clients and new Java 3D client application scene graphs into a unified scene graph that's composited and displayed on the screen. There's a new X11 window manager that demonstrates how one interact with a desktop metaphor that's more than just a stack of sheets of (opaque) paper. There are also some demo applications that give you an inkling of what it's like to deploy an application whose visual elements occupy 3-space. To begin your own exploration, watch for the project's open source announcement on javadesktop.org.

The other big open source announcement that I wanted to mention was Java 3D. Java 3D has seen much use in serious endeavors like engineering and medical science, and it's been used in loads of games and virtual reality applications. However the big question many developers gravitate towards, as they while away the moments waiting for their tiny espressos to brew, is this: would it be possible to use Java 3D to build a first-person-shooter view of the operating system and would we be allowed to remove files or kill processes by blasting at them with impossibly large weapons? Not surprisingly, the answer to that question is yes. As to the natural follow up question: will the processes and files fight back? We're still looking into that. One example of such an application, which I haven't tried, is the "Brutal File Manager". If you're aware of others, I'd like to hear about them.

You'll find the new Java 3D API open source project here: java3d.dev.java.net. It's a big software stack. The developers describe it like this:

The Java 3D API provides a set of object-oriented interfaces
that support a simple, high-level programming model you can
use to build, render, and control the behavior of 3D objects
and visual environments. With the Java 3D API, you can
incorporate high-quality, scalable, platform-independent 3D
graphics into applications and applets based on Java
technology.

Java 3D is an integral part of the Looking Glass Project. If you're planning to explore desktop 3D in depth (IOK, not all that clever, but hey - this is a blog) check it out now.

Selling Snakes with Huckster

Disclaimer: I wrote most of this blog about a month ago. Before I finished, a combination of vacation and other distractions kept me from completing it. So finally, here it is.

At Sun Microsystems, we're all required to take vacation during the week of July 4th. I think it's more of an economic requirement than a patriotic one. Ofcourse some people take Independence Day pretty seriously, for example founding Fathers John Adams and Thomas Jefferson both managed to drop dead exactly fifty years later, right on the 4th. I'm not quite as inspired by the date however I am writing this outdoors on a beautiful Pennsylvania afternoon with four US flags fluttering within my line of sight over the top of the laptop. Pennsylvania weather is a big change from California's Bay Area, it's humid here. Sometimes it's unbearable however today it just makes the breeze more entertaining. A little bit like swimming without getting wet. Or cold.

The weather at the Castle Rock and Big Basin parks in the Santa Cruz mountains was different but just as nice. Earlier this week my older sons and I and some friends went backpacking from Castle Rock, through big Basin, and all the way out to the Ocean. The trail ends at Waddell Beach where the kite surfers zoom around above the surf like a cloud of giant butterflies. The trail itself is impressive, having been cut into the side of ridges covered with Coastal Redwoods and in other places Chaparral and rock formations that look like they were lifted from old Roger Dean album covers. The trail winds up and down, always opening up a new little vista, never boring.

In many places the trail is just a two foot wide shelf cut into a ridge. As you walk westward your right shoulder brushes up against the scalloped edge of the trail cut. Just past your left shoulder there's a good approximation of a cliff. Rattle snakes are common on the sunnier parts of the trail and on the second day we passed a baby that shook it's tiny rattle half heartedly and then slipped into the bushes. We felt very manly then, tramping past the venemous snake, even bending over for a closer look. That feeling passed later in the afternoon when we turned a corner into another sunny vista and nearly stepped on the baby's big mother. We didn't see the rattlesnake right away but we heard it angrily shaking its big maraca. The cliff on the left looked pretty dangerous at that point so the rattle snake headed to the right. Unfortunately for the snake, the trail's right shoulder was even steeper. The rattler strugged but couldn't wind it's way up, so it settled for a waist high defensive position at the base of a small tree growing out of the scalloped edge of the trail. Rattling for all it was worth the snake spring loaded its coils and pointed it's big triangular head directly at us. Left side cliff. Right side, angry rattle snake aimed directly at my shorts.

My friend Norm and I are software engineers. We were also the adult supervision for this trip, so we snapped into action and took some digital pictures of the snake. It seemed likely that someone would create a web site about us after the bodies were found and having a picture of the snake that did us in would make our epitaph more interesting. That taken care of, we tried to calcuate how far the snake could lunge and Norm decided that it was unlikely that it could hit a target perched on the far left edge of the trail. Since I wasn't carrying dinner, Norm suggested that I go first. I'd like to say that I strode fearlessly past the reptile. The truth is that if I'd had a tail, it would have been between my legs as I leapt past while the snake rattled.

If you're still reading this (and you're not Norm) then you're probably wondering where the technical content escaped to. I've been saving it and it's your reward for putting up with my travelogue.

The word "huckster" seems to have the same Dutch origins as "hawker" and both words are used to described peddlers whose pitch is mightier than their product. Like snake-oil salesmen (that's the best I can do for theme continuity). This year at JavaOne James Gosling created a simple presentation editor/player called Huckster and used it for his keynote presentation. He's also launched a Huckster open source project that you'll find on javadesktop.org in the projects section here. Huckster makes a number of simplifying assumptions that reduce the scope Huckster's design and implementation to the point where one hacker could carry off the first version without making a joke out of their day job. It probably doesn't hurt that the developer is James Gosling.

• The only elements needed for a presentation are images and text. Users who need fancy charts and diagrams can always produce those in more specialized tools.
• Fine control over slide layout is overrated. You can live without being able to insert a couple of pixels of padding between a slide's title and the first bullet and you certainly don't need to be able to control where all of the line breaks go.
• A direct manipulation WYSIWYG style GUI isn't neccessary for entering the text for titles and bullet points. You're better off working with an outline editor flanked by a slide preview window.
• Transitions are evil. I'm really sure about the thought behind this design constraint, however it's clearly stated in the docs. I'm guessing that during his formative years James was involved in some kind of bloody PowerPoint accident.

One novel Huckster feature that I haven't seen in any other presentation tool is that it dyanmically reduces the font-size for titles and bullet text. The more you type the smaller the fonts get. If you type for a long time (I tried this) the text gets really really small. I have yet to do a full one-hour presentation with Huckster however with small examples this seems like a very useful feature.

I have to admit that when I first tried Huckster on my Linux laptop I couldn't add images to the presentation - which pretty much defeated my objective of creating a slide with the picture of the great big rattlesnake. The problem was that Nautilus (the drag source) would only provide a file URL string. When I drag-and-dropped an image on Huckster it just inserted the file URL as text. So, hooray for open source, I changed Huckster so that if you drop a string that can be parsed as a URL and that produces an image, Huckster does the right thing. I also fixed some other minor problems and proudly sent them back to James to be incorporated in the next version.

Here's the snake presentation encoded as a huckster ".esl" file. It's kind of refreshing to see a simple plain text file format again.

A Big Snake
-Hans's Blog
-July/August 2003
-\I500:/export/home/hans/big-snake.jpg
Same Snake
-This time the image is used for the slide's background
-\I500b:/export/home/hans/big-snake.jpg
The End

And here's the same tiny presentation exported as HTML (just images really) so you can have a look.

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.

Opening the Door to JavaDesktop.org

This work is licensed under a Creative Commons License.