Despite what some other outlets are saying, the Apache Harmony project is not dead. Evidently, Tim Ellison, a senior developer on the project, said things would wind down soon for Harmony. But Geir Magnusson Jr., creator of the Harmony project and member of the Apache Board, when asked if Harmony was coming to an end, said definitively "no."

Apache has no plans to scrap Harmony. IBM wanted to support OpenJDK, and that's fine. At the Apache Foundation, the people are participating as individuals, so IBM is not a member of Harmony. My assumption is those employees that worked on Harmony before will now work on OpenJDK.

And, certainly that's a big loss. It's not a good thing for Harmony at all. But keep it in perspective: For the Apache Foundation, it's up to the community what will be done. We do what the community wants, not what the board wants. We have retired projects before, and if the community decides that's what it wants to do, fine. But there are a lot of phones in this world that are running software that came from the project. Android uses the Harmony class library.

In case you missed it, the Internet exploded this morning over news that Oracle would be suing Google over its use of Java in the Android platform. Software patent litigation at its finest. I've linked to the actual legal document at the bottom of this post, if you want to read the original text.

Additionally, James Gosling has posted a short blog on the subject, but his blog exploded, too. Here's the transcript: Oracle finally filed a patent lawsuit against Google. Not a big surprise. During the integration meetings between Sun and Oracle where we were being grilled about the patent situation between Sun and Google, we could see the Oracle lawyer's eyes sparkle. Filing patent suits was never in Sun's genetic code. Alas.... I hope to avoid getting dragged into the fray: they only picked one of my patents (RE38,104) to sue over.

We'll be talking to the folks behind the Harmony project, as well as folks around the valley next week to get a bigger perspective on this litigation and its implications for Java. Could this be the first nail in Java's coffin? Will the phone makers be culpable? What does this mean for the Apache Foundation, Red Hat, and anyone else who builds open source Java infrastructure?

It's kind of funny, though. For years, Sun tried in vain to make money from Java. It would seem that Oracle has finally found a way to monetize the language.

Oracle's complaint against Google for Java patent infringement

The Apache Foundation recently elevated a number of projects to top-level status. One of them, which has flown under the radar since its creation in 2003, is Click, a framework for Java Web application development. The problem, according to its creator, Malcolm Edgar, is that Click is so well documented, and so easy to use, he gets little feedback from people using the framework. "Because of our efforts, we don't get a huge amount of questions. There have been a lot of downloads, and we know people are using it, but we never hear from them," he lamented. When Edgar began work on Click, there were no standards for Java application frameworks. "We were only given low-level plumbing tools," he said, which was followed by the emergence of the Struts framework. "Struts is the COBOL of Java Web applications," he said. "If you build containers and low-level down-in-the-weeds stuff, it's for you." But Edgar wanted something with greater focus on the user interface, and he got involved in Tapestry. "I thought it was the best thing since sliced bread," he said. Inspired by Web Objects from Apple, Tapestrybrought fat-client UI constructs such as actions and events. It was "more of what a UI framework should be like, more than the I/O stuff that was around then," he said. But Tapestry had too big a learning curve, and Click was a response to that -- a framework with sophisticated UI concepts but readily usable in commercial settings, where there is a lot of job churn and variation in programming expertise. There was a need, he said, "for something people can get their heads around in a few days." Click is a core component for Avoka Technologies of Sydney, Australia, where Edgar is a software engineering manager for the company's FormCenter forms hosting platform. As to whether Avoka might follow the trend to commercialize open-source software by offering support packages, Edgar said there is just no business model. "Apache is the best place for this. There's a big community behind [Apache], so it won't go away in a few year's time, which is important for people making decisions about what software to use."

It's hard to believe it has been 15 years since the Apache Web Server was first created. I'm sure we could all sit here and ruminate, quoting stories and telling tales of great excitement in the data center from years past. But instead, I'd just like to mention a simple truth that shows just why Apache is the Web server of choice for most of the Internet. Every time I have recently been privy to a troubleshooting session in an enterprise, there is one commonality when they're using Apache: they always rule it out as a point of failure immediately. If you're using a stable Apache, you can be almost positive that your problems have nothing to do with the actual server itself.

It's that stable. And has been for at least 10 years. That's not to say some of the mods that can be added to the server aren't glitchy from time to time. But when you get right down to it, the Apache Web Server is, generally, the most stable and reliable part of any Web stack. And that's why, after 15 years, it's still the only reasonable open source choice. New HTTPd servers come and go, and every time I see someone talk about LightHTTPd, or some other replacement for Apache, invariably, there is an email to Bugtraq a week later that renders the advantages moot due to some newfound security risk.

It says a lot that any security problem in Apache Web Server is immediate front page news. Mainly because they occur about as often as the Olympics. Anyone care to share an Apache story?

Like a kid waiting for Christmas to come, I have been watching the Mahout project with great anticipation. When you toss around the concepts of map/reduce and machine learning, there's an awful lot of potential for radical ninjas to ensue. While the magical science-fiction world of artificial intelligence is still in a fetal state within our reality, it is, nonetheless, a growing science.

One of the things humans are discovering about making real thinking machines is that a wealth of experience goes a long way. It's the same for humans and machines: The more memories we have, the more we are able to structure thought processes based on those memories, and to learn from them. For computers, memories can be thought of as datasets. And the bigger the dataset, the more understanding can be extracted.

We all know about the BIG DATA PROBLEM. But if I were going to write something here in the guise of a souped-up VC, or grizzled startup veteran, I'd say the big data problem, when observed from the right angle, is more like a big data opportunity.

Imagine how much optimization information you could pull from six years of user logs? Need metrics, anyone? Try juicing all of your user stats. Not just this month's stats, but all of them. Why not throw in the databases of old user info you got from that newly acquired company you're still digesting? Hadoop is the place to put all of this stuff, as we should all know by now. But the data in Hadoop is only as good as the people who extract meaning from it. And with petabytes of data available at once, what human being could ever comprehend, much less query that mound of information? We can, and do, poke at it, and pull massive amounts of data from it. But there is the potential for infinitely more meaning to be derived from our data.

The big data problem is not a problem with the machines anymore. They're ready, thanks to Doug Cutting, the Apache Foundation, Yahoo, Facebook, Cloudera, and all the hordes of other Hadoop committers out there. The big data problem is a problem with us. These datasets are just getting too big, and we can't spend our days reformatting them, writing connectors for them, or passing them through oodles of filters.

Today, enterprises spend most of their time integrating, not coding. They're making this database work with that database, and wrapping this system in that one. Most of these activities are performed to transform data from one form into another. The customer database has to be able to exchange information with the new databases brought in through company mergers. The HR system has to talk to the ERP system, and both have to be backed up according to processes that change daily. It's all about taking information, transforming it programatically, and passing it on. And the way we do it now is ludicrously inefficient.

No, the future is not in "integrating" big data. The future is in teaching the machines to understand big data for us. We've already done this in places that aren't generally associated with artifical intelligence. Take a look at any corporate firewall or load balancing system, and you can see how the rules have moved away from being simple laws into ever more complex Turing-complete languages of their own. Most of the business processes you work with every day are essentially organically grown machine rules; they've evolved out of experience with what works for the organization. Companies are, after all, organic hive minds with mechanical arms. Large distributed systems, as it were.

If we can build enough common tools to create machine learning on top of big data, humanity as a whole will be remarkably changed for the better. Imagine machines able to identify cancer trends through the analysis of patient data correlated with weather patterns and bird migration. Who knows what sort of broad connections like that could exist in our world? Perhaps someone will teach the machines to look through our software repositories and learn how to write code by understanding every check-in, every rewrite, every refactorization...

Of course, this is all still pie-in-the sky. Mmmm, pie. Pie is good. But you can't make pie without first making dough. And before you make dough, you have to crush grain into flour. And harvest the grain. We all currently exist somewhere in the latter portion of that metaphor, as far as building big learning machines is concerned.

No matter: The folks behind the Mahout project are working on making that dough. Mahout began as a sub-Lucene project, and has morphed into the first real attempt at building a foundation for machine learning on top of Hadoop. Version 0.2 of Mahout was officially released on Wednesday, and there's a number of interesting new features:

• Significant performance increase (and API changes) in the collaborative filtering engine
• K-nearest-neighbor and SVD recommenders
• Much code cleanup, bug fixing
• Random forests, frequent pattern mining using parallel FP growth
• Latent Dirichlet Allocation
• Updates for Hadoop 0.20.x

The point is: Pay attention to Mahout. Maybe go contribute some code. It's an interesting project that, I feel, is really working towards an inevitable future.

Just a quick note to all of you out there in the tubes that ApacheCon is going on now. I am off to the 10th anniversary party, here in my home town of Oakland. It should be a fun bash, especially because Microsoft and HP are some of the sponsors. The conference continues tomorrow, but the party goes all night tonight! I've uploaded our pictures of the event. they can be seen on Flickr. Oakland Mayor Ron Dellums also declared today officially ASF Day in Oakland.