IMO

... and Oracle killed it. By this time, most people know that the ASF has resigned from the JCP EC. What was posted was our final version of the notice, but I'd also like to share with the community an earlier, rougher and more "emotional" version. It says the same, but in a more face-to-face conversational way. I feel that both versions represent the disappointment, anger and sadness over this whole issue, which has been fostering since 2006. The below just captures it from a different point of view:

The Apache Software Foundation is resigning from the Java Community Process (JCP) Executive Committee (EC). On December 7, 2010, by a vote of 12 YES and 3 NO votes, the EC approved the Java 7 and Java 8 JSRs and TCKs under license terms which are fundamentally incompatible with open source. The results of the Java7/8 JSR votes from yesterday mean that the EC has just approved a major fundamental JCP specification which, along with its TCK license, makes distribution of a tested, compatible implementation impossible under *any* open source license by anyone other than Oracle. The EC, by voting in favor of the Java 7/8 JSRs, have given Oracle, who openly ignored the letter of the law as well as the repeatedly stated intent of the community, tacit approval to willfully ignore its contractual obligations, despite any "protests" within their "YES" vote comments. This approval was at the direct expense of a fellow EC member as well as the Java community at large. Yesterday's vote is the final straw in an issue which has been ongoing since August 2006 and as described in our Open Letter dated April 10, 2007. The withholding of an acceptable, FOU-free TCK by Sun, and now Oracle, is against both the spirit and the letter of the JSPA. What is not new is that Oracle continues to violate and not honor the JSPA agreements, which are a foundation of the JCP. What *is* new is that the EC, by fact of their vote, has allowed them to do it. It is obvious that the JCP is not a standards forum, nor a community process at all, but rather a cabal to control the Java ecosystem. The ASF can no longer justify its continued involvement within this entity. As such, the ASF is removing all official representatives from any and all JSRs. In addition, we will refuse any renewal of our JCP membership and, of course, our EC position. The ASF is saddened to have to make this move, but we feel that the JCP is completely broken and makes a mockery of the term "community," a concept which has great value to Apache.

Of course, we had hoped that our previous blog post would have spun up more support, but being the pragmatists that we are, we also knew that the other EC members were being seriously pressured by Oracle to vote YES, and so we held out little hope. We also hoped for a better response from Oracle, but what we got was basically self-serving lip-service with what is most likely the funniest and yet most inaccurate line yet in the whole ordeal:

"Oracle provides TCK licenses under fair, reasonable, and non-discriminatory terms consistent with its obligations under the JSPA."

If that little nugget doesn't show that Accuracy and Oracle don't mix, I don't know what will. The JSPA says, in 5.C.III, that a spec lead can't:

"impose any contractual condition or covenant that would limit or restrict the right of any licensee to create or distribute such Independent Implementations"

and, of course, the FOU restriction does exactly that. And as far as "non-discriminatory", well, Oracle has deemed that OpenJDK (*their* distribution) not have any FOU restrictions on the TCK, but that the ASF's (Harmony) will. And that isn't discrimination? And so, the JCP is dead... All that remains is a zombie, walking the streets of the Java ecosystem, looking for brains... But maybe, from this death, a new, true community process might arise somewhere, with a different collection of people, one with no entity "more equal than others". That is something I think the ASF would be quite interested in seeing.

If you look at the projects within the ASF, you'll notice right off the bat that the vast majority are Java. We do have a handful of other projects based on other languages but, for better or worse, most of 'em are Java. But if you look at the code that *powers* the ASF you'll notice a big difference. For one thing, for the most part, we do not run anything that requires a JVM (well, we prefer not to). Also, we prefer all of our sites be as static as possible, which makes mirroring them easier. But the biggest surprise might be just how much we use scripting languages for all the tasks/applications/tools that we need. We use a suite of Perl, Python and Ruby, with Perl being the clear frontrunner (mostly since JoeS is such a Perl monger). What I think is so useful about all this is that it gives a true, clear perspective on how real infrastructure is architectured (my word). People tend to focus, unjustly, on the applications themselves, and give little thought or credence on the infra required to truly support and implement all that. And this skewed perspective can easily result in bad, dangerous mistakes when making the transition from one architectural design to another, because it ignores a big, big part of the puzzle. As people look at, investigate and migrate into the cloud, this will become even more of an issue. And a concern.

Today, I (as Release Manager for the project) released the latest, and what is expected to be the last, alpha version of the NextGen release of Apache httpd. This is pretty exciting news because for now on we'll be focusing on pushing out beta releases in anticipation of a quick trip to 2.4.0-GA. Certainly, Apache httpd 2.4.0 has been a long time coming, but it will be well worth the wait. The new features, especially related to MPMS, Authn/Authz and the Proxy module, will continue to be the reference standards for web servers. I'm really excited by all the mod_proxy improvements because that's an area which I, and others, have been giving special attention to. You combine that with the various async changes, the Event and (for the time-being still experimental) Simple MPMs and you have a killer server. So download and try it out and give us your feedback. Cheers!

The ASF uses an ssh-based voting tool, mostly developed by Roy, to handle the new member and new director voting process. New members are elected in using a simple yes/no/abstain whereas directors are voted in using the STV system. The tool is great, but it had the requirement of actually having to ssh into a specific machine to cast your votes. Well, after some discussions on the members mailing list, our illustrious SysAdmin Joe (with some patches from others) created this exceptional GUI front-end for the tool, which makes casting votes even easier. Hopefully, with this front-end, the voter tool will be used for a bunch of other things... As far as setting up the voter tool, well, I just use a bunch of scripts I hacked together years ago... Not fully automated, but good enough.

I've made my ApacheCon US 2008 slides available at:

• http://people.apache.org/~jim/presos/ACUS08/

There will also be available on Slideshare shortly as well.