August 2010


Contrary to popular rumors, Red Hat’s recent webcast was not to announce an imminent acquisition. Red Hat instead laid out an ambitious cloud strategy, going as far as claiming that only Microsoft and Red Hat are positioned to deliver an end-to-end cloud stack. However, the most important announcement from Red Hat may well be overshadowed by its comparison versus Microsoft Azure or its PaaS plans.

Here’s why IT decision makers shouldn’t ignore Red Hat’s submission of the cloud neutral Deltacloud cloud API to the Distributed Management Task Force (DMTF) and Apache Software Foundation.

Deltacloud sputtered under a single vendor’s control
Deltacloud was announced nearly a year ago at the 2009 Red Hat summit. Brian Stevens, CTO and VP, Engineering at Red Hat described Deltacloud’s goal:

The goal is simple. To enable an ecosystem of developers, tools, scripts, and applications which can interoperate across the public and private clouds.

Today each infrastructure-as-a-service cloud presents a unique API that developers and ISVs need to write to in order to consume the cloud service. The Deltacloud effort is creating a common, REST-based API, such that developers can write once and manage anywhere.

A cloud broker if you will, with drivers that map the API to both public clouds like EC2, and private virtualized clouds based on VMware and Red Hat Enterprise Linux with integrated KVM.

Red Hat’s approach was simple and seemingly appealing enough. Write to the Deltacloud APIs and your workloads can be ported across any cloud provider’s infrastructure that Deltacloud is able to interoperate with. However, the prospects of trading cloud provider API lock-in for Red Hat API lock-in wasn’t an appealing prospect for potential Deltacloud adopters. Whether “The World’s Open Source Leader”, as Red Hat bills itself, or not, lock-in is lock-in.

Choosing open standards & open source for Deltacloud
Red Hat wisely decided to contribute their Deltacloud API implementation to an independent third party, the Apache Software Foundation. By moving the implementation to an Apache Incubator project earlier this summer, the Deltacloud project is no longer saddled with the chains of a single vendor controlled open source project. This in turn has made it easier for multiple vendors to consider adopting and contributing to the Deltacloud project.

Red Hat appears to be following the standardization through implementation approach, and has submitted the Deltacloud API specifications to DMTF cloud standards body.

Regardless of how successful Red Hat’s cloud and PaaS business results are, they will likely pale in comparison to the customer value enabled should Deltacloud become a widely adopted industry standard.  By leveling the cloud workload portability playing field, Red Hat is enabling other vendors to compete based on the quality and completeness of their PaaS offering rather than portability itself.

It’s encouraging to see that Deltacloud already allows a high level of portability across six different cloud providers, with support for two more providers on the way.

Bryan Che, Red Hat cloud product manager, explained the Deltacloud announcement:

We do not want Deltacloud to be under the control of any one particular vendor, including Red Hat. If you want true interoperability and true portability, you need a third-party governance structure.

On the other end of the spectrum are vendors such as Eucalyptus that have decided to adopt Amazon EC2’s APIs. Marten Mickos, Eucalyptus CEO explains:

We believe the Amazon API is becoming the industry standard, and that many companies will follow it.

Choosing defacto standards vs. open standards
Deltacloud’s success as the standard for controlling cloud operations is far from guaranteed. In the same token, Amazon’s EC2 API remaining the defacto standard is not guaranteed as cloud usage shifts from early adopters to the mainstream enterprise market. Enterprises have been increasingly educated to demand open standards for which multiple implementations exist. IT decision makers must weigh the short term benefit of adopting a cloud specific API, such as Amazon’s EC2 API, versus the long term benefit of a cloud agnostic API such as Deltacloud.

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.”

By now you’ve read that Oracle has sued Google for patent and copyright infringement related to the Android platform. Google has responded that the claims are baseless and counter to the open source community movement. The press, pundits, Oracle and Google seem to have ignored the Java Enterprise Edition (Java EE) impact of Oracle’s suit. Here’s why IT decision makers shouldn’t ignore the Java EE impact.

Oracle’s Java ME revenue stream
InfoWorld’s Neil McAllister summarizes the Oracle v. Google legal situation nicely:

At issue is Dalvik, the unique, Java-based runtime at the heart of Google’s Android smartphone OS. Oracle, which gained stewardship of the Java platform when it bought Sun Microsystems in 2009, claims Dalvik knowingly, willfully, and deliberately infringes on Java intellectual property. According to a complaint filed with the U.S. District Court in San Francisco last week, Oracle is seeking a halt to any further Android development, destruction of all infringing Android software, and for Google to pay damages, both actual and statutory.

Tim Anderson’s post asks an interesting question: “Apple, not Android is killing client-side Java – so why is Oracle suing Google?”

The simple answer is Java licensing.

With Google claiming 200,000 Android device activations daily, it’s plausible, as IDC and others have suggested, that Oracle is simply trying to get a piece of the Android revenue stream. Android is surely limiting the revenue potential from licensing Java Micro Edition (Java ME) to device manufacturers.

While Oracle does not split out its Java licensing revenue, and neither did Sun for that matter, Peter Goldmacher, an analyst at Cowen and Co., estimates the figure to be $250 million annually. This figure includes revenue from licensing the multiple editions of Java, from Java ME to Java Standard Edition (Java SE) to Java EE. It’s pretty obvious that a $250 million revenue stream is worth protecting, and attempting to grow.

Google’s threat to Oracle’s Java EE control
I’d propose a more complex, less clear, answer to the question “Why is Oracle suing Google?” – because Oracle wants a tighter reign over Java EE. Why? Revenue potential of course. I’d hazard a guess that a non-insignificant piece of the $250 million Java licensing revenue estimate is driven by Java EE licensing. With mobile and cloud being two major investment areas for vendors and enterprises, Oracle likely wants to see a growing use of compliant Java usage – via appropriate licensing through Oracle – in the mobile and cloud arenas.

Enterprises have invested billions in Java EE technology over the past decade based on the value of open standards and multiple implementations of those standards. The ability to migrate amongst Java EE vendors has helped minimize fears of vendor lock-in.

However, Java EE’s portability value proposition has come under scrutiny from the likes of Google App Engine (GAE) and VMforce from VMware and Salesforce.com. Google clearly states that only a subset of Java EE APIs are supported on GAE. VMforce claims to offer a set of APIs that are only available through Salesforce.com. The fact that both platforms are cloud based, and that both platforms are not Java EE compliant likely hasn’t gone unnoticed by Oracle. The cloud appears to be, or at least have a potential of being, an environment where customers are willing to trade productivity and TCO for the higher degree of vendor lock-in associated with a cloud platform as a service.

Oracle’s Java EE licensing would be negatively impacted if vendor lock-in becomes a lower priority for enterprises, thereby minimizing the need for vendors to claim “Java EE Compatibility”.

Additionally, Microsoft, a non Java ecosystem vendor, has been dipping its toes in the Java ecosystem. For instance, Tomcat applications can now be deployed on Azure. It shouldn’t surprise anyone if Microsoft were to deliver an optimized Tomcat or Java EE experience on Azure in the future. If and when this occurs, Oracle would surely like to be involved, from an associated licensing standpoint.

What’s next for Java?
Some have questioned what this suit means to the future of Java. For instance, Redmonk’s Stephen O’Grady makes a prediction as to the outcome of Oracle v. Google:

…whoever wins will also lose. This suit is going to negatively impact – probably substantially – Java adoption. The enterprise technology landscape is more fragmented by the day, as it transitions from .NET or Java orthodoxy to multi-language heterogeneity.

To a degree, this isn’t new news. Sun had been planning for the day where multiple programming languages are able to run alongside the Java language on the Java Virtual Machine (JVM). Higher up the Java stack, Java EE vendors have been attempting to support popular Java-based programming models such as OSGi, and scripting languages such as PHP and Groovy, within their Java EE products. As Stephen points out, the days of “Java” being the answer to every project are long gone. The ability to select the programming language and programming model best aligned wit the project at hand is quickly becoming a differentiator in the Java EE market.

While the Oracle v. Google suit is a distraction, and potentially a concern from the Java vendor ecosystem, the future of Java, the platform, is and has been, much broader than the actions of its controlling entity, Sun or Oracle.

Continue to choose open standards and multiple implementations
Whatever the resolution, and however long it takes, IT decision makers would be wise to minimize risk by selecting offerings that support open standards for which multiple implementations exist. This is timeless advice and worth repeating, especially as customers consider cloud platform investments.

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.”

Forrester analyst Jeffrey Hammond’s [1] LinuxCon keynote [2] kicked off with the announcement that open source had crossed the IT adoption chasm. Hammond’s data, drawn from five Forrester, Eclipse and Dr. Dobbs surveys over the past two years, showed nearly 80 percent of organizations are using open source software in IT development projects. The survey results also found that IT executives were much more pragmatic about increasing open source usage and that software developers are increasingly important to product selection decisions.

Expanding open source usage isn’t a top priority
When IT executives were asked “how important are each of the following business goals to your internal IT organization when making software decisions?”, they rated “Increase the use of OSS” as follows:

Forrester survey results

Interestingly, 47 percent of IT decision makers selected a “1” or “2” in 2009, implying that expanding the usage of open source is not a business goal for their organization when making software decisions. This is a full 10 percent higher than IT executives that selected a “1” or “2” to the similar question in 2008.

On the other end of the spectrum, only 8 percent of 2009 respondents, down from 9 percent in 2008, stated at expanding open source usage was a very important business goal when making a software selection decision.

Keep in mind that the survey question states “when making software decisions”. As such, an IT organization could consider the expanded usage of open source as a non factor during software selection, and yet select an open source product for a given project based on the product’s characteristics beyond simply being open source. The converse is true from respondents that selected “very important” as their response – they may very well select a closed source product based on project needs.

The survey results indicate that the vast majority of IT decision makers select software based on its ability to meet their business requirements, not whether the product is open source or not. And yet, the minority, who have either decided to reject closed source software or open source software, get the most attention in today’s IT folklore.

The results are very much in line with customers I’ve interacted with, or whose stories I’ve been told by colleagues on the IBM WebSphere sales team. Even as little as a year ago, customers were much more likely to state “we’re moving everything to open source” or “we’ll never touch an open source product”. Today, it’s common to utilize a mixture of open source and closed source products.

If your company is in the minority that has rejected either open source or closed source software in its selection processes, you must ask why your competitors are making a different decision.

Developers the new king makers?
Another key finding from Hammond is that the software decision making process is tipping towards developers, away from IT executives. Hammond states:

More than ever: Developers can block – or significantly aid the adoption of software!

Developers are much more willing to recommend products that they are already productive with. This has been a boon for open source products which are free for developers to use and gain experience with. It’s no surprise that traditional software vendors now offer developer editions of their respective software at no charge, in order to match their open source competition.

Hammond goes on to explain that IT executives are beginning to reassert control over the software selection process. As such, Hammond provides the following advice for software vendors:

To win you must drive adoption and affirmation through developers, and purchases through management

This will be an interesting power struggle to watch play out across IT department. It’s important to again recall the lack of importance that IT executives put into “increasing open source usage” as a business goal. Software vendors, open source or not, that meet the needs of developers and other key stakeholders, such as the operations teams and administrators, while integrating well with existing infrastructure have an opportunity to secure the IT executive’s selection vote.

Who holds the balance of power in the software selection process at your company?

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

SAP, arguably one of the remaining enterprise software vendors to accept and use open source within its products, made news by announcing a broader open source strategy. More importantly, SAP explained how they planned for the greater acceptance of open source components within their projects. Enterprise IT decision makers can learn from SAP’s progress along the open source adoption cycle.

Risk, a four letter word in IT
As IDG’s Joab Jackson reports, SAP faced two key related hurdles while attempting to grow its usage of open source components within their products – executive acceptance and developer education. Not surprisingly, these very same issues were also highlighted in a newly released Accenture survey of open source adoption amongst 300 US and UK companies with over $500 million in yearly revenue. Accenture explains:

Despite a very encouraging picture, some organizations still remain hesitant. The biggest challenge, mentioned by 35 percent of all companies, is still around training developers how to use open source. Furthermore, lack of senior management support appears to be a key reason given for not using open source software among organizations that have looked at it but ultimately chosen not to use it.

IBM’s Bob Sutor, VP of Open Source and Linux, recently detailed ten questions he is frequently asked by customers considering open source. Here are a few of key questions Bob typically faces:

  • Of the hundreds of thousands of open source projects, how do I tell which are the good or bad ones?
  • I need a 5 to 10 year plan for installing enterprise software. Which open source projects and companies can I count on to GUARANTEE support for the software for that long?
  • How do I avoid making a really bad, possibly job-ending, mistake when moving to open source software?
  • Will I have legal or license problems if I use open source projects?

Bob tends to speak with C-level executives and IT decision makers. These audiences are often very concerned about risk mitigation and want to ensure that open source decisions do not add undue risk to the enterprise.

OSS approval processes mitigate risk
Training developers to appropriately utilize approved open source projects and products within an enterprise software project helps address executive and decision maker concerns surrounding open source adoption. This is true whether the software project will only ever be utilized internally or could potentially be made public.

According to Jackson’s report, SAP has standardized a process for managing which open source software is approved for use by SAP’s internal developers. Jackson writes:

Using a program called Code Center, offered by Black Duck Software as part of its Black Duck Suite, von Riegen’s office runs a companywide registry of which open source applications have already been approved by SAP for use within its products. It also specifies which versions of these applications have been approved, which streamlines the maintenance process for the company.

SAP’s open source approval process follows similar processes in place at software vendors such as IBM, Oracle and Microsoft and enterprises alike.

The process begins by identifying which open source projects and products are already in use within the enterprise development process. Think it’s odd to scan for open source usage before a usage policy is in place? Think again – the open source folklore is laden with stories of IT managers stating “we don’t use any open source” and one of his developers piping in to correct them.

Second, more than likely with the help of your legal team, identify the licenses and project governance approaches that your company deems in line with your adoption of the related open source project.

The first two steps will result in a list of approved open source projects that your developers can utilize within their application development efforts.

Finally, determine which open source projects identified above are projects your company would be willing to let developers contribute into. Most enterprises don’t contribute to open source projects even while their usage of open source continues to expand. According to data from Accenture’s survey, only 23 percent of respondents expected to contribute to an open source project. However, being able to contribute into an open source project as part of a developer’s day job is increasingly and attractive recruitment tool. As such, I wouldn’t be surprised if enterprise open source contribution were to accelerate. It’s important to start thinking about which projects could make the shortlist of projects your company’s developers are able to contribute to.

Usage of products such as Black Duck’s Code Center or OpenLogic’s Deep Discovery Scanning Solution is growing within enterprises. For instance, OpenLogic announced a 97 percent increase in quarterly year to year revenue since adding the OSS Deep Discovery Scanning tool to its product mix. The growing use of these tools points to a growing understanding that open source adoption must be planned and managed, as is the case with any technology adoption decision.

Does your company have a formal open source adoption process? Why not?

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.”