I released reposurgeon 3.30 today. It has been five years and a month since the first public release.
In those five years, the design concept seems to have proved out very well, finding use in many repository conversions. But the project exhibits an unusual sociology; I don’t get lots of casual contributors, only a few exceptional ones.
Your typical open-source project sees a sort of exponential distribution in which small fix patches from people you see stop by only once are common, single feature-sized patches less so, and complex sustained work that reimagines entire subsystems is rare. There’s an obvious inverse relation between frequency and complexity scale. At intermediate and higher complexity scales you often get regular contributors who do extended work on different things over time. GPSD is like this.
On reposurgeon I see an entirely different pattern. Casual patches are rare to nonexistent. For long stretches of time I have no active collaborators at all. Then a hacker will appear out of the void and begin contributing very clever patches. He (no shes yet) will draw closer to the project, and for a few days or weeks we’ll be in an intense collaborative mode tossing ideas and patches back and forth. Some complex series of features will be implemented.
Then, his particular feature-lust fulfilled, said hacker will quietly vanish into the interstellar darkness never to be seen again, like some comet on a hyperbolic trajectory after a pass near the Sun. Never yet has there been more than one cometary hacker at a time.
OK, I exaggerate slightly. The project has some semi-regular hangers-on in the #reposurgeon channel (one of them is A&D commenter Mike Swanson). But those people tend to be power users rather than major code contributors; the pattern of large code drops by people who appear, do work that impresses the hell out of me, and then vanish, still dominates code contributions.
My wife Cathy called this one right when I remarked on it. Most people never use reposurgeon more than once, but the hands that find it are disproportionately likely to be very skilled ones. All of my half-dozen or so cometary contributors have been damn good hackers even by my elevated standards, careful and imaginative and tasteful. When people like this detect a deficiency in a tool, they fix it – and their idea of “easy” fixes would daunt lesser mortals.
It’d be nice if some of these hackers would stick around, because I love collaborating with people that bright, but oh well. They’re as in demand as only the capable can be. And at the end of the day, there are much worse things you can say of a software project than “it attracts high-quality work from high-quality people, er, even if they don’t tend to stick around”.