Open Source


Oracle’s recently announced a proposal to move the open source Hudson project to the Eclipse Foundation. Should your company’s stance on Jenkins or Hudson change as a result? Short answer, no. The more interesting question is what this contribution means for the Eclipse Foundation.

Eclipse contribution won’t mend the Hudson & Jenkins split
In explaining Oracle’s proposal, Ted Farrell, Chief Architect and Vice President, Tools and Middleware at Oracle, writes:

…I can’t speak for the Jenkins folks, but one of the good things about Hudson moving to Eclipse is that anyone can participate. When the fork happened, I think it came down to a difference of opinion about how to run an open source project. Oracle and Sonatype wanted more of an enterprise focus, and CloudBees wanted more of a grass-roots environment which is how Hudson came to be. I think both are valid opinions.

So when we started talking about this move to Eclipse, we initially focused on talking to people whose views were more in line with our Enterprise focus. Now that the proposal is public, we welcome anyone to join the conversation over the next 2 months while we finalize the submission and get it accepted.

Farrell makes several points that appear counter to the public record.

First, unlike Oracle, CloudBees relies on Jenkins to power a commercial product aimed at enterprises. To claim that CloudBees has anything less than an “enterprise focus” is curious.

Second, when a community around any open source product up and moves to another location, under a different project name, that’s not a fork – that’s a rebranding. Jenkins community member Andrew Bayer told InfoWorld’s Paul Krill:

The Jenkins organization on GitHub now has almost 500 repositories, the majority of those plug-ins, and almost 100 public members, while Hudson only has its core repository available and only four public members. Of the 25 most commonly installed plug-ins from before the split, 21 of them have moved primary development to focus on Jenkins, with the remaining four not having any changes during that time. In fact, 40 new plug-ins have been added to Jenkins since the split, while only one has been added to Hudson. The development community has definitely made its choice heard.

The lack of community response on the Hudson proposal mailing list at Eclipse is not a very good start for the project. Two individuals that have commented suggest they support the proposal if it will unify the Hudson and Jenkins camps. However, there’ no indication of a Hudson and Jenkins unification occurring as a result of the Eclipse contribution proposal.

Eclipse at risk of becoming a graveyard for abandoned OSS projects
Like most, I’m a big fan of the Eclipse Foundation, not simply because Ian and Mike are Canadians!

However, I fear that Eclipse is at risk of becoming a home for projects whose owners are looking to gracefully reduce their investments while gaining some open source kudos along the way.

Rewind to November 2009 when Oracle and SpringSource jointly announced the Gemini project proposal. Gemini was based on SpringSource’s DM Server technology. Two short months later SpringSource announced the Virgo project proposal to contribute SpringSource’s dm Server to Eclipse. Although SpringSource had been a big proponent of OSGi, OSGi and dm Server became less of a priority for SpringSource after it was acquired by VMware.

SpringSource tried to play up the potential for increased community contributions to the Gemini project.

However, VMware/SpringSource killed off their dm Server product as a result of contributing the project to the Eclipse Foundation. The lack of a product and revenue linked to the Eclipse project should have been a warning sign for the Eclipse Foundation.

A year and a half later, while OSGi support is offered by WebSphere, GlassFish and JBoss, and continues to gain developer attention, the Eclipse Gemini project is stuck in neutral.

Does Oracle, or more importantly, the Eclipse Foundation, truly expect a better fate for Hudson?

Oracle doesn’t have a viable business associated with Hudson. This makes any future investment decisions regarding the project at Eclipse tenuous at best. Cue the graceful exit music.

While I agree that, “if you’re going to kill it, open source it!“, I simply don’t think that the Eclipse Foundation needs to be, or should want to be, the destination of choice for these types of projects.

I hope I’m wrong about the fate of Hudson at the Eclipse Foundation. The Eclipse Foundation is too important to open source projects to become, or even just be viewed as, anything but a leading destination of choice for new and exciting projects.

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

A recently released survey of 2,760 mobile application developers reveals challenges for Google, Microsoft and RIM around fragmentation and access to developer time and mindshare.

The survey was conducted in early April 2011 by research firm IDC, and Appcelerator, a mobile development platform provider for building cross-mobile platform applications using HTML, CSS, JavaScript, PHP, Python and Ruby. Appcelerator claims 1.5 million developers and over 20,000 applications built with its open source products.

Not surprisingly, Apple and Android phones and tablets occupy the top four spots in terms of developer interest in developing for a certain platform. There’s over a 40 percent gap between the two leaders and everyone else, including RIM, Microsoft and HP’s respective mobile platforms.

Android’s challenges with fragmentation
The survey gets interesting when developers discuss their concerns with Android. Fragmentation is overwhelming the number one concern.

A feature/function comparison versus Apple’s iOS or ability to make more money from Apple’s ecosystem are at the bottom of the Android concerns list.

IDC and Appcelerator also point out that there appears to be significant gap between interest in Android as a tablet OS and tablets that support Android.

On the software side, 71% respondents are “very interested” in the Android OS, but on the hardware side, only 52% are very interested in developing applications for the Samsung Galaxy tab. This drops to 44% for Motorola Xoom, the first Android tablet with Android’s Honeycomb OS.

This is somewhat surprising considering the relatively strong hardware specifications, especially compared to the likes of Apple’s iPad 2, that Android tablets offer. However, fragmentation concerns may be a root cause to the lack of interest in having to test with and support the various Android tablet offerings.

One can see why Google is working hard to reduce fragmentation, even if it allows outsiders call Google’s open source credentials into question.

RIM and Microsoft’s race for relevance
When asked if any other platform can catch up to Apple or Google, 62 percent of respondents said “no”.

Digging deeper, the respondents are more interested in the Microsoft & Nokia partnership versus announcements from RIM or HP surrounding their respective mobile platforms. Respondents felt that the Microsoft and Nokia partnership could position Microsoft as a more serious competitor to Apple and Google.

However, even amongst this group, when asked what poses the biggest risk to the success of Microsoft’s mobile platform, 46 percent answered, “not enough time”. The only higher ranking risk was a perception that Google and Apple are just too far ahead.

What’s troubling is that Appcelerator helps developers build native, cross-device mobile applications from a single code base for iOS, Android, and Blackberry.

These developers can’t find the time to target anything other than iOS and Android, even with a tool that addresses multi-platform support from a single code base.

These developers are saying that the marginal cost of tailoring the single code base application for RIM or Microsoft platforms is outweighed by the value of delivering the next feature for iOS and Android users of their application.

I would have expected these responses from developers tasked with building for multiple mobile platforms without the benefit of a cross-device framework or tool like Appcenerator offers.

RIM, Microsoft and others hoping to catch Apple and Google, need to dig deeper into these results and determine what can be done to keep developers interested in building for their mobile platforms.

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

Devops, a term coined to describe the expanding reach of developers into areas typically considered operations tasks, is still viewed as a trend impacting early adopter enterprises – but for how long? What can you do to prepare what should you look for in technology that enables the devops model?

The developer land grab that is devops
The desire to release new functionality faster to end users is high on every developer’s wish list. However, most enterprises have multiple layers of processes, assigned to separate roles, which often increase the time between a new feature being developed and made available to users. However, most IT managers would agree that these processes and separation of roles were instituted to increase the quality and uptime of IT environments, and ultimately the quality of the end user experience.

The growing access to automated, self service, provisioning of IT resources and environments is enabling developers to flatten the roles, if not processes, between a developer and the end user.

RedMonk’s Michael Cote suggests that devops can be viewed as a land grab by developers. Cote writes, “after ejecting every function except writing code, development teams have been bringing those roles back to the core team, starting with QA, then product management, and now operations.”

Not surprisingly, devops is taking hold primarily in startups or smaller companies where the separation of developer versus operations roles is ill-defined by necessity.

The changing role of operations in a devops world
In larger enterprises with established separation of roles between developers and operations teams, the devops term may in fact be counter productive. It can suggest that as developers undertake tasks previously owned by the operations team, operations staff become less critical to the IT organization.

In fact, the reality underlying devops is far from that mistaken belief. Cote describes the changing role of operations staff in a cloud-driven devops world:

Rather, it means that as with QA and product management, their role moves from “keeping the lights green” to “delivering good, productive experiences.” Operations becomes one of the product owners, not just the “monkeys” who hook up wires to servers and increase disk-space.

The451 Group’s Jay Lyman shares a similar view in his research on devops, concluding:

However, in the larger picture and in the long run, particularly at greater scale, there is undoubtedly need for system administrators. One of the bottom line findings of my research on devops is that the trend is very much about a dramatically changed purpose and role for system administrators, who are typically freed up of mundane OS maintenance and other tasks, but who must also embrace openness and transparency in their operations and scripts, which can be very foreign.

Far from developers replacing operations staff, and thereby accepting some of the manual tasks required to keep an environment up and running, new cloud technology removes the need for these manual, and at times mundane, tasks in the first place. As these tasks are removed, operations teams are able to better contribute to the value that their business and end users perceive to be coming from IT.

Transitioning towards a devops model
Much of the transition required by the devops model involves changes to organizational design, processes and a revised definition of roles. These types of transitions can be lengthy in duration and often face resistance initially.

It is for exactly this reason that vendors must offer both an evolutionary and revolutionary option in their cloud and PaaS offerings targeted at enterprises.

An evolutionary approach is required to help IT organizations gain value while they transition to tomorrow’s more responsive and productive IT organization. Without this evolutionary step, the desire to protect one’s sphere of influence in the overall IT process will encourage IT staff to resist change before they can see the benefit of a cloud-enabled devops model.

A revolutionary approach also needs to be delivered in the same cloud-focused tool or product. This choice enables enterprises to shift gears between evolution and revolution in their IT processes without having to acquire separate products with separate skills requirements. More importantly, this choice allows enterprises to shift between evolution and revolution in their IT processes at their own rate and pace.

VMware’s open source-based Cloud Foundry beta and IBM’s Workload Deployer are two PaaS offering that attack the devops opportunity from two ends of the spectrum.

VMware’s beta offering appears targeted at enterprises ready for revolution, with a developer in control of the overall development to deployment process. It’s too early to tell if this is by design, or simply didn’t make it into the developer targeted marketing surrounding the beta. Knowing VMware’s long history with enterprises, one would expect VMware to address the spectrum of stakeholders whose roles are impacted by cloud and PaaS in a devops model.

IBM’s offering assumes that enterprises want to select between both evolution and revolution in their IT processes on a project by project basis while. This choice enables IT organizations to secure buy in from IT employees after proving out the benefits of more closely aligned developer and operations functions in a given project.

Preparing for a devops future
Like any major change in processes or role definition, IT decision makers need to allocate sufficient time for the shift to occur.

Successful transitions will most likely occur if there are proof points, relevant not only to the business, but to developers and operations staff, from a handful of smaller projects. Selecting projects, developers and operations staff that would be best suited for a new way of doing things would be a good fist step.

Additionally, determine the degree to which your IT organization can accept the revolutionary changes to roles and processes as codified by the cloud and PaaS tools you consider. Select your cloud and PaaS tools based on your organization’s unique needs.

Whatever you do, starting to think about devops models sooner rather than later, is the right approach for building tomorrow’s IT department.

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

A high profile VC and a well-known mobile application developer were recently involved in a debate about whether to build for Android or Apple mobile platforms. The answer it turns out is, it depends, or both, or simply build for the mobile browser.

App developers and companies have different goals, so why follow the same advice
Well respected VC, Fred Wilson, principal of Union Square Ventures, has previously suggested that developers interested in the largest user base should invest as much, if not more, in developing for Android as they do for iOS. Wilson justifies his recommendation by looking back at the desktop operating system market. Wilson writes, “I believe the mobile OS market will play out very similarly to Windows and Macintosh, with Android in the role of Windows.”

Countering Wilson’s advice is Marco Arment, founder of Instapaper and former lead developer of Tumblr. Marco suggests developers need to keep a closer eye on development economics, degree of fragmentation, payment integration, and the willingness of users to pay for applications or extensions on a given mobile OS platform.

Marco’s advice is likely to resonate with individual developers hoping to directly monetize their mobile application either through selling the application or through in-application purchases. Over time however, one shouldn’t bet against Android closing the gap versus Apple along the lines of development economics, payment ease of use and fragmentation.

It remains to be seen whether Apple’s platform can continue to generate higher application and in-application purchase revenue for developers even while Android boasts the #1 mobile OS by unit share. Today, the App Store revenue gap between Apple and all other mobile platforms is striking.

On the other hand, a company that sells goods or services which are exposed through the mobile application, but does not monetize the application itself, needs to pay more attention to Wilson’s advice. If the vast majority of a bank or retailer’s prospective users are going to use an Android device, the company had better offer a compelling user experience on that platform.

But why choose between developing for Android or Apple?

Build mobile web browser applications
It’s somewhat amazing to watch companies that don’t rely on directly monetizing their mobile application invest in native mobile applications for iOS or Android. In a rush to be the first to market, companies optimized for a device rather than following the cross-platform and cross-browser web application strategy they’ve used for the better part of a decade.

Not surprisingly, this will change thanks to HTML 5, CSS 3 and JavaScript.

For instance, if TweetDeck, which is best known for its thick-desktop client, can see the light and deliver the same user experience in a web-browser across desktop and mobile devices, chances are your company’s web application can evolve into a mobile web browser application without paying the cost of device-specific implementations.

The key element of TweetDeck’s announcement is that “TweetDeck Web, however, is a standalone web site and requires no downloads, no App Stores and is not limited to any one brand of web browser.”

No App Stores is a win for the browser
The “no App Stores” angle obviously has its pros and cons. However, unlike individual developers, companies that aren’t monetizing the mobile app itself don’t need to rely on an App Store to attract users. They already have users and other processes to attract new users. Their users simply want to interact with these companies through mobile devices. Putting the company’s web application into an App Store adds extra hurdles for users and for the company when it comes to fixing defects or updating the application with new features.

If users begin to rely more on App Stores and less on the Internet itself for finding new vendors of goods or services, being in the App Store of choice will become as important as being listed in Google’s web index. But we’re years away from this scenario becoming reality, if ever. In the short to medium term, established companies can well address new and existing customers through a mobile web browser application.

It’s strange that Google hasn’t recognized the mobile browser-based application opportunity and is instead attempting to replicate Apple’s App Store strategy. The browser undermines the value of the underlying OS.  And since Google doesn’t much care to profit from the underlying OS or the device, unlike Apple, they should be encouraging companies to build mobile web applications, not device-native applications. Google should be indexing and promoting these mobile web browser-based applications.

Consider cross-device frameworks as a step towards standard browser applications
For individual developers and companies that need to be an App Store, or want to access more of the device native capabilities, such as the camera or GPS, then evaluate the various cross-device frameworks previously covered on Open Sources. For instance, PhoneGap already has an impressive list of cross-device native feature support. Using a framework such as PhoneGap, and their build service could make it easier, faster and cheaper to build applications for Android and iOS, instead of having to decide which platform to prioritize.

Over time, standards will emerge to access core mobile device capabilities, such as the camera or contact list, in a cross-device fashion. Whether this occurs through defacto standards around a framework such as PhoneGap, or a formal standards body efforts is unclear. Maybe Google will smarten up and realize they have more to gain by spearheading this initiative than trying to play Apple’s App Store game.

If the past decade has taught us anything, it’s that the browser is the application runtime that matters most. Build for the browser.

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

Google’s recent announcement that Android Honeycomb will remain closed to outside developers, while partners have access to the code isn’t sitting well with open source proponents. However, the stark reality is that Android’s growing mobile maretshare has little to do with how open the operating system truly is.

Android a bait and switch to open source developers?
In a BusinessWeek interview, Google’s Andy Rubin, vice president of Android engineering, explained that Google had to make some design tradeoffs to ship a tablet-optimized version of Android, dubbed Honeycomb. Rubin explains, “we didn’t want to think about what it would take for the same software to run on phones.” To prevent developers from trying to run Honeycomb on phones, a scenario that Google didn’t plan or test for, Google has decided to keep the source code for Honeycomb private “for the foreseeable future”.

While Android is often referred to as an open source mobile platform, the development approach is far from open. Google develops Android behind closed doors and makes the source code available when, and as it now appears, if, Google feels is appropriate.

Not surprisingly, some open source developers are taking an exception to the Honeycomb news. Linux developer Adam Drew writes:

In hindsight Android was a bit of a bait and switch with a dash of divide and conquer. Most of the open-source folks are fine with Android being closed up so long as it is opened up later and that means that we lose a large portion of the potential community to Android. This has translated to lower participation in projects like MeeGo and little demand on manufacturers to provide devices that we can easily install other operating systems on. If Android were fully closed we’d have a large base of support waiting to come over to freer pastures but with Android existing in this quasi-open state enough of the open source crowd will stick with it to make it hard for critical mass to grow behind projects like MeeGo.

Openness is often trumped by other stakeholder concerns
RedMonk’s Stephen O’Grady tackles the question of whether it matters if Android is open or not. O’Grady writes:

But while developers are unquestionably and understandably disappointed, there is little evidence to suggest that a less than open Android will have a material cost in developer traction associated with it. Apple’s iOS, a platform that is not open source, has immense developer traction with over three hundred and fifty thousand applications available at the moment.

Based on market share of mobile devices shipped or number of applications for a particular mobile platform, it’s abundantly clear that mobile operating system success has little to do with openness.

In fact, O’Grady concludes that while Google may have felt that openness would turn out to be a differentiator in the market, that hypothesis simply hasn’t been proven out.

If openness isn’t driving Android’s growth, then what is?

Benchmark Capital general partner Bill Gurley’s great post titled “The Freight Train That Is Android” provides some clues.

Gurley argues that Google is attempting to “take any layer that lives between themselves and the consumer and make it free (or even less than free).” This is incredibly important to handset vendors and carriers who have an incentive to use and promote Android over alternatives. The fact that Google shares mobile search revenue with its handset partners makes Android not just free, but a profit center, which is hard for a vendor to ignore regardless of the openness of the platform itself.

As mobile handset alliance members, these vendors have access to Android source code well ahead of third party developers. As such, the openness of Android is a distant secondary issue, if at all. These vendors are however concerned with developers building applications for the platform and end user adoption.

Application developers may care about Android’s openness. However, a large user base and the ease with which the platform enables developers to deliver applications that end users will value, and pay for directly or indirectly, are much larger concerns. The market reach of Android through the ever growing number of vendors supporting Android and Google’s investments to close the feature/function gap to Apple iOS can’t be ignored. These two facts render the question of Android’s openness into the background for the vast majority of developers.

Finally, end users, who should arguably care the most about the openness of their mobile devices, continue to vote with their wallets and select products that optimize user experience over openness. This is an interesting observation considering that their traditional PC environments allows for a highly customizable environment with the flexibility to mix and match hardware with operating systems. One would have expected mobile buyers to seek this same level of hardware and software flexibility in their “post PC” device purchases.

Continue preparing for increased Android usage in your enterprise
Handset vendors, carriers, application developers and end users continue to select other priorities over openness when making a mobile device decision. These stakeholder actions have surely made it easier for Google to minimize its focus on openness with an eye on delivering the functional and non-functional requirements of key stakeholders.

Whether openness ever truly mattered to the potential success of Android is anyone’s guess. The question becomes increasingly irrelevant with each day and each market share percentage that Android captures. As an IT decision maker, your best bet is to continue to prepare for an influx of Android-based devices, personal and company-purchased, in your network; sooner than you may have hoped.

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

 

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 kernel.org. 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 Indeed.com 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.”

Infrastructure as a service (IaaS) vendor Enomaly establishes a marketplace to buy and sell unused computing resources. Dubbed SpotCloud, the new beta service has the potential of helping IT departments reduce costs while also increase revenue potential from IT. Is SpotCloud right for your business? Will Enomaly’s open source efforts affect your decision?

Creating a win-win-win scenario for buyers, sellers and Enomaly
SpotCloud offers sellers with unused computing resources an opportunity to convert these idle resources into a profit centre. Sellers have the ability to define capacity quotas, utilization levels, duration and pricing.

Buyers are able to search for computing resources based on processing power, pricing and the physical location of the computing resource. Buyers can access short term computing resources for significantly less than purchasing the resources in-house or through a third party cloud computing provider. Enomaly claims savings can be up to 60 percent for buyers using SpotCloud.

While Amazon does offer buyers a spot market for its Elastic Compute Cloud (EC2), the resources available are from a single market participant, Amazon. SpotCloud aims to create an efficient market through attracting a large number of buyers and sellers. For creating this marketplace, providing the software to enable sellers to securely make their excess computing resources available and handling billing and payments, Enomaly keeps between 10 to 30 percent of the seller’s revenue.

On paper, it’s a win-win-win scenario for all parities involved. But there are a few considerations before jumping into the marketplace.

The preverbal cloud lock-in issue
Sellers providing computing resources must support a compatible IaaS platform which makes these resources usable and provides usage tracking in a standardized fashion.

SpotCloud currently only supports the Enomaly Elastic Computing Platform (ECP), Enomaly’s IaaS product which has been on the market for over five years. Enomaly offers a feature limited, version of Enomaly ECP for SpotCloud sellers to use at no charge. SpotCloud expects to add support for other IaaS platforms in the coming weeks. As this occurs, sellers will have additional reassurances about reduced lock-in.

Buyers on the other hand must have a virtual machine (VM) package, also referred to as appliances, before being able to use the resources from SpotCloud. The packaging of these appliances is however based on proprietary desktop and command line tools from Enomaly. Seeing this as a potential area of concern, Enomaly founder and CTO, Reuven Cohen, announced plans to open source these tools in the near future.

An opaque market without service level agreements
Enomaly refers to the SpotCloud market as being opaque because the seller’s identity is unknown. This is attractive to sellers, like hosting providers, who have excess capacity to sell at a lower price than they offer directly to their regular customers. Opaque markets allow sellers to offer lower prices on excess capacity without cannibalizing their primary revenue source.

An opaque market could concern buyers that need to know where their workload will run or who may be concerned about the security of their data within the VM. The former concern is addressed by the ability to select resources from sellers based on the geographic location of the physical computing resources. SpotCloud does not directly address the latter concern. However, prudence suggests being cautious, especially in the early days of SpotCloud, about the type of data and workload being processed through resources from the marketplace.

Another key consideration is the fact that SpotCloud does not offer service level agreements (SLAs). For may IT organizations, this could be a deal breaker. However, SpotCloud is intended for workloads that can be restarted when a failure occurs or can take longer than expected without impacting business critical processes. If these don’t meet your business needs, SpotCloud may not be a good fit for your business.

Could SpotCloud to follow in Amazon’s footsteps?
SpotCloud will sound very much like Amazon cloud offerings did when they first hit the market – not up to par with the needs of a typical IT department. And yet, Amazon is the leading public cloud provider in the market. IT departments, startups and others have decided to work within the limits of Amazon Web Services (AWS) in order to benefit from the lower cost and greater flexibility that AWS offers.

SpotCloud has the potential to follow in Amazon’s footstep based on its lower cost, revenue potential and greater flexibility. Companies drawn to these benefits will begin using SpotCloud as an element of their IT processes, not as wholesale replacement of established processes.

Few CIOs can ignore an opportunity for lower costs while also generating revenue for the business, as long as risks can be managed effectively. IT decision makers are encouraged to track the progress of SpotCloud and consider its use for certain non-business critical tasks with limited security concerns. IT decision makers seeking to shift the view of IT being a cost center should consider offering excess computing resources to the SpotCloud marketplace.

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

« Previous PageNext Page »

Follow

Get every new post delivered to your Inbox.