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.
Take ViewVC 1.1.0 for a spin. Kick the tires. Send feedback — positive and negative — to the mailing lists. I might be slow to respond, but "I'm not dead!", and neither is ViewVC.
.o O ( "I think I'll go for a walk … I feel happy." )
Hey there, know the feeling myself (the "loneliness" when developing on a project). Users still demand stuff, though *g* ... some even offer donations, but money isn't what I'm after. Help would be much better in most cases.
ReplyDeleteIntegration of Mercurial shouldn't be all too difficult, given that both tools are written in Python. Any clues about the mode of patching would be appreciated. How do I get my patches approved, how do I contribute at all?
Oliver, I connected with you in #viewvc on irc.freednode.net, but for the sake of others who might be wondering the same thing, I offer the following:
ReplyDeleteSubscribing to the dev@viewvc.tigris.org list and discussing changes there is the single most important starting point. Patches should be made against the trunk codebase, and be as small as possible, each conveying a single logical change. Some more info can be found at http://www.viewvc.org/contributing.html.
(And yes, I agree -- I'd much rather have the extra eyes and hands than any payment for work!)