May 2010


Google’s WebM, an open and royalty-free media format based on the VP8 video codec, was amongst the highlights coming out of Google I/O 2010.  After examining the software license, open source pundits questioned whether WebM should, in theory, be classified open source software. The larger question is why Google allowed this debate to occur in the first place, and what it means for your organization when evaluating an “open source product”.

Google has positioned WebM as an open alternative to the popular H.264 video codec.  Browser vendors from Microsoft, Mozilla, Opera, Adobe and of course Google have signaled support for WebM based on the open nature of WebM.  The royalty free angle surely helped in this decision.  As would be expected of an open source project, Google released the source code to WebM.

Open source in theory or practice?
Google did not however utilize an Open Source Initiative (OSI) approved license for WebM. As such, in theory, WebM could not be considered open source software under the open source definition (OSD). ComputerWorld UK columnist and OSI board member Simon Phipps writes:

“Many government and business policies around the world point to OSI when defining what is acceptable as “open source”. The OSD remains the “gold standard” and we all have much to lose if it is subverted.”

The WebM FAQ explains Google desire to utilize a standard BSD or Apache license, but deciding to utilize a BSD-based license in order to meet Google’s needs:

“The Apache license is somewhat similar in effect to this license. The main reason it was not used is that filing patent litigation against someone using the Apache 2 license only terminates patent rights granted under the license. Whoever filed the litigation would still be able to use the software they are suing over and still be in compliance with the license. This license, however, terminates all rights when patent litigation is filed. Rather than modify the Apache license to meet our needs, which would probably lead to significant confusion, we went with the simpler approach of a BSD style license + patent provision.”

Bruce Perens, author of The Cathedral & Bazaar, decided to submit the WebM license to the OSI for review and approval as he wishes to create a derivate work based on it.

Google’s Open Source Programs Manager, Chris DiBona, responded asking the OSI to delay a review of WebM. Dibona wrote:

“Please hold off on submitting this while we determine certain compatibility issues internally at google….I would also point out that we’re uncomfortable with making license proliferation worse and in the event we do submit it, we will want a couple of changes to how OSI does licenses.

1) We will want a label explicitly deterring the use of the license.
2) We will want the bod (board of directors) list archives open for any discussions of webm. We are not comfortable with OSI being closed.
3) We need to know OSI’s current corporate status…..”

Responses to DiBona quickly addressed Google’s three requirements as being non issues.

Suppose for a minute that Microsoft has followed Google’s approach with WebM licensing, and further, required the OSI agree to “changes to how OSI does licenses” as a precursor to submitting a license for OSI review and approval.  Microsoft would have been lynched by virtually every open source pundit.

Google is treated quite differently by open source pundits because Google contributes much to open source projects and generally tries to release source code under an OSI-approved license whenever possible – namely, when it suits Google’s business needs.

Wither the “open source” brand?
There is however a larger issue at hand.  As open source becomes mainstream, vendors are under pressure to market their offerings using the “open source” brand to the highest degree possible without misleading customers.

For better or worse, an OSI-approved license has become the de facto requirement for vendors calling themselves or their products “open source”.  When Google, one of the largest supporters of open source, goes out and purposefully circumvents the OSI, what signal does this send to other vendors?  How important is using an OSI-approved license likely to be in the future if other vendors follow Google’s lead?

If using an OSI-approved license no longer becomes the precursor to utilizing the “open source” brand, enterprises, or more importantly, developers who often make the initial decision to use an open source product, risk using purported open source software which may be at odds with the enterprise’s legal policies.

I completely understand that Google felt it’s business needs were not met using an existing OSI-approved license – even if some suggest otherwise.  I also understand why Google would want to limit its patent offer in the WebM license to any user until that user decides to sue another user for patent infringement related to WebM usage.  Google has every right to make business decisions and utilize a license closely aligned with those decisions. However, Google, for all its open source credibility, should be expected to work with, not around, established open source processes.  If the process is broken, help fix it, not make it worse.

Going forward, it becomes even more critical for you to validate that software carrying the “open source” marketing badge aligns with your expectations.

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

VMware and Google recently announced a partnership to enable Java applications based on the open source Spring framework to run in Google App Engine for Java (GAE/J). Does this mean enterprises should reconsider GAE/J as a deployment environment for certain Java applications?

Enterprise Java credibility
It’s fairly easy to conclude that Google has lacked credibility within the enterprise Java cohort prior to the VMware partnership. For instance, the GAE/J Google Groups forum had a grand total of 4,962 members as of this writing. Considering the millions of Java developers in the world, five thousand or so interested in GAE/J is a rounding error at best. While Google is a strong supporter of open source, and open web standards, Google has chosen to take a less than pure route when it comes to Java standards. This is true with the open source Android platform, where applications are written in Java but don’t compile to Java bytecode; causing consternations to the “write once, run anywhere” Java marketing proposition. It’s also true for GAE/J where Google has decided to support only a subset of Java Enterprise Edition (Java EE) specifications. I don’t know of too many enterprise Java decision makers who want to check a “Will it Play in App Engine” page to see if a Java specification or framework their company relies on will work in GAE/J. This clearly has played a role in the relative lack of attention that GAE/J has received from enterprise Java shops.

VMware lends Google enterprise Java credibility
Will VMware & Google’s new partnership addresses enterprise Java user concerns surrounding GAE/J? The overwhelming coverage of the announcement seems to suggest that VMware’s SpringSource division does lend Google credibility with enterprise Java developers, administrators and decision makers.

Readers familiar with the enterprise Java market will recognize SpringSource as the founders of the open source Spring Framework and other Spring-related open source projects. The non-standard Spring Framework is developed in the open by VMware/SpringSource. The Apache 2.0 license associated with the Spring Framework has proved historically sufficient to set aside fears of application lock-in to a non-standard framework. In many ways, the Spring Framework has become a de facto standard which competes against the open standards-based Java EE platform. It’s this “de facto” nature of the Spring Framework that Google appears to have been drawn to.  Although, the open source nature of Spring likely played a role as key parts of GAE/J are based on open source projects.

Forrester analyst Jeffrey Hammond writes:

“VMWare gives Google a significant boost in enterprise developer permission. While Google is the darling of developers outside the firewall, they still struggle inside the firewall. The reality is that enterprise IT development shops are just different than Web startups or Web giants. And enterprise Java development is something that the Spring folk understand. While I question the magnitude of the adoption percentages that SpringSource GM Rod Johnson quoted yesterday, our own research with Dr. Dobbs and Eclipse developers confirms that Spring is indeed one of the most popular frameworks among Java developers at large shops (with a fair amount of Apache Struts and homegrown frameworks as alternatives).”

Open versus de facto standards
For this discussion, one has to consider whether “de facto” of Spring will be enough to get enterprises over the sparsely supported standards on GAE/J.

On one hand, Spring’s “de facto” nature adds to GAE/J’s issues. Like GAE/J, Spring is not Java standards compliant. One can clearly argue that a lack of open standards compliance hasn’t affected Spring’s adoption. However, history and the future are seldom related. I recall sharing with SpringSource CEO Rod Johnson a tweet to the effect:

“Enterprises didn’t much care about lock-in to the non-standard Spring portfolio when it was from SpringSource a small, friendly, company. Now that it’s coming from VMware, a large enterprise software vendor with well established profit motivations, it would be wise to get behind a relevant Java spec, like Java EE 6 Web Profile.”

Over the past nine months, and as recently as a WebSphere conference two weeks ago, I’ve heard of large enterprises using Spring that are planning on migrating to open standards. As predicted, being open source is no longer enough to alleviate fears of lock-in now that VMware is part of the discussion. To be clear, I am in no way suggesting Spring usage in the enterprise is not going to decline by half overnight or anything ludicrous like that. However, enterprises are starting to consider their future freedom of action with applications locked into a framework controlled solely by one of the largest software vendors on the planet.

The CIO is the last to know
On the other end of the spectrum is a quote from my friend James Governor of Redmonk is ringing in my head: “CIOs are often the last to know”. James’ would argue, and I’d agree, that developers selected the Spring Framework, standards be damned, well before their managers or CIOs knew or had a say. Some subset of these developers are likely to try deploying their Spring applications on GAE/J simply to see what works and what doesn’t. Of these developers, some will be able to convince their management that GAE/J represents a lower cost deployment environment than the traditional data center for Java applications. The application’s business criticality, and more importantly, the sensitivity of data required or generated by the application will have an impact on whether an enterprise IT decision maker will approve a GAE/J deployment. Using GAE/J for development and testing, with the actual production deployment not on GAE/J, is another potential use case for Spring with GAE/J. For its part, VMware is positioning the Spring Framework as a path towards portable Java in “any” cloud platform.

Where does your company fit on the de facto versus open standards spectrum? Will you give GAE/J another look now that Spring applications are supported?

Follow me on twitter at: SavioRodrigues

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

Alfresco, SpringSource, Signavio and Camunda have launched an open source project under the permissive Apache 2.0 license, spawned mainly by prospective Alfresco OEM partners’ weariness of LGPL software.

Alfresco announced the Activiti Business Process Management initiative which the sponsoring vendors hope will become a top line project at the Apache Software Foundation.

A few months ago when Alfresco announced a shift in licensing of Alfresco Community to the LGPL, Alfresco CTO, John Newton, wrote:

“We have considered more liberal licenses as well, but we currently have two main LGPL components – Hibernate for database access and JBPM for workflow – which prevent us from going to something like Apache or BSD licenses. However, this is something we may consider changing in the future.”

It seems Alfresco is attempting to address the LGPL components within its product with an eye on shifting to a permissive license such as the Apache 2.0 license.  To that end, Newton writes:

“Activiti emerged from our desire to have an Apache-licensed BPM engine. Although we were quite happy with the (RedHat JBoss) jBPM engine, it’s LGPL license was preventing us from OEMing Alfresco to larger software companies that were concerned about any open source license with the letter G in it. It’s irrelevant that they shouldn’t be concerned about it…”

Newton alludes to Red Hat’s unwillingness to change the jBPM license from LGPL to something more permissive.

“It’s understandable that RedHat did not want to change its license, but our business needs dictated that we needed to find an alternative.”

Red Hat’s reluctance to change the jBPM product license could be due to jBPM components from third parties whose license Red Hat would not be able to change.

It’s interesting to note that Hibernate, the other LGPL component used by Alfresco, is also owned by Red Hat.  It stands to reason that Alfresco will move to an Apache 2.0 licensed alternative to Hibernate such as Apache OpenJPA.

As Newton states, one can definitely understand Red Hat’s reluctance to change the license.  However, one has to wonder if Red Hat could expand the applicability of its middleware portfolio with a more permissive license.  On one hand, the JBoss Application Server, an LGPL licensed product, has garnered strong downloads and continues to grow revenue at a faster pace than Red Hat’s Linux business.  It would seem that the LGPL hasn’t been a hindrance to JBoss Application Server adoption.  On the other hand, as Newton points out, some ISVs, and as I’ve heard, some customers, remain concerned about viral licenses.  While the LGPL was created to specifically address the viral nature of the GPL, some ISVs and customers remain weary.

In Alfresco’s case, the business need for a permissive licensed BPM component was so high that they’re willing to make Activiti 1.0 the default BPM engine for Alfresco by the end of 2010, displacing a more mature 4.x jBPM product.  While a 1.0 release isn’t always bad, most people in the software industry will argue that product quality and functionality improves with releases.  In an interesting twist, the original project founders of jBPM who left Red Hat two months ago have joined Alfresco to design and develop Activiti.  It’s unclear whether the license terms for jBPM played any role in their departure from Red Hat.  It is however important to note that Activiti wouldn’t be getting the attention it is if not for Alfresco’s backing.  And Alfresco wouldn’t be backing Activiti if jBPM were available under a permissive license.

Does the LGPL provide your company sufficient freedoms or is a more permissive license a requirement before making open source selection decisions?

Follow me on twitter at: SavioRodrigues

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

Open source has been promoted as, amongst other things, a means of minimizing vendor lock-in.  However, it’s unclear that this value proposition holds when utilizing software as a service (SaaS) or platform as a service (PaaS) in the cloud.

Open source helps, but isn’t sufficient to provide future freedom of action
Access to a product’s source code can increase the freedom of customer choice and minimize the risk of vendor lock-in.  Conventional open source wisdom suggests that the risk of forking an open source project, or simply shifting from paying customer of commercial open source product to a free user of the related open source code are two important risks that keep open source vendor motivations in check.  This is theoretically true. However, unless the open source project has a strong community of third party developers, a fork isn’t a credible option.  Additionally, finding third party support isn’t always easy, nor the best long term approach.  It may be easier to migrate to an alternative product with a roadmap and community support that your enterprise can rely on.

I’ve argued that open standards have a much larger impact on minimizing vendor lock-in than open source alone.  For instance, reducing the risk of vendor lock-in through open standards, implemented by a plurality of vendors, regardless of the product’s source code availability, has been a major driver of Java EE adoption.

Open APIs protect future freedom of action
Earlier this week @swardley tweeted:

“Looking for a good speaker to argue that “Open APIs are enough to prevent lock-in”. MSFT bailed on me. Recommendations welcomed.”

I tend not to like discussions that paint the world as black and white, which is why I responded that open APIs matter a lot more than open source in cloud deployments.  Relying solely on open source to minimize lock-in within a SaaS or PaaS cloud deployment is just asking for trouble.  The very same reasons that open source doesn’t protect against vendor lock-in to the degree proponents would hope apply to SaaS or PaaS offerings based on open source as they do to open source products deployed in one’s data center.

On the other hand, if application relies on an open API that has been implemented by another vendor, you now have the hope of moving your application elsewhere.  The distinction between an open API and an open API that has been implemented by another vendor delineates between theoretical and actual freedom of action.  Whenever possible, always put more weight on actual freedom of action when making purchasing decisions.

Open source vs. open APIs, a test case
A few weeks ago Salesforce.com and VMware jointly announced VMforce, a PaaS for Java developers.  It’s interesting to note that the VMforce marketing highlighted two seemingly conflicting value propositions.  First, Java developers could build richer applications by leveraging the salesforce.com APIs that are already available on Force.com.  Second, companies could expect application portability from Force.com infrastructure to other cloud environments.  The portability claim is based on the fact that VMforce applications will run on the Spring Framework on tc Server, two Java open source offerings.  The Spring Framework is well known to run on multiple application servers.  tc Server is essentially Tomcat, which has also been shown running in various environments, including Microsoft’s Azure cloud.

In essence, VMforce offers a PaaS with a set of proprietary APIs and an open source runtime platform.  As such, VMforce is a great test of whether “OSS is enough to minimize vendor lock-in in the cloud”.  The blunt answer is, no, it is not.  Any applications that want to leverage the Salesforce.com APIs, which, frankly are interesting and could help deliver richer user experiences, are tied to one and only one cloud infrastructure, Force.com from Salesforce.com.  This will remain true until a third party implementation of the Salesforce.com APIs is available – when these APIs become open and implemented.  This is true even while the underlying application server platform is open source and is portable to other cloud environments.

As your company begins making SaaS and PaaS cloud selections, remember to ask whether APIs provided are open and which third party have implemented the APIs in question.  Think of open APIs as you do about open standards today; necessary purchasing criteria when seeking to minimize vendor lock-in.  Think of open source in the cloud as you do in your data center, a contributor to future freedom of action, but not sufficient to guarantee it.

Follow me on twitter at: SavioRodrigues

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

Enterprises are still in the early days of mobile application development. The growing evidence suggests enterprises should focus time and resources on cross-mobile-device applications.

Choosing amongst the many mobile platforms:
There’s no doubt that building native mobile applications, targeted at and leveraging the native device capabilities can produce very compelling user experiences. However, the question invariably boils down to which mobile platform should your enterprise build mobile application for?

The iPhone OS is definitely a leading contender. There’s an argument to be made for growing adoption of iPhone OS devices as Morgan Stanley suggests that the iPAD is cannibalizing the netbook market.

Android which now accounts for nearly half of U.S. mobile web traffic. However, it’s interesting to note that Motorola, a key Android partner and device manufacturer is rumored to have acquired a mobile OS company, Azingo. What’s more, Motorola Co-CEO, Sanjay Jha is quoted:

“I’ve always felt that owning your OS is important, provided you have an ecosystem, you have all the services and you have an ability and the scale to execute on keeping that OS at the leading edge. And I continue to believe that at some point, if we have all of those attributes, that owning our own OS will be a very important thing.”

HP, fresh off its Plam acquisition, plans to further invest in PalmOS and develop new tablets using the platform.

RIM is now planning to release its own tablet based on the BlackBerry OS, most likely version 6, to target the consumer market. This makes sense for RIM as they have many of the ecosystem and scale capabilities that Motorola’s Sanjay Jha deems a requirement for owing an OS.

We shouldn’t forget that Nokia is betting on Symbian and Microsoft continues to bet on the Windows OS mobile for mobile phones and potential future tablet devices.

Infinite requirements with finite IT budgets:
Given infinite time and resources, enterprises could target a few or all of these platforms with native applications. And therein lies the huge challenge IT departments and their line of business peers face. Today, the vast majority of enterprises building traditional web applications build and test for one to three PC-based browsers. These enterprises simply don’t have the resources to build native device applications for even two of the leading mobile platforms in addition to the traditional PC-based application. This is the overarching message I’ve heard when talking to customers about their mobile application plans and challenges.

Following early adopters isn’t always helpful:
It’s important not to base mobile application development decisions of early adopter companies. Many of the best known enterprise mobile applications, especially for the iPhone, have been built using the device’s SDK. This is to be expected as early adopters experiment with user experiences and getting out ahead of the competition. But over time, these businesses are bounded by the same IT economics as other companies. As your user base shifts from PC-based browsers to PC-based browsers and varying mobile devices, the need to targets these range of devices requires a build once, test often approach or a larger IT budget. The latter is unlikely to occur, especially over the long run. As such, the best approach is to build cross device applications. As countless others have stated, the mobile experience will be dominated by HTML5, CSS3 and JavaScript. Even Adobe has pledged to deliver first class HTML5 tools.

Of course the challenge of building open web standards compliant applications using HTML5, CSS3 and JavaScript alone is that these applications don’t get to take advantage of native device capabilities, like GPS or the accelerometer. This is where open source frameworks from PhoneGap, Rhomobile, Appcelerator and the like come in. These frameworks allow companies to build cross device applications while also taking advantage of some of the more common native device capabilities, again, like accelerometer or GPS. There are obviously considerations about application lock-in to the framework itself versus building against open web standards.  If this is a concern for your business, ensure that the open source license and the community around the open source framework meets your requirements for flexibility and future freedom of action.

Are you building native mobile applications today, and more importantly do you expect to in two or five years?

Follow me on twitter at: SavioRodrigues

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