It’s done. I’ve finally submitted the Subversion vision and roadmap proposal resulting from the Subversion Vision Conference last week to the Subversion developer community for digestion and debate. The proposal is the result of many hours spent crawling through my notes from the conference, browsing photos I snapped of our whiteboard scribblings there, distilling all that information into organized thoughts, composing drafts of the proposal, and then editing it to death. (Many thanks to Hyrum Wright, who collaborated with me on the manifesto proposal and provided invaluable editorial review.)
You can read the full text of the proposal (and follow any subsequent discussion which may occur) in the development list archives at http://svn.haxx.se/dev/archive-2010-04/0047.shtml. I’ll highlight some of the key suggestions here, though.
The first order of business was to define Subversion’s target market, and some of the key benefits that Subversion can offer to that market. My proposed project/product vision sums it up quite nicely (if I do say so myself):
Subversion exists to be universally recognized and adopted as an open-source, centralized version control system characterized by its reliability as a safe haven for valuable data; the simplicity of its model and usage; and its ability to support the needs of a wide variety of users and projects, from individuals to large-scale enterprise operations.
With that vision in mind, we are empowered to start talking in generalities about feature roadmaps and trends. Here’s what is proposed:
- 1.7: WC-NG; HTTPv2; ‘svn patch’; typical slew of various bug fixes
- 1.8: repository-dictated configuration; tree conflicts improvements; WC-NG-enabled stuff (rename tracking, compressed pristines, shelving/checkpointing, …)
- 1.9: Editor v2 (for server->client rename handling improvements)
- 2.0: FS-NG (ideally a parallelized task), with some (to-be-identified) FS-NG enabled features.
An admitted shortcoming of this roadmap is its lack of associated release dates. Realistically speaking, I think the myth of returning to six-month release cycles in Subversion has been dispelled by experience. The relatively easy work we were doing years ago is all done, leaving only the challenging stuff. I suspect this means we’ll have roughly 9-15 month release cycles, at least until more of the larger plumbing-type tasks are completed. That said, we’ll be trying to identify in our public roadmap not just what we’re doing, but what we wish we could do if we had more manpower.
That brings me to the topic of communication. The proposal speaks about our community’s need to do a better job of communicating with our target audience. Many of you already benefit — and have been benefitting for nearly a decade — from “getting the inside scoop” on Subversion via your relationship with CollabNet. That channel is certainly not going away (and if anything, I suspect you’ll find it being enhanced). But this doesn’t excuse the developer community from being a bit more transparent about its efforts via our recently redesigned project website. Overall, my hope is that enhanced lines and media of communication between Subversion’s developers and its vast user base will be mutually beneficial, and that Subversion consumers with money and developer hours to spend will be encouraged, enlightened, and empowered enough to apply those resources towards the acceleration of Subversion’s roadmap.