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.
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.