C4 is over and I'm back in Seattle, which means these last two posts will be Almost Live-blogging C4.

I get about 60 emails every day from a robot. Well, not a robot that moves around, but our version control system -- the server that manages our project's source code.  Every time someone checks in a change to the source code, the system sends out email to everyone that includes information about what got changed, who changed it, and their comments about that change.

MacBU is somewhat schitzophrenic in that roughly half of our development team is in Redmond, and half in Silicon Valley.  I'm in Redmond, so when I started at MacBU, I got to know the SIlicon Valley part of the team primarily via email, a good deal of which was from the source control system.  And there are also smaller parts of our team in Ireland and Japan and China where the email communication is even more important.

Our system is set up this way so as to encourage good collaboration.  For example, knowing that everyone will get email that contains the checkin comments, most people try to write decent checkin comments.  This good for team communication in the present, but it is also crucial for helping our future selves, when we'll look back on our checkin comments from today and try to answer the crucial question "What were we thinking?". 

But 60 emails a day is overload.  I usually scan them but often don't have the time to follow closely what people have been working on.  They are still helpful, of course, but the lessons are clear -- our software systems help us communicate within the team, and thereby build team cohesiveness and awareness, but there are obvious limitations. 

So what got me thinking about this?  Brian Fitzpatrick, one of the people behind Subversion, the latest and greatest open-source source control project, spoke at C4 on Saturday.  Brian had a number of examples of how the features available in a version control system affect the community that uses it, and he talked about trying to make decisions about the design of Subversion with the community dynamics in mind.

Interestingly, its not always obvious what the 'right' choice is, and indeed, there are cases where one project might want a certain feature done one way, and another community might want a completely different implementation.  For example, the very meaning of 'checking in' might be very different.  At MacBU, checking in means taking responsibility that the code works and doesn't break the existing build.  But in another setting (think Wikipedia), checking in could mean "here's my ideas for what this file should be -- what do the rest of you think?". 

The trend of thinking about software not just as a set of features, but instead as a foundation for community building isn't a new one, but it still surprising how far reaching and subtle the influences can be.  Working on the Mac Office products, we use the phrase 'personal productivity' quite a bit, and most people know really well what makes themselves productive. 

We also care about 'team productivity' and 'collaboration', but those things can mean different things to different people, and they are much harder features to deliver, especially when 'personal productivity' can be at odds with 'team productivity'. It's more evidence that there's plenty of innovation still needed in our market segment, and why there's a future for Mac Office well beyond the horizon we can see today.