March 2011

Much has been written about the importance of foundations versus single vendor controlled open source projects. Yet, there’s been too little focus on the gradual shift that often occurs between these two ends of the open source project spectrum. The OpenStack project is being asked to accelerate its transition into a foundation-led project, maybe a little too soon.

Rackspace struggles with control versus influence
The OpenStack open source project that aims to deliver “a massively scalable cloud operating system”. OpenStack was launched with great fanfare 8 months ago, with claims of over 50 organizations, including Rackspace, NASA, Dell, Cisco and Canonical, participating in the project.

However, Rick Clark, a Rackspace lead on the OpenStack project, raised some eyebrows when he announced his departure from Rackspace to join Cisco. Clark has many good things to say about Rackspace and the OpenStack project itself, but felt that the Cisco opportunity was too good to pass up. However, he goes on to explain a degree of frustration with the way the OpenStack is being managed.

Clark states his view “that Rackspace is trying to control OpenStack rather than influence it.” Clark provides some examples of Rackspace making decisions that impact the OpenStack project behind closed doors. And while Clark doesn’t necessarily disagree with the end result of these Rackspace decisions, his concern centers on the fact that Rackspace has the ability to make these decisions without community input in the first place. While Rackspace is doing right by the OpenStack project today, Clark asks, “What happens if Rackspace is under new management, say Oracle, for example?”

Clark’s proposes that Rackspace put the OpenStack project under the control of an open source foundation. Rackspace would lose control over the project, but would more than likely retain its influence considering the amount of code and ongoing investment Rackspace would bring to the community.

The notion of influence versus control has been previously discussed by Simon Phipps, ex-chief open source officer at Sun. Simon writes:

In my experience, attempting to retain control of a project you’re starting or hosting leads to mistrust, contention and a rules-based focus that diminishes your reputation. Relaxing control will lead to the community innovating and growing in ways you’ve not anticipated, as well as enhancing your reputation. As I’ve frequently said (although less frequently been heeded): trade control for influence, because in a meshed society control gets marginalized while influence delivers success.

It’s interesting to note that Simon admits that his advice isn’t always easy for vendors to follow. Even Sun, during Simon’s time as chief open source officer, frequently opted for control over influence. This was especially true in the early stages of an open source project led by Sun.

Transferring control to a foundation, when the time is right
Like many, I’m a supporter of open source foundations. However, one must consider where the project is in its lifecycle before arguing that its prospects would be brighter within a foundation than elsewhere.

In some cases, the success of an open source project is un-related to whether a single vendor or a multitude of vendors control the project. Projects such as MySQL and Spring fall into this category.

In other cases, a foundation is the right place for an open source project, but when the project control is handed over to a foundation is an important question. For instance, control of Drupal was not handed over to the Drupal Foundation until five years after its founding. As another example, control of WordPress didn’t move to a foundation for nearly seven years after the project began.

The pressure for Rackspace to cede control over OpenStack to a foundation appears to be premature. Dell’s Rob Hirschfeld, an OpenStack community member, writes

While companies like Dell (my employer), NTT, Citrix, Cisco (Rick’s employer), and Microsoft are clearly investing in OpenStack, none have yet achieved NASA or Rackspace’s level of technical commitment.

The challenge for Rackspace is to expand the OpenStack market and ecosystem so that partners are motivated to jump in more and more quickly. If my experiences inside Dell are indicative of the broader community, Rackspace’s leadership makes it much easier for partners to increase their own commitment. Like teaching my daughter to ride her bike, she needed to know that I was running next to her before she would pedal hard enough to balance by herself.

Few open source projects succeed in attracting third party vendor contributions if the project doesn’t appear to be evolving at a rapid enough pace. Third party vendors want to know that they’re contributing to a project that will eventually, if not already, become the leading project in the particular product category.  Who controls the community is an important, but second order question for third party vendors considering contributions.

Rackspace should be afforded the time to grow the feature/function competitiveness of OpenStack and the quantity of third party contributions before being prematurely forced down the path towards a foundation.

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

Recent changes to how Red Hat makes source code to Red Hat Enterprise Linux (RHEL) available have raised the ire of some within Linux and GPLv2 circles. However, the changes are intended to help Red Hat compete more effectively in the enterprise Linux market, which is ultimately good for customers and the Linux community. Find out how the changes may impact your company’s use of Linux.

Increased RHEL copycats compelled Red Hat to action
Since RHEL 6 was released nearly 4 months ago, Red Hat has decided to ship the kernel source code with Red Hat’s selected patches pre-applied. Prior to RHEL 6, Red Hat offered their selected patches separate form the standard Linux kernel available from Prior to the change, interested parties could more easily determine what changes Red Hat had made to the standard Linux kernel?

This seemingly inconsequential shift in packaging has resulted in some Linux advocates questioning whether Red Hat is obfuscating their work. Some have claimed that Red Hat’s new approach adheres to the letter of the law, but not the spirit of the Linux GPLv2 license.

Why is Red Hat taking this new position?

Red Hat CTO and VP of Worldwide Engineering, Brian Stevens, explains:

To speak bluntly, the competitive landscape has changed. Our competitors in the Enterprise Linux market have changed their commercial approach from building and competing on their own customized Linux distributions, to one where they directly approach our customers offering to support RHEL.

Frankly, our response is to compete. Essential knowledge that our customers have relied on to support their RHEL environments will increasingly only be available under subscription. The itemization of kernel patches that correlate with articles in our knowledge base is no longer available to our competitors, but rather only to our customers who have recognized the value of RHEL and have thus indirectly funded Red Hat’s contributions to open source that will advance their business now and in the future.

Having recently met Stevens, I’m reassured that my initial pegging of him as a straight shooter and pragmatic thinker was spot on.

At first glance, it’s hard to believe that RHEL has much to worry about in the enterprise Linux market. Even as Ubuntu grows in cloud deployments and Amazon Linux offers an alternative to RHEL on Amazons’s cloud, RHEL remains firmly in a leadership position. For instance, as this chart from job trends indicates, RHEL skills are is hot demand, and still on a growth trajectory far and above Ubuntu, CentOS, Oracle Linux and Novell SUSE.

However, as Stevens indicates, while RHEL usage and demand for RHEL skills may be increasing, Red Hat is not longer the only vendor in town to offer RHEL support. In fact, third-party vendors that offer lower cost RHEL support than Red Hat offers have the added benefit of not having to invest in developing RHEL, or the RHEL clone, to the degree that Red Hat does. This lower level of investment allows third-party vendors to offer lower cost support than Red Hat.

The long term competitive impacts of lower cost Linux offerings
Some companies are attracted to these lower cost RHEL support providers. However, one must question the value that these third parties deliver to the Linux market, and their impact on paying Red Hat customers, especially in light of Red Hat’s decision surrounding kernel and fix packaging.

It’s well documented that Red Hat invests significantly in Linux community projects. These investments are funded by revenue from RHEL customers. Third party RHEL providers are significantly less active in the Linux community, as is necessitated by their lower investment business model.

Its difficult to argue that the Linux community is better off when a customer willing to pay for RHEL support does so through a third party.

The customer does benefit from lower costs in the short term. But, the long term impact is the risk of a less competitive Linux, unless and until these third party RHEL providers step up their community Linux investments.

While RHEL may have the dominant market share in the enterprise, Red Hat is trailing in areas such as virtualization and cloud deployments. A growing revenue base helps Red Hat, like any vendor, invest in new areas and to close the competitive gap in areas that it’s trailing.

How Red Hat’s new policy may impact your company
Red Hat’s new policy has little, if any, impact on Red Hat customers as NetworkWorld’s Stephen Walli concludes. Walli suggests that the recent negative press about Red Hat’s has blown the situation out of proportion.

If you’re paying for a RHEL clone, don’t be surprised if your costs go up as your vendor’s cost may have a more difficult time keeping in sync with RHEL.  It’s also possible that your RHEL clone provider will have a more difficult time claiming full compatibility with RHEL, thereby making it more difficult to run ISV applications certified on RHEL, but not on your RHEL clone. As a result, your company may be faced with a future decision of continuing to use the RHEL clone with third party support, or moving to Red Hat for support.

I tend to agree with Walli. It’s not only Red Hat’s right to compete, but in the best interests of its customers and the Linux community as a whole.

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

App Stores are all the rage these days with companies vying to release their applications ahead of competitors. Not surprisingly, open source components are being used to speed delivery of these applications.  Companies need to ensure their open source usage fits within the requirements of both App Store and open source component licenses.

Companies using open source aren’t complying with licenses
OpenLogic recently released results from a scan and license compliance assessment of 635 leading mobile applications.  Sixty six applications, just over 10 percent, were found to contain components with an Apache or GPL/LGPL licenses.  Of these applications, over 70 percent failed to comply with requirements of the open source license.

OpenLogic’s analysis suggests that companies using open source components in their App Store applications are doing so without fully understanding license implications.

Ignoring license requirements means that App Store providers could pull a company’s application from the App Store, thereby impacting the company’s users and affecting the company’s competitive position.

GPLv2 & Apple App Store license incompatibility an areas of concern
Another issue to consider is that Apple’s App Store terms of service is incompatible with the GPLv2 license.  Companies considering using GPLv2 components in their App Store destined application should think twice, until the incompatibility is resolved.

The GPLv2 doesn’t allow someone to impose further restrictions on the GPLv2 licensed code than the original licensor allowed.  The GPLv2 also doesn’t allow restrictions on usage.

The Apple App Store terms of service on the other hand does prohibit usage as defined in the list of Usage Rules – if an activity does not appear on the list, a user is not allowed to use the App Store application in that way.

In effect, an Apple App Store application which abides by Apple’s terms of service is deemed to be restricting usage and imposing further limitation on usage rights than were envisioned by the original licensor of the open source code.

Far from being an abstract example, this situation is precisely why the popular VLC media player was removed from the App Store.

With the vast amount of GPLv2 code available for use, the incompatibility between the App Store terms of service and GPLv2 is a problem in need of a fix.

NetworkWorld author and OuterCurve technical director, Stephen Walli proposed a solution that relies on dual licensing of GPLv2 components.  Walli writes:

“This suggests a way for developers that are strong believers in free software to also use the Apple App store as a channel to get their software in front of a larger audience. The project could essentially create a dual licensing scheme using the GPL for its wider audience and a separate Apple App Store distribution license for the executable version and its derivatives that sits on the App Store and that further allows others to use and to publish the binary on the App Store. “

The key challenge with a dual license approach is for GPLv2 licensed open source projects to agree that creating a new App Store friendly license is appropriate. Some developers who believe in the freedoms enabled through the GPLv2 will likely resist supporting a license that restricts user freedoms.  Additionally, open source projects that rely on other third-party open source components would require each third-party project to agree to a dual license, or find a replacement third-party project, before the parent project could use a dual license.

The Apache 2.0 license doesn’t have the same issue as GPLv2 when it comes to Apple’s App Store terms of service, and could become the license of choice of companies seeking to use open source in an Apple App Store application.

Apply sound open source usage principles to App Store apps
Until the GPLv2 and App Store incompatibility is remedied, companies are encouraged to seek legal counsel before using GPLv2 code in their App Store destined applications.

Additionally, blaming developers, contractors or third-party service providers for improperly using open source software within your company’s App Store application after the fact isn’t a good plan.

Instead, ensure your company has guidelines and approval processes in place, just as you are encouraged to have for using open source within internal projects.  Use a license scanning and governance solution from vendors such as OpenLogic, Black Duck or Protecode to validate that projects are adhering to your company’s open source usage guidelines.

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

Research in Motion (RIM) is planning to make its popular BlackBerry Messenger (BBM) available on Android and iOS platforms. What’s RIM thinking, and how with a cross-platform BBM impact your enterprise?

BBM offers immediate gratification and exclusivity
While RIM made a name for itself through its email support, today’s users are much more inclined towards the instant gratification that SMS texting, IM chats or BlackBerry Messenger (BBM) provides. BBM push notifications and ability to see if the person you’re “BBMing”, the act of BBM chatting, has received or read your note and is in the process of replying, provide immediate gratification that email simply doesn’t.

Today, BBM is only available on BlackBerry devices, making it easy for non BlackBerry owners to feel outside of the loop when your BlackBerry wielding friends, colleagues and business contacts are BBMing.

While it pains me to say, as a long time BlackBerry user, and faithful Canadian, I would gladly leave to an iPhone or Android device if I could get BBM on those devices. Far more than push email and a physical keyboard, BBM is the key feature that keeps me a BlackBerry user.

RIM smartly plays up the unique BBM user experience and exclusivity in BlackBerry advertising campaigns.

BBM on Android and iOS could accelerate migration away from RIM
Considering the tight race that RIM is facing against Android and Apple, and how important BBM is to keeping users on a BlackBerry device, I was surprised to read that RIM is planning to offer BBM on non-BlackBerry devices. The Boy Genius Report blog reports:

…we’ve been told RIM will offer stripped down versions of the BBM experience BlackBerry owners know and love. That way, Android and iOS users can communicate with practically anyone who has a smartphone using BBM, but they might not be able to share photos, location, or videos (when RIM crosses that bridge). Users who want the full BlackBerry Messenger experience will still need a BlackBerry smartphone to get it.

This move is increasingly difficult to understand when one looks at RIM’s revenue by source from their latest fiscal quarter 3Q11 ended November 27, 2010.

The Devices category represents revenue from smartphone sales. The Service category represents revenue from carriers for every active BlackBerry device on the carrier’s network. The Software category represents revenue from the sale of packaged software.

With over 95 percent of RIM’s new revenue linked to devices sold or active on a carrier’s network, why would RIM make it easier for users to leave the BlackBerry platfrorm?

RIM’s plans for owing the smartphone messaging category appear risky
RIM may be hoping that the stripped down BBM experience on non-BlackBerry devices could attract new users from the Apple and Android camps. This seems like wishful thinking, especially considering BlackBerry’s lack of application parity, ease of use or device specifications that would have attracted users to iPhone or Android devices. To balance this upside, if there is any, RIM must balance against the downside risk of losing exiting BlackBerry users who are currently tied to a BlackBerry device because of BBM alone – like yours truly.

It’s possible that RIM’s strategy team expects users like me to leave the BlackBerry ecosystem over time anyway. At least this way, they may be able to make some money off users like me through BBM on a non-BlackBerry device.

RIM may be hoping that making BBM cross platform would allow them to own the messaging category, much like GoogleMaps owns the location and map application category across Android, iOS and BlackBerry devices.

While RIM may very well own the messaging category across smartphones, the burning question is, so what? Does RIM intend to capture advertising revenue through BBM on non-BlackBerry devices? Good luck with that not ruining the user experience.

Does RIM intend to charge a one-time or ongoing fee to access BBM from a non BlackBerry device? I’d happily pay such a fee, but let’s do some quick math.

Based on fiscal 3Q11 results, RIM nets approximately $300 from a new BlackBerry device purchase and approximately $60 per active subscriber per year. Over a three year cycle, RIM stands to collect $480 per subscriber, or about $160 per year.

If I leave my BlackBerry behind for an iPhone or Android device, I’d probably pay about $20 per year for BBM access. Keep in mind that a cross platform BBM alternative, Whatsapp, costs $0.99 on the iTunes App Store.

For each existing BlackBerry user that leaves, RIM needs 8 non-existing BlackBerry users to generate $20 each per year in RIM revenue, either directly or through monetizing advertising, just to break even. Seems like a tall task.

It’s more than possible I’m missing something that RIM’s strategy guru’s see. I am however hoping that RIM goes ahead with this plan, and it’s a net positive for RIM’s business.

Continued pressure on IT for cross-platform Mobile device support
If RIM does go ahead with this plan, IT departments can only expect increased interest in non-BlackBerry device usage requests to access enterprise systems and applications. Plan to adjust your enterprise mobile policies or face user complaints.

It’s unclear how BlackBerry will offer security and management of BBM on non-BlackBerry devices. A lack of equivalent security and management options for BBM on non-BlackBerry devices could be a reason for enterprises to continue preferring BlackBerry devices for enterprise usage. Stay tuned for more details from RIM throught the year.

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