Today marks the ninth anniversary of my first commit to Subversion. Back then, the project was less than a year old, with folks actively coding on it for only six months so far. There was a command-line client. It could do commits and updates, but only to an XML storage format. There was no repository concept. No server to speak of. Pretty bare-bones. My first commit was a fix for some path handling issues – using the correct directory separator character on Windows platforms. Simple stuff. In retrospect, everything seemed relatively simple then. The goals were clear – to create a compelling replacement for CVS, where “compelling” meant “better, but similar enough to be easily embraced”.
That was a long time ago. I’ve had two children since then, and one of them is already in school. “Time flies,” and all that. But in software years, that was eons ago. Subversion has long since surpassed being a compelling replacement for CVS. Today, it’s a compelling replacement for most things and a decent replacement for still more. Even statements like that are misleading – Subversion doesn’t have to fuss as much with unseating other version control systems these days because it’s become the default choice of version control for many segments of the software development market.
Unfortunately, time doesn’t stop flying simply because you taste a little success. And looking backward while the world moves forward is only fun until you slam your skull into some of those harsh realities that inevitably lie in the path ahead of you. So I have a confession to make on behalf of the Subversion development community. We’ve been moving forward with no clear vision for some time now. This shouldn’t come as any amount of surprise to my fellow developers. I’ll fancy a guess that it’s no surprise to many of our loyal users, either. That’s not to say that we’ve been inactive – far from it. Our recent releases have simply been primarily focused around time-consuming features and tasks (merge tracking? a working copy library rewrite?) that are, for the most part, things we’d been hoping to get around to since our 1.0 release and just couldn’t delay any further. The release process hasn’t stalled. It’s just been a while since we (the developers) were able to look any meaningful distance into the future, stake a claim to some set of features and enhancements that we were united in achieving, and confidently assert to our waiting consumers that, “Yes, that Thing You Wanted? You’ll have it in 10 weeks’ time.”
There are many possible reasons for this: the easy stuff is finished, leaving only hard stuff to do; software maturity yields developer attrition; our millions of users keep us busy servicing the existing features; and so on. You might call them “excuses” if you have a particularly negative bent about you. You could call them “par for the course” if you’ve ever worked on the same software for a long period of time. I’m choosing to call them “motivation”.
This year I and my CollabNet peers will be trying to address Subversion’s lack of vision. Now obviously, we can’t do this ourselves – even in its CollabNet-bolstered infancy, Subversion was a true open source project, governed internally and driven only as far and as fast as its individual human contributors afforded. But we can certainly strive to encourage a common interest in roadmap development amongst our peers. To that end, I’ve already begun working with some of my fellow developers (including our friends at WANdisco and Elego) to develop a realistic, achievable, living project roadmap for Subversion; I hope more of the Subversion workforce will be of like mind. With the project’s recent move to the Apache Software Foundation, I’m optimistic – the ASF is a high-profile open source organization overflowing with talented developers who themselves are Subversion users.
Where do you fit in? Well, certainly the Subversion community wants to know what you need from Subversion. (If you’ve seen our issue tracker lately, you know that our users have never been shy about filing bug reports and feature requests.) But more than that, we need able programmers willing to help us chart and navigate this course. You don’t have to be a stellar software developer – many of us wouldn’t regard ourselves that highly, and anyway I’ve always found that interaction with an open-source community like this is highly conducive to improving your skill set while still serving the public need. You don’t have to have oodles of free time on your hands, either – we’ll take what you can give, and every little bit helps. What do you say? Visit our new “Getting Involved” web page, and learn how you can contribute to Subversion’s success. Help us restore momentum and energy to Subversion.