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.