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
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.
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?
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 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).
- 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.
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.
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?
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.
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.
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.
(I guess just my opinion? Except semver): Features aren't necessary worthy of a major version bump (backwards compatibility generally is).
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...
This does not sound like a great marketing strategy, more like a formula for pissing off users.
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!
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/#...
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 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!
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.
Optional dependencies are a well-solved problem in Ruby land. The careless use of dependency declarations causes enough pain already - please, no more.
