Capistrano maintainers add new dependency to promote paid service | Hacker News Reader

Capistrano maintainers add new dependency to promote paid service

github.com

60 pointsyeasayer42 comments

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

> From an engineering point of view it should be a separate gem...

Absoluitely, this isn't an engineering decision it's to finally test and see if there's a market for people to support open source now that we've built something that was widely requested.

> From a marketing point of view I understand the move, but I don't like it much.

I'm actually with you, it's a little bit driven by the fact that if we don't make the product break-even we'll have a hard time to continue running it at a loss.

HN often complains about services that were free suddenly disappearing, or being discouraged from investing to learn/adopt a product that has no clear model behind making it sustainable.

I find it interesting that for closed source products that people run for free the crowd seems to have a different view than when someone tries to make open source sustainable through some measurement/monetization, even when it's done in a very considerate way.

> Anyway, I'm using mina (less feature complete but much fa

Mina is great where it fits, I have a slew of projects using everything from Mina through Puppet via Chef and Ansible, a couple on the side still using Capistrano ;-)

This luxury of choice is one we too often take for granted.

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?

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

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.

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

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

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

Absolutely true, two observations:

- I've often wondered about syntax highlighting in rspec to make things more readable in tests, I wish I would have known about this and seen it featured more prominently.

- RSpec have no vested interest in promoting Coderay. I do have a vested interest in making Harrow come to break-even, if we don't make it break even I may have to step away from the FOSS work that I so enjoy.

Thanks for sharing rspec+coderay, that's gonna make life in rspec projects much more bearable!

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

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.

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.

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

Actually we wanted to ping people once not on every time they use the tool, this is the lesser evil, it also allows us to push something to turn off the integration without having to bump Capistrano's version for no reason, simply by deploying another (noop) version of the integration gem.

> I am sure there are many technical solutions to avoid the dependency.

It's trivial if you use a Gemfile: `gem "capistrano", "~> 3.4.0"` or `gem "capistrano", "3.4.1"`. You will stay on a version of Capistrano before 3.5.0. That's what I'm going to do, along with some more research into setting up Docker and something like Kubernetes for our deployments.

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.

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?

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

> My understanding of this phenomenon is that only people with extreme views comment.

I believe so too, we have much more positive feedback from new customers from the exposure this post has brought than we have negative.

In either case I'm glad for the opportunity for HN to discuss how to monetize FOSS, to see what people consider fair and unfair and to learn a little bit more about people's standpoints.

> My understanding of this phenomenon is that only people with extreme views comment.

Definitely not only, but you've put your finger on an important point here: such people are far more likely to comment, making the threads a distorted image of the community.

I feel like this is one of those phenomena that has a well-known name, but can't think of it. Anybody know?

Were you thinking of "vocal minority"? Seems to fit here.

I've had something on the tip of my tongue since seeing the parent comment last night - I think this is close https://en.wikipedia.org/wiki/Spiral_of_silence but it doesn't seem to say too much about when the majority behave this way, maybe it's a disparity between perceived like-minded group size and actual group-size.

Haven't upgraded any of our apps to use it yet, but I really like what I've seen. The default output always seemed heavy on verbosity for me, but managing it was always one of these things we often never got around to!

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.

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 :)

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.

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.

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 :)

Oops. They seem to have responded pretty fast though.

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

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

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!

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

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

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.

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

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.

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.

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

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

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

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

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.

Terrible idea

Reply on news.ycombinator.com