6 ms·

Capistrano maintainers add new dependency to promote paid service

60 points by yeasayer 10y ago

chris_wot 10y ago
I don't understand the response. Why would they need to bump capistrano's version every time they update capistrano-harrow?
- codebeaker 10y ago
  Seven year Capistrano maintainer here. I'm the person who is responsible for Harrow, the gem plugin and the response to the issue linked at GitHub. The point of separating the gem is so that we don't have to bump Capistrano's version, every time there's a change to what is effectively a first-party plugin. Sorry if the way I responded at GitHub was unclear. It's a common theme of my maintainership of Capistrano that people have always asked for a web-based version, in the mailing lists, at user groups and meet-ups, more so since Capistrano 3 as we grow in popularity amongst teams who wouldn't normally have a Ruby toolchain installed on their machine. That said, we have to strike a balance, Harrow was bootstrapped predominantly with money from my software development agency with some seed funding to see us through a smooth launch and get us the UX help we desperately needed to make a product we could be proud of (pro tip: don't let a bunch of ops guys write a Javascript app.), so we have to figure out if this is commercially viable, or whether it was a wasted endeavour, that puts me in the slightly uncomfortable position of what amounts to advertising baked in to open source tools. As I wrote on my blog [1], it's a fine line to tread, but so far the response has been overwhelmingly positive. [1]: lee.hambley.name/2016/04/24/seven-years-under-a-palm-tree.html
  - chris_wot 10y ago
    I thought your response was fine :-) I see what you are saying now - basically that was part of Capistrano already, so moving it to its own gem is a very good idea. I guess I'm wondering why it needs to be a dependency in Capistrano - is there something in it that Capistrano needs? Wouldn't the new gem rely on Capistrano and not the other way around? Regardless, the one lodging the issue probably should have stepped away from the keyboard before lodging the issue. Good on you for maintaining Capistrano, it's never an easy job so I hope you get lots of clients who pay you on time and make reasonable requests!
    - codebeaker 10y ago
      > I thought your response was fine :-) I see what you are saying now - basically that was part of Capistrano already, so moving it to its own gem is a very good idea. Thanks for the vindication, if it wasn't an external gem, I'd probably have to re-release Capistrano, exactly. This is less invasive. > Wouldn't the new gem rely on Capistrano and not the other way around? Typically yes, but I have a vested interest in promoting Harrow so that I can afford to keep working on open source, it's slightly cheeky but apparently I earned some good will in all the time I've worked on Capistrano as we've had genuinely net-positive responses to the suggestion. > Regardless, the one lodging the issue probably should have stepped away from the keyboard before lodging the issue. I'm guilty of writing much worse, a little empathy goes a long way on the internet. I just apply Hanlon's razor anytime I see something that makes my blood boil, apart from making me feel a little bit less bad about myself, it's a quality of life improvement. Thanks for the constructive discourse.
duaneb 10y ago
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.
- codebeaker 10y ago
  Capistrano maintainer here, I gave a more comprehensive answer in this thread [1], I hope that answers some of your questions. Specifically to address your point about having "nothing to do with the tool for the vast majority" there may be some sense to that. We first built a pure, pure literal web front end for Capistrano, it turns out something that limited is not that useful, however when you boil the problem down in to: - Management of secrets, variables, keys, etc - Tasks that can be combined with sets environment specific config and re-used It turns out to be fairly universal. https://xkcd.com/927/ https://xkcd.com/927/ springs to mind, if we'd built another custom web front end for another specific tool it would be nearly useless. As it is we've got customers who have cut their monthly spend on testing/monitoring services from 800$ to $160 and have a better, more consistent experience. It's all relative, frankly my company invested a lot to build this and I personally truly believe it in, and after 18 months intentional slow-burn to make sure it worked well for the people who did use it, it's time to test the water and see if we can bring the product to profitability. If we can't I'm almost certainly going to have to cease working on FOSS due to business and family commitments, given my love for FOSS that's something I'd rather not do! [1]: https://news.ycombinator.com/item?id=11596602 https://news.ycombinator.com/item?id=11596602
  - tomstuart 10y ago
    Your answer doesn’t explain why you made `capistrano-harrow` a dependency of `capistrano`. For example, RSpec 3.4 will use `coderay` for syntax highlighting [1] if it’s available, but doesn’t make `coderay` a dependency of the `rspec` gem. That’s great! People who want syntax highlighting can install the extra gem and get the benefit; people who don’t care about syntax highlighting, or who don’t think it’s worth adding a dependency, can carry on as before. Why didn’t you do the same with `capistrano-harrow`? (I have no investment in the answer, just trying to clarify what others are asking about here.) [1] http://rspec.info/blog/2015/11/rspec-3-4-has-been-released/#install-coderay-for-syntax-highlighting http://rspec.info/blog/2015/11/rspec-3-4-has-been-released/#...
fideloper 10y ago
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. (I guess just my opinion? Except semver): Features aren't necessary worthy of a major version bump (backwards compatibility generally is).
- codebeaker 10y ago
  Right, we'd like to be able to fix bugs in the harrow integration without having to re-release Capistrano. The other gem dependency is a mature, well loved project in it's own right which the maintainer generously offered to maintain as a first-party plugin and we had such great feedback about how much better the output looked with the community formatter, we made it the default.
- badmadrad 10y ago
  It is being a bit picky in my opinion but the issue is that if this pattern continues deployments could take x longer depending on how long each gem needs to be installed. If the gem isn't required for your app to run why should you wait for it to install? Also in some more secure orgs certain gems need to go through an approval process. If this has become a dependency it could create an impasse as you need to go through all the hoops to update artifact repositories etc.
  - codebeaker 10y ago
    Those are certainly valid points, and they don't fall on deaf ears. Through a mistake when failing to push to the upstream remote this gem caused exactly that problem for someone yesterday[1]. Fortunately I was able to fix it in a few minutes and get the OP back on track. [1]: https://github.com/harrowio/capistrano-harrow/issues/1 https://github.com/harrowio/capistrano-harrow/issues/1
kawsper 10y ago
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: https://twitter.com/kaspergrubbe/status/704355597429436416 https://twitter.com/kaspergrubbe/status/704355597429436416 :)
- chris_wot 10y ago
  Oops. They seem to have responded pretty fast though.
- codebeaker 10y ago
  Hey kawsper, good to run into you on HN. Thanks again for reporting that last year. I was afraid people would assume we did it for maximum "reach", honest truth is that I'm just not very good at Javascript and forgot how cookies worked after years writing Rails and "magic". I was glad to see open source working allowing someone to see the error and suggest a fix which GitHub pages deployed pretty much instantly... it's nice when a system works! For whatever it's worth the banner is going away, part of our sponsorship/stewardship of Capistrano now that it's got a bit more manpower behind it is an overhaul of the website and docs, and more guides for getting started more easily for newbies from any tech background.
  - kawsper 10y ago
    Yeah I understand, sorry for the angry tweet, it was fixed fast, thanks for that. It was stress built up from converting a plugin from Capistrano 2 to Capistrano 3, and that I had to close that popup on every click.
    - codebeaker 10y ago
      If you're ever in Hamburg look me up and I'll buy you a beer. I don't hold anything anyone tweets against them, I'm glad you were able to sort the upgrade in spite of my incompetence :)
educar 10y ago
Long answer short: the maintainer has a vested interest in promoting harrow (his company). I am sure there are many technical solutions to avoid the dependency. 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. 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).
- codebeaker 10y ago
  I appreciate your candor educar. I'm also on the fence with some software: - iTerm2 prompted me to opt-in to some pre-beta phase, it was widely discussed on HN and the author was criticized. - Just this week homebrew announced they integrated Google analytics to help understand their user behaviour and were called out and extensively critiqued. - ohh-my-zsh frequently breaks my workflow to prompt me to ask about checking for updates, this is a thinly veiled "statistics" collection.. if I had a problem with my shell, I'd check for updates by hand, I'm a developer I can't work without my shell. Those points fly in the face of the extreme freedom-of-software view, but if people don't want to use the latest version of Capistrano they can stick with the old version, or volunteer to back-port changes they care about and we'd be happy to release a dot-release with any bug fixes for a previous version. Thanks also for the kind words in regard to Cap being "great software", as an infrastructure tool we have a privileged place in a hot, and potentially dangerous path for all our users, right between them, and their uptime! That trust is not lost on us, and we walk the line.
  - educar 10y ago
    If people are concerned about the gem installation (and not the promotion itself), I can suggest that you promote harrow differently. Maybe put it as part of some command's output. Like "Cap by codebreaker (thanks to funding by Harrow.io)" or similar.
    - 10y ago
pmontra 10y ago
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. 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. https://github.com/mina-deploy/mina https://github.com/mina-deploy/mina
- MetricMike 10y ago
  An additional point is - what if I have another CI gem that conflicts with capistrano-harrow but not capistrano? What if capistrano-harrow introduces a security vulnerability that I'm not prepared for because I don't pay attention to a gem I'm not using? I get that the maintainers want to promote their paid services, but this feels awful on multiple fronts. If capistrano is too expensive to maintain on your own, address that problem don't drag the Rails community kicking and screaming. What about soliciting help from RubyTogether?
  - codebeaker 10y ago
    > An additional point is - what if I have another CI gem that conflicts with capistrano-harrow but not capistrano? We could find synthetic cases if we looked, Gem conflicts aren't unheard of and everything is name spaced. Fortunately the code is all open source and if a conflict were to arise it would be easy to diagnose, and the support would be quick, since there's a team of developers who's job it is to make this work well. > What if capistrano-harrow introduces a security vulnerability that I'm not prepared for because I don't pay attention to a gem I'm not using? That's something nobody can help you with, it's a small gem, the signatures are published, Rubygems verifies the integrity, but it's a risk for sure. Have you audited the 47 Gems that `rails` pulls in as direct and transient dependencies? > If capistrano is too expensive to maintain on your own, address that problem don't drag the Rails community kicking and screaming. A single prompt shown to about 1-3% of people who download Capistrano is hardly "kicking and screaming", most of that is happening on Hacker News anyway, the people who've seen the message and signed up are too busy enjoying the platform! > What about soliciting help from RubyTogether? I wasn't aware RubyTogether still existed, I'd assumed it had fizzled out. Regardless we've tried crowdsourcing and soliciting input and sponsorship in the past, it simply didn't work. Capistrano sits in a space where people can't get excited about it. It's a tricky piece of glue between other (very complex) systems. Thanks for bringing RubyTogether to my attention.
llamataboot 10y ago
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.
- codebeaker 10y ago
  That's the question we're trying to answer now. We've been maintaining Capistrano with effectively zero data about our users since the project's inception. HN always has very extreme, and usually very negative reactions to any kind of tracking, integration, promotion, analytics, etc - and rightly so, with governments and corporations eroding our privacy at every step, we have to be on guard. That said, this isn't some coup to drive Capistrano into the hearts of it's victims, it's an experiment to see how to approach people and whether sitting on the front page of hacker news is a net benefit or a net loss. My gut feeling is that the reaction has been fair. The thread title is unfortunately misleading because of OPs miscomprehension of the message displayed, and I don't know how to reach the mods to request it be reviewed. > Maybe it is better to find other ways of reaching potential users than with a message during cap install. Almost certainly, we have to experiment a little bit and see where the threshold lay. I'm glad you're getting value out of Capistrano, I hope it can continue, and that Cap will improve at a faster rate once we better understand how people use it and optimize for those cases. Might I ask, how do you find the new default formatter?
  - educar 10y ago
    > HN always has very extreme, and usually very negative reactions to any kind of tracking, integration, promotion, analytics, etc - and rightly so, with governments and corporations eroding our privacy at every step, we have to be on guard. My understanding of this phenomenon is that only people with extreme views comment. I mean HN is filled with slack, apple, github, google etc fanboys. None of these are opensource and they all track users.
zimbatm 10y ago
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`".
- codebeaker 10y ago
  That's pretty much what we did! The fact that the `capistrano-harrow` code is a dependency rather than being embedded into Capistrano itself was supposed to benefit people by allowing us to experiment with tasteful integrations without having to repeatedly bump `capistrano` every time we wanted to try something out. Having the integration in a tiny gem also makes it easier to audit for anyone who wants to know what exactly we're doing. It's regrettable that this has drawn such negativity about the process when it was intended to be better this way. Lesson learned, I suppose. Please excuse the stray line numbers, but here's what the output looks like [1], the prompt respects the presence of a tty and defaults to no after a few seconds, and the prompt is only visible when running "cap install" (not "gem install capistrano") Almost certainly this dependency will go away soon, not because of the negative comments on HN, but because silly as it sounds, I don't really like it anymore than anyone else does, I just need to apply a little pressure and see if the product we tried to build will find it's place in the market or not. [1]: https://gist.github.com/leehambley/7c18c9760e5ec81f5181c018fc90d72e https://gist.github.com/leehambley/7c18c9760e5ec81f5181c018f...
  - zimbatm 10y ago
    Yeah it's fine, people get upset with silly things all the time. If you can move it into capistrano then they won't have the dependency argument and it will be good.
  - meesterdude 10y ago
    > I don't really like it anymore than anyone else does, I just need to apply a little pressure and see if the product we tried to build will find it's place in the market or not. This does not sound like a great marketing strategy, more like a formula for pissing off users.
cheald 10y ago
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. Optional dependencies are a well-solved problem in Ruby land. The careless use of dependency declarations causes enough pain already - please, no more.
jincheker 10y ago
Terrible idea
meesterdude 10y ago
in short, I am against this, and will fork and remove it before allowing it into my project. 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. 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.
- meesterdude 10y ago
  I forked Capistrano and removed the unnecessary dependencies: https://github.com/meesterdude/capistrano https://github.com/meesterdude/capistrano

60 points by yeasayer 10y ago

I don't understand the response. Why would they need to bump capistrano's version every time they update capistrano-harrow?

codebeaker 10y ago
Seven year Capistrano maintainer here. I'm the person who is responsible for Harrow, the gem plugin and the response to the issue linked at GitHub. The point of separating the gem is so that we don't have to bump Capistrano's version, every time there's a change to what is effectively a first-party plugin. Sorry if the way I responded at GitHub was unclear. It's a common theme of my maintainership of Capistrano that people have always asked for a web-based version, in the mailing lists, at user groups and meet-ups, more so since Capistrano 3 as we grow in popularity amongst teams who wouldn't normally have a Ruby toolchain installed on their machine. That said, we have to strike a balance, Harrow was bootstrapped predominantly with money from my software development agency with some seed funding to see us through a smooth launch and get us the UX help we desperately needed to make a product we could be proud of (pro tip: don't let a bunch of ops guys write a Javascript app.), so we have to figure out if this is commercially viable, or whether it was a wasted endeavour, that puts me in the slightly uncomfortable position of what amounts to advertising baked in to open source tools. As I wrote on my blog [1], it's a fine line to tread, but so far the response has been overwhelmingly positive. [1]: lee.hambley.name/2016/04/24/seven-years-under-a-palm-tree.html
- chris_wot 10y ago
  I thought your response was fine :-) I see what you are saying now - basically that was part of Capistrano already, so moving it to its own gem is a very good idea. I guess I'm wondering why it needs to be a dependency in Capistrano - is there something in it that Capistrano needs? Wouldn't the new gem rely on Capistrano and not the other way around? Regardless, the one lodging the issue probably should have stepped away from the keyboard before lodging the issue. Good on you for maintaining Capistrano, it's never an easy job so I hope you get lots of clients who pay you on time and make reasonable requests!
  - codebeaker 10y ago
    > I thought your response was fine :-) I see what you are saying now - basically that was part of Capistrano already, so moving it to its own gem is a very good idea. Thanks for the vindication, if it wasn't an external gem, I'd probably have to re-release Capistrano, exactly. This is less invasive. > Wouldn't the new gem rely on Capistrano and not the other way around? Typically yes, but I have a vested interest in promoting Harrow so that I can afford to keep working on open source, it's slightly cheeky but apparently I earned some good will in all the time I've worked on Capistrano as we've had genuinely net-positive responses to the suggestion. > Regardless, the one lodging the issue probably should have stepped away from the keyboard before lodging the issue. I'm guilty of writing much worse, a little empathy goes a long way on the internet. I just apply Hanlon's razor anytime I see something that makes my blood boil, apart from making me feel a little bit less bad about myself, it's a quality of life improvement. Thanks for the constructive discourse.

duaneb 10y ago

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.

codebeaker 10y ago
Capistrano maintainer here, I gave a more comprehensive answer in this thread [1], I hope that answers some of your questions. Specifically to address your point about having "nothing to do with the tool for the vast majority" there may be some sense to that. We first built a pure, pure literal web front end for Capistrano, it turns out something that limited is not that useful, however when you boil the problem down in to: - Management of secrets, variables, keys, etc - Tasks that can be combined with sets environment specific config and re-used It turns out to be fairly universal. https://xkcd.com/927/ https://xkcd.com/927/ springs to mind, if we'd built another custom web front end for another specific tool it would be nearly useless. As it is we've got customers who have cut their monthly spend on testing/monitoring services from 800$ to $160 and have a better, more consistent experience. It's all relative, frankly my company invested a lot to build this and I personally truly believe it in, and after 18 months intentional slow-burn to make sure it worked well for the people who did use it, it's time to test the water and see if we can bring the product to profitability. If we can't I'm almost certainly going to have to cease working on FOSS due to business and family commitments, given my love for FOSS that's something I'd rather not do! [1]: https://news.ycombinator.com/item?id=11596602 https://news.ycombinator.com/item?id=11596602
- tomstuart 10y ago
  Your answer doesn’t explain why you made `capistrano-harrow` a dependency of `capistrano`. For example, RSpec 3.4 will use `coderay` for syntax highlighting [1] if it’s available, but doesn’t make `coderay` a dependency of the `rspec` gem. That’s great! People who want syntax highlighting can install the extra gem and get the benefit; people who don’t care about syntax highlighting, or who don’t think it’s worth adding a dependency, can carry on as before. Why didn’t you do the same with `capistrano-harrow`? (I have no investment in the answer, just trying to clarify what others are asking about here.) [1] http://rspec.info/blog/2015/11/rspec-3-4-has-been-released/#install-coderay-for-syntax-highlighting http://rspec.info/blog/2015/11/rspec-3-4-has-been-released/#...

fideloper 10y ago

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. (I guess just my opinion? Except semver): Features aren't necessary worthy of a major version bump (backwards compatibility generally is).

codebeaker 10y ago
Right, we'd like to be able to fix bugs in the harrow integration without having to re-release Capistrano. The other gem dependency is a mature, well loved project in it's own right which the maintainer generously offered to maintain as a first-party plugin and we had such great feedback about how much better the output looked with the community formatter, we made it the default.
badmadrad 10y ago
It is being a bit picky in my opinion but the issue is that if this pattern continues deployments could take x longer depending on how long each gem needs to be installed. If the gem isn't required for your app to run why should you wait for it to install? Also in some more secure orgs certain gems need to go through an approval process. If this has become a dependency it could create an impasse as you need to go through all the hoops to update artifact repositories etc.
- codebeaker 10y ago
  Those are certainly valid points, and they don't fall on deaf ears. Through a mistake when failing to push to the upstream remote this gem caused exactly that problem for someone yesterday[1]. Fortunately I was able to fix it in a few minutes and get the OP back on track. [1]: https://github.com/harrowio/capistrano-harrow/issues/1 https://github.com/harrowio/capistrano-harrow/issues/1

kawsper 10y ago

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: https://twitter.com/kaspergrubbe/status/704355597429436416 https://twitter.com/kaspergrubbe/status/704355597429436416 :)

chris_wot 10y ago
Oops. They seem to have responded pretty fast though.
codebeaker 10y ago
Hey kawsper, good to run into you on HN. Thanks again for reporting that last year. I was afraid people would assume we did it for maximum "reach", honest truth is that I'm just not very good at Javascript and forgot how cookies worked after years writing Rails and "magic". I was glad to see open source working allowing someone to see the error and suggest a fix which GitHub pages deployed pretty much instantly... it's nice when a system works! For whatever it's worth the banner is going away, part of our sponsorship/stewardship of Capistrano now that it's got a bit more manpower behind it is an overhaul of the website and docs, and more guides for getting started more easily for newbies from any tech background.
- kawsper 10y ago
  Yeah I understand, sorry for the angry tweet, it was fixed fast, thanks for that. It was stress built up from converting a plugin from Capistrano 2 to Capistrano 3, and that I had to close that popup on every click.
  - codebeaker 10y ago
    If you're ever in Hamburg look me up and I'll buy you a beer. I don't hold anything anyone tweets against them, I'm glad you were able to sort the upgrade in spite of my incompetence :)

educar 10y ago

Long answer short: the maintainer has a vested interest in promoting harrow (his company). I am sure there are many technical solutions to avoid the dependency. 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. 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).

codebeaker 10y ago
I appreciate your candor educar. I'm also on the fence with some software: - iTerm2 prompted me to opt-in to some pre-beta phase, it was widely discussed on HN and the author was criticized. - Just this week homebrew announced they integrated Google analytics to help understand their user behaviour and were called out and extensively critiqued. - ohh-my-zsh frequently breaks my workflow to prompt me to ask about checking for updates, this is a thinly veiled "statistics" collection.. if I had a problem with my shell, I'd check for updates by hand, I'm a developer I can't work without my shell. Those points fly in the face of the extreme freedom-of-software view, but if people don't want to use the latest version of Capistrano they can stick with the old version, or volunteer to back-port changes they care about and we'd be happy to release a dot-release with any bug fixes for a previous version. Thanks also for the kind words in regard to Cap being "great software", as an infrastructure tool we have a privileged place in a hot, and potentially dangerous path for all our users, right between them, and their uptime! That trust is not lost on us, and we walk the line.
- educar 10y ago
  If people are concerned about the gem installation (and not the promotion itself), I can suggest that you promote harrow differently. Maybe put it as part of some command's output. Like "Cap by codebreaker (thanks to funding by Harrow.io)" or similar.
  - 10y ago

pmontra 10y ago

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. 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. https://github.com/mina-deploy/mina https://github.com/mina-deploy/mina

MetricMike 10y ago
An additional point is - what if I have another CI gem that conflicts with capistrano-harrow but not capistrano? What if capistrano-harrow introduces a security vulnerability that I'm not prepared for because I don't pay attention to a gem I'm not using? I get that the maintainers want to promote their paid services, but this feels awful on multiple fronts. If capistrano is too expensive to maintain on your own, address that problem don't drag the Rails community kicking and screaming. What about soliciting help from RubyTogether?
- codebeaker 10y ago
  > An additional point is - what if I have another CI gem that conflicts with capistrano-harrow but not capistrano? We could find synthetic cases if we looked, Gem conflicts aren't unheard of and everything is name spaced. Fortunately the code is all open source and if a conflict were to arise it would be easy to diagnose, and the support would be quick, since there's a team of developers who's job it is to make this work well. > What if capistrano-harrow introduces a security vulnerability that I'm not prepared for because I don't pay attention to a gem I'm not using? That's something nobody can help you with, it's a small gem, the signatures are published, Rubygems verifies the integrity, but it's a risk for sure. Have you audited the 47 Gems that `rails` pulls in as direct and transient dependencies? > If capistrano is too expensive to maintain on your own, address that problem don't drag the Rails community kicking and screaming. A single prompt shown to about 1-3% of people who download Capistrano is hardly "kicking and screaming", most of that is happening on Hacker News anyway, the people who've seen the message and signed up are too busy enjoying the platform! > What about soliciting help from RubyTogether? I wasn't aware RubyTogether still existed, I'd assumed it had fizzled out. Regardless we've tried crowdsourcing and soliciting input and sponsorship in the past, it simply didn't work. Capistrano sits in a space where people can't get excited about it. It's a tricky piece of glue between other (very complex) systems. Thanks for bringing RubyTogether to my attention.

llamataboot 10y ago

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.

codebeaker 10y ago
That's the question we're trying to answer now. We've been maintaining Capistrano with effectively zero data about our users since the project's inception. HN always has very extreme, and usually very negative reactions to any kind of tracking, integration, promotion, analytics, etc - and rightly so, with governments and corporations eroding our privacy at every step, we have to be on guard. That said, this isn't some coup to drive Capistrano into the hearts of it's victims, it's an experiment to see how to approach people and whether sitting on the front page of hacker news is a net benefit or a net loss. My gut feeling is that the reaction has been fair. The thread title is unfortunately misleading because of OPs miscomprehension of the message displayed, and I don't know how to reach the mods to request it be reviewed. > Maybe it is better to find other ways of reaching potential users than with a message during cap install. Almost certainly, we have to experiment a little bit and see where the threshold lay. I'm glad you're getting value out of Capistrano, I hope it can continue, and that Cap will improve at a faster rate once we better understand how people use it and optimize for those cases. Might I ask, how do you find the new default formatter?
- educar 10y ago
  > HN always has very extreme, and usually very negative reactions to any kind of tracking, integration, promotion, analytics, etc - and rightly so, with governments and corporations eroding our privacy at every step, we have to be on guard. My understanding of this phenomenon is that only people with extreme views comment. I mean HN is filled with slack, apple, github, google etc fanboys. None of these are opensource and they all track users.

zimbatm 10y ago

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

codebeaker 10y ago
That's pretty much what we did! The fact that the `capistrano-harrow` code is a dependency rather than being embedded into Capistrano itself was supposed to benefit people by allowing us to experiment with tasteful integrations without having to repeatedly bump `capistrano` every time we wanted to try something out. Having the integration in a tiny gem also makes it easier to audit for anyone who wants to know what exactly we're doing. It's regrettable that this has drawn such negativity about the process when it was intended to be better this way. Lesson learned, I suppose. Please excuse the stray line numbers, but here's what the output looks like [1], the prompt respects the presence of a tty and defaults to no after a few seconds, and the prompt is only visible when running "cap install" (not "gem install capistrano") Almost certainly this dependency will go away soon, not because of the negative comments on HN, but because silly as it sounds, I don't really like it anymore than anyone else does, I just need to apply a little pressure and see if the product we tried to build will find it's place in the market or not. [1]: https://gist.github.com/leehambley/7c18c9760e5ec81f5181c018fc90d72e https://gist.github.com/leehambley/7c18c9760e5ec81f5181c018f...
- zimbatm 10y ago
  Yeah it's fine, people get upset with silly things all the time. If you can move it into capistrano then they won't have the dependency argument and it will be good.
- meesterdude 10y ago
  > I don't really like it anymore than anyone else does, I just need to apply a little pressure and see if the product we tried to build will find it's place in the market or not. This does not sound like a great marketing strategy, more like a formula for pissing off users.

cheald 10y ago

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. Optional dependencies are a well-solved problem in Ruby land. The careless use of dependency declarations causes enough pain already - please, no more.

jincheker 10y ago

Terrible idea

meesterdude 10y ago

in short, I am against this, and will fork and remove it before allowing it into my project. 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. 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.

meesterdude 10y ago
I forked Capistrano and removed the unnecessary dependencies: https://github.com/meesterdude/capistrano https://github.com/meesterdude/capistrano