| Wind River's Fogelin on the acquisition of BSDi |
An interview by Rick Lehrbaum (Apr. 5, 2001)
This week, embedded software market leader Wind River Systems announced that they are acquiring BSDi's software assets, which includes the BSD/OS operating system and some related software tools. This event is likely to have a major impact on the overall embedded software market, and is of particular interest to the nascent Embedded Linux Market.
To gain a deeper understanding of Wind River's motivations and intentions relative to applying the BSD operating system to embedded applications, LinuxDevices.com founder Rick Lehrbaum spoke with John Fogelin, the Vice President and General Manager of Wind River's Platforms Business Unit. Here's what Lehrbaum learned . . .
RL: First, I have to say that I'm surprised and stunned by today's announcement!
Fogelin: We're very proud to have an opportunity to help sponsor the open source movement of FreeBSD, and we're looking forward to taking this technology forward. We're excited about bringing a new alternative, our new option of UNIX into the embedded space.
RL: A year ago, you said "we embrace open source and are evaluating Linux as an OS option for Wind River customers" and "we are prototyping solutions on Linux now." Six months ago you were talking about issues of licensing, and the differences between the terms of GPL and BSD. It seems that in deciding how to respond to the Linux phenomenon, you took the approach of trying to get the benefits of open source without any of the disadvantages -- at least from Wind River's perspective -- and tried to leverage the APIs of Linux to a fairly high degree by acquiring BSD/OS.
Fogelin: That's fairly accurate, except for saying that we were responding to Linux in this way. Frankly we were responding to a trend which we've seen, which is UNIX becoming available as a technology base on which to build embedded devices. It was really in response to that market demand that we looked to the available sources for a UNIX operating system to fulfill that demand -- and we certainly had a lot of available options. A year ago, I did comment on Linux being a possibility. However, I had a nagging concern all last year about the implications of the GPL, and as the year went on I found that I wasn't alone in that discussion. In considering all the options, I was pleased to find that the BSD and FreeBSD technologies are, in fact, very sound, very high performant, and part of an open source movement that's very well run. We're extremely pleased with the technology and the community that comes behind it.
RL: How do you account for UNIX catching on all of a sudden, after it appeared to be dying off in both the embedded and real-time markets? Ten years ago, for example, there were efforts by VenturCom and others to put UNIX into the embedded space and the real-time space; but VenturCom and the others eventually found they were better off going in the direction of Microsoft's WIndows NT. Yet you say you are really responding to an upswell of interest in UNIX, rather than Linux?
Fogelin: Let me answer that in two ways. First, I really honestly believe that the Linux community has brought more interest to UNIX-like operating systems by virtue of its success. I want to give credit where credit's due. Secondly, we have seen the utilization of UNIX technology in embedded operating systems from day one, not least of which is the BSD TCP/IP stack which lies at the heart of most operating systems -- embedded included. So in fact UNIX has had a profound impact on operating system design outside of its specific implementations such as the BSD operating system, or Solaris. So I think it's unfair to say that UNIX was dying out; I think the technologies were coming forward. Certainly, UNIX had a really tough go, but, in my opinion, the POSIX effort to create standards never really achieved the kind of traction that was necessary to bring the fragmented offerings back to one. And it was during that time that the Linux effort was born. There was a common enemy, in the form of Microsoft. The availability of a common reference hardware (the PC) along with that common goal (the enemy, Microsoft) created one of the most successful open source movements we've seen. But now, as we present it with the challenges that are inherent in the embedded environment, where there's a great deal of fragmentation and where one has to constantly reconstitute the operating system to be appropriate for the types of applications we're building, we find the issues of GPL to be a significant Achilles Heel.
RL: But don't you think the lack of control over common open source which results from the BSD open source license is going to force BSD into fragmented threads [especially in light of the diversity of the embedded market]?
Fogelin: First of all, I think you might want to think about the number of open source movements around Linux vs. the number that are around BSD, and then take some solace in the fact that there are comparatively few around BSD [in comparison to the number around] Linux. In fact, I guess would say that if you're looking at how an open source community is run, the most important component is who has the rights to commit changes and how those changes are orchestrated. I was very impressed with how the FreeBSD community has organized themselves, with seven core members who in turn orchestrate the committing rights of some 300 committers, who then access the contributions of some 5000 developers here in North America alone. That process is a democratic one in which core members stand for election on an annual basis, and that process is first of all much more inclusive and allows people to really, if anything, defragment as opposed to fragment disparate interests.
RL: I'm a little confused. I haven't been following BSD as closely as Linux, so I may be a little clueless about this, but I had the impression that the BSD/OS that you guys have purchased is a derivative of FreeBSD source, and that it doesn't necessarily have to stay in sync with FreeBSD. Am I wrong about that?
Fogelin: You're not wrong about that, in fact you're hitting on exactly the appropriate relationship, in my mind, between commercially available off-the-shelf versions of an operating system and its open source cousin. If you were to look at the benefits of the open source movement and the benefits of the commercialization phase, I think are fairly self evident. In the context of an open source movement, it's an opportunity for industries to get together and build common interfaces, to innovate in the open, to allow people to bring forward new ideas and share them quickly for the advancement of new technologies. But of course, in any collaboration where there are different coding practices and different types of standards being met, you find a great deal of fragmentation, and frankly a great deal of quality issues. What remains as a challenge for anyone, and this is certainly a competitor to Wind River that's not new, is that on the first day people provision themselves with whatever open source they can find and then they set about the process of building the finished product. And when that finished product needs to be up for five nines of availability, or it needs to be landing airplanes, or it needs to be used in a mission critical devices, someone must make a significant investment in testing, in wringing out the code, in porting the code, in scaling it down to a smaller footprint, in enabling longer battery life, and so forth. So it's in this regard that a snapshot or a derived work from these technologies becomes a very valuable asset, which is made available through business models such as Wind River's, which is royalty based. So that is exactly the relationship that we're looking to bring forward. It's really not an either/or situation. This is why, over the years, I've felt some frustration -- because I'm a major fan and a major supporter of the open source movement, but I also believe very firmly that there's value that can be added to an open source offering beyond what you can find on the net today.
RL: Hearing you talk about it this way makes it sounds as though BSD/OS is simply the latest FreeBSD source, commercialized, but I'm guessing that might not really be the case. How close is BSD/OS to FreeBSD? Is it the same source code?
Fogelin: No they actually diverge in some areas quite a bit, and in some other areas less. So it's not quite a simple answer. Different segments of the technology benefit from being very closely aligned to the open source because we want to stay very current in that regard, but other components of BSD/OS are value-added components licensed from other commercial vendors who have no interest or, frankly, any business motivation to make that available as open source. That includes a variety of media types and formats, graphic drivers, and so forth. So we're able to take the open source the last mile, if you will. Quite often, in any open source movement, there is a recognition that there's a great deal of synergy with the productization efforts, to be able to license-in those last pieces to make it whole, to make it relevant to a particular industry or relevant to a particular company. And, of course, supportable, because one of the nice things that you get out of taking this particular code and bringing it to a known place, where it's been tested and if you can regress from that test, is that you can continue to maintain, track, and fix bugs against that particular branch. And that's something which customers are very interested in being able to dial in -- a sustainable investment that they can get maintenance releases on, and so forth. That's what I mean by the commercialization.
RL: It seems to me that if you are taking FreeBSD and making BSD/OS a better OS, in general terms, those improvements would be best be put back into FreeBSD. That could, for example, include things like graphics drivers and media support. These are things that are very common. On the other hand, when you are adapting it to some specialized application that is really unique, and not something likely to be wanted for other purposes, it makes sense for it to be adapted specifically for that customer's application.
Fogelin: You used the word "better." I don't see that BSD/OS is better (than FreeBSD), per se. I think it's a different type of value proposition to the customer than one you would achieve by [simply making use of] the code available in the FreeBSD format. These both have benefits, they both serve a very important purpose in the modern day and age of writing and developing embedded applications. There is a gap between what you can get from any open source movement -- stepping aside from the GPL issue for a moment. Any customer usually begins with a provisioning of code that comes from a variety of sources. And then what happens is they begin building and stabilizing that code for their particular intent. What happens after about nine months is they realize, after their third round of funding, they more OS engineers than they have application engineers, because they're spending all of their time stabilizing the code that they've taken ownership of, with no one to support them. And so what we've found is there's really a legitimate purpose for donating time and investing efforts in open source areas, but let's not fool ourselves in thinking that this job can be completely finished by the open source community to make it specifically tailored to any given company's needs. That's where a company like Wind River comes into play -- we can now really enjoy the benefits of both worlds. And as we stabilize and tailor the technologies of these operating systems to be available to our end users, we'll be doing it in such a way as to get them to market faster than they would if they were to just take FreeBSD or any open source, for that matter. It remains to be seen, I suppose, just how the open source efforts in the world continue to go forward -- but it's keeping all of the industry honest. If it's possible to get something done faster through the open source, then I say that's outstanding, and we should just acknowledge that and continue to look for ways to add value beyond what's available in that fashion.
RL: You may be aware that there's currently a growing interest within the Embedded Linux Consortium in pursuing standards for Embedded Linux. This isn't just a defensive move by Embedded Linux vendors, but it's also being driven, in large part, by some proprietary OS vendors who want to be more "Linux-like" -- or "UNIX-like" as you put it -- such as QNX and LynuxWorks. Do you foresee Wind River playing a pivotal role in helping to define some common standards for "POSIX-and-beyond," which could be shared among all of these OSes?
Fogelin: I think you've hit on one of the real advantages of any open source movement, and that is to drive toward commonality. By doing one's work in the open, you receive, quite often, feedback that maybe you weren't prepared for, for example when something was not very well thought out. It allows an industry to reach a common ground more efficiently than you've seen traditionally through proprietary operating systems. So I agree wholeheartedly that an open source movement is an excellent vehicle to bring standards into industries that are prepared for that. But I would want to emphasize that it's absolutely not Wind River's intention to contribute or, frankly, utilize code that's licensed under the GPL. We still have very strong opinions with regard to the GPL.
RL: I'm really speaking of things that have nothing to do with the GPL here. I'm talking about the fact that, for example, you have QNX and LynuxWorks who want to see a common "POSIX-and-beyond" standardization, including things like GUI APIs -- and I'm not talking about using any code, but rather the interfaces between chunks of code -- so that their proprietary OSes can be interoperable with each other and with Linux.
Fogelin: My sense is that I've been on many standards committees over the years and discussed interfaces, and there's always an agreement that everybody's going to go back and make faithful implementations that are semantically and syntactically faithful to those agreements. We've seen, however, whether it be the POSIX effort or any other standard, that in practice people go back and make slightly variant implementations. In my opinion, what the open source community provides us is a vehicle not just to agree on interfaces, but in fact to produce the reference code that's necessary to really allow people to collaborate and work on this. So to me, a standard is really only a standard if the code that backs it is available. And it's in this way, I think, that you find yourself challenged by putting the code out in a way that's licensed with the appropriate "business-friendly" license. So we will absolutely continue to use the open source vehicle to build such standards, we would certainly be interested in collaborating on interfaces, and we'll be in an excellent position now to bring some of these standards forward complete with implementations -- and doing those out in the open.
RL: I'm thinking that since these OSes (Linux, FreeBSD, QNX, LynxOS, etc.) are relatively similar in many of their APIs, it seems like there is a good opportunity to have common components that could actually be used in any of them.
Fogelin: Who was it that said "Standards are wonderful things, there are so many to choose from"?
RL: What do you expect the impact of the acquisition of BSD/OS to be on VxWorks? I gather you see UNIX as not having a lot of overlap with your VxWorks business?
Fogelin: No we don't. UNIX is a more resource-intensive environment. It tends to bring forth a file system that may or may not be in Flash, so you may or may not have a hard disk. You've got a virtual memory system that allows you to have run applications larger than the physical memory space will allow, and so forth. In that regard, it (UNIX) tends to find its profile in larger resourcefull environments. It will fit quite comfortably in the same channel at Wind River with our VxWorks and VxWorks AE offerings. And in fact, if anything, it's going to be a "1 + 1 = 3" because there are many instances, a 6U router for instance, that has a UNIX backplane and then you have VxWorks sitting within the line cards that are running things like the fiber optic connectivity or the Ethernet. That sort of configuration allows a company like Nortel or Lucent to have a single supplier provide not only the UNIX technology necessary to drive the main processor, but also the I/O control and the networking controls through VxWorks.
RL: So you probably won't be in a hurry to develop a small footprint "embedded BSD/OS" that can, say, boot out of 4MB of Flash, since it might cut into your VxWorks business?
Fogelin: We're not making a product announcement here, so I'm not prepared to declare the features of "BSD" or "eBSD", but I do want to say that one of the things we have is the opportunity in a frictionless fashion to take IP (intellectual property) from one operating system offering and make it available in the other. So I think over time you're going see a blurring of distinction between capabilities of these operating environments. But then again, from a merchandising standpoint and from a product branding standpoint, there will always be a POSIX-complete faithful implementation that will be referred to as BSD. But don't be surprised to start seeing some of these technologies, in a componentized fashion, float among any of these operating system offerings.
About John Fogelin: Fogelin, Wind River's sixth employee, began as "staff carpenter" for Wind River in 1987, building shelves for computers. From this auspicious start, he went on to help develop the wind microkernel, which resides at the heart of the VxWorks run-time system. Subsequently, he led the development team that built the revolutionary Tornado project. Today, Fogelin oversees all aspects of research and development for the Tornado tools and VxWorks operating system -- the technologies at the center of Wind River software. Before joining Wind River, Fogelin designed hardware for embedded applications used in devices ranging from biomedical equipment to arcade games. His interest in engineering is not limited to software, however. He has also crafted a seaworthy kayak, as well as a guitar, and is in the process of restoring his 1962 Volvo.
Related stories: Talk back! Do you have comments or questions on this story? talkback here
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
news feed