Maybe the scope was too vague or the goal was too monolithic if he was implementing patches he didn't need. It is easier to declare tight little tools as "done." Plugability/modularity helps this as well, because it lets those things that need to vary and evolve over time do so without threatening the health of the core.
There was definitely an element of that, too. Most of the patches were reasonable changes: bug fixes, or minor feature additions that improved the usability for some large segment of the user base. There were a few that snuck in that I later regretted, but I got better at saying "no" as time went on.
However, ultimately, if every project said "no" to every feature the developer did not personally need, there really wouldn't be very many widely-adopted projects. They key is balancing patches that you don't personally need against your vision for the product: and I did have a vision for Capistrano. It just wasn't really clearly defined, especially early on, which is why I regret some of those patches.
It was definitely a learning experience all around.
Thanks for the reply. I can see how the definition would increase in clarity it grows and you eat the dog-food. I'd also like to thank you for being frank with your decision to step aside as the maintainer -- far too many projects languish as the developer doesn't make a public declaration like you did.
I'm surprised Buck held out so long. I don't know if many people looked at the Capistrano ML, but it was just this giant hellish suckhole of entitled Windows users angrily demanding someone help them with their homework. Buck doesn't spell it out, and probably wouldn't even admit it, but I got the pretty strong idea having to support windows was the main cause of misery.
However, I have some criticism over the way it's been handled, and I'd like to point out before saying it that it's not a personal attack, just some observations. I don't use Cap but I do use net/ssh and I'm very grateful for Buck's contributions. However ...
It's his right to walk away, and as he points out, he owes the community nothing. But it's still a bit weird and passive-aggresive, the way he's done it. Healthy human interaction in a situation like this would be polite but insistent assertiveness; defining your limits and consistently sticking to them, not holding it in, getting silently angrier and more pissed off, then quitting in a blaze of defensiveness.
There are techniques for dealing with users/contributors, distributing the load so no one person is overwhelmed. Capistrano's documentation, for example, was/is awful. The website has almost nothing useful. The way to learn how to use it is to perform any number of searches for people talking about how they did it on their blogs, and then doing it yourself by trial and error. Or the entitled newbie way, which is to pile on the mailing list, where their questions were foolishly answered, attracting ever more entitled newbies looking to have their problems solved for them, causing stress. Decent documentation would have solved a lot of that.
And overloaded with feature requests/patches? There are websites for handling feature requests, and the developer should have insisted on nothing but properly tested patches fixing a known bug. Wouldn't that have gotten the situation more under control? Or hell, why not roll cap into Rails proper and spread the load that way?
It's all just a bit suboptimal, is all. Oh well. Good luck to the dev. Hopefully other projects can also learn from the experience.
You're right, of course, about the documentation being awful. I was actually working on fixing that at the end, but every time I'd spend a few evenings writing docs (which was a few more evenings where I didn't get to do what I wanted to do), people would ask questions on the list not covered by what I'd just documented...and I'd get discouraged all over again. Docs help, for sure, and I painted myself into a corner where there was too much to document in the amount of time I could afford to spend on it. My fault.
I actually used a website for handling feature requests and patches (lighthouseapp.com), and it worked great. But even the best tested patch for a known bug still needs review. It needs to be applied and tested locally. It needs an update to the ChangeLog. And eventually it needs to be bundled and released, each new release requiring (at minimum) some release notes and a blog post announcing it.
It was a bunch of little things that got more and more annoying. I would have loved to distribute the load across more devs, but aside from a few who would review patches on specific topics (Scott Chacon, for instance, helped with git issues), it was all me, all the time.
"It was a bunch of little things that got more and more annoying."
What you need to do is write a script to automate those small but repetitive tasks! I heard about this great bit of software to do that for you called Capi.. oh.
I was going to add, I think a factor contributing to the lack of ongoing support you received is simply capistrano's place in the stack. Unlike Rails or other libraries, it very much has a "deal with it once then forget about it" usage pattern, which would seem to discourage ongoing participation. Or if there was some kind of missing feature "blocking" the envisaged deploy scenario, that would create a pressing need to "get this in NOW!" - and then forget about it.
The simple position of Capistrano as the deploy mechanism - a critical "bottleneck" through which one must pass but then safely forgotten - could be the reason for the "all me, all the time" dynamic.
Anyway, glad to see you don't seem bitter. Good luck and looking forward to future projects.
I think this is because he became emotional due to the attachment of Capistrano to his personal identity. It was his "baby", after all. So it wasn't just a professional moving on but a personal "good bye".
