Most real innovation is done by crazy people doing crazy things. The keys are:

• Learn all you can before you go adventuring.
• Don't be afraid to make mistakes.
• Only make new mistakes.
• Keep your eyes open.
• Don't just look straight ahead: develop your peripheral vision.
• It's the things that go in unexpected directions are the most important.

One of the classic stories of serendipity and invention is the color mauve.

• Some have asked why IBM is sending open letters, rather than talking to us directly: asking if this isn't rather kindergarten-ish. Well, yes: it does appear that way.
• Some have asked what IBM would get if Java were open-sourced: doesn't IBM already have the source? Again yes, they do have the source. It's also true that anyone can get the source. The major restriction is that if folks want to redistrubute their changes, they have to pass the test suite. Which means that about the only thing that they could get from liberalization is to be able to skip testing.
• Some of IBM's statements have essentially distilled down to "we'd love to help: open source java so that we can". This has led to questions about whether or not IBM has been able to help. The answer is that they have. They're one of the strongest participants in the Java Community Process. Their participation over the years has been substantial, and we're very thankful for it. For example, IBM was the major mover that led to the creation of the Swing API to replace the AWT api. They contributed many engineers to the Swing team. Viewing that time in hindsight, it is more than slightly ironic that these days they're endorsing SWT, which is essentially a clone of the AWT architecture, which they had strongly condemmed back when the decision to create Swing was being debated.
• Some have asked when, given IBM's apparent zeal for open source, DB2 and WebSpere will be open sourced: ask them, not me - it does seem unlikely.
• Most of the comments I've heard from folks about open sourciing Java have been negative. Hmmm... Not so much negative as concerned: Developers value Java's cross platform interoperability and reliability. They're afraid that if Java is open-sourced then someone will try to fragment the community by creating incompatible versions of Java and ignore the community process, just like Microsoft did. Microsoft did a lot of damage to the community and many developers strongly do not want that to happen again.

  This is a big issue for us. If we do something to make Java even more open-source than it is already, having safeguards to protect the developer community will be something we pay a lot of attention to. Carefully done, open-sourcing could actually promote interoperability by making it easier for disparate groups to align behind one code base.

The platform APIs include extensive facilities built on top of Swing to do window, action, toolbar and menu management. There is also an abstract file system that allows things like CVS repositories and FTP sites to be viewed as file systems. There's a whole framework for wizards, and a facility for managing and storing settings. My personal favorite is the AutoUpdate module that allows applications (at the direction of users through plugin manager UI) to be extended by installing plugins, and to handle automatic updating when new versions appear.

Taken together these dramatically simplify the construction of sophisticated desktop applications. Take them out for a spin!

While it is true that as a part of it we did sign up for Microsoft's Communications Protocol Program that is a part of the US v. Microsoft case, our full agreement both modifies and expands on it to give us a much more broad and useful agreement. It is important to understand that in no way does this lock Sun or Sun customers into interoperating with any Microsoft system on Microsoft's strict terms. Right now, most of our interoperability is achieved through reverse-engineering. We have the option, entirely at our discretion, to access Microsoft's specifications through the collaboration agreement. But before we do so, on a case-by-case basis, we will do an analysis of the business case for the entanglements that such access implies (principally confidentiality and royalties). Right now, the vast majority of the software that we (Sun) produce has free and open specifications and we provide the implementations of a large and growing fraction of it as open source. We are not going to slow down our involvement in the open source community. Right now we have launched no projects that will access any Microsoft specifications under the agreement - we simply have the option to, if we decide that the benefits outweigh the costs.

• In Rick Ross's Where Is Java In This Settlement? he worries that Sun may have sold out the Java community. We didn't. We have not sold our soul to the Dark Side. We haven't overnight turned into mindless lap dogs. We've had a lot of experience with Microsoft over the years, and it has made us very cautious.

  One of his big concerns was about the departure of Rich Green, which the rumour mills say left Sun in disgust (as reported in The Register). This is unbelievably far from the truth. Rich Green was my boss, I was with him day after day. Rich worked very hard to make this agreement happen. He left in relief, happy that things were settled in a way that left him with a clear conscience and a sense of closure. In fact he (and I, and many others) felt that concluding the suit was good for Sun, good for the industry, and good for the Java community. He left for entirely independent reasons that have nothing to do with Sun and had really been hanging in to make sure that the court cases got settled right. He still has good relationships with everyone at Sun and left on a very friendly basis. He will be missed by all of us, and will remain a visible presence in the industry.

  Farther down in the article Rick characterizes Microsoft as having paid off Apple to "abandon its commitment to Java compatibility". I use Apple's OS X every day, and I work with folks at Apple all the time: their commitment to Java compatibility is very real.

  One thing he says that I agree with is where he says "How can Sun show us that it still has the strength, vision and leadership to deserve our support and loyalty? The way they should do it, in my opinion, is by ensuring that a significant portion of the settlement proceeds will be used to benefit Java developers and strengthen independent, standards-based efforts to advance Java.". This is exactly what's being done. Our investment in and commitment to Java is very strong.

  We fought hard to win those court cases. And we did win. Bigtime. Finally getting them cleared up gives us an extra pile of cash to invest in moving forward, it stops sucking the life out of all of us who dedicated enormous amounts of time to the cause, and it frees us from all sorts of procedural entanglements that were a part of the litigation process. This settlement is a Very Good Thing.

• There's a long thread of discussion on Slashdot Two Takes on the Java Dilemma that is pretty entertaining, from a wow, what are they smoking! point of view. There are voices of reason, and conspiracy nuts. There are so many comments that it's impossible to go through them all. I'll just address a couple near the top: Java is most definitely not for sale. Not to IBM, not to anyone.

  There are a set of postings in that thread that aren't directly about Java, they're about Unix and x86:

  Yes, Intel x86 can handle many of the tasks that only Unix machines used to be able to handle. I'd just tend to debate whether they're capable of doing these tasks as cost effectively, as reliably, and as efficiently.

  Well judging by the amount of people dropping their old UNIX gear, and taking up rackfulls of AMD or Intel boxes (especially the new 64bit offerings), i'd say the answer to that is a big YES.

  This is a bizarre comparison because x86 is a CPU architecture, and Unix is an operating system family: they are not the same things! All the Unix flavors run perfectly well on x86. Yes: Linux is a Unix flavor. Where this relates to Java and Sun is that because such a huge fraction of customer applications that run on Sun hardware is written in Java, we can treat CPUs (and even operating systems) as commodities, in the same way we treat disk drives. We can use whatever underlying CPU technology (x86/x86-64/Sparc/...) or OS technology (Solaris/Linux/...) is most suitable for the situation at hand. We aren't constrained by the instruction set or OS interface that is baked into our customers' applications. This is hugely liberating for hardware design.
• As for Richard Stallman's Free but shackled: The Java trap , it's hard to know where to begin. He has his own rather peculiar definition of "Free" that I think violates the First Law of Thermodynamics (energy is conserved): developers put a huge amount of energy into creating software and if they can't get that energy back in a way that balances, then the system falls apart. I've been in this discussion countless times and I'd like to avoid landing there again. GPL software is not "free": it comes with a license that has a strong political agenda. Like GPL software, the Java platform is "free" in many senses: you don't have to pay anything for the runtime or developers kit and you can get the sources for everything. Unlike GPLd software, the Java sources don't come with a viral infection clause that requires you to apply the GPL to your own code. But the sources for the JDK do come with a license that has a different catch: redistribution requires compatibility testing.

  This is just context for the real point I want to make: when you have platform software like Linux or the JDK, the platform interface (in the case of Java, the VM and API specifications) divides the world of developers into two groups: those who work under the interface to implement it, and those who work above the interface and build applications based on it. These two communities have needs that conflict. In particular, a blanket freedom for developers under the interface, to do whatever they damn well please, is incredibly disruptive and damaging to developers above the interface. The catch in the Sun Java source license is all about defending the needs of developers who work above the interface. This ends up being constraining to folks who work under the interface, but in a way that is hugely beneficial to those who work above. We believe that for a developer who has built a Java application they have a right to trust that when some other developer says "I have a Java VM for you to use", that their application will work.

  So yes, like the GPL, our source license does have an agenda. It's not a hidden one, and we believe it's a very beneficial one (at least, to application developers!).

• There has been a big debate about implementation languages in the Gnome world. It's been all over the map, but one point of concern has been a set of formless dreads about the usability of the Java language specification. We've been very clear about this, but it seems like few have read the spec: if you look in the frontmatter, it contains an explicit statement that anyone is free to implement the specification. It goes much farther than most other specification documents: it actually includes a patent rights grant.