Category Archives: open source

Google Contacts and CardDAV

Earlier this week Mark Nottingham wrote about CardDAV and DAV based protocols:

All of this led me to mutter ‘DAV WTF?’ at the IETF APPS Architecture Workshop the other week. Do we really need to give folks the opportunity to mint more application-specific methods and headers?

Interestingly, Lisa Dusseault — one of the core folks in the DAV world — blogged about this the other day;

Were I to propose CalDAV today it would probably be CalAtom — some things would be easier, some harder, but it would catch a wave instead of drifting in the tail of something that was never much of a popular wave. Oh well, we needed something then, and WebDAV gave the most leverage at the time.

I gave a big sigh of relief when I read that, and I hope that the CardDAV folks take this to heart. Some parts of WebDAV (e.g., properties; see Yaron and Larry on this) deserve to be taken out back and shot — although, as Lisa says, they were necessary because of the state of the art at the time. That doesn’t mean we can’t do better now.

Almost as if in answer, yesterday Google announced the release of the Contacts API, which is AtomPub/GData based. Unlike CardDAV, it’s not based on vCard, which is both a blessing and a curse, since lots of popular contact systems (like the Mac address book) know how to export vCard information, and because vCard provides a very rich model for information about people. I’m not sure whether this is progress or not.

Twitter, meet Planet…

So Cote thinks that it’s time for organizations and companies to aggregate Twitter:

In theory, this whole pulse idea could be packaged up to be as easily deployable as ‘planet’ sites. Here, ‘pulse’ is the operational brand-name of aggregating Twitter accounts, where as ‘planet’ is the tried and true operation brand-name of aggregating blogs.

Last time I looked, There was an RSS feed for every person on Twitter, and the code for Planet is available (I’m pointing to Sam’s Venus version). About the only thing missing here is a nice web based UI that lets you put in people’s Twitter user names….

Today was my last day at OSAF

My first day at OSAF was odd because I just walked into my home office and bam, there I was, at work on my new job. My last day was correspondingly odd, with a round of e-mail and IRC goodbyes, and my exit interview over the telephone. Such a difference from the normal way of work. This is also true of my nascent job search. I’m going to wait until that has come to its conclusion before I write about it, but already the experience has been very different from every other time I’ve looked for a job.

OSAF 2.0 and Me

On Tuesday, OSAF announced a substantial restructuring of the Chandler project. We’ve accomplished quite a lot on Chandler over the last 12-15 months, and I am particularly proud of what the Chandler Server/Cosmo team has accomplished during that time. The project is entering a new stage, with a much smaller staff. That staff will not include me — I felt that the project would be better served by letting me go and keeping one more engineer on staff. It is likely that I will remain involved with the Chandler community, although I’m not sure what form that will take at the moment.

I am looking for a new opportunity, and am open to lots of possibilities. I have done a wide variety of things in recent history: development work (server side Java, client and server side Python), open source community work, and engineering management. Depending on the opportunity, I’m able to do any of those things, on either a full time or consulting/contracting basis. My contact information is on the about page of my blog, as is my LinkedIn profile, which is a pretty good summary of my credentials.

Prism App for Photophlow

I’ve been using Photophlow a fair amount over the last few days – It’s been pretty fun, although the real value will come if we manage to use it for shoot planning or review, which hasn’t happened yet.

One thing that I’ve noticed is that having Photophlow open in a browser while I’ve got other webapps running tends to make the overall experience a bit less nicer. So taking a page from Travis Vachon, I created a Prism (Webrunner) application for Photophlow. This lets you run Photophlow as a standalone application, in a container which is essentially a custom version of Firefox. You can get the webapp here. You will also need a copy of Prism to make this work.

ApacheCon US 2007 Update

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

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

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

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.