Tag Archives: open source

ApacheCon US 2007 Update

Leave a reply

Yesterday I did my talk on Open Source Community Antipatterns. I am always nervous talking about community stuff in front of an Apache crowd, because these are folks who have a huge amount of cumulative experience in this area. There were some good questions and several people asked me if the slides would be available. I’ve put them up on the page with some of the other for ApacheCon US 2007. I was happy to have that under my belt.

I also co-hosted the ApacheCon Lightning Talks with Brian Fitzpatrick, last night. The Lightning Talks at ApacheCon are very entertaining, to the point of really being part of the entertainment as opposed to being part of the technical program. A no slides rule helps keep it that way. Kudos to those brave folks who gave “straight talks”, and to those who found ways to make their funny talks relevant somehow. Thanks to Fitz for asking me to do it with him — I expect Wilfredo Sanchez to be returning to his regular spot as the co-host, though.

Technorati Tags:

ApacheCon US 2007 is now in full swing

Leave a reply

The main conference portion of ApacheCon US 2007 has now started here in Atlanta. We’ve already had two days of tutorials and the Apache committers’ Hackathon.

I’ve put up a set of pictures on Flickr and will be updating them throughout the week.

Best of the 2.25 days so far: Doc Searl’s keynote about the live web, including ProjectVRM.

Caja: Capability Javascript

Leave a reply

Ben Laurie has posted some initial information about the Caja (Capability Javascript) project that he is leading at Google. The code is going to be open sourced under the Apache License (with Ben running it, that’s no surprise). Caja is based on the work that Ben did on CaPerl a few years back. I saw CaPerl when we were looking at how to improve Python security for Chandler Desktop. Ben was interested in doing some capability stuff for Python, but the stars never aligned for it to happen. I’m glad to see that his work will live on – it’s not like JavaScript couldn’t use some security help. People worried about yet another version of Java/ECMAScript should go read Ben’s post before they complain.

Leopard, Java, and Open Source

38 Replies

I haven’t gotten around to upgrading to Leopard yet for several reasons, probably the most prominent of which is that Lightroom doesn’t work correctly, and I’m starting to use it a lot (more on that in a later post, perhaps). But it’s not for lack of Java 6. I’ve been following the Java on Leopard thing with bemusement, but John Gruber’s most recent post sparked a few thoughts.

Since I haven’t posted in a while, let me remind you of the context. For a while I was a Java developer, but that was another life ago, and since then, I’ve been a Python developer, and am now a manager of Java (and Javascript) developers. I’d agree with John that Java is not directly important to the Mac. No important piece of Mac software that I am aware of is written in Java, and the only important (unless you count Azureus, which Mac folks would not) client side Java apps are Java IDE’s or custom corporate applications. So it is hard to make a compelling argument that a late Java is directly bad for Macintosh sales, which Apple is surely focused on.

Nonetheless, I do think that Java, and all those Java developers (who many in the Mac community look down their nose at) are important. Their pushing for Titanium Powerbooks and MacBook Pros helped (in a lot of situations that I am directly familiar with) to improve Apple’s credibility in development shops, which helped Apple get to where it is today. I might still be using Windows if I hadn’t gone to ApacheCon 4-5 years ago and started to see the Mac’s, which were being used by my Java developing friends.

Gruber says that Java is not made to “just build” on any Unix-like OS:

Several irritated Java developers suggested that I’d feel differently if it were a developer runtime that I personally cared about — that I’d be irate if, say, Perl or Ruby or Python were dropped or degraded in Leopard. But that’s not a good comparison; Perl, Python, and Ruby pretty much compile out of the box on Mac OS X. Apple doesn’t have to do much at all — at least relative to Java — to include them on Mac OS X. Why? Because that’s how these tools are designed and engineered — they’re made to “just build” on any Unix-like OS. It’s not Apple’s responsibility that Java isn’t like that — it’s Sun’s.

Actually, I don’t think that he is correct here. When I worked at Apple, one of the projects that I worked on was a port of Java 2 to run atop the Newton operating system. I personally wrote the driver code for networking and the file system, and I can tell you from first hand experience, that Java definitely builds fine on Unix like operating systems. That’s not the problem. The problem is where OS X is not a Unix like operating system.
The places where there seem to be problems are the places where Java needs to talk to Carbon to do all that client side GUI Java stuff. I don’t think that you can claim that Carbon is part of “any Unix-like OS”.

I do think that there is something important buried in the quote from Gruber’s post. Look at the difference between the runtimes that got “kept” in Leopard. Perl, Python, and Ruby (Let’s leave aside for a moment the sad truth that hardcore Python and Ruby developers end up installing their own local runtimes). Not only were these runtimes bundled, but 2 of the 3 were actually improved – things like bridges to Cocoa, DTrace probes, and so on. What’s a critical difference between these runtimes and Java? How did all these improvements happen? Many of them were done by people outside of Apple, on a schedule that was not Apple’s, but which coincided with Apple’s. The Ruby DTrace probes were done by Joyent, the Python Objective-C bridge was done by people outside Apple. Apple pretty much just had to pick up the changes that were made. How did this happen? Those runtimes are open source, as were all the improvements that I just mentioned.

A few years ago at JavaOne, Sun took a poll of Java developers to see if open sourcing Java was important to them. If I remember right, about half those developers said no. From where I sit, it looks like an open source Java would have contributed substantially to having Java 6 ready to go for Leopard. Today, Sun has opened up the source code for Java, but a version of Java based on that opened codebase has yet to arrive. Maybe open source Java really is important after all. I guess we’ll have to wait for OS 10.6 and Java 7 to find out.

On Scoble’s Chandler interview

1 Reply

A couple of days ago, Scoble paid a visit to the OSAF office in San Francisco and did a video interview with Mimi Yin, the product designer for Chandler, and Katie Parlante, the General Manger of OSAF (and my boss). Of course, I heard about how the interview went, but I was curious to see how the interview would go. Robert and I have talked briefly about Chandler over the years, but not in any detail, and I wanted to know what he thought about what we have done so far. When someone says “I want it”, that’s generally a good indicator, and I was glad to hear that phrase pop out of Robert’s mouth. Also, he asked almost all the questions that I could have wanted him to ask, so if you watch the interview, you’ll get a pretty good idea about some of the most important ideas in Chandler. It should be no surprise that I want to expand/clarify some of the things in the interview, so here goes:

Where’s my Outlook?
If you watch the video, it’s clear that Chandler Desktop today is not very much like Outlook, in the sense that it is not an e-mail centric application. If you believed the Wired-induced hype about Chandler being an Outlook killer, you’re probably disappointed. How did this happen? When we sat down and looked at what people were using PIM’s for, how they worked, and what they needed the most support for, we discovered that there was a big need for supporting groups of people working together as opposed to individuals just managing their own information. That’s why you see an emphasis on sharing and collaborating. A bunch of the infrastructure that we built early on for supporting customized personal information is supporting what you see, so there’s still the capability for doing individual personal information management, but we haven’t focused on those capabilities. Developers take note.

Web-based Chandler
This came across unevenly in different parts of the interview, so I want to make this clear. Chandler Server/Cosmo, which powers our free Chandler Hub service, is a web based version of Chandler. It doesn’t yet have all the features of the desktop version, but we are getting there, and we plan to get all the way there. Not only that, the back end of Chandler Server can provide you with data in a variety of formats/protocols. We want to make sure that you can get data into and out of Chandler Server as easily as possible.

Edit-Update / Sharing (or turning e-mail into a Wiki)
In the interview, Robert latched onto the edit/update features of Chandler. These are still in a primitive state, but you can see the value of them already. He had a great summary of how it works – “you turn e-mail into a wiki”. Exactly. You can create and share a collection with any number of people, and they can all edit/update items in that collection and see each other’s changes, without groveling through endless e-mail reply chains. At one point in the interview, Mimi said something about e-mail being the hub of people’s usage. Truth of the matter is that e-mail is more like the glue that holds batches of information together. Collections of items with edit/update is a different kind of glue.

Plugins/APIs
Robert asked about a Chandler that could slurp data out of Facebook/Twitter/blogs/blog searches and manage all that stuff via the dashboard (the triaging workspace) and Chandler collections. This is a topic near and dear to my heart, and solving that problem is actually the biggest reason that I came to OSAF to work on Chandler. Personal Information Management is no longer about the tiny set of data types that Outlook typically manages. Today, most of my personal information (by volume) lives in the cloud, so any system that is going to manage that information must be integrated with the cloud.

If you look at the Plugins menu of Chandler Desktop, you will see hints at being able to do what Robert asked for. There are demo quality (read: proof of concept) plugins to yank data out of Amazon.com wishlists, EVDB/eventful.com calendars, RSS feeds, and Flickr. We had a plugin for grabbing your del.icio.us bookmarks, but it got way out of sync, but it wouldn’t be too much work to put it back. All these parcels turn their data into Chandler items, which can then be stuck into collections or managed via the dashboard.

On the server, we’re a bit further behind on data type extensibility. It’s possible (I mean it’s code, right?) but it’s going to be a bit more difficult to do because of the server environment. The server does provide good access to calendar data via a number of calendar protocols, including webcal, CalDAV, and Atom feeds. In addition, the AJAXY web UI talks to the rest of the server using Atom feeds and AtomPub, so in theory you could implement a different client by using those feeds and AtomPub. I am quite sure that we will be doing more work on data access API’s for Chandler Server in the months ahead. If you have ideas, suggestions, or code, come by the cosmo-dev mailing list or the cosmo IRC channel.

What’s Left to do?
If you watched the interview, you’ll know that there are a bunch of things that Robert asked about which are not there yet. This is not the 1.0 release of Chandler, and there’s plenty to do. At the same time, the desktop and server are done enough that people can use them and developers can get an idea of what we are trying to do and where we are trying to go. In the server project we’ve already had some good contributions from people outside of the OSAF staff (the hibernate based storage engine, and the minicalendar in the web UI). We’d (the desktop and server projects) love to see even more people get involved.

To keep up on Chandler happenings, visit the Chandler Project blog.

Chandler Preview Release

5 Replies

Last week Chandler hit a milestone that we’ve been calling “Preview”. Preview is a coordinated release of the Chandler Desktop application, the Chandler Server (Cosmo), and a free sharing service, Chandler Hub. Chandler Server not only provides calendar and general item sharing services for Chandler Desktop, it also includes an AJAXy UI that implements a decent slice of the functionality of the desktop. We’ll be working to increase the coverage of that slice over time. Chandler Hub is running on top of the Chandler Server software, and anyone who wants to could run a similar service by grabbing the code and installing it.

Over the years, many people have said to me, “let me know when Chandler is usable”. This is your notice that we now consider Chandler usable. The release numbers on the desktop and server are at 0.7 – so we are not saying that Chandler is feature complete, but the current features are usable. I’ve been using the calendar features for quite some time.

There are some important resources that you should take some time to look at, including:

I’d also like to highlight some of the interesting work that has been going on in the various Chandler projects: Brian Moseley has written a few blog posts about the work that he’s done using REST/Atom to provide services for the AJAX Web UI of Chandler Server. Jared Rhine has written a thorough and thoughtful post about what it means to be/run an “open service”. The OSAF QA team has built Windmill, a great tool for testing AJAXy web applications.

There is plenty of stuff going on in the various projects, and a lot of things left to do. We’d love to work with designers, developers, testers, and writers to bring Chandler to its fullest potential.

ApacheCon US Early bird deadline is Sept 22

Leave a reply

This year’s ApacheCon US runs from November 14-16, 2007 and will take place at the Westin Peachtree in Atlanta, Georgia.

Here are some of the talks that I am especially interested in attending:

I will be giving a talk titled “Open Source Community Anti-Patterns”, and I am thinking of trying to organize some kind of photography BOF/event whatever. If you’d be interested in that, leave a comment.

Early bird registration has been extended to September 22, so register now if you are planning to attend.

The Erlang community

5 Replies

Matt Croydon Didn’t agree with my commentary on the Erlang community, and he’s partially right. I shouldn’t have said “we need a community” because there is an Erlang community, and I knew that. I have never been a fan of Java, and I don’t want to be stuck using the moral equivalent of Java when the multicore/concurrency thing shakes out. So if I want to be able to use Erlang (and I’ve not totally made that decision), then it needs to have a bigger, more diverse, and easier to find community.