From an engineering point of view it should be a separate gem, requiring capistrano: if you don't use Harrow or never heard about it (me) you keep using capistrano. If you use Harrow you use capistrano-harrow. Same thing with rspec and rspec-rails.<p>From a marketing point of view I understand the move, but I don't like it much. Anyway, I'm using mina (less feature complete but much faster) so I don't get into this any further. <a href="https://github.com/mina-deploy/mina" rel="nofollow">https://github.com/mina-deploy/mina</a>
I still don't get why it is shipped by default with Capistrano. It simply has nothing to do with the tool for the vast majority of users, and the remaining users can install it themselves. Disappointing.
Long answer short: the maintainer has a vested interest in promoting harrow (his company).<p>I am sure there are many technical solutions to avoid the dependency.<p>I, for one, see no issue with this whatsoever. This is just a minor self-promotion in return for a great piece of software that I get for free. I wouldn't have known harrow before this otherwise. How is this any different from gmail or youtube or whatever which bombards us with bazillion ads using our data? Want to use the free software, put up with the ads.<p>Maybe the maintainer should make a paid version that removes this dep and see how many people are willing to fork up the money (my guess: very few).
I guess the question needs to be -- will this inclusion actually drive more users to Harrow than the damage to goodwill/annoyance of including it. Personally, I'm less inclined to try Harrow now, but I admit that's just personal bias. I don't think there's anything wrong with trying to build platforms to sustain work on great FOSS products - of which cap is definitely one (that I use every day! thanks!) -- in an ideal world this dependency doesn't exist AND harrow gets enough users to support further work on capistrano. But since this isn't an ideal world, I'm not going to second guess the choice too much, other than to say, I don't think it will make people choose to use Harrow that wouldn't otherwise, and maybe it is better to find other ways of reaching potential users than with a message during cap install.
I don't have any problem with the Capistrano team promoting Harrow, but I'm really not pleased with unnecessary dependencies. The Ruby world already has a massive problem with transitive dependency bloat. Every additional dependency causes linear load time increases (even if it's not loaded) for every file required. Bundle directories become massive over time. Adding unnecessary hard dependencies only exacerbates that issue.<p>Optional dependencies are a well-solved problem in Ruby land. The careless use of dependency declarations causes enough pain already - please, no more.
They also started advertising in the docs of Capistrano, and when it launched it had a bug that made the ad appear on every pageview: <a href="https://twitter.com/kaspergrubbe/status/704355597429436416" rel="nofollow">https://twitter.com/kaspergrubbe/status/704355597429436416</a> :)
Maybe this is because I'm not deep into the Ruby world, but I'm not sure I'm understanding the issue with adding/changing dependencies as a project is updated.<p>(I guess just my opinion? Except semver): Features aren't necessary worthy of a major version bump (backwards compatibility generally is).
in short, I am against this, and will fork and remove it before allowing it into my project.<p>If this is a marketing attempt, and if it's getting a significant amount of pushback, it's a bad marketing attempt and should be yanked.<p>I wish the folks behind Capistrano the best of success, but disagree with this marketing approach and hope they explore other approaches that are more palatable.
The best approach would be to put the harrow advertisement when installing the capistrano gem. Something in the lines of: "hey, if you want to support our work check out Harrow, we think you'll like it. `gem install capistrano-harrow`".