Archive for category Computers

Firefox 2.0

Posted by on Wednesday, 1 November, 2006

I tried to like Firefox 2.0. Really. I tried. I’m a huge fan of Firefox 1.5.

The first problem is that it doesn’t feel like a 2.0 release. There’s nothing obviously better or worse about it; all the features are new things under the hood, not normally visible to users. If I secretly swapped your old Firefox for Firefox 2.0, I doubt you’d notice.

That said, I’m still happy about getting the internal improvements like “better phishing protection”, automated search-term suggestions, session resumption, web feed awareness, and javascript 1.7. Seem like nice things to have, even if they’re not particularly compelling.

The thing is, Firefox 1.5 has crashed on me… oh, maybe twice in the last year or so. But Firefox 2.0 has crashed on me every day for a week now. I’ve given up on it for the time being. I’ll wait for 2.1 to see if the stability improves.

More Goings On

Posted by on Monday, 23 October, 2006

The Subversion Summit was a huge success, you can read various bits about on the shared Subversion developer blog.

I’m currently heads-down, working on a new musical-like chidren’s play — Ray Bradbury’s Dandelion Wine, which is opening at the Chicago Children’s Theatre next month.

And finally, a local magazine published an interview of me and my two engineering cohorts at the Google Chicago office. Whee!

Two Great Computer Summits

Posted by on Sunday, 15 October, 2006

I’m back in Silicon valley this week, attending two different gatherings.

The first was yesterday, a summit for mentors who participated in Google’s Summer of Code program. It was really incredible รขโ‚ฌโ€ about 80 representatives from a huge array of open source projects all gathering at Google to talk about their experiences mentoring students. Fitz and I got to give our fun ‘how to protect your project from poisonous people’ talk that we gave at the last OSCON, and it was like a group therapy session. Lots of nodding heads and empathy all around.

Monday through Wednesday of this week is the very first Subversion Developer Summit. Subversion has a thriving developer community, but we’ve never actually gathered in one place before… most of us have never met in person! So we’re going to be holed up in a big conference room at Google this week, planning the future of Subversion. Results of our discussions will probably be posted to some sort of group blog.

Fun times!

What I’ve Really Been Working on at Google

Posted by on Friday, 28 July, 2006

It’s been a long week. After almost a year at Google, our team finally released our new service to the world at OSCON this week in Portland. Of course, I didn’t actually get to attend the conference; I spent four days holed up in a smelly hotel room with three other team-mates, trying to prepare for public launch. This lovely photo shows us like the caged animals we are.

My co-worker Fitz and I did manage to escape the hotel room twice to present two talks. We’ve been working together so long now that we can actually finish each other’s sentences, so we’ve turned this abliity into a presentation gimmick. We stand in front of crowds each holding a microphone, riffing on slide bullets back and forth. I’m not sure if it’s comedic or just novel, but we get really great feedback. One blogger did an amazing writeup of our first talk, and another blogger practically republished the slides of our second talk. A third blogger said that our first talk was the “best session of the day”. Woo!

In any case, the real news is our product announcement.

Long ago I made post describing What I Do at Google. Namely, I work on the Open Source team, whose mission is to promote open source software development however we can: create more of it, and make it better. Working for a large company like Google, we have two main resources: (1) money, and (2) a massive data-serving infrastructure. Given these resources, how can we accomplish our mission? Our team has been using money in a few ways. We make financial donations to important open source projects, and sometimes even pay people to work full-time on them. We also fund the hugely successful Summer of Code program, which pays hundreds students to work on open source software as ‘virtual summer internship’; the result is not only accelerated open source development across the board, but a whole new generation of open source programmers.

But it’s the massive data-serving infrastructure that we’ve not really used much — until now. Our big product announcement was Open Source Project Hosting on our team’s main website, You can read all the gritty details in our FAQ, and there are many blogs and news posts that talk about our new service, as well as folks posting screen shots.

The general jist of the service is: come to our site and create an open source project. There’s no approval process. Within a few seconds, your project is ready to go. You get a super-simple front page which describes your project, an issue tracker, and a Subversion repository to store your source code.

No, this is not a new concept. There are many project-hosting sites out there such as Sourceforge and Tigris. Our intent isn’t to compete directly with these sites, but rather to provide more options to open source developers; we feel that we’ve got a fresh new take on project hosting, and we’re excited to see how developers make use of it. Following the motto on our front page, we’ve “released early” (our service is admittedly quite spartan right now) but also plan to “release often” — there are a whole slew of new features planned over the next several months.

Let me draw your attention to the two main features we’re providing at launch. The issue tracker (written by a team-mate of mine) is unlike any I’ve ever seen. Like many Google products, it’s extremely fast and AJAX-y, has cool customizable views, and has a simple Gmail-like interface. Instead of forcing users to fill out myriads of fields, the issue entry is simple and uncluttered. Developers can invent any sort of arbitrary ‘labels’ to describe an issue, much like Gmail labels. The issue tracker then uses Google search technology to search over all of the data in a free-form fashion. There’s just one search box. I really think it’s a whole new approach to issue tracking applications, and we hope it’s useful to open source developers.

However, the thing which I’ve been working on for the last ten months (with Fitz) is the Subversion hosting feature. A typical Subversion repository has two different back-end options for storing your code: either a BerkeleyDB database or a FSFS (flat filesystem) store. What Fitz and I have done is write a new Google-specific back-end which stores the code in our datacenters, specifically in an internal technology called Bigtable. Jeff Dean (another Googler) has given public presentations about Bigtable, and you can read more about this technology by Googling for it. It’s much like a gigantic spreadsheet for holding data, but it can run over thousands of machines spread over mulitple datacenters. So just like other Google services (picasaweb, Gmail, Calendar, etc.), your data gets put into a massively scalable, redundant, and reliable system. I know that in the past, I’ve been personally frustrated when my own Subversion server goes down; it can be a lot of work to manage your own repository. Instead of being distracted with that, let Google Code be your free host, and get on with coding!

I know that some of my closer friends may wonder if I’ve turned to the Dark Side. Aren’t I the same guy who worked on open-source Subversion for five years? Who wrote a free book about Subversion? Why have I spent time all this time writing a proprietary (!) extension to an open source system? My answer is that it’s all about seeing the forest through the trees. Yes, I wish that our new Subversion back-end were open-sourceable, but it’s not a realistic possibility. Google has amazing hardware and a complex mountain of software to make use of it effectively, but it’s all one proprietary ecosystem. Releasing this new Subversion back-end as open source would be meaningless, since it’s not something that can function outside of Google. That said, the point here is the larger, longer-term benefit: by providing free, highly-available Subversion repositories to the world at large, we open to “embiggen” open source everywhere. (Yes, that’s the word used by my team leader, Chris DiBona). ๐Ÿ™‚

To technical friends: I hope this post has been enlightening. To my nontechnical friends and family: hope that wasn’t too much babble!

Convention talks

Posted by on Wednesday, 17 May, 2006

By the way, my co-worker Fitz and I are going to collaboratively present two talks at the O’Reilly Open Source Convention this coming July. I’m quite excited… I’ve never been to OSCON before, nor have I been to Portland. Click on the logo below for more info about OSCON.

Sketching my living room

Posted by on Saturday, 29 April, 2006

Things have been busy. Lots of travel for Google and family. Six flights in two weeks is too much.

The baby, at six months, has decided to start crawling. This coincides with his first two teeth. So now he crawls around the house, gnawing on chair legs when we’re not looking; I think he may be secretly building a dam. And today he learned to pull himself up onto low surfaces, standing and balancing precariously on coffee tables, couches, and steps. Now we have to catch him every time he falls over, as he tries to furniture-surf. I think this sort of behavior is a bit… early… for only six months old!

The new banjo is great too. After practicing on it for a couple of weeks, it’s hard to go back to the old banjo. The new banjo allows a lot more control, more subtlety of tone and dynamics. I took a one-day master class with Greg Cahill (a well-known bluegrass player) and came away with a whole bunch of tablature-ified licks to practice. And last night, my Friday Night Jam group actually played in public at a coffee house. Lots of people came and went, it was great fun. However, we tend to overplay in public. If I can’t hear my own banjo, then you know everyone is playing way too loud!

The fun project of the weekend is preparing to receive a baby grand piano. Mom is moving into a smaller house, and I’m inheriting the Steinway 1935 baby grand. The question is, how the heck are we gonna fit this thing into our living room?

Luckily, Google just released a new free product called Sketchup. It’s really amazing. It’s sort of like a point-and-click paint program that allows you to create 3D models, and the user interface is really dead simple to use. After a 15 minute tutorial, it took me about an hour and a half to recreate our living room. We could then spin furniture around, orbit the camera around the room, and find a place for the piano:

Really, you gotta try this program. Go download it and play around! Of course, my wife laughed at my insistence on using this program. In about half the time, she took out our actual house floor plans and made little paper cut-outs of our furniture. By the time I finished the 3D model, she had long figured out where to put the piano already, and was off working on other chores. Hmph.

Pillars of code

Posted by on Wednesday, 15 February, 2006

So a lot of people have heard about how Google engineers get a couple of 24″ flatpanels attached to their machines. But a co-worker turned me on to the idea of rotating them vertically. It’s amazing that the server can do that!

(photo by Jon Trowbridge)

I mean, man, look at the length of that Emacs! I can see entire files now without scrolling!

What I do at Google

Posted by on Wednesday, 28 December, 2005

Friends and family often ask me what I do at Google. I can’t give details, but I can explain in general. And by posting this blog entry, I can refer people here!

Most of this information is available at

I work for Google’s open-source team. Our mission is to promote open source software (OSS) in multiple ways:

  • Opening Google code: …we help internally developed software get released as open source. See our projects page for a list.
  • Publishing Google APIs: …so that people can write 3rd-party applications that use our technology, such as search or maps. See our APIS page for a list.
  • Sponsoring OSS organizations: …we participate, both financially and politically, in important OSS organizations such as the FSF, Mozilla, Apache and Python foundations.
  • Participating in OSS communities: …we participate directly in OSS communities where we have expertise: Apache, Subversion, Firefox, Open Office. We attend OSS conferences and speak about open source.
  • Encouraging new generations of OSS coders… by creating programs like the Summer of Code, whereby we pay students to work with mentors on OSS coding projects.

Hopefully this gives you a better idea of what sort of things I do. If you’re interested in Google, send me an email, we’re always looking for new people!

The Risks of Distributed Version Control

Posted by on Thursday, 10 November, 2005

It’s funny how times change. When we started writing Subversion five years ago, CVS was the big evil beast that we were aiming to “subvert”. These days, while Subversion still has a long way to go in performance and features, it has reached critical mass in the open source world. The users@ list has thousands of subscribers and has become self-supporting. Every major free operating system ships with a relatively recent version of subversion. There are several books in the bookstore about Subversion. Major projects like KDE, Apache, and GCC have switched to it, along with dozens of others. When you run across an open source project using Subversion these days, it’s no longer a novelty. It’s become the default safe choice for most new projects.

And now, lo and behold, a whole new generation of version control systems has appeared on the horizon: arch, codeville, monotone, bazaar-ng, svk, git, mercurial. These are the new kids in town — the Distributed Version Control systems — and they aim to unseat the establishment. Yes, you heard right: Subversion is now The Man. I wonder when that happened? ๐Ÿ™‚

What makes this new generation of systems fundamentally different is that they take the idea of “disconnected operations” to the extreme. Every user has an entire copy of the repository — 100% of a project’s history — stored on the local computer. Each person is effectively an island onto themselves. Users connect their private repostories together in any way they wish and trade changes like baseball cards; the system automatically tracks which changes you have and which ones you don’t.

There’s something fresh and self-empowering about this model, because it’s a superset of CVS and Subversion’s traditional single-repository model. An open source project can decide that exactly one repository is the Master, and expect all participants to push and pull changes from that master repository as needed. Of course, a project can also organize itself into more interesting shapes: a tree-like hierarchy of repositories, a ring of repositories, or even just a randomly connected graph. It’s tremendously flexible.

Proponents of these systems tend to be a bit fanatical about their “superiority” over today’s centralized systems. Over and over, I hear testimonials like this:

“It’s great! If I want to implement a new feature, I don’t need to have commit access at all. I have my own private copy of the repository, so I can write the whole thing by myself. I commit changes to my private repository as often as I want until it’s all finished. Then I can present the whole thing to everyone else.”

This user is describing a great convenience, but I view it in a slightly darker light. Notice what this user is now able to do: he wants to to crawl off into a cave, work for weeks on a complex feature by himself, then present it as a polished result to the main codebase. And this is exactly the sort of behavior that I think is bad for open source communities. Open source communities need to work together. They need to agree on common goals, discuss designs, and constantly review each other’s work.

In the subversion community, we call the behavior above “dropping a bomb”. It’s considered anti-social and anti-cooperative. Usually the new feature is so big and complex, it’s nearly impossible to review. If it’s hard to review, then it’s hard to accept into the main codebase, hard to maintain code quality, and hard for anyone but the original author to maintain the feature. When this happens, we typically scold the person(s) for not working out in the open.

Good Behavior, on the other hand, involves coming to the community with a design proposal. After some discussion, we ask the developer(s) to either (1) submit a series of patches as work progresses, or (2) give him (or them) a private branch to work on. They needn’t have commit-access to the core code — a branch is all that’s needed. That way the larger community can review the smaller commits as they come in, discuss, give feedback, and keep the developers in the loop. The main goal here is never to be surprised by some huge code change. It keeps the community focused on common goals and aware of each other’s progress.

So while most people say: “isn’t it great that I can fork the whole project without anyone knowing! ” My reaction is, “yikes, why aren’t you working with everyone else? why aren’t you asking for commit access?” This is a problem that is solved socially: projects should actively encourage side-work of small teams and grant access to private branches early and often.

I probably sound like Mr. Anti-Distributed-Version-Control, but I’m really not. It’s definitely cool, and definitely convenient. I just think it’s something that needs to be used very carefully, because the very conveniences it provides also promote fragmentary social behaviors that aren’t healthy for open source communities.

For more on this subject, see this essay by Greg Hudson — it was the writing which originally had my head nodding on this topic. Also relevant is Karl Fogel’s excellent new book, Producing Open Source Software. It’s all about managing and promoting healthy open source developer communities.

Moving to Google

Posted by on Friday, 16 September, 2005

(Here’s the text of an email I just sent to the Subversion developer and user community mailing lists:)

I’ve been part of this community for a very long time, and I want to let folks know that I’ve decided to change jobs. It means I won’t be working on Subversion full-time for Collabnet anymore.

Before any weird rumors start, allow me to elaborate.

I have no grievances with Collabnet — it’s a wonderful place to work. The company deserves huge kudos for taking the time (and risk) to pay people to work on open-source software for all these years.

What’s really going on is more personal; I’m ready to move on. It’s tough to work on the same product for 50 hours a week for five years, and I’m close to burning out. I need a change. I need to work on something new for awhile. Opportunity recently presented itself (at Google, in case you’re wondering), and the job offer felt like the the next thing (and Right Thing) for both me and my career.

Ironically, this shift is happening right at the same time that Collabnet is ramping up its investment in Subversion — more people working on it, more support, more marketing. So please don’t interpret my departure as “Collabnet losing interest in Subversion”, the situation is actually quite the opposite.

In truth, I’m not particularly worried about either Collabnet or Subversion. I consider this project to be a huge success. What started out as just me, Karl, and Jim at a whiteboard (back in April 2000) has blossomed into a huge community of developers and users. Development keeps happening, and the lists are full of users supporting each other. It makes me proud!

I’m not going to disappear completely, mind you. I’m simply stepping my involvement down a notch. Instead of “obsessed guy constantly mailing the lists and driving features”, I’ll become a typical svn developer who participates in my free time. I won’t have time to read the users@ list anymore, but I’ll still be chatting on the dev@ list and in #svn-dev on

Thanks, everyone! Witnessing the birth of a completely self-sustaining open-source project has been rather miraculous to watch. (Lucky me, I have another miraculous birth to witness in the very near future… ๐Ÿ™‚ )