Red Hat

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

Red Hat released Red Hat Enterprise Linux (RHEL) 6 earlier this week. The new operating system, filled with technical innovations, performance enhancements and customer-requested improvements, has met with positive press, customer and partner response. However, how it’s being marketed could be much more important – to customers and to open source vendors in general.

Leading with lower cost
According to IDC market share figures, Red Hat is the undisputed leader in the enterprise Linux market. Red Hat achieved this position, with the help of partners such as Dell, IBM and HP, largely on a simple message of “lower cost”.

In the past, RHEL was not as feature rich as Unix variants or even Microsoft’s Windows NT, and Windows Server product line. Yet, the “lower cost” message was powerful enough to encourage customers to adopt RHEL in areas where its features, or lack thereof, didn’t impact the operating system selection process.

In October 2008, Red Hat’s CEO, Jim Whitehurst told Computerworld:

I’ve had a couple of conversations with CIOs who said “we’re a Microsoft shop and we don’t use any open source whatsoever, but we’re already getting pressure to reduce our operating costs and we need you to help put together a plan for us to help us use open source to reduce our costs.

The low cost glass ceiling
In response to this quote, I wrote that the focus on low cost risked unnecessarily limiting the growth of open source businesses.

I also wrote about Red Hat’s revenue glass ceiling as being directly attributed to its primary focus on “lower cost”. In the post, I wrote:

Yet, Red Hat’s business model, which focuses on low cost, has trained its customer base to fixate more on the price of Red Hat products than the value these products deliver. It encourages customers to trade RHEL for cheaper options.

A renewed focus on high value
It seems Red Hat has learned that “lower cost” is important, but “higher value” is much more important to customers. I’d like to say, “I told you so”, but that wouldn’t be very Canadian of me.

Look at RHEL’s marketing today, the title reads: “More reliable. More open. More comprehensive.” A search for the term “cost” returns zero hits on the RHEL for Servers marketing page.

Look at how Red Hat compares itself versus Microsoft, Oracle and VMware: “More reliable than Microsoft.” More open than Oracle” and “More comprehensive than VMware”. Not as single mention of cost.

Red Hat has also been much more vocal and upfront about technical benefits in RHEL 6. For instance, virtualized guests can achieve 85 percent to 90 percent of the performance of running on native hardware. Additionally, comparing the maximum memory or logical CPUs supported by RHEL 6 versus, for instance, Microsoft Windows Server 2008 R2, shows a wide gap in Red Hat’s favor. Specifically, 2 TB to 64 TB versus 2 TB and 32 to 4096 CPUs versus 4 to 64 CPUs, when comparing RHEL 6 versus Windows Server 2008R2 respectively.

Counter to Whitehurst’s prior suggestion that open source products do not face feature bloat risk, RHEL 6 includes 2,058 packages, and 85 percent increase over RHEL 5. This represents a significant increase in features that RHEL customers can beneit from.

What IT decision makers can expect with high value OSS
The shift from an emphasis on low cost to high value will surely become a growing trend in open source vendor marketing. This will be a positive, and important shift in the ongoing evolution of open source software vendor business models.

IT decision makers are likely to face a moderately more complex task when comparing offerings and features from competing vendors. Higher value is much more subjective than deciding between two products primarily on costs.

This shift could also result in open source vendors requiring additional professional sales resources, beyond today’s inside sales teams. IT decision makers can expect more direct sales interactions going forward than in the past.

Last, but not least, IT decision makers should plan for potential subscription cost increases as open source products begin to focus on value delivered, and price for it accordingly.

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

While Red Hat’s leadership in the enterprise Linux market is without question, questions have been raised about Red Hat’s inability to retain its “market leader” position in the growing public cloud market. Growth prospects for Red Hat Enterprise Linux (RHEL) were delivered yet another hurdle as Amazon announced its own Linux AMI.

IT decision makers considering cloud investments should understand Amazon’s Linux AMI offering and its pricing versus Red Hat’s cloud offerings and pricing.

Amazon’s RHEL-compatible Linux
After some discussion it was uncovered that Amazon’s newly announced Linux AMI is in fact based on CentOS, which in turn is based on RHEL.

It’s interesting to note that Amazon’s entry into Red Hat’s market, using a RHEL-variant has not been met with the negative press that Oracle faced when they announced a RHEL-compatible Linux OS. Perhaps, it’s because Oracle was going after the enterprise, which has been Red Hat’s turf, while Amazon is going after the cloud OS arena, where Red Hat has yet to establish itself versus Ubuntu.

Amazon explained the impetus for this new offering:

Many of our customers have asked us for a simple starting point for launching their Linux applications inside of Amazon EC2 that is easy to use, regularly maintained, and optimized for the Amazon EC2 environment. Starting today, customers can use Amazon Linux AMI to meet these needs.

Amazon further detailed some of the benefits of using the Amazon Linux AMI, versus, for instance using another Linux AMI available on Amazon EC2 or building one’s own Linux AMI:

The Amazon Linux AMI is a supported and maintained Linux image provided by Amazon Web Services for use on Amazon Elastic Compute Cloud (Amazon EC2). It is designed to provide a stable, secure, and high performance execution environment for applications running on Amazon EC2. It also includes several packages that enable easy integration with AWS, including launch configuration tools and many popular AWS libraries and tools. Amazon Web Services also provides ongoing security and maintenance updates to all instances running the Amazon Linux AMI. The Amazon Linux AMI is provided at no additional charge to Amazon EC2 users.

Why Red Hat should be concerned about Amazon’s Linux AMI
IT decision makers should take note of two key related points.

First, the Amazon Linux AMI is provided at no charge for Amazon EC2 users beyond the per hour infrastructure charge, which starts at $0.085 per hour.

Second, Amazon is offering support for the Amazon Linux AMI through AWS Premium Support, which starts at the greater of $100 per month or $0.10 per dollar of total monthly AWS charges.

Contrast this with Red Hat’s pricing options for Amazon EC2.

Existing Red Hat customers that qualify have the option of repurposing existing unused RHEL entitlements on Amazon EC2. According to Red Hat, in order to qualify, a customer must, amongst other requirements:

Have a minimum of 25 active subscriptions and move only not currently used Red Hat Enterprise Linux Advanced Platform Premium and/or Red Hat Enterprise Linux Server Premium subscriptions and have a direct support relationship with Red Hat.

New or existing Red Customers also have the option of using the Red Hat Enterprise Linux Hourly Beta, which is priced at $19/month plus $0.21/hr, which is in addition to Amazon’s EC2 infrastructure charge.

According to Red Hat, RHEL Hourly Beta customers receive “Support for the Hourly Beta offering includes two-day, business-hour response and email-only support”. This level of support is equivalent to a RHEL Basic Subscription – priced at $349 per year, which translates to $0.040 per hour.

It’s interesting that Red Hat has opted to charge over 5 times as much for RHEL Hourly Beta as a customer deploying RHEL would pay for an equivalent level of support in a traditional datacenter deployment. On the other hand, this leaves Red Hat plenty of room to revise their pricing as the RHEL Hourly offering moves from Beta to generally available status.

Next, let’s compare Red Hat’s RHEL Hourly Beta pricing versus using the Amazon Linux AMI with AWS Premium Support. A customer wishing to run more than 16 days, or 386 hours, a month of RHEL workload on Amazon EC2 could achieve a lower cost through the Amazon Linux AMI.

With Amazon’s entry into the Linux OS market, enterprises now have the ability to run a RHEL-compatible Linux distribution with support from a trusted vendor for as little as $100 per month.

It will be interesting to watch Red Hat respond. As shown above, Red Hat’s current RHEL price premium for cloud environments is large enough that it could potentially be decreased to address competitive price pressure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Red Hat is, without a doubt, the poster child for an open source subscription-based business model. This business model has come under scrutiny of late, stemming from a recent interview in which Red Hat’s CEO explains that reaching $5 billion in revenue requires replacing $50 billion in revenue currently flowing to other computer companies.

After joining Red Hat in December 2007, Whitehurst was quoted:

When I look at the quality of our existing technology, and the incredible brand that we have and the markets we play in, we should be a $5 billion company or more. If you just look at operating systems and middleware–that’s nearly a $100 billion business. We’re a $500 million business. We have barely scratched the surface.

Whitehurst and team grew Red Hat’s annual revenue to nearly $750 million in their most recent fiscal year. Computerworld UK columnist Glyn Moody asked Whitehurst whether Red Hat would reach the $5 billion revenue mark he had originally aspired to. Moody details Whitehurst’s response:

His answer was a good one. He said that he did think that Red Hat could get to $5 billion in due course, but that this entailed “replacing $50 billion of revenue” currently enjoyed by other computer companies. What he meant was that to attain that $5 billion of revenue Red Hat would have to displace software that currently costs $50 billion. Selling $50 billion-worth of software — even if it only costs $5 billion — is somewhat hard, which is why it will take a while to achieve.

Before I go on, let me explicitly state that I have a lot of respect for Red Hat and its people. In my role at IBM, I compete with JBoss, a division of Red Hat — but this post isn’t about JBoss. It’s about Red Hat’s business model choices.

I don’t accept Whitehurst’s explanation as to why reaching $5 billion will take longer than he may have originally anticipated.

Whitehurst seems to be saying that every $1 made by Red Hat results in $10 of existing revenue loss to established vendors. I won’t question the 1-to-10 ratio, as I have no data to offer.

I will, however, question the base assumption that Red Hat revenue comes at the direct loss of existing revenue enjoyed by “other computer companies,” as Whitehurst puts it. This may once have been true at the Linux level, where Red Hat Enterprise Linux (RHEL) has been a migration path for Unix customers.

But are masses of Unix customers still looking to migrate to RHEL? Or is it more likely that the majority of customers with Unix workloads today are going to remain on Unix? IDC’s estimates of server operating system market opportunity suggest as much — the revenue opportunity for Unix operating systems is forecasted to be flat from 2009 to 2013. If RHEL was growing largely at the expense of existing Unix revenue, one would expect a decline in these IDC figures.

I would assert that Red Hat’s Linux revenue growth potential is no longer linked to displacing another vendor’s revenue. Rather, the revenue potential is linked to growing usage of RHEL for new projects. Being the incumbent, Red Hat should find it easier to sell more RHEL licenses into an account than before, when it had to displace an alternative operating system to get into the account.

Yet, Red Hat’s business model, which focuses on low cost, has trained its customer base to fixate more on the price of Red Hat products than the value these products deliver. It encourages customers to trade RHEL for cheaper options.

Next, considering Red Hat’s JBoss business, it’s difficult to argue that JBoss is growing at the expense of IBM or Oracle. For instance, only 13 out of 133, or 9.8 percent, of JBoss-related customer case studies involved a migration from an establised enterprise application server to JBoss. Do migrations happen? Of course. But much more often, customers select JBoss for new projects alongside projects running on established enterprise application servers. However, by training customers to seek out low cost, rather than value, JBoss is now exposed to the likes of VMware SpringSource tc Server and other open-source-based application servers that are less expensive, if also less rich in features.

RHEL and JBoss products continue to perform well in the market and to drive revenue for Red Hat. That is without question. It will take Red Hat at least 13 years to reach $5 billion in revenue if the company is able to maintain the 15 percent year-on-year growth rate it achieved in the past year.

My issue is with Whitehurst suggesting that Red Hat’s revenue gains are linked to another vendor’s revenue slide. This may have been true in the past, but not any longer. Red Hat’s revenue growth is much more related to increasing workloads at existing customers or customers considering new projects. As Red Hat attempts this, the company has to realize that its focus on low cost has benefits and consequences.

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

Red Hat’s cloud strategy appears focused on retaining existing customers, not attracting new customers.

There’s little argument that Red Hat is the undisputed leader in the enterprise Linux market by the measure that counts most, revenue. However, Red Hat’s position as the leading Linux vendor for cloud workloads remains in dispute at best, and far from reality at worst. All signs point to Ubuntu as the future, if not current, leader in the Linux cloud workload arena.

First, data from the Ubuntu User Survey decidedly points to Ubuntu’s readiness for mission critical workloads, with over 60 percent of respondents considering Ubuntu a viable platform for cloud based deployments.

Second, statistics taken from Amazon EC2 and synthesized by The Cloud Market, clearly point to Ubuntu’s leading position against other cloud operating systems in EC2 instances today.

With these facts in hand, once could have expected Red Hat to take steps to grow Red Hat Enterprise Linux (RHEL) adoption in cloud environments. In fact, Red Hat’s Cloud Access marketing page boldly claims:

“Red Hat is the first company to bring enterprise-class software, subscriptions, and support capabilities all built in to business and operational models that were designed specifically for the cloud.”

However, Red Hat announced a program in which existing customers, or new customers willing to purchase, at least 25 active subscriptions of RHEL Advanced Platform Premium or RHEL Server Premium could deploy unused RHEL subscriptions on Amazon EC2. With the minimum support price of $1,299 for RHEL Advanced Platform Premium, and a minimum of 25 subscriptions, the price of entry is $32,475. Well, you’ll actually need at least 26 subscriptions, so you can move subscription number 26 to Amazon EC2 with full 24×7 Red Hat support. As such, the price of entry is $33,774. I’m assuming that customers have to pay the full cost of Premium support per year even if the Amazon EC2 instance is not running 24x7x365. If it were otherwise, one would expect Red Hat’s marketing page to point out this nice feature. Additionally, once a customer elects to move an unused RHEL subscription to the Amazon EC2, the subscription must remain there for a minimum of six months according to current eligibility guidelines.

These requirements seem at odds with the low cost of entry, ease of trial, selection and disposal, and pay-per-usage of software and hardware on public cloud infrastructure.

The other alternative is to use the beta of Red Hat Enterprise Linux on Amazon EC2 for a Basic EC2 server. This hourly beta offering provides unlimited email support with 2 business day response time at a cost of $0.21 per hour. This is a much easier way for customers new to RHEL to try it out in a cloud environment. If a customer decided to deploy cloud workload on RHEL requiring 24×7 support, they would however be faced with the $33,774 price of entry calculated above.

I wouldn’t be surprised if Red Hat, and frankly, other software vendors, try several different pricing models before finding the approach that balances the vendor revenue potential from licenses deployed in customer’s datacenters with the flexibility and freedom of pay by usage pricing in the cloud.

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

Red Hat’s CEO Jim Whitehurst kicked off his third year at Red Hat with a State of the Union address.  In his post, Jim discussed Red Hat’s efforts within the Java community:

“Late last year the Java Community Process (JCP) reached a significant milestone when they approved the specification for the next generation of Enterprise Java; JavaTM Platform, Enterprise Edition 6 (Java EE 6). We believe that the approval of this specification starts a new chapter in the story of Java and we are proud to have contributed and acted in a leadership role in the formation of this standard which aims to make enterprise Java easier to use and more appealing to more developers, while still maintaining the benefits of open standards.”

Craig Muzilla, Vice President of Middleware at Red Hat picked up on the Java thread and wrote a nice post ahead of Oracle’s roadmap presentation on Wednesday.  While many will be following Apple’s every move on Wednesday, those of us in the Java community will be listening to Oracle’s plans for Sun products, including Java.

“As Oracle Chief Executive Larry Ellison said shortly after the acquisition announcement  in April of last year, Java is “the single most important software asset we have ever acquired.”

We agree with Mr. Ellison’s statement; Java is one of the most important technologies developed and adopted during the past twenty years. It has fostered significant innovation throughout the IT industry and has enabled businesses and governments to operate with greater efficiency and effectiveness. Java is larger than any single company; we are all part of Java, customers and vendors alike.

We encourage Oracle to fulfill their original proposal and establish an independent governance process for the JCP (Java Community Process). And, finally, we encourage Oracle to continue the tradition of making the technology easily accessible, to vendors and customers alike, to secure its broad adoption and continued strength in the market.”

Craig points out that Oracle was amongst several vendors, including IBM and Red Hat, calling for Sun to make the Java process more open and less susceptible to any one vendor’s influence or control.  While I’d be surprised if Oracle announced an independent governance process for the JCP on Wednesday, I don’t think Oracle will act to damage the Java ecosystem.  Customers and developers have invested too much in Java products over the past decade on the basis of their investment being protected through a multi-vendor community.  The customer backlash would far outstrip any perceived competitive benefit of tightening control over the JCP.  Oracle’s far too smart of a vendor to risk that or encourage non-standard Java usage as we’ve seen with Android.

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

Next Page »