Jonathan Schwartz was interviewed about Sun's (inevitable) adoption of RSS. Scoble then disagreed with some things that Schwartz said. Simon Phipps just wanted Sun to be given some credit for moving on the RSS meme. Of course, this exchange lead to the usual comparison of which platform has more RSS aggregators written for it. Which is all old news anyway.

One part of Simon's reply stuck out to me:

We're already here. Not in the legions Microsoft has, admittedly, but it's the quality that matters not the quantity (or, indeed the volume of postings!)

I read a lot of Java related blogs and a lot of MS related blogs, but very few of the Java blogs are by Sun folks. So I followed Simon's link to Sun bloggers, eager to stock up on the good content that I've been missing out on. When I got there, I discovered that the list isn't very long, although it includes lots of Sun luminaries, and that about half of the blogs haven't been updated in 2004. Color me disappointed. It's hard to claim quality when quantity is AWOL.

I started thinking about the broader communities (beyond the companies), because as Schwartz pointed out in his interview, it's really all about communities. So I took a step out. Instead of looking at the MS bloggers and the Sun bloggers, I tried to look at the .NET bloggers and the Java bloggers. When I did that, I saw that there are lots of non-MS .NET bloggers (many quite good) and many Java bloggers, also quite good. In order to see that, I had to stop and think about it for a while -- I'm a Java guy, so good Java blogs came easily to mind. It took a little while longer for .NET bloggers, but I can think of a number of them without consulting NNW, so that's also good.

Even after thinking about it, I still feel that the .NET blogging community is a smaller appendage to the larger MS blogging community, while the Java blogging community is a big place that the small Sun blogging community is trying to break into. What I mean is this: If I'm looking for thought leadership from the community, in the Java community, I'm looking towards the non Sun bloggers -- these are the folks doing AOP, Groovy, SGen, Prevalence, WebWork, etc. This shows the rich ecosystem that has grown up around Java. If I look at the .NET community, I pretty much look for the MS bloggers. There are some leaders outside of MS, but pretty much the thought leadership resides with folks inside the "big house". From where I sit, this is an accurate characterization of the .NET and Java ecosystems.

In the end, the two companies have to decide not only that they want to foster communities, but what kind of community they want.

One of the issues that we are working on for the 0.4 release of Chandler is what we call sharing -- the ability to share Chandler Items with other people. As soon as you start talking sharing, you need to start thinking about authentication and access control. Before I got to OSAF, there was some talk of doing this sort of thing by using capabilities, a technology that people have seen in an OS textbook but never really been exposed to. Fellow ASF member Ben Laurie is a big advocate of this approach. So as we started into sharing, I took some time to look through my (paper) copy of Henry Levy's Capability-Based Computer Systems which details the evolution of capability oriented systems. In these pages you encounter the Burroughs B5000, the MIT PDP-1, the CAL-TSS, the Plessey 250 and its descendent the Cambridge CAP. You'll also find the CMU Hydra and StarOS systems. The IBM System/38 (now known as the AS/400) appears as the only commercially successful capability based system (and most people don't really know about it). The last system described is the ill fated Intel iAPX 432. I was quite enamored of this system -- I think the original Intel databooks are still in a file cabinet in my parents house.

Even if you're not up for a tour of computer architecture, you'll benefit by looking at the first and last chapters to learn more about capabilities and the problems they are trying to solve. It's worth it. As time passes the knowledge of these systems' designers will slowly fade away, and the lessons they learned will be lost, dooming us to insecure C-based hardware forever.