Today, I finally got around to releasing ViewVC 1.1.0.
I know. And you're right — that's not the most uplifting lead-off line ever written for a technical blog. Sounds mostly positive (new release?!), with a hint of exasperation, and all shrouded in a mysterious cloud of why-should-i-care. Sorry about that. But allow me to explain.
ViewVC 1.1.0 represents — maybe misrepresents — three years of development on features introduced since 1.0.0 came out. I'm pretty pleased with the features, many of which were contributed by and/or willingly tested by volunteers. Here's an overview, taken from the official release announcement:
- Extensible path-based authorization w/ Subversion authz support
- Subversion versioned properties display
- Unified markup and annotation views
- Unified, hassle-free Pygments-based syntax highlighting
- Subversion svn:mime-type property value honoring
- Support for full content diffs
- Standalone server improvements
- Commits database management and query enhancements
- Support for per-root configuration overrides
- Optional email address obfuscation/mangling
- Pagination improvements
- ... plus many bug fixes and additional enhancements!
"That's it? After three years' time, that's all we get?!"
It's okay. I've asked myself that a hundred times, too. It's a bummer, but I think I'm learning another hard lesson about open source projects: when a piece of software reaches a certain level of maturity, the developers-to-users ratio tends toward nil.
Before I ever started working on ViewCVS (which was what ViewVC was called at the time), it was already a well-established, widely used piece of software. CollabNet used it to display version control repositories in its CollabNet Enterprise Edition software suite. SourceForge.net was doing the same. It seemed that everybody had a copy of ViewCVS. The software was ubiquitous, worked well, and CVS wasn't changing significantly. And ViewCVS's developer participation reflected this plateau of innovation, too — I think there might have been two or three folks active at the time, mostly just fixing the occasional bug.
Seven years ago, I was tasked by CollabNet to add support for Subversion to ViewCVS. Subversion hadn't even released its 1.0 version at the time. Subversion was still this young, exciting, rapidly developing new entry into the version control world. I (with the help of others) did get Subversion support added to ViewCVS, and along the way I inherited primary maintainer-ship of the project. The project was renamed to ViewVC later to reflect the fact that it was no longer CVS-only, and I began focusing on fixing outstanding bugs and tracking changes in Subversion's new releases.
Fast-forward a few years. Now Subversion's rate of change — at least, in terms of what's of interest to a repository browser tool — is starting to plateau, too. And ViewVC's contribution rate is again reflecting that. Fewer active committers (< 2), investing less time (< 1 day/month), and with fewer volunteer contributions.
It's lonely here.
But it doesn't have to be. There still remain opportunities for improvement in ViewVC. Off the top of my head, I'd say adding support for other version control systems — Mercurial, Git, etc. — is a place where your expertise and effort would be not only appreciated, but required, if only because I don't use those systems myself. Scalability and performance improvements are always welcome. And I'd love to see ViewVC's MySQL integration expanded — why not use the database as a glorious cache of information that takes too long to harvest at runtime from the VC system?
So, while I might casually kick myself in the backside for finally and barely eeking out a new release of ViewVC, I do so understanding now that this may just be the way things go for mature software, thankful for ViewVC's many users, and happy to be working on free code.