
Capistrano maintainers add new dependency to promote paid service - yeasayer
https://github.com/capistrano/capistrano/issues/1655
======
pmontra
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)

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

------
duaneb
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
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
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/#...](http://rspec.info/blog/2015/11/rspec-3-4-has-been-
released/#install-coderay-for-syntax-highlighting)

~~~
codebeaker
> 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!

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

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

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

~~~
dang
> _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?

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

~~~
codebeaker
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](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.

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

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

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

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

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

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

~~~
badmadrad
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
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)

------
meesterdude
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
I forked Capistrano and removed the unnecessary dependencies:
[https://github.com/meesterdude/capistrano](https://github.com/meesterdude/capistrano)

------
zimbatm
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
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...](https://gist.github.com/leehambley/7c18c9760e5ec81f5181c018fc90d72e)

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

------
jincheker
Terrible idea

