If you've ever written a system to parse or generate XML, you owe something of a debt to Tim Bray, he co-authored the initial specification XML 1.0 published in 1998. And, nearly a decade after the introduction of XML, it is a concept familiar to all programmers and many non-programmers. Given this achievement, one might be content to rest on one's laurels, but in talking to Bray you get the sense that, while he might be best known for his contribution to XML, he is singularly focused on the development of the next generation of participatory technologies. Bray is focused on the Atom publishing protocol, contributing to open source, and helping to push Sun toward a more "ecumenical" approach to web development. Most importantly, you get the sense that Bray is trying to use technology to create an Internet that is more transparent and inclusive Internet.
In 2004, it was Bray's efforts in concert with other executives (Phipps and Schwartz) that helped make blogging something to be encouraged at Sun. Here's an excerpt from an entry on Bray's blog from 2004 titled "Making Sun Policy" in which he discusses the decision-making process that went into Sun's more liberal blogging policy:
...It became apparent that there were a lot of people out there who wanted to speak up but thought it might be a firing offense. It turned out that Sun had an official policy in place from years gone by, saying that speaking up in public without management and legal approval was a firing offense. Jonathan's reaction to this discovery wasn't printable.
At the same time that Bray was trying to encourage Sun to become more transparent and responsive to the community in 2004, the Java platform was suffering from a sense of stagnation and irrelevance. In October of 2004, the O'Reilly Network ran a feature article about "The State of Java" in which various editors chimed in with observations about how Java had become "stale" and how Java had become "the new COBOL". Clearly, Java was having something of an identity crisis three years ago.
Fast forward to today and Java's reputation is recovering. The platform still has its opinionated detractors and there are always ongoing language wars, but fewer people are comparing the platform to COBOL. We're seeing a new renaissance of creativity as projects like JRuby or sleeper projects like F3 start to expand Java, the platform, beyond the limitations of Java, the language. And, more often than in the past, Sun is encouraging internal staff to engage the community.
Recently Bray had an opportunity to reflect on three years of Sun's blogging policy in Three blogs.sun.com Years:
It's helped improve Sun's image. Three years ago we were seen as a big faceless lawyer-bound monolith; now the world sees that this is in fact an unruly tribe of people, many of them really bright, maniacally focused on the tech and biz of IT.
Sun's financial performance could best be described as "mediocre" since naming Schwatz as the CEO, and Sun is facing challenges in the form of declining sales in its core server market and competition from both HP and IBM. Sun has succeeded in changing developer perspectives by open sourcing both Solaris and the JDK. It would be inappropriate to give Bray sole credit for helping to resuscitate Java as a platform, but clearly, Bray's dedication to transparency and push for community participation played a signifcant role in helping to change perceptions. Time will tell if this change in perception helps to bolster Sun's services segment and if corporate-community engagement affects the bottom line.
Tim Bray recently took some time out of his hectic schedule to talk to the O'Reilly Network about his current work on the Atom protocol, his views on JRuby, and Sun's evolving Web strategy. Here's the transcript:
Tim O'Brien: In your role as Director of Web Technology at Sun Microsystems, what do you focus on? What are your day-to-day responsibilities?
Tim Bray: I'm a generalist. I'm interested in everything from the operating system up to through the web tier up to the application layer. And, Sun actually is probably a little bit undersupplied with generalists. Obviously, we have world class experts in Java and operating systems and things like that, but I'm more a multi-layer person.
So, I have a pretty free hand in what I turn my attention to. Clearly, it involves spending a lot of time listening to what people are talking about out there. I go to a lot of conferences. I attend quite a few internal meetings down at headquarters. For the large part, I'm a communicator. I'm always tinkering with software and usually have some sort of development project underway.
O'Brien: Paying attention to the JRuby project, I noticed there are some Jira bug reports from you. You said you are a communicator, but how active are you in particular projects? Are you overseeing people who are involved in projects like Glassfish and projects like JRuby?
Bray: I have no direct reports. I'm certainly not overseeing people. I use JRuby, and since it is a fairly bleeding-edge kind of thing, that means I find bugs. When I find bugs I report them. You'll also see me reporting bugs occasionally on NetBeans. I think those would be the only two projects I've actually reported bugs on in the last year. That's not true, I also reported a core Ruby bug. Let me see, what else. I pay close attention to Ruby on Rails, and those would be the only ones I'm watching really closely.
Wait, that's not true, there's a couple of internal projects of course that I watch closely. Things that aren't announced yet. Come to JavaOne and hear about them
O'Brien: On Ongoing there are links to software projects like APE, what is APE?
Bray: I co-chair the IETF Atom Working Group, and the current thing that the Atom Working Group is just about finished with is the Atom protocol. And, I've discovered in the course of working on standards, that when you write a standard, it really helps to try to implement it at the same time. Because then you learn what works and what doesn't work, so APE stands for Atom Protocol Exerciser and it is a program that emulates all the things that an Atom protocol client would do. It is used to test implementations of the Atom protocol.
I wrote that myself, and we had an Atom protocol interoperability event this week actually at Google and it really got put through it paces.
O'Brien: I saw the compatibility chart on the Wiki, it looked interesting.
Bray: It was a fascinating event
O'Brien: On the Atom protocol, on your blog this week you wrote a blog entry called "How Big is the Club?". In this entry you mention speaking at a conference and mentioning Twitter only to realize that not that many people really understood what it was. Have you ever had that happen to you with Atom? How large do you think the Atom audience is? Who's really paying attention to Atom?
Bray: At the moment the only people who are are paying attention to Atom are programmers and implementers. First of all in the syndication space, and then in the general web technology space. And, that's as it should be. I would point out that when we were building XML 10 years ago, similarly, the only people that were paying attention were implementers.
Atom is not something that should ever be visible to an end user any more than XML is. On the other hand if our hopes and dreams for its application are true it should really have a dramatic impact on the end user experience of the Web. But down in the plumbing it enables things that people will experience.
O'Brien: Most people look at Atom like they look at RSS. It is "Just a syndication format"..
Bray: ...well, Atom is two things, first of all it is a syndication format, absolutely, so the Atom data format is essentially just a cleanup of RSS based on what we've learned in the years that RSS has been deployed. And, that work is finished it is RFC 4287; it is done and shipping it is fairly widely used.
The other half of Atom is the Atom publishing protocol which is what we were talking about earlier...
O'Brien: How is the Atom Publishing Protocol going to transform the Web. Most people know it as an syndication format, tell us something about the publishing protocol.
Bray: You may have heard of something called the MetaWeblog API, which is what some blogging systems use to support publishing. It is trying to do that.
Here's the dream; everything should have a publish button. Every spreadsheet, every cell phone, every camera, every news reader, every mail reader, every word processor should have a publish button. As soon as you see something you like on your screen, you should be able to press the publish button and have it on the Web. And, for that to happen, and given the fact that there are a lot of different places to publish on the Web. I mean maybe you are on Blogspot, maybe you are on Facebook, maybe you are on LiveJournal...whatever; there's going to be more coming. Clearly, you need some sort of a uniform protocol that anything with a publish button can use to communicate with anything that publishes.
Atom is a very light protocol layered on top of HTTP designed to enable that dream. Based on what we saw in the room at Google this week I think we're well on our way to realizing that dream.
O'Brien: Hypothetical, you work at a place like the New York Times or the BBC, and there is a content management system (CMS) system that tracks everything from images to news stories. Do you see Atom as something that could be extended for all content types? Is that what you are trying to get to with Atom? Or, is it just for blogs, just for photostreams, just for spreadsheets. Are you trying to build the foundation for a general content repository? Something that could be used in a an enterprise content management system?
Bray: Well, I have a very bad track record of predicting the applications of general purpose technologies that I help invent. My predictions about what XML was going to be used for were notably wrong. The design center of the Atom protocol was clearly blogging. On the other hand, we're already seeing applications that are not blogs. For example, a couple of your colleagues from O'Reilly came to the interop event and had Atom server implementations that had nothing to do with blogging; in fact APE couldn't interact with them because the only thing they could upload was DocBook XML. What we're trying to do is do a really good job of producing something that will be useful for the blogging space, but it doesn't have any built in limitations.
My prediction is that there are going to be a lot of applications that I'm not really smart enough to predict and will surprise me.
O'Brien: And, that's via the extension mechanism that is a part of Atom?
Bray: Indeed, but also it is just the basic function of having a super lightweight way to do what we computer programmers call CRUD operations that is create-retrieve-update-delete. A general purpose lightweight way for a simple minded implementation to put things on the web, update them once they are there, and delete them when you don't want them anymore. That just by itself ought to have a lot of interesting applications.
O'Brien: Is it time to turn off our RSS feeds?
Bray: Why would you do that? Sorry, I don't understand. RSS is the world's most successful application of XML, and is being used by literally hundreds of millions of people. I'm missing something...
O'Brien: I meant, is it time for a universal switch to Atom? Is it time to turn off our RSS feeds?
Bray: Oh, I see what you are driving at. Well RSS seems to work just fine for basic person-to-person blogging. I think that most implementers given the choice would rather work with Atom because it patches a few irritating glitches in RSS. If you are writing a facility that is to consume feeds, you are going to have to consume both RSS and Atom, and it is worse than that, you are going to have to consume multiple versions of RSS. Because that's the way it is. On the other hand, if you are writing something new that generates a feed, you might as well generate Atom because it is a lot cleaner, and it will route around some bugs that might otherwise bite you. All the software out there that reads feeds can now read Atom.
O'Brien: Do you see RSS fading away in the face of Atom, or do you see people always having to inter-operate between the two.
Bray: I think increasingly new feeds that are brought into production will be in Atom, we're already seeing that. But, technologies on the Internet tend not to die away. You know there are lots of things out there that still use the blink element in HTML. So, I'm sure that RSS will be pumping about the Net in high volumes for years to come.
O'Brien: Is there anything you think the community is missing about Atom, or do you think it's been covered?
Bray: I think that a high proportion of people, haven't yet noticed the Atom Publishing Protocol. Now, judging by the tune of our interop event a lot of people also have, but I suspect that in a couple years from now the Atom Publishing Protocol is going to be a really big deal.
In my lighter moments I say that it has a chance of wiping XML off of my gravestone.
The key points I'm trying to get across: everything should have a publish button because the more contributors we have to the Net the better the Net is. Anything we can do technologically to reduce the friction to enable more stuff to go onto the Net is a good thing and that's what Atom is trying to be. The crucial thing is to enable people to contribute and not just read.
O'Brien: Did you know about that partnership with Canonical?
Bray: Well it was hardly a secret. Mark Shuttleworth showed up at JavaOne last year and he and Jonathan [Schwartz] smooched and made kissy-kissy on the stage. So, it is hardly a secret that Sun and Canonical are buddies.
O'Brien: At the same time, Marc Fleury was also on stage at JavaOne and there is no similar partnership with Red Hat? Is it correct to assume that you are siding with Ubuntu at the expense of the relationship with Red Hat?
Bray: Well up until last week, because we had these licensing issues around the JDK, and NetBeans and EE and all these other things, you just couldn't put them into any Linux distro in any good way. We made our policy decision a year ago that we were going to open source this stuff, but, as you probably know, there are a lot of legal mechanics that go around getting the licensing right and so on. And, that took a huge amount of work. I happen to know that it was being worked on just days before the announcement; there were a lot of i's to dot and t's to cross. Now that that is done, it is perfectly plausible that any Linux distro can make it very very easy to install Java and use Java.
Canonical was the first to step up and do it with Ubuntu, but I can't imagine any major Linux distro not doing it.
Why would you not make it easy to install Java?
O'Brien: The argument from some in the Free Software community is that there are still portions of the code that are encumbered by non-free licenses. Do you have any response?
Bray: That's correct, there are portions of the code that are still encumbered. We were quite open about that. In particular I think it is in the low-level Java SE itself. Some of the examples were the 2D graphics and the font rendering. And, we are working on fixing that, and hoping for help for the community as well on that. Typically, what happens whenever a commercial product is open sourced, it isn't a binary switch were you go from zero to everything.
Having said that, we were able, working with Canonical and engaging the lawyers, to work out a way were it could be in...
O'Brien: ...the Multiverse...
Bray: Yeah, it is in the Multiverse. I am not an Ubuntu guru, I'm not sure what the equivalent is for Red Hat but they've found a way to make it happen for Ubuntu, so I can't imagine that it would be impossible to do for any other Linux distro.
O'Brien: There's no animosity there?
Bray: Not that I'm aware of.
It is clearly the case that right now in the developer community, Ubuntu has got the "heavy mojo." Ubuntu is really engaging the attention and affection of a large proportion of developers and I think that inside Sun as well as outside Sun there's a lot of people who are super affectionate towards Ubuntu. You plug in a digital camera and it just works and stuff like that.
O'Brien: One can only guess at the announcements that are going to come out ay JavaOne. Should we expect JRuby to be finished? It appears that there is a flurry of activity surrounding JRuby.
Bray: It is painfully obvious there is a flurry of activity.
O'Brien: What should we expect news on, JRuby and NetBeans? JRuby and Glassfish certification?
Bray: I couldn't comment on preannouncements.
Let me say one thing, my perception is that the actual biggest driver of hard work on JRuby is getting Rails working nicely. Getting all the Rails tests to pass and getting some big actual Rails applications running smoothly. I think it's generated quite a bit more work than Glassfish.
O'Brien: I get the build emails every two hours and it looks like they are getting closer. Charles has said he won't consider JRuby done until Rails is supported. He's also made some public remarks about the difficulty of web development in Java. Is Sun's embrace of JRuby and Rails, an admission that there needs to be an alternative to JavaServer Faces?
Bray: How to address this? Well, I'm not sure how many alternative frameworks we need. If you look at the market empirically, there are developers who are using lots of different frameworks, people who are using the various web frameworks, both the official EE stuff and the lightweight stuff like Spring and Hibernate.
People are using PHP, a whole lot of people are using PHP. Rails has a fantastic growth curve. Then there are other things that people aren't paying as close attention to such as Django from the Python community. I think that Sun needs to live in the world as it is. And in the world as it is, there's lots of different web frameworks and all of those web frameworks are being used to build applications that need iron to run on and operating systems to support them. I don't see any reason why Sun shouldn't try and love them all as best we can.
O'Brien: So it's not JRuby on Rails in competition with JavaServer Faces, you still see a place for both?
Bray: None of these things is going to go away.
The one concern I've had is that Sun has gotten pretty enthusiastic about Ruby on Rails and so on over the last year. That doesn't mean that we can afford to ignore things like PHP and Django. I think we need to be a good host to all of those things. having said that I think that there's pretty widespread perception not just inside Sun that Rails is hitting a darn sweet spot in web frameworks in terms of two very important criteria: time to market and maintainability.
O'Brien: You mentioned Seaside on your blog. Are you paying attention to Seaside? What interests you about Seaside?
Bray: It is clear that Seaside is quite architecturally different from all the other web frameworks. You've got to watch out here because I have a conflict of interest as an investor in DabbleDB, so I have real money on the line. Having said that, the reason I'm so impressed with that software is what it does, not how it is built. DabbleDB has an absolutely wonderful user interface and seems to do something to me that's tremendously useful. I was flabbergasted when I found out it was built in Seaside. But clearly, its existence is pretty strong evidence that Seaside is useful.
O'Brien: So, Seaside is something to pay attention to?
Bray: I think that DabbleDB is something to pay attention to. It may just be the case that the two guys who built it are such brilliant designers that they could have produced something like that using a different framework. It is at least an existence proof that Seaside can be used to build things that are interesting.
O'Brien: I just asked you a series of questions about JRuby and different web frameworks, and one can only notice that Sun is getting more involved and aggressive about embracing scripting. Is there anything else you'd like to comment on?
Bray: I think that Sun is trying to change its stripes somewhat. Up until this last year Sun's basic positioning was, "Well the answer is Java, what was the question?" And, while I think we are trying to become more ecumenical and support developers where they are, that doesn't mean we don't have an opinion. Clearly, we think Java is highly appropriate for a wide range of applications. It is correct to notice that we're banging the Ruby drum these days, but that doesn't mean if you are running PHP we don't love you.
We need to become more ecumenical and reach out to developers wherever they are.
O'Brien: That being said, do you have any plans to change the name of JavaOne to (Java|Ruby|PHP|Python)One?
Bray: I don't get a vote on that.
Timothy M. O'Brien is a developer and entrepreneur living in Chicago, IL. He spends his days programming in Java, Python, and Ruby.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.