While Futurice is a company that is not tied to a particular technology, Ruby on Rails is one that is gaining popularity among the projects we deliver to our customers. From our perspective, the reasons are obvious. Ruby is a powerful language that is easy to grasp. Rails brings us efficiency and genuinely supports Futurice’s promise: Your rapid development partner. Ruby on Rails is mature, the documentation is good, and the support for automated testing is unbeatable when compared to any other framework we use.
If Ruby on Rails is so great, why we are still selling more web projects that are done with the Java EE stack, or custom Drupal or other fine CMS platforms? Of course, one big reason is our internal technical skill set with regards to these technologies and a good reputation with such projects. But another side of the story is that Ruby on Rails is not always easy to sell. We have failed selling Rails to customers a few times, but on the way we have also learned how to do it better.
The very first issue you need to tackle is to sell Ruby on Rails internally inside your company. It is embarrassing if your proposal of Rails to a customer is shot down when the guy next to says “we only offer Rails because this programmer guy happens to like Rails”. Selling Rails internally means that your CEO, Mr. Sales Guy and the J2EE architect sitting next to you really believe that Ruby on Rails is important and will help you deliver better projects.
Selling Rails to your customers might be extremely easy and straightforward. But sometimes it is harder than internal marketing efforts ever were. These are some of the reactions we have heard after proposing Ruby on Rails.
The “Java reaction” is probably the most common one we hear. If the customer really only accepts Java, you may still sell Ruby as a part of the project. For instance, some Java-only customers do not care if the integration tests are powered by Ruby. Or you might propose implementing the web front-end with Rails, and use Java for back-end integrations and other “heavy stuff”.
If the customer’s requirement is to run on Glassfish or any other JEE container, you can readily say that it’s not going to be a problem with jRuby. If the customer is not assured, hand them a .WAR file and demonstrate it will run on their chosen container as well as the “real Java” apps they already have.
If the customer is afraid of Ruby, open up your recent project and show them the code. Start by showing some easy-to-read ActiveRecord validations or show how easy it is to create a full blown REST API within ActionControllers. If your customer is at least a tiny bit open minded towards new technologies, they will understands that Ruby as a language is not a real problem, in case they really need to touch the code later on.
Drupal or Plone might have 80% of the “features” your customer needs, but let them know that those features will be quite easy to implement with Rails as well. Actually, you have more choices to choose from with community driven plugins, and creating something of your own is not going to be tricky. The important part, however, is to understand that the missing 20% will probably eat up more than 80% time spent on the project, and spending it with Rails is very likely much more efficient than tweaking the CMS. The more the customers service looks like an app and not a pure CMS, the more confidence you should have recommending Rails.
If you have a customer that does not know Rails or trust Rails, an easy way to raise confidence is to show much you trust it yourself. Promise them the first actually working demo within one week. Organize a workshop and develop the most important feature with the customer within two days. Give the customer a smaller price tag over the Java option you may also offer. And don’t forget to refer to a list of popular apps made with Rails.
Then there are reactions that you don’t hear, but you perceive anyways. This silent guy in the meeting room is still thinking of the cool companywide backup script he wrote in Perl last night only to be wakened up with someone mentioning the two ugliest curse words: Ruby and Rails. The problem with Ruby and Rails communities being so loud and so “right” make some people dislike – even hate – Ruby on Rails. The worst thing you could do in such situations is to arm your Rails gun and start debating. Instead, concentrate on demonstrating why you are such great people for the job and how you have proven yourself by delivering successful software earlier, no matter what technology you used.