Sunday, May 1, 2011

Can you Distribute a Ruby on Rails Application without Source?

I'm wondering if it's possible to distribute a RoR app for production use without source code? I've seen this post on SO, but my situation is a little different. This would be an app administered by people with some clue, so I'm cool with still requiring an Apache/Mongrel/MySQL setup on the customer end. All I really want is for the source to be protected. Encoding seems a popular way to go for distributing PHP apps (eg: Helpspot).

I've found these potential solutions:

  • Zenobfuscate - not all types of Ruby code is supported however, so that counts that out
  • Ruby Encoder - may be the best option, as their PHP encoder looks alright (I haven't tried it however) but it's not available yet. I've used IONcube for PHP before and it worked well, but it doesn't seem that IONcube is interested yet.
  • Slingshot - it was mentioned in the other SO post, but it solves a different problem to mine and the source is still visible.
  • RubyScript2Exe - from the doco, it's not production ready, so that counts that out.

I've heard that potentially using JRuby and distributing bytecode might be a way to achieve this, but I've never used JRuby so I'm not sure what's involved.

Can anyone offer any ideas and/or known examples? Ideally I'd love to have some kind of automated build scenario as well.

From stackoverflow
  • You can, but it wouldn't do anything to prevent somebody from reverse-engineering or modifying it. I remember there was an article about similar attempts to obfusticate Perl and how they could be effectively bypassed by a debugger and 5 minutes of effort.

    Unkwntech : I don't think obfusticating perl is needed perl is obfusticated enough by itself...
    Dan Harper - Leopard CRM : Whatever solution it is, it's not as secure as not giving anyone the app. I'm just trying to figure out how to stick a hurdle as large as possible in front of anyone trying to get to the source. There is a small element of trust there as the customers have paid to use the software.
  • If you can't wait for the delivery of RubyEncoder, then I think ZenObfuscate is the most promising. Though it may require some modifications to your source code, they do say this on their site:

    ZenObfuscate costs $2500 for a site license or is individually negotiable for other licensing schemes. Yes, that is expensive. That was on purpose. But don't let that thwart you too much. If your product is really cool and we want to see it succeed, we'll make it work. "Really cool" is not freecell.

    Of course, for $2500 (or more), you'd hope to get a few tweaks to the compiler that'd make your codebase fully supported. It might be worth engaging them in the conversation.

    Dan Harper - Leopard CRM : I didn't notice that, thanks Pete, maybe it is worth talking to them about it.
  • I'd spend less time and money on hiding/protecting your code & more time/money on getting customers.Customers beat code all day long.

    George Jempty : -1 for not answering the question
  • Take a look at JumpBox.

    I've had conversations with them on the topic, and they seem to have a solution that will work soon for Rails apps.

  • If you release the source, obfuscated or otherwise, your app will be pirated. See, for example, Mint. It depends on what you're building, but you may find that you're better off releasing the app as a hybrid of sorts: A hosted app with a well-defined API, and a component that runs on the customer's server. As long as the true value of your product lives on the server side, you don't need to obfuscate your code, and you can just release the source code unmodified. Additionally, this may also give you the opportunity to reach clients running, say, PHP rather than Ruby. See, for example, Google Analytics, HopToad, Scout, etc, etc.

    guns : ++ This is the new open/closed source world of the web application. It actually represents a really great scenario for developers - your application's value is in your service and execution, not necessarily in the code itself. You can enjoy both the freedom of open code and the benefits of limited supply.
    Dan Harper - Leopard CRM : -1 for not answering the question. This is not a question of architecture design, business models, or whether the app will be pirated or not.
    Toby Hede : I think that given there is no actual solution for this problem, and it is generally an inherently flawed approach, offering alternatives is quite reasonable.
  • You can also take a look at Mingle from ThoughtWorks studios as an example of using JRuby for this. It's a Ruby on Rails app, they run it using JRuby. They've customized jruby to load encrypted .rb files.

  • Your best option right now is to use JRuby. A little bit of background: My company (BitRock) works with many proprietary and commercial open source vendors. We help them package their server software, which is typically based on PHP, Java or Ruby together with a web server or application server (Apache, Tomcat), the language runtime and a database (typically Postgres, MySQL) into a self-contained, easy to use installer. We have a large number of PHP-based customers (including HelpSpot, which you mention) but also several Rails-based ones. In the case of the RoR customers the norm is to use JRuby together with Tomcat or Glassfish although in some cases we also bundle a native Ruby interpreter to run specific scripts that rely on libraries not yet ported to JRuby (usually not core to the application). JRuby has matured quickly and in many cases it actually runs their code faster than regular Ruby. You will need to also consider that although porting your code to JRuby is fairly straightforward, you will need to invest some time on that. You may want to check JRuby Stack which is a free installer of everything you need to get started. Good luck!

  • I'm wondering if you could just "compile" the ruby code into an executable using something like RubyScript2Exe ?

    To be honest I haven't used it but it seems like it could be what you want, even if it just packages up the scripts with the interpreter into a single executable.

0 comments:

Post a Comment