A few quick thoughts about the Google Summer of Code Mentor Summit, which I attended last weekend.
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!
I believe we got the chance to chat for a bit about WordPress Saturday night at the hotel, you might remember that I had some (hopefully constructive) criticism about WordPress.
You’re not alone on the Subversion front. I do believe that most people there, even if they aren’t on git, understand at this point that it’s the emerging victor of the DVCS wars, so there’s not really much to complain about it other than a steep learning curve for those coming from non-distributed systems.
You may remember that I’m from the wxWidgets project. We just switched to Subversion a little over 3 years ago from CVS. For having used CVS for 15 years before that, it was a big deal. git was around when the switch was made to Subversion, but it wasn’t solid, and definitely had some issues on Windows, which is our biggest, most important platform. Additionally, it really still wasn’t clear at that point where the world of version control systems was going. We were getting plenty sick of CVS, and Subversion was a proven rock solid solution at this point with great Windows support through TortoiseSVN and other great tools on the other platforms.
git has certainly proven itself, and it does work great on Windows now, but I still don’t actually see our project moving over to it for at least another couple years, probably more. There’s no rush. We feel a little bit of lag in certain operations, that’s for sure, but it’s nothing to be very concerned about. Right now, the developers that do see a huge advantage to using git (and there are a few, including one of our core developers) are finding git-svn plenty adequate, and at the same time, we haven’t alienated any smaller, less experienced, occasional contributors with a new, complicated versioning system.
Version control systems have been some trolls’ favorite target subjects due to how incredibly easy it is to get people incredibly heated up over something that they really should hardly care about. It’s one of many tools in developers boxes, for most projects, there’s really very few version control systems that wouldn’t work perfectly fine. You really don’t need to feel pressured to prematurely move over. All of your current WordPress developers are obviously plently familiar with Subversion. How many actually have a decent amount of experience with git enough to work just as fast and efficiently on WordPress if it’s setup in git as they do in Subversion? How many of your developers will you need to train on git if you moved over today? Just keep an eye on those numbers every 6 months to a year or so, and make the move when the answers to those questions make it sound feasible.
Hi Bryan,
Thanks for stopping by and for the very thoughtful comment.
Broadly speaking, I agree with your statement that version control is not something that we should really have to think or argue about. It’s just a tool. However, I do think that the differences between centralized and decentralized systems is significant enough that a community’s choice of one or the other as the official tool for the project tends to suggest (and in some cases preclude) certain kinds of workflows. The structure of DCVS like Git encourages things like frequent branching and module ownership; in turn, those sorts of development techniques encourage certain kinds of collaboration that otherwise might not emerge.
Of course, none of this is absolute. As you suggest, the propspect of retraining developers is awfully daunting, in many cases probably outweighing the immediate benefits of a switch. And tools like git-svn have the potential to mitigate the differences between systems.
Thanks again for the food for thought. To me, the best part about the Mentor Summit experience was getting to share this kind of experience.
Insightful…