When boards are available, the hardware debugging occurs. The debugging process isn't only testing the physical components, however. Now, software can be run on the device. This may require you to build more prototype devices to allow more people to test it. Software drivers in Linux and the new hardware are debugged simultaneously. An added benefit is that the software may find problems with the hardware that would normally not be found until the hardware is in production, and vice versa. The next hardware revision should be stabler due to simultaneous hardware and software testing. Sharing the sample code written in Linux is easy and royalty-free.
The re-spun board may become a beta or even a final release product, but it's now ready for testing and use by software partners and customers. When these early-access people receive hardware, they receive Linux software that runs on the product. The third-party companies can use the developed Linux code as a template. For example, the real-time-kernel vendors can view the source code in Linux, and determine how software interacts with the hardware. Seeing live code in source form is better than just looking at documentation describing the product. By studying the template code, the new-software designers can better understand how to maximize their projects to run on the new hardware.
How does this work in real life? MCG is writing sample Linux code to take advantage of our new HA systems. We're now sharing this code with select real-time-kernel developers, other OS vendors, key third-party vendors (both hardware and software), and with customers. The Linux code jump-starts their efforts, and they can turn out a marketable product faster. More software vendors can develop code sooner. Instead of just working with one OS provider and writing the software ourselves, we can work with a larger number of vendors and let them adapt, with our assistance, their software to the hardware.
Today, we're sharing Linux-based software drivers for our new hot-swap controller with select vendors. The hardware is patent pending. But to be useful, we must have software using this device. These partners are utilizing the Linux sample code to jump-start their efforts. Instead of simply sharing APIs or ABIs, we can offer working Linux software. This Linux code doesn't need to go through a complete "productization" cycle, because it's designed as a proof-of-concept tool. Software, then, is ready sooner. We're also finding that some customers are asking us to make our Linux code a product. They would then buy Linux from us and deploy with Linux-based products. This could be a large upside to our Linux efforts.
Our hardware is now ready, but the software isn't there yet. We started the Linux work right before we released our first hardware product. We envisioned the software arriving in logical steps, allowing customers a chance to initially develop with it. Now these same steps are being accomplished by several real-time-kernel vendors. As the hardware evolves, the software under Linux will be ready soon after the prototype boards come from the labs. Then, our partners can see some software running on the boards and system prior to the hardware's final release.
Once we have OSs on the hardware, we'll need communication software and enabling tools. Also, because of our new HA system, we'll have to teach some software providers—third-party vendors and customers—how to write applications that can take advantage of the new HA features. Again, we plan to write sample Linux code for these partners and then share it with them.
As the software becomes freely available under Linux, more developers will look at, examine, and critique the code. Additional people will add features and correct bugs, too. This will result in a stabler software product and more efficient code. Also, software will be produced more quickly.
Instead of writing code specifically for one RTOS, we're writing Linux code and sharing it with five to 10 times as many software companies. These firms then support our new hardware and features. The end result is that our customers can start developing sooner with hardware and software that has been designed together.
Our process is sparking a revolution within our company. We're now considering offering all of our board-support and system-support packages with Linux to our partners and customers. Software and hardware engineers can work closely on debugging and producing more efficient products.
A side benefit will be for us to use Linux in our factory as part of our testing on the assembly line. Since the Linux code was produced in conjunction with the hardware, hardware tests with software can be readily available. The software moves from the lab to the factory to ensure quality products off the factory floor.
Another advantage is the cost of the operating environment. With Linux, the software is essentially free, but we incur the ongoing costs of supporting the Linux environment. Because we are constantly changing the Linux code for new hardware, the burden of supporting the OS, in addition to the proof-of-concept software, is minor. Our out-of-pocket cost for OSs should drastically decrease.
Using Linux as a development tool that follows the hardware-development process, we hope to produce better hardware and allow more of our software partners and customers to write software for our boards and systems more rapidly. So they can deploy a final solution sooner. That means they can sell their product faster. So can the hardware manufacturer.