Google Summer of Code is a program, run by Google, which encourages open source development by paying college students to undertake summer coding projects with various open source projects. I co-mentored two projects for WordPress, and was one of the lucky few from among WP’s fifteenish mentors to get a trip to the Googleplex in Mountain View.

The Summit was organized as an unconference. On Saturday, attendees proposed session topics on a big scheduling board, and indicated their interest in other suggested sessions with stickers. This being a supremely geeky conference, I didn’t understand about half of the session titles.

A few takeaways, in no particular order:

• Process matters. A lot. Probably 2/3 of the sessions I attended were devoted to project workflow: version control, code review, various kinds of testing. Probably some of the focus on process is due to the fact that it constitutes common ground between even those individuals whose software projects are quite different from each other. But I think it also speaks to the importance of workflow that really works, especially in the decidedly non-top-down world of open-source development communities.
• WordPress seems pretty far behind the curve in terms of development infrastructure. Take version control: WordPress is the only project I heard about all weekend that still uses (or is not in the process of moving away from) centralized version control like Subversion. Git seemed like the most popular platform (there was a whole session on migrating massive project repos from SVN to Git, which was probably my favorite session of the weekend). I came away with lots of ideas for how the WP and BuddyPress development processes might be improved (and, more importantly, why it might be worthwhile to pursue these ideas), which I’ll be working on in the upcoming weeks and months.
• More generally, I came away realizing that WordPress devs (and probably other kinds of devs, but this is what I know!) have a lot to learn from the way that similar software development projects are run. I was part of some extremely interesting conversations with core developers from Drupal and TYPO3 and was really, really impressed with the way the way that their development workflow informs and enables better software. Some WordPress fans have a tendency (sometimes joking, sometimes not) to disparage other projects like this, an attitude that can prevent us from learning a lot from each other. That’s a real shame, and it’s something I’d like to rail against.

I met some great people and learned a lot at the Summit. Many thanks to Google for footing the bill, to WordPress for selecting me to go, and to Stas and Francesco for their cool GSoC projects!

Related posts:

1. Google Summer of Code, WordPress, and BuddyPress
2. Revisiting Git, Github, and the wordpress.org plugin repository
3. Lessons learned on HDD replacement

via Reza Vaziri

These Google fears came just a week after I read Jason Scott‘s delightfully titled “Fuck the Cloud”. I don’t really buy into all the too-simple “you’re a sucker if you use cloud services” rhetoric, and I think (as urged in a Twitter conversation I had with @GeorgeReese) that a lot of what Scott is complaining about is more about backups than it is the cloud. Still, this piece, along with my Google woes, was enough to get me thinking about how wise it is to depend on web services like I do.

My first reaction on Saturday morning, when Google was acting up, was to back my stuff up. I saved all of my Reader subscriptions in a local OPML file, updated my POP3 backups of my Gmail messages in Thunderbird, and saved local copies of my important GDocs. I was able to make these backups because Google has allowed it by embracing the right kinds of standards. And this fact – that backups can be made and exports done – is one of the things that makes me relatively comfortable using Google’s services so extensively.

This relatively straightforward exportability stands in contrast to the situation at some of the other sites where I create and store content. I’ve used Tweetake to export my Twitter activity to a CSV file, but the solution is far from elegant. For one, I don’t really like giving my Twitter password out to a bunch of sites. Also, I’m not crazy about the fact that I can’t really do incremental backups. Ideally Twitter itself would offer some streamlined way to export one’s tweets. Facebook is even worse. I feel uncomfortable using Facebook’s message/email system because I know that there will probably come a day when I want access to those messages but cannot get them.

I don’t necessarily blame Twitter or Facebook for their total failure to provide content exporting. There is a sense in which the kind of content being created in these spaces – or, rather, the meaningful units of content to which we attach value and thus would want to save – is quite different from the most discrete units provided by email. What’s really valuable in Facebook is not just what I write, but what others write to and about me and my friends. Only a total snapshot of my entire immediate network would provide the kind of value for posterity that I want. With Twitter the situation is perhaps even more extreme: like in Facebook, the content I value is closely related to the content created by others, but in Twitter these people are not necessarily part of my immediate network at all (like when you @reply to someone you don’t follow because of some term you’re tracking). Pushed to the limit, you might even say that only a snapshot of all Twitter activity would really capture its value at any given time, since part of the value of Twitter lies in the potential you have to mine the collective consciousness, to get a sense of the zeitgeist. When the content that you value is so holistic, the details of backing it up become dicey.

On a more local scale, it’s probable that standard export formats will emerge as services like Twitter become more popular, in the way that something like Atom or RSS can be used to backup or restore a blog. In this sense, maybe my worries about certain kinds of cloud data storage are the kinds that will go away with time. Or at least until the next new kind of content is invented.

There are some other aspects of the cloud question that I find interesting, such as whether one should really feel more comfortable with local backups than with remote ones, and whether paying for a service really makes it more reasonable to feel comfortable keeping your stuff there, but I’ll save that for another day.

Related posts:

1. Saving tweeted items for later