January 2011

Salesforce.com and Engine proclaim Ruby to be the language for cloud applications. Yet, recent announcement by Amazon.com and Oracle’s NetBeans project raise questions about Ruby’s current and future enterprise adoption.

Ruby, the language for the cloud?
Salesforce.com acquired Heroku, a Ruby and Ruby on Rails (RoR) platform as a service (PaaS) provider in early December 2010. At the time, Salesforce.com CEO, Marc Benioff, spoke highly of Ruby’s future:

Ruby is the language of Cloud 2 [applications for real-time mobile and social platforms]. Developers love Ruby. It’s a huge advancement. It offers rapid development, productive programming, mobile and social apps, and massive scale. We could move the whole industry to Ruby on Rails.

Tom Mornini, CEO of Heroku competitor Engine Yard’s, echoed Beinoff’s views about Ruby’s affinity with cloud-based applications.

I’ve previously highlighted data from the Tiobe Programming Community Index that indicates Ruby’s usage declined in 2010. Additionally, amongst enterprise job postings on Indeed.com, the actual number and growth rate of jobs requiring Ruby skills trailed jobs requiring PHP and Python skills.

If Ruby is in fact the language of the cloud, enterprises haven’t received the memo as yet.

Amazon.com endorses Java, not Ruby, first
Amazon.com recently announced the AWS (Amazon Web Services) Elastic Beanstalk beta, based initially on Java. While Amazon.com did allude to other languages being supported by AWS Elastic Beanstalk in the future, they started with Java, not Ruby.

As I said last week, “when the de facto public cloud provider, Amazon.com, launches a Java-based cloud platform offering ahead of another language such as Ruby, it speaks volumes about Java’s future.”

Amazon.com’s AWS success has been largely outside of the enterprise, with the very same small companies, departments, startups and developers. This audience should, we’re told, have an affinity for Ruby.

NetBeans drops Ruby on Rails support
Just this week, Oracle’s NetBeans IDE project announced yet more news bad new for Ruby adoption amongst enterprises and developers alike. The NetBeans team explained:

“After thorough consideration, we have taken the difficult step to discontinue support for Ruby on Rails in the NetBeans IDE. … Although our Ruby support has historically been well received, based on existing low usage trends we are unable to justify the continued allocation of resources to support the feature.”

Ruby on Rails will continue being supported on NetBeans 6.9.1 or earlier. However, as of NetBeans 7.0, NetBeans developers building Ruby on Rails applications have to decide between staying current with NetBeans releases or Ruby on Rails support within their IDE of choice.

Making sense of the Ruby hype
According to analysis by RedMonk’s Stephen O’Grady, the alpha geeks on Hacker News are quite interested in Ruby on Rails. As RedMonk has previously stated, the alpha geeks are typically ahead of the IT adoption curve. If this holds for Ruby, enterprises should start seeing more of their developers interested in using Ruby and Ruby on Rails for the next project at hand.

IT decision makers are encouraged to use caution when considering Ruby for new enterprise projects. Jumping on the Ruby bandwagon, when usage statistics and vendor actions suggest caution, doesn’t appear to be a winning IT strategy. On the other hand, using Ruby for a new application in order to learn the pros and cons of including Ruby into the IT toolkit would be valuable, especially if the alpha geeks are in fact correct about Ruby and Ruby on Rails.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

Amazon selecting open source Apache Tomcat as the Java application server powering Amazon’s entry into the Java Platform as a Service (PaaS) market came as little surprise to Java vendors and industry watchers. Amazon’s pricing strategy on the other hand will surely surprise some vendors and IT decision makers. Additionally, Amazon’s apparent lack of contributions to the Apache Tomcat project should be considered during Java PaaS selection decisions.

Betting on Java in the cloud
Amazon’s newly announced AWS Elastic Beanstalk beta cloud offering is being positioned as proof that Java is in fact alive and well. Sacha Labourey, CEO at CloudBees, a Java PaaS provider, writes: “This is great news as it reinforces the message that the future of Java is in the cloud, not on premises.” I’d adjust Labourey’s comment to read: “the future of Java is in the cloud, and on premises”.

Amazon’s Jeff Barr explains AWS Elastic Beanstalk as follows:

AWS Elastic Beanstalk will make it even easier for you to create, deploy, and operate web applications at any scale. You simply upload your code and we’ll take care of the rest. We’ll create and configure all of the AWS resources (Amazon EC2 instances, an Elastic Load Balancer, and an Auto Scaling Group) needed to run your application. Your application will be up and running on AWS within minutes.

When the de facto public cloud provider, Amazon, launches a Java-based PaaS offering, ahead of another language such as Ruby, that speaks volumes about Java’s future.

Amazon’s loss leader pricing for AWS Elastic Beanstalk
While AWS Elastic Beanstalk is seen as good news for Java, Amazon’s pricing strategy may not be welcome news for some Java vendors.

Amazon’s Barr mentions, almost in passing, “PS – I almost forgot! You can build and run Elastic Beanstalk applications at no charge beyond those for the AWS resources that you consume.”

Amazon has effectively set the price for the operating system, web server, Java runtime and application server software components of a public Java PaaS at $0.00/hr.

Aside from these software components, functionality to monitor a running environment and proactively provision and scale up and down resources to meet service level agreements would be considered key elements of a PaaS.

Amazon offers these capabilities through Amazon Elastic Load Balancing and Auto Scaling, the latter being a feature of the Amazon CloudWatch monitoring service.

Elastic Load Balancing costs $0.025 per hour per elastic load balancer, while Auto Scaling is available at no charge for an every-five-minute monitoring cycle frequency, or for $0.015 per instance hour if an every-one-minute monitoring cycle is required. When these costs are added into the picture, Amazon’s Java PaaS, excluding hardware, storage and bandwidth charges, costs as little as $0.04 per instance hour including one load balancer. Over a year, this setup would cost about $350.

Amazon’s loss leader pricing strategy poses a challenge for emerging PaaS providers to offer equivalent function at such a low price point. Emerging PaaS vendors will attempt to differentiate versus Amazon’s offering, thereby hoping to defend a higher price point for their offerings.

The price point could also impact established open source based Java providers that have grown based on a lower cost of acquisition value proposition. Enterprises drawn to these solutions for a departmental or less business critical application could become enamored with Amazon’s $350 per year price point. After years of telling IT buyers to make purchase decisions for certain projects based on acquisition cost alone, these open source vendors may have to face the stark reality of their buyers agreeing, and using Amazon’s PaaS as a negotiation tool.

Amazon taking more than it gives to open source?
What’s more troubling for customers is Amazon’s willingness to take seemingly an order of magnitude more from the open source commons than it contributes.

For instance, while relying on the adoption and brand awareness of Apache Tomcat, Amazon is not even a current sponsor of the Apache Software Foundation. Additionally, it appears Amazon is not an active contributor to the Apache Tomcat project.

Amazon is not duty bound to sponsor or contribute to Apache simply because it’s using Apache developed code. However, if Amazon’s Java PaaS is wildly successful, or even successful enough to lower the price point customers are willing to accept for a public Java PaaS, then vendors who fund Apache Tomcat development, and who must now compete with Amazon’s Java PaaS price point, will have to reconsider their investments in the Apache Tomcat project.

Declining vendor sponsored contributions to the Apache Tomcat project would be of concern to the many customers that utilize Apache Tomcat either directly or indirectly, and in a cloud environment or not. Amazon could choose to contribute resources into the Apache Tomcat project to offset declining contributions from existing vendors in the Apache Tomcat community. This would however add to Amazon’s cost structure for AWS Elastic Beanstalk, and thereby necessitate a price increase or for Amazon to accept lower profit margins.

Advice for IT decision makers
IT decision makers interested in deploying public cloud PaaS workloads should start considering Amazon’s AWS Elastic Beanstalk. However, do so while understanding that Amazon’s current pricing may not fully reflect the true costs of developing and delivering a Java PaaS to customers.  Amazon can only rely on the contributions of a community while competing with the main contributing vendors to that community for so long. Also, don’t be surprised if Java PaaS vendors, established or emerging, are unwilling to compete at Amazon’s price point, but would rather offer differentiated value.

Interesting times ahead, for IT buyers and vendors alike.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

The current situation between Oracle, the Hudson community and Hudson project founder Kohsuke Kawaguchi sheds new light on the relative value of a trademark as a project control mechanism. Understanding the balance of power in community driven project can help IT decision makers avoid vendor lock-in.

Oracle controls the Hudson trademark
Controlling an open source project’s trademark has given the controlling entity, often a vendor, significant control over the project itself. For instance, control over the project’s future direction, or even something as seemingly mundane as where the source code will be hosted.

I previously covered the unfolding story about Oracle preventing the open source Hudson project from making project infrastructure decisions that the Hudson community wanted. As owner of the Hudson trademark through the Sun Microsystems acquisition, Oracle was well within its rights to act as it has.

Hudson community sides with founder
This week, the Hudson community is being asked by project founder Kohsuke Kawaguchi and other project leaders to support their proposal of renaming the project Jenkins, thereby no longer being beholden to Oracle’s control through the Hudson trademark. Kawaguchi writes:

The central issue was that we couldn’t convince Oracle to put the trademark under a neutral party’s custody (such as Software Freedom Conservancy), to level the playing field. In a project where the community makes commits two orders of magnitude bigger than Oracle, we felt such an arrangement is necessary to ensure that meritocracy continues to function.

The response from the community, users and interested readers has been overwhelmingly supportive.

Sacha Labourey, CEO of CloudBees, where Kawaguchi now works, extended an offer for Oracle to join the newly branded Jenkins community:

What about Oracle now? They essentially have two choices. They can either keep working on their own project under the good old Hudson brand, or they can participate as an equal player in the newly branded community. Personally, I’d really like to see Oracle join forces with the rest of the community…

Sacha’s offer is important because it presents Jenkins not as a fork, but simply a rebranding.

A fork would imply that there are now, at least, two viable competing project destinations for community members to contribute to and decide amongst.

Project contributions & founder brand outweigh trademark ownership
Positioning Jenkins as a rebranding, not a fork, hinges on two important factors.

  • The trademark controlling vendor’s contributions being outweighed by the community’s contributions to the project.
  • The project’s brand remaining tightly linked to the founder’s personal brand.

Both aspects hold for the Hudson project.

Labourey states:

Well, the difference here is that Hudson has an “asymmetry” in its community: one of its community members, ORCL, claims they “own” the brand and every contributor has to sign a contributor agreement granting them a copyright license. This “asymmetry” is frequent in many projects (JBoss, Glassfish, etc.) Yet, what is less frequent is when the “owner” of such asymmetry contributes very very little IP to the project (but receives a lot of free IP from the contributors through the CLA).

While several key leaders exist at the Hudson project, few would argue that Kawaguchi’s personal brand is not intimately linked to that of Hudson, and soon Jenkins. This is especially true since Kawaguchi is involved in the day to day technical work and decisions of the project. In other projects, the founder will become less and less involved in the day to day technical direction of a project to focus on other work items, such as the business surrounding the project. In these cases, even when the founder leaves or attempts to start a competing project, the original project remains sufficiently viable as the founder’s absence is less apparent in the project’s development process.

Advice for IT decision makers
IT decision makers are encouraged to identify the control that a vendor has over an open source project, before making vendor selection decisions. Project contributions and employing key community members whose contributions are valued by the community should be valued over ownership of project trademarks during vendor selection decisions.

Even a vendor as large and established as Oracle is not immune to losing control over a community project, thereby putting customers using the project in an unenviable position of deciding between the vendor and the community.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

Pundits have predicted the growing adoption of tablets as a top 10 trend for 2011. According to Mashable, a new Forrester report estimates that 44 million tablets will be sold in 2015, surpassing even laptop sales by nearly 5 million and desktop PC sales over 25 million.

Android-based tablets are expected to capture a significant share of the overall tablet market and they’re making quite the splash at this year’s Consumer Electronics Show (CES).

If Twitter buzz is any indication, two Android tablets, the Motorola XOOM and the T-Mobile G-Slate, will be strong competitors to the iPad.

Tablets in and around the enterprise
As consumers adopt tablets for home use they will undoubtedly want to use their personal tablets to access enterprise systems from outside of the office.

Sales teams and employees that already have remote access to enterprise systems will seek to drag their personal tablets onto enterprise IT networks from outside the office.

Like me, tablet buyers seeking to use personal tablets for occasional work purposes aren’t ready to ditch their work PC or laptop. Rather, I’d like to augment my work machine with my personal tablet so I can access mail, calendar and enterprise web applications when I’m not at work and can’t be bothered turning on my laptop. I’d also like the option of carrying a tablet when travelling versus my Thinkpad or MacBook Pro. It’s important to note that while my tablet is a personal device, one which will be infrequently used for work purposes, the ability to do so did and will factor into my purchase decision.

IT will resist user requests for accessing enterprise systems from personal tablets, citing enterprise security, administration and management requirements. Device vendors will work to address these enterprise requirements, while balancing against the backlog of consumer focused requirements. And when they do, IT will, at times grudgingly, accept personal tablets onto the network.

The iPhone and iPad’s growth in the enterprise followed this trend. Android tablet adoption in the enterprise is unlikely to be significantly different.

The iPad’s enterprise lead over Android
With this history well known, it’s interesting to note how little attention is being paid to enterprise features by Google or Android device makers. This fact is especially striking considering how far ahead the iPad already is with its enterprise readiness.

Watch the Android 3.0, aka Honeycomb, preview video, the Motorola XOOM launch video or the T-Mobile G-Slate press release for even a scant mention of enterprise features.

Scour the Galaxy Tab website or support site to determine its appropriateness as a personal device with which to access enterprise systems. You’ll have to click on “Other Features” and on to “Working Remotely”. Once there, you learn about the Galaxy Tab’s Wifi and 3G connection options. That’s great.

Now, what about using a Galaxy Tab to connect to your office Cisco VPN? Or what about information for administrators? If relevant information exists on the Galaxy Tab marketing or support site, it’s not easily found.

For instance, Galaxy Tab users trying unsuccessfully to connect to a Cisco VPN discuss trying an OpenVPN client which requires the user to root their Galaxy Tab. Just imagine IT telling users to root their Android tablet in order to connect to the enterprise network – fat chance indeed.

In another example, enterprises that wish to use their own Root CA (certificate authority) chain or import an un-trusted public Root CA not in the Android OS firmware are unable to do so. This security-related feature remains an identified Android issue with a medium priority on the issues list.

The Motorola XOOM website provides no mention of enterprise readiness.

Now, head on over to the iPad Support site. Right away you’ll notice that “Enterprise” is a support topic listed on the left-hand navigation menu. From here, consumers and IT workers can learn about topics such as ActiveSync configuration, enterprise networking, deployment and security.

Android tablets ignore the enterprise at their peril
InfoWorld colleague Ted Samson recently wrote about Apple formally declaring its enterprise intentions. Samson writes:

But now Apple has apparently come out of the enterprise closet: The company today pushed out a promotional email, entitled “Mac in the Enterprise,” that is chockfull of information for large businesses on how to integrate Macs, iPhones, and iPads into their IT ecosystems.

The simple and effective manner in which Apple is communicating the iPad’s business-readiness, if even for occasional usage, deserves not just kudos, it begs for imitation from Android device makers.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”