Billy Marshall founded rPath a few years ago, pioneering the delivery of software appliances. Prior to that he spent several years at Red Hat as creator of the Red Hat Network and then as VP, North America Sales. He is currently spending the summer as a consultant at EMC in its Cloud Infrastructure Group. Note: While there are various types of owners of applications, application owners are referred to as ISVs in the text below.
The interview with Billy consists of two parts. In Part 1, the interview focuses on rPath’s view of software appliances (SWAs), hurdles for Linux vendors that want to get into the SWA business, which vendors have the best chance of succeeding, and two important topics: pricing and support. In Part 2, we focus on which applications are likely to make their way into SWAs, how some large ISVs are creating SWAs around their applications, and the relationship between SWAs and clouds. (Marshall wanted us to note that the comments made in this interview are his own and do not in anyway reflect rPath’s views.)
Linux.com: Novell and Red Hat are in various stages of creating SWA businesses. rPath, under your leadership, set out to create a SWA business before just about anyone else. Tell us what rPath’s view is around SWAs.
Billy Marshall: One of our hypotheses was that there would be a proliferation of open source stuff that people would want to take advantage of. We felt that it is difficult for a Linux vendor, such as Novell or Red Hat, to say that they were delivering all of the good stuff that ISVs needed for application support and that users wanted. For example, users say I don’t like this version of Python or I like this utility better. At rPath, we believed that this greater proliferation of stuff is good for everyone. It is just difficult for any vendor to stand up and say “We are delivering the good stuff in our release (SUSE Linux Enterprise Server or Red Hat Enterprise Linux). You use it, and it will work great for you.”
rPath also said that hypervisors would become the dominant driver layer, not the operating system (OS). An OS has classically done two things: provide a driver layer to access hardware and provide system services to the application.
We believe that the hypervisor will become the driver layer and everyone will load their applications onto hypervisors as virtual machines. There is no doubt that this will happen. We thought about being a hypervisor company for a short time, but we had no credibility there. We decided to create an application delivery system because we had expertise there that allowed ISVs to deliver their applications to any hypervisor or cloud in a production format. And rPath has done this! We think that this is pretty clever, and we were way ahead of the market at the time, but now the market is starting to catch up.
Linux.com: Give us one of the biggest hurdles for Linux vendors and Microsoft as they begin to make their way into the SWA business.
Marshall: They don’t want to give up their distribution channel with the hardware OEMs. They want to “own” the hardware. They don’t want to cede control to the hypervisor. The OS vendors do not want anyone to change anything because it screws up their release model. Every two or three years OS vendors give you a new release and in the meantime they give you updates. They declare to their customers “what I give you is what you should use and don’t change anything.” Changing this approach would affect their engineering model. Their engineering models are not built to maintain or support anything other than what they deliver; whereas, rPath was set up to support application owners and ISVs doing different things with the bits.
Linux.com: Red Hat announced its Red Hat Appliance OS (RHAOS) and then little has been announced since then. You are close to Red Hat. What happened?
Marshall: Red Hat has never delivered anything. Red Hat killed the RHAOS (Red Hat Appliance OS). It never saw the light of day. I would say that Red Hat is not even interested in clouds. Red Hat is interested in having a hypervisor, KVM. In a recent “about face,” on the old strategy where they declared the hypervisor as a feature of the general purpose OS, Red Hat now says that its KVM hypervisor is a product unto itself and not a feature of a general purpose OS. Red Hat is interested in having an OS, a hypervisor, and having the JBoss application support infrastructure. It has all of the components to play the hardware OEM distribution game (with KVM) as well as the ISV distribution game with JBOSS. It’s just the way Red Hat goes to market, kind of slow. In Red Hat’s defense, however, it may be moving slowly because the market for SWAs is just developing and maybe they are just taking it slow intentionally.
Linux.com: A number of companies are trying to get into the SWA market. Tell us who you think the potential winners are.
Marshall: Red Hat has all the assets, JBoss is a great application asset and they have KVM. They just need to get the management system done. Red Hat seems to be so enamored with its existing success with the general purpose OS that it doesn‚Äôt seem to be very inclined to make the changes to split the business–hypervisors on hardware and JBOSS and other components of the OS supporting applications.
Red Hat does not want to do anything to upset the apple cart. It wants status quo to continue as long as possible. Microsoft is the same way. Their distribution channel is so closely tied to the hardware that the last thing they want to concede is that all the hardware needs is a little hypervisor, which probably ought to be embedded in the hardware anyway. If this were the case, then Microsoft would have to turn their attention to the application delivery infrastructure.
VMware can be a winner if it can figure out how to pick up the application assets to complement what it has. 100% of VMware’s DNA is around its hypervisor. There is VMware Studio, but VMware does not own it, but they contribute a little bit to it. My view is that VMware should embrace Linux in a big way.
Amazon who has put up the cloud infrastructure can be a winner. Microsoft and Red Hat are at risk, but they could be successful if they can change their culture and strategy.
Linux.com: You did not mention Novell. Novell is entering the SWA business without any serious competition from Microsoft and Red Hat. What are Novell’s chances?
Marshall: Novell has a start with its SUSE Studio and KIWI tools, but it still has a business model built around the OS and not the tools like rPath. To generate significant revenue with a focus on the OS, you have to sell at high volume. For example, suppose you get 5% of the SWA list price for the OS portion of a SWA appliance. For IT infrastructure SWAs, you would get about $50 per SWA on the average for the OS. ISVs would have to sell 20,000 SWAs to generate $1,000,000 for the embedded OS. If you are first to market with this business model and Novell is one of the first, then it could have a shot at making significant revenue provided:
- Very large numbers of SWAs with some variation of SUSE Linux Enterprise Server as the embedded OS are sold
- Customers do not start demanding ISVs to embed variations of RHEL and Windows when Red Hat and Microsoft eventually get serious about this market
Linux.com: Let’s talk about pricing and support for a bit. Tell us the nature of rPath‚Äôs pricing model for SWAs.
Marshall: At rPath we sold maintenance for the OS infrastructure and the lifecycle management system that came with it. The average price per system deployed per year was about $250 – $300 and that did not include any support. Support was priced on top of that. We priced support for designated contacts, not for systems. Our view was that our support burden does not scale based on the number of systems you deploy. Our support system scaled, based on the number of people authorized to aggravate us for support. We sold support for $15,000 (list price) per designated contact per year for 9×5 support and $25,000 per year for 24×7 support.
Linux.com: Some vendors try to set the terms for their OS used in a SWA as a percentage of the cost of the SWA. The price of SWAs range from less than one thousand dollars for infrastructure SWAs to over $10,000 for business processing SWAs. What do you think of this pricing model for SWAs?
Marshall: This is also what Oracle does and this appears to be what Novell is proposing. This is a tough row to hoe. rPath did this sometimes too in the event that ISVs or application owners had a hard time tracking sales. We would allow them to set terms as a percent of their shipment dollars on both maintenance and license. The going rate for OS vendors is 2% to 5% of the SWA price. So, for a low priced SWA, the OS vendor gets a few dollars per SWA. If you are pricing this way, then a ton of SWAs need to be shipped or OS vendors don’t make much money.
Linux.com: In Novell’s maintenance/support model for SWAs, ISVs own the relationship with the customer for maintenance/support. The customer will call the ISVs anyway. ISVs also control which patches they will apply to embedded variations of SUSE Linux Enterprise Server. This is in contrast to the customer managing patch levels for general purpose OSs such as SUSE Linux Enterprise Server. Tell us what did you do at rPath.
Marshall: Rather than say to people, don’t change anything or you’re off the support wagon. We said, you are still on the support wagon, but you just have to get your maintenance from whatever source you got the package that you changed. rPath majored in the packaging technology that made it easy to assemble and maintain whatever it was that you liked best into a software manifest. We used a lot of source code control techniques in the technology, but we applied the thinking to system engineering as opposed to applying it to the problem of tracking a thread of code through an application. We said this is a thread of packages for a system. We made it very easy for people to reproduce and assemble their system images to represent their application. What we said at rPath is that the production layer is the hypervisor and the applications guys now have the responsibility to deliver the software stack onto the hypervisor.
We started giving ISVs options with respect to what Linux packages they could start with in addition to rPath Linux, and then they could replace packages they didn’t like with ones that they liked better. So they were given a core based on rPath Linux, SUSE Linux Enterprise Server, Ubuntu, or CentOS.
If an ISV got calls on bugs in the Ubuntu stuff, for example, the ISV would help diagnose what the problem is, but rPath did not patch Ubuntu. The ISV would have to pass the problem upstream and when the change patch came back rPath would package it up for the ISV. If the ISV wanted rPath to fix a bug in the written code, then it would need to use rPath’s Linux.
Bill Claybrook is a marketing research analyst with over 30 years of experience in the computer industry with the last 10 years in Linux and Open Source.  From 1999 – 2004, Bill was Research Director, Linux and Open Source, at Aberdeen Group in Boston.  He resigned his competitive analyst/Linux product marketing position at Novell in June 2009 after spending over four and one half years at the company.  He is now President of New River Marketing Research in Concord, MA.  He holds a Ph.D. in Computer Science.
