Wind River is celebrating their 40th anniversary as a company with a series of historical look-backs posted on the Wind River channel on YouTube. One of the videos is an interview with Jerry Fiddler who founded Wind River back in 1981, by Wind River current CEO Kevin Dallas. Jerry Fiddler talks about how he got started in computers, and especially about how Wind River got started and grew. It is both a fantastic set of historical anecdotes and some solid product management and strategy insights.
Jerry Fiddler Getting into Computers
Jerry Fiddler came to computers via a wonderfully odd path. He did music and photography before getting into computers. He says he got interested in technology from a couple of books he read in the 1970s. One was Ted Nelson’s Computer Lib/Dream Machines. The other Stewart Brand’s book about the MIT Media Lab (however, on checking the facts, that book by Stewart Brand only came out in 1988, about a decade too late. Memory is not always reliable).
He worked at the “electronic and computer music lab” at the University of Illinois, which obviously gave him some experience using computers (to produce music in some way). He said that he wanted a job as a resident composer for the resident dance company at the university, but you had to be a grad student to qualify. Since Fiddler had absolutely no interest in graduate studies in music, he instead got into the computer science department.
After a few more twists and turns (listen to the interview for the details), he ended up at Lawrence Berkeley Labs (LBL). At that point, in 1977, he was doing computers. Mostly real-time systems architecture and control systems. His last job at LBL was using an Intel 8080 processors to control a neutron beam source for a fusion reactor they were building.
Founding Wind River Systems
Wind River was founded in 1981, after Fiddler got tired of working for a government agency. The group he was working with was great, but the job not so much. His first job after leaving LBL was building very specialized control software for a video editing system for Francis Ford Coppola. Lots of super-precise control over machines that spun physical video tapes to exact locations in time. The system even included some very early touch-panel user interfaces.
Since he did not want to become an employee, he started a one-person consulting company and called it Wind River. This happened in 1981 (obviously). In a rather funny twist, Fiddler and his girlfriend then went on a year-long around-the-world trip… but since he did not want to lose the client, he hired Dave Wilner to do the job while he was out. Interesting way of running a company, but Fiddler definitely had a great year!
In the early 1980s, many companies sold operating system kernels. Often, as Fiddler recounts, as simple ROM chips that you would plug into a board to get the kernel. However, those kernels were not easy to use or develop for, as that aspect had been basically ignored by the developers. There was no networking, file system, or development tools.
There was a real revolution in control computers when the Motorola 68000 came out – it had enough performance to really replace the old minicomputers in industrial use. The microprocessors were smaller, needed less power, and a lot cheaper. But they needed software to be useful.
This was the niche that Wind River found to fill. Wind River ended up building tools around the kernel that they had bought to use in their consulting work, while doing that consulting work. The eventual name of the product, “VxWorks” came from that the fact that Wind River made Virtex work. Thus, Virtex Works, or VxWorks in short. Later on, of course, Wind River built their own kernel to replace Virtex, as it made little sense to ship somebody else’s product as a core to your own product
I had heard a slightly different legend… that VxWorks came from the idea that Virtex actually did not work at all, and that the kernel had to be replaced. I guess a story retold through generations of Wind River employees get a bit distorted. Good to get that clarified.
Fiddler makes the observation that you really want software people to do software. Not just hardware engineers who do software as an afterthought. Hardware engineers are typically happy to make something work at all – but do not automatically think about how you make the system useful for software people. They expected that maybe a few lines of software would be quickly thrown together, but it would not be all that difficult. A software person, you don’t see it like that. How do you facilitate programming? You expect the software to be big and much more complex than the hardware.
Which is something I absolutely sympathize with and recognize even today – without software support, even the best hardware features are totally useless and in practice worthless. That’s why today all silicon companies provide programming tools and APIs around their hardware, so that the products built with their silicon actually take advantage of the full power of the hardware.
Wind River was also very early (maybe even the first) to introduce the idea of remote access and remote work using the network. Until this time, you typically connected over a serial port which was very slow (downloading a new software build could take 30 minutes…). They took the Sun motto of “the network is the computer” and applied it to embedded. Early Wind River tools included such revolutionary concepts as remote interactive debuggers where you could use a workstation to look at the code running on the control computer. This is the standard pattern for embedded today, established in the 1980s with the help of Wind River.
Product vs Consulting
The Wind River story told in the video got really interesting at the point where Wind River changed (I guess the modern name is “pivoting”) from being a consulting company to a products company. Fiddler took a chance and fired all consulting customers, removing 100% of their revenue. In his mind, a small company can only do one thing well – and consulting and product development are not compatible.
When growing, Fiddler says that he could reasonably see two-three years ahead. Like going from ten people to 40-60 people. He did talk about billions of connected Internet-of-things devices very early… but the vision has not really happened as he thought it would. In particular, security and reliability are not really there at all.
The success of Wind River was built on being a software company with a strong background in methods. He says the first document that was ever written was a coding standard, which eventually evolved into quality metrics and code reviews – which nobody else was doing at the time. Provide a good system-level software experience.
The second part of the success was that Wind River designed support into the product. In order to scale the business they worked hard to provide help, documentation, and examples as part of the product offering. Competitors at the time that sold kernels were really consulting shops with a bit of code. Wind River on the other hand aimed to “ship a product on tape, and ship it over and over again”. This was tough to build, and required multiplying the engineer force “by a lot”. But it also let the sales multiply more times and out-grow the competition that was limited by the need to provide consulting people for each deal. Big investment that paid off in the end.
This is a really interesting point, and something that is still true for products that provide an API to their users. It is not obviously easy to find the resources and time to do that final polish – but unless you do that, a product will not be truly scalable as you will be bottlenecked on support, consulting, and working with the customers. There is nothing wrong with working closely with some customers… but every new user or new deal should not require a consultant to come along.
Working with Customers
Fiddler has some advice on building successful products: Do not ask customers what they need, they rarely know. Instead, you need to understand what the customers are doing deeply enough that you can propose solutions to them. Since early Wind River was a consulting house, they knew what their customers needed since they were or used to be that very customer.
This makes sense, and it is a good place to start, but I also think that it is a difficult understanding to maintain. How do you maintain the expertise in application building when your engineers are now working on tools for the application builders? These are rather different things. Fiddler does note this, to be honest.
Another aspect of the customer interaction is to avoid boxing yourself in to a certain application. Fiddler emphasizes that you can never imagine what the customers are going to do. Told the story of an early customer, a sawmill. “How hard can their problems be?” Turned out that the sawmill basically ran Catscans on each log that came in, and then optimized the sawing process for maximum profit as well as avoiding the expensive saws getting stuck on difficult parts of wood. On the fly, in real time. Fiddler could never have imagined that, never would have thought to go after the sawmill market – but when someone brings in a problem, you can solve it and learn from the process. Totally agree, that aligns with my own experience.
Towards the end of the interview, Kevin Dallas steers it towards talking about the future. The main theme here is robustness and security. Fiddler makes a good case that we need more robust and secure and attack-proof software for things like power grids, home automation, and all the other new applications where real-time highly available software is being used… but usually developed in a way that is not really even close to as strict as the classic aerospace and space applications where Wind River come from.
Fiddler goes on to tell some interesting security-related stories. For example, Wind River worked with the NSA (presumably the US National Security Agency) rather early, and that they audited the Wind River code and helped make it more secure! I had not heard about that before. Or that VxWorks was used in Formula I where the software had to be proven against the teams modifying the official software.
As could be expected, the Mars rovers were brought up. All NASA Mars rovers: Pathfinder, Spirit and Opportunity, Curiosity, and now Perseverance run some version of VxWorks. Fiddler talks about working with NASA, as well as the “classic” priority inversion problem that hit the Pathfinder mission in 1997. It is still extremely cool that a problem in a piece of software running on Mars was possible to remotely diagnose. Including using simulation tools for the software, back on Earth. Fiddler claims they could have fired up an interactive debugger and stepped through the code on Mars to diagnose the problem; but that was never needed in practice. Not sure how much fun it is to run a debugger with a 15 minute round-trip time to the target either.
I love his last advice to today’s Wind River engineering – “have fun”. Don’t burn out your engineers, and try to avoid death marches (at least most of the time). There has to be a life-work balance.
In total, I found this interview quite fascinating. I feared it would be some kind bland celebration, but instead it was an entertaining talk with a man who had a lot of good stories to tell. Maybe Kevin Dallas sometimes injected a bit much of current Wind River strategies into some questions and comments, in a way that felt a little bit forced… but not much. And overall, he mostly let Jerry Fiddler talk, and that was definitely the best way to do this.
Finally – WNDRVR – honestly? Why?