I've taken my reports on Aggregators that support gzip and Aggregators that don't implement RFC 2616, Sec 3.8 product tokens and broken them out into separate pages, so the people won't have to go trawling through the blog to find them.

Russell Beattie is the latest Java developer to stick his toe in the Python pond. He's looking for the Python equivalent to J2EE / Orion Server. His post lists some options, and the comments produce some more. This is an area where the Pythonistas could do some focused evangelism / development.

Steven Noels is saying that the value in building something in an open source way is the process it teaches the participants. I agree.

So, what is the value behind building open source, then? As usual, in the end, it all boils down to the people, and the environment they operate in. If you are used to work inside an open source project, you are used at working with a non-strict environmental context. Interfaces can and will change, there will be discussions about design, and you better make sure your code is designed for maintainability and extensibility, or someone else will go in and refactor the hell out of it. Also, you have to stand up and defend your ideas, and you're aware of the fact that people are looking into each and every code change you are committing to the source repository.

It's also a nice side benefit that you get the source code ;-)

More from Bruce Eckel on Python:

Bill Venners: You said in your keynote, "Errors discovered with real data seem to me to be the hardest to find." Bruce Eckel: Yes. If I'm writing a Python program, I can very rapidly get to the point where I have a working program, and then I can actually feed it real data. And it seems like certain kinds of errors are much harder to find without putting real data into it. When you're trying to make something, the closer you can get it to the real thing as soon as possible, the more you'll find out about it early on. You really have to get it that close, or things will slip through the cracks. Bill Venners: You're saying it takes me longer to write code that is statically checked at compile time, but the problems the compiler finds are not the kind of problems that have to do with real data. Bruce Eckel: That's actually very well put. Once I get the program running, I feed it real data. Then I'm going to find some interesting errors. So the sooner I can do that, the sooner I can find those errors.

Via eWeek:

However, GM's Scott issued a strong warning to Microsoft, Sun and the other players in the Web services industry, that enterprises will not tolerate the standards wars of the past. "We have no appetite for it," he said.

Jim Gray, one of the giants of databases, trasaction processing, and systems research in general has this essay on the economics of Distributed Computing. This came across during OSCON, and I didn't have time to blog it because I was trying to be somewhat timely about conference blogs. Later in the day that I saw it, it was cited in the OSCON business models panel. If you are interested in grid computing or web services, you should read this.

Jorgen Thelin and Joseph Ottinger are talking about standards and their relationship to innovation, in the same tones that Andy, Jason, and I have. Nice to see that others are having these thoughts.

Charles Miller ponders the role of Java in

Expansive, inspiring, sweeping developments in the field of computer science

The explanation for this is simple. Java itself was none of these things. It took ideas that had been explored before and integrated them in a (arguably) simple way. After that, it was all luck -- Java was in the right place at the right time.

Santiago Gala posted a comment to Andy's blog that says what I was trying to say better than how I said it.

I think a lot of issues with the JCP come from people trying to use it as a weapon, to impose and freeze a certain approach as "the right thing". This is where I find Ted's approach (routing the process around) right. On the other hand, having JCP to consolidate what people is already using is probably good.

Maybe, then, the problem is with the role of the JCP as "consolidator" versus "innovator" in the evolution of the Java platform.

Andy doesn't want to have the JCP at all:

I want Sun to ditch the whole JCP and move strictly towards open source.

I don't want to go that far. There's a role for standards, but both the JCP and W3C are acting as "innovators" (a better term might be experimenters) not consolidators. In his final talk at OSCON, r0ml suggested that the open source community

should aspire to create a definitive literature for particular problem domains.

That's the essence of what I'm talking about when I say we need to route around the JCP (and actually the same argument applies to the W3C). Even if Sun were convinced to ditch the JCP and just do open source, we still need something like what I described: a definitive, or semi-definitve literature, it's just that in that case the literature would be drawn from open source projects only instead of JSR's and open source is it would be today.

Regarding this comment:

You ignore them, I'd rather engage them.

You've fallen into the trap of revolving your world around Sun. By doing so you give them power. I *am* engaging them. I spent a few hours at OSCON with Danese Cooper and some other people talking about how to solve some of these same problems. Convincing Sun about the JCP is hard. Sun never wanted it, they were strong armed into it by the vendors. Think about that -- you not only have to persuade Sun, you have to persuade IBM, BEA, Oracle, etc., because the JCP is their place to play the lockin game under the guise of standards. I'm in favor of efforts to change the JCP, but I believe you've picked the harder battle, one I'm choosing not to fight (and that's all I was trying to say when I wrote die-hard, optimist, or wishful thinker). Just because I'm not going to fight that particular battle doesn't mean I'm going to sit on my hands.

I saw some things at OSCON that concern me greatly regarding the future of Java. The MS people who came to the dynamic languages BOF tried to come on the terms of the language implementors who were there. Sun has never done this. It's weird when I start to say, "Microsoft actually looks like the more open of the two companies". This is of course like Scylla and Charybdis, but nonetheless worrisome. Miguel's demo of Eclipse on IKVM on Mono should both console and worry people worried about Java. On the one hand, if this thing can be tuned up more, then we don't need a real Sun branded/developed Java VM anymore, and the whole thing is open source. Then we don't need Sun. We also have a migration path for all that Java code. On the other hand, it means playing in the MS vm sandbox, and I'm not naive about what that means. Time is growing short. We need to stop looking at Sun as the potential saviour of all this and take control of our own destiny. And if Sun wants to join us, that's fine.

Lefkowitz, AKA r0ml, talked about missing enterprise scale open source apps. Enterprise apps are aimed at > 10k people and computers over a period > 10 years. Here's his list:

• DistributedCron - you need to run 80k jobs on 10k computers, some jobs depend on other jobs, and you must notify the responsible party if their job doesn't run. Commercial versions typically mess up because they can't preserve the job stat across version upgrades. "You cannot lose telemetry while the aircraft is in flight". He noted that enterprises spend more dollars on operations then on development - this is really an operations problem, not a code problem.
• Asset Management - This is basically a license manager. An effective open source asset manager whould help highlight how much money is our could be saved by using open source. Many firms are unable to track their asset usage. This drives them to sign enterprise wide deals for licenses, which create long term lock in for the vendor.
• Single Sign-On - What he means here is a single sign in Linux distribution. You should sign in once, and then you are signed in for anything else in the system that needs a password. This is a combination of Kerberos, PAM, OpenSSL, LDAP, and modifications to every password using piece of code in the distribution.
• Messaging - MQ Series, Tibco replacement.
• Change Management - Challenge: what would it take to rev Debian stable on a weekly basis? If the systems manager needs to undo a particular update, the affected systems must automatically be upgraded. Keep the rpmdb equivalent off host. Challenge: how can I tie a CVS check in to a bug report (and the reverse). This is also about a methodology for change management. What is the open source equivalent of the SEI CMM?
• Relationship Management - Open Source CRM. This is about keeping track of your collaborators. We shouldn't just throw software over the (fire)wall to people, we should demand a relationship with them. How can we find out what features they are using ,etc? Questions we ought to be able to answer: What % of bug reports come from employees of financial services firms? Which industries have the highest patch submission to running copies ratio? This is not just the software, it's also the marketing department to go with it.
• Source Terminator - "Source code is like toxic waste - the less you have the better". We should aspire to create a definitive literature for particular problem domains. This doesn't mean a single solution for each domain, it means a set of definitive solutions and approaches. Once we have this we can start deleting code and merging it. Parrot is an example of this approach.

I went to both of r0ml's talks and found both to be thought provoking and entertaining.