OOPSLA was founded in 1986 by the earliest of early adopters: researchers and practitioners thrilled by the prospects of object-oriented programming. Now, as we convene for the twentieth time, objects are utterly mainstream, the very foundation of a great deal of the world's software. But the thrill of creation is addictive, and OOPSLA has developed a strong tradition of being the spawning ground for new ideas, artifacts, and movements—things like software patterns, aspects, refactoring, reflection, Eclipse, UML, and the Agile methods. At OOPSLA, languages like Smalltalk, CLOS, C++, Beta, Self, Eiffel, C#, and Java have sprouted and bloomed, contributing their underlying ideas and expressive power to the pool of computing concepts. OOPSLA strives to mingle people on the vanguard of research, and practitioners in the trenches who are reflecting upon and trying to understand just about every facet of software and programming.

People at OOPSLA like to interact in all sorts of ways, so we have papers, posters, and presentations; workshops, tutorials, and essays; lightning talks, panels, and films; and receptions, BoFs, and a special event—this year it's the San Diego Zoo. All this plus Practitioner's Reports, DesignFest, and Camp Smalltalk.

People at OOPSLA like to learn from each other and from the masters, so we have sessions selected from the very cream of our carefully refereed submissions, alongside talks and events planned around invited participants. This year we have people who built the mainstream: people like Grady Booch (co-creator of the Unified Process) and Ralph Johnson (coauthor of Design Patterns); we have people who challenge the mainstream like Ward Cunningham (inventor of Wikis), Dave Ungar (inventor of Self), Kent Beck (software patterns, XP), and James Noble; we have people who insist on inventing the future like Gerry Sussman (co-inventor of Scheme), Jimmy Wales (the father of Wikipedia), and David P. Reed (inventor of the TCP/IP end-to-end argument and co-developer of Croquet, the ultimately flexible tool for exploration); and we have people who buttress the present like Martin Fowler and Mary Beth Rosson.

This year we have two co-located conferences devoted to topics that are only now entering into the early mainstream: the Dynamic Languages Symposium and the Social Software Symposium. Our focus is on creativity and innovation, anchored by a keynote by Robert Hass (the former poet laureate of the United States), continuing with the Working With Vision panel, and The Instant Art School Experience.

We are especially proud of Onward!, our innovative track for altering or redefining the art by proposing leaps forward—or sideways.

We'll even take a look Backward!, in a retrospective session celebrating the tenth anniversary of Java, featuring Guy L. Steele Jr., and with a multimedia reminiscence of OOPSLAs gone by, featuring an all-star cast.

There's a lot to learn about OOPSLA. Visit the OOPSLA website to get it all.

Larry's talk also pointed out a fact I always love to hear: Disney's Mickey Mouse was created for Steamboat Willie, which was a parody of Buster Keaton's Steamboat Bill Jr. The best part is that both the parody and original were released in 1928, which means that the Disney company knows of what it speaks when it worries about people ripping off the success of Mickey Mouse.

Larry, though, is not against property rights, but for a balance between the owner's rights and society's. This led him (and leads me) to *a*a, a fictitious computing language and platform. He pointed out that the law really only permits two extremes for *a*a: License it as open-source, thereby increasing the likelihood of it spreading to every platform and device on the planet, and also increasing the likelihood it would hijacked or embraced and extended; or keep it proprietary (owned by its inventor, *u*), thereby limiting its reach because people fear *u* would one day decide to monetize it at the expense of all those who worked hard to spread its adoption.

Larry proposed an alternative view: Put ownership *a*a into sort of conservancy which would protect its integrity just as *u* does now, but without the taint of being a (potentially) greedy for-profit company.

Like anything else, the issues are complex. It would be irresponsible, for example, for Disney to release Mickey to the public domain—Disney shareholders rightly see Mickey as a source of Disney value. On the other hand, the Disney company is superb at stealing. For something like *a*a, it's never clear when the language and platform is sufficiently established. Nor is it clear when control becomes self-strangulation.

This month there are two different sorts of conferences that might deserve your look. Both are heavy into Java, but their focus is elsewhere. This first is the Agile Development Conference, June 25-28, in Salt Lake City, Utah. Agile development is about recognizing that the requirements for a project change as the users of the software see the software and learn what it can do. Agile developers care about interactive or participatory design, delivering software early and often, and test-driven development in which the tests are developed before the code as part of its specification.

I was on the technical paper selection committee and we were quite selective. Unfortunately I can't go because I'm off to a writers' conference. I think you might enjoy hanging with the agiles.

The other conference is the Eighth European Conference on Pattern Languages of Programs, 25–29 June, in Irsee, Germany. This conference is affectionately known as EuroPLoP, and is one of a set of conferences the Hillside Group started. The Hillside Group is a non-profit that shepherds patterns-related things. Doug Lea and I are members of its board. PLoPs are interesting because they feature a writers' workshop style of interaction. (I wrote a a book about them.) A writers' workshop is a semi-formal way of reviewing and critiquing work, developed at the end of the 19th century in the creative writing community. At PLoPs we use them to help authors improve their patterns and pattern languages, but audiences are allowed to observe. In a sense it is like watching the process of creation, and people find they get a much deeper understanding of the work in this format than in a standard presentation style.

The best part of EuroPLoP is that it takes place at Kloster Irsee, which is a former Benedictine monastery (founded in the 12th century) and now housing a brewery, located in Bavaria, Germany. The accommodations, food, and beer are excellent, and the atmosphere is not like any other conference you've been to, unless you've been to one of the other PLoPs.

The patterns community over the years has brought us not only patterns and pattern languages, but writers' workshops, wikis, extreme programming, and agile development in their search for how to make programming more effective and humane. Check it out.

My answer last night to this question was that it was the same problem that faced a poet about to sit down and write a poem: How does she know that it will be good? And of course, she doesn't no matter how much training or practice she has had. Sun doesn't know how well it will live up to the Guiding Principles for java.net. Here's why: Sun didn't write them, I did. Executives at a company come and go, and some will buy into the Principles and others won't. Regardless, Sun can't know without the experiment being run.

java.net is a barometer for Sun's courage to bring together a diverse and uncontrolled & uncontrollable mass of people. The executives in place the day I put the Guiding Principles on the table agreed, and now we'll see how well Sun holds up its end of the bargain, and thereby will you know the heart of Sun.

But the first time around I wanted give you my perspective on Java. Most importantly - and somewhat paradoxically - I had nothing to do with Java and still don’t. My predilections as far as languages are concerned are toward the more exotic and paradigm shifting. Java is a mainstream language with some nice incremental improvements on existing languages - and the early Java designers were not too proud to borrow from other languages: Smalltalk and Lisp, for example, provided automatic memory management. My cap is off to James Gosling and his original team for the basic language, to Bill Joy for his vision to push it forward, and to Guy Steele for helping solidify it. Java is a good language that provides a solid platform for people to innovate using objects on modern networked hardware platforms without having to worry about the rug being pulled out from under them.

And this is what I want to talk about. Sun has done what I think is an unprecedented good deed for the computing community, a good deed as often vilified as celebrated. For almost a decade, Sun has stuck to its guns to keep Java from changing in unpredictable ways, and it has done so for the purpose of keeping the ground solid and steady underneath your feet. To do this, Sun has retained control, and many people - sometimes myself included - have criticized Sun for keeping too stiff a grip on Java. The Java Community Process (JCP) has taken its share of hits, as have Sun’s licenses, which have twisted the minds of the most brilliant lawyers - and I should know since I helped write the most complicated of them.

I work in the belly of this beast, and when I joined the company I expected to see dictators stomping through the corridors shouting “Java is mine, mine, mine” or to find a “Just Say No” committee. But not so. Without exception, the folks working on Java sincerely believe in compatibility and the sometimes mythical “write once, run anywhere”; they talk about developers being able to rely on the same language and semantics running on every platform; the lawyers are constantly trying to make the licenses plainer and more generous while still keeping the wolves at bay; and the executives - though they hate it - almost always lay down the cash to keep Java and its community of application developers thriving.

How can you know this is true? How can you test it yourself? Simple. Consider these things.

Many of Sun's Java activities have never made a profit and never were intended to. This had always been justified by the phrase, “Church versus State.” “State” was the part of Sun trying to make money with Java, and “Church” was the part that pushes and maintains the values Java represents. And the latter was never intended to make money. Think of how many companies would ever embrace an idea like “Church?”

The JCP, as controlled as it initially was by Sun, has always been open enough for a savvy outside organization to make fundamental changes to the language and platform. And over time, control has been systematically loosened to the point where it is effectively as open and fair as any standardization process I’ve been involved with.

Sun still is willing to write Reference Implementations and Technology Compatibility Kits for JSRs led by organizations that either cannot afford to do them or aren't prepared to. Doing this work is hard and expensive, and many organizations are not prepared for what it would take.

And finally, I am here to tell you that as hard-edged as the control seems, the folks at Sun sincerely believe in the altruistic goal of keeping the language and platform steady and reliable for you in the face of forces that would splinter the community and offer always changing alternatives.

Not many companies do things like this. Sun is still not perfect in its execution, but it’s trying much harder than it gets credit for. So my cap is off to Sun as well. I urge you all to keep up the pressure to help Sun get better at balancing the needs of compatibility with the desire for innovation.

To find out more about me, take a look at my website: Dream Songs.