3 ms·
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
by aaronblohowiak 18y ago
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.
- jamis 18y agoThere 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.
- aaronblohowiak 18y agoThanks 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.