Could open source build a jetliner?

Register or Login to like
Register or Login to like
Outline of a plane in the sky with clouds

I know this might sound like an odd question. It first came up in a conversation I had with Gary Hamel, the eminent business thinker and one of the first people to recognize the importance of distributed co-creation and that it will change management in the 21st century. We were discussing how the power of participation could replace traditional management for purposes of coordination and what it's limits might be. We ended up using the analogy of building a jetliner as our best example of where tight coordination is required. This question has been nagging on my mind ever since.

Airplanes are truly modern marvels of tight coordination on a massive scale. A well designed airplane is the result of tens of thousands of small design tradeoffs that are perfectly balanced and tightly managed. The end product is an engineering marvel that is a modern jetliner.

Design to manufacturing introduces a myriad of new coordination challenges. Hundreds of thousands of components must come together with minute tolerances. Indeed, the design and manufacture of an airplane represents the pinnacle of what modern top-down coordination can produce.

Which brings me back to the question. Can a bottoms-up, participative system develop something as complex as a jetliner,  considering it requires such close coordination amongst the various parts? The more I think about it, my answer is both no and yes. Here's my thinking and I would very much like to hear your thoughts.

My knee-jerk answer to Gary was no. That's not what participative systems are good at. Upon further reflection, I would more clearly say, "In the very short term and in the strictest sense of the question, my answer is no." While open source has shown an amazing ability to develop highly complex systems, it's power is the distributed nature of the innovation process. Look no further than Linux.

Think about how Linux is created. Those closest to individual components are able to drive optimized solutions to those problems. In these self-emergent systems, the underlying detail and complexity of the components can be far beyond anything a top-down, centrally planned system can muster. However, if those components must be tightly coordinated to work together, I'm not sure participative systems have a way to do that.

The more I thought about the problem, the more I realized that IT'S THE WRONG QUESTION. It is asking whether a participative system stuck into the middle of a traditional command-and-control ecosystem, can outperform it. And to that question, I still say no. The right question to ask is, "Could an open ecosystem in aviation produce a superior aircraft over time?" And to that question, my answer is "yes."

The power of participative systems in the bottoms-up innovation comes from having those closest to the problems involved in solving them. Linux is successful not because Linus Torvalds specified his requirements for each component, but rather because he did not. He allowed others, with different skills and expertise to drive the various components of the system, and ultimately the whole has benefited. If the various parties involved in the myriad components of aviation were allowed to drive their own designs forward, would the benefits of the individual components being superior offset the fact that they are not as tightly optimized to work together?

Let's again look at x86 and Linux as an analogy. For many years, tightly coupled RISC/Unix systems represented the ultimate in computing performance. They dominated high-end computing. Today, the performance mantle has moved to x86 and Linux. Red Hat Enterprise Linux alone, runs over half the world's equity trading volume—and those are systems bought for performance, not price. Why?

Simply, no single engineered system can keep up with the mass of innovation that is happening in an open system. Intel can drive it's microprocessor roadmap without worrying about "breaking" applications that are tightly joined to hardware. Application vendors can drive their own roadmaps without worrying about optimizing it for hardware. And Linux operates at its own pace. Each of these systems have innovated faster because they are not encumbered with the need to coordinate across the entire system. And together, open systems based on x86 and Linux now represent the gold standard for performance in computing.

What is the lesson learned from our experience with Linux and the jetliner question? An open system could not create the tightly coupled, highly coordinated system that is a RISC/Unix computer. Instead, it created something better, faster, and cheaper. Why would aviation be any different?

Jim Whitehurst is President and Chief Executive Officer of Red Hat, the world’s leading provider of open source enterprise IT products and services. With a background in business development, finance, and global operations, Whitehurst has proven expertise in helping companies flourish—even in the most challenging economic and business environments.


I think the more appropriate question is: Can you build a jetliner for 2000$? Linux took off because everybody could afford a PC and had a strong incentive to make their PC work better by improving Linux.

The same thing is happening right now with do-it-yourself drones and there is already stuff popping up like OpenSource UAV autopilot software.

It will probably will take a couple of decades and maybe a new generation of engineers, but I'm sure a lot of this stuff will be used in the jetliners of the future.

This is a fascinating concept. In the computer/tech world, we have the 7 layers of the OSI model that helps "coordinate" some of this effort. Projects/companies can work on the physical, data, network, appliation layer, etc. without impacting other layesr. Open standards also play a role in this.

I wonder if there is an equivalent to this in aviation that would help foster this type of collaboration.

This is an interesting topic, but there's another interesting question, which you only tangentially touched on. Specifically, the level of systems integration in the manufacturing of a plane is enormous. Open source's greatest strength, and sometimes it's greatest weakness, is that everyone can (and sometimes does) fork and splinter projects, rather than cooperate and work together.

Note that I'm not saying that this can't be done, but it might be interesting to ponder who is the ultimate 'Benevolent Dictator for Life' (ala Linus) when it comes to the overall systems integration of components for an airliner.

Thanks for a great article to spark an interesting discussion.

There is a clue in the current world of Open Source goodness:

Wonderful, complex software, pffft for hardware.
That'll change some as 3d printers do more and more of the work, but Open Source seems to work best when:

1. There are common elements that do not confer competitive advantage -- like operating systems -- and cost savings leverages work on other components.


2. Enough people with skills, interest, and resources exist to make it happen -- a la the GIMP and the original Firefox web browser

That "resources" angle is a biggie. Whether its a fab, autoclave, test rigs, etc, most of us don't have the kind of resources to do the things a jetliner requires. Heck -- most of us don't have any actual need for a jetliner.

Open source is great for a lot of things. Probably good for lots of the things that go into a jetliner. The plane itself?

Hard to imagine.

I suspect an open design approach could work well for a jetliner and many other pieces of large hardware, but it would require industry investment and a radical shift in ideology. If carriers were to invest in design engineers and form a consortium dedicated to the design of planes, they could drive costs down on new planes - instead of Boeing and Airbus each designing a new plane, investing 100% of the time and money in TWO new planes, the end users could design one plane to their specs and take the lowest bid on testing and, eventually, production. As with open source software, smaller players (smaller carriers or other interested parties) could offer their voice and input to the design process, benefiting themselves and their larger competitors at the same time.

Now of course I've glossed over much detail here - nothing is as simple as one paragraph. But I could see an open design philosophy allowing the end users of large goods to drive the design process and create cost savings. You end up with a product which directly reflects the needs of the users rather than being 1 step removed and those users can compete on their ability to provide service, driving costs across the design and use chain down in the process.

I think the analogy of Linux and construction of an airliner is a bit flawed. Linux was successful because Linus had a vision, and had the will and tenacity to drive that vision. When it took root, he also had the intelligence to let it go and grow with the aid of many others.

For an open source airliner to be successfully built, it would need an initial visionary, a champion to lead it through the initial phases. Once it had been accomplished (or nearly so), secondary players (like the many branches of distro's of Linux that exist) would come forward and start their own open source aero companies. We're lacking the brave (foolish?) individual that can start that process.

But I look forward to seeing that person try.

Complexity is not the issue with this analogy. It's the cost of the tools. The tools and equipment needed for airworthy commercial aircraft design are *way* beyond 99.99% people's budget. So your development community will be a hand full of Elon Musks, John Carmacks. The Linux kernel is very complex indeed, but almost every individual in the western world has access to the tools to contribute.

Spot on, Joe. The difference between creating software (Linux for example) and an airliner is the barrier to entry for "participants".

The risk for Linus Torvalds was his time or rather passing up the opportunity to do something else with it. The risk for an open source manufacturer to propose a new wing design would be in the tens, if not hundreds, or millions of dollars.

Torvalds' work, stunning as it was, had no warranty attached to it, which is the case for open source software. I might be very willing to risk a couple of days and some CPU cycles on an interesting piece of open source software, but I'm not risking my life flying in something where no one entity has legal responsibility for its design and manufacture.

Open source brings a wealth of creativity and function that most of us, myself included, could never hope to produce on our own or afford to buy. But it always comes with the inherent risk that if something goes wrong, you're dependent upon the kindness, of which there is much, of others or your own potentially inadequate resources to fix it.

At 35,000 feet, I'd rather not have to post to a mailing list if the wing looks like it's going to come off.

Yup, yup, yup.

The linux kernel cost millions to develop if you consider the value of the programming talent required to get it to its current state. However, that talent was provided by thousands of people who had the time and talent to offer. There was, arguably, some opportunity costs incurred, but not major out-of-pocket outlays.

Hard to build a jetliner without some major out-of-pocket outlays.

"Open" doesn't have to mean "massively distributed development" though.

An Openly Transparent development process for an airliner, led by air carriers, would drive production costs down due to increased competition to build the finished product and reduce vendor lock in. It's about reducing duplication of effort - why should two companies create essentially the same technology, with associated costs, when they're going to produce the same amount of goods in the end? (To clarify: certainly, let them create competing products, but, like with Linux, let them re-use existing "code" in doing so)

Instead, let them compete to produce the airliner that an open process has decided is the best airliner. The ability of a competing carrier to make improvements to this open blueprint would be the impetus for innovation and goad to make the product the best possible.

That is essentially the airplane manufacturers are doing with subcontractors. They create a design and then let others bid on producing pieces of it. Without doubt, some of those suppliers have come up with innovative solutions the primary manufacturer hadn't considered. This is the same thing that happens within the diverse contributor community to open source.

If we had to pay all of the great people who have created the open source software we rely on today, the cost would be staggering. They do it because of they have a communal spirit and it's fun. Otherwise, they'd stick to their day jobs.

I'm certainly grateful to all of them.

The reason I think it won't work in the medium term is vested interests protecting themselves through buying regulation. This can be anything from patents over inspections to no matter what. Free and open source software were a historical accident with a spectacular evolution moving more quickly than those buying laws could react.

Not sure who the vested interests are, but the FAA sort of likes to know who's building things and who's accountable for them, particularly when hundreds of live are at stakes.

Open Source software is rarely used, without exhaustive, proprietary testing in life-safety applications. At least not by responsible practitioners.

The jetliner example is ambitious, and as many have already cited, the tools and materials needed to make a prototype let alone scale up to production does not lend itself to an open source or crowd sourced project. Jetliners with the inherent liabilities and safety issues trigger a response in customers and regulators that they need a single "throat to choke" if somehting goes awry. Starting smaller, there are a number of aviation projects that have been supported by entusiasts and the EAA (Experimental Aviation Association) for years. Kit built or plan built experimental aircraft have a lot of the positive qualities of the open source community. Most of these start with one person or a small group with a vision to build a lowest cost flying machine, or in some cases a machine that does something nothing else does. Along these lines FAA came up with an unlicensed category of aircraft. The FAR part 103 ultralight. Most of these are flying lawn chairs, but you can look them up online and see an insane variety of designs from powered parachutes to carbon fiber speed demons. This is also an area of contention because the part 103 rules are so restrictive that there are very few truly legal planes. most are heavier, or faster, or carry more fuel than the rules allow. in computers, this is called innovation, in flying, innovation usually means breaking rules that carry weight of law.

If your computer crashes, no problem.

In a previous life, I made parts for planes. There is a reason they do it the way they do. In fact, the current process of making planes is not arbitrary, it has been a process of evolution. The important issue of safety, for example, has created a chain of liability.

If I don't use the right type of teflon insulation on my wires, or the gold plating is too thin on the connector pins, the company I worked for might be put out of business if the plane crashes.

If I contribute a subroutine that induces a buffer overflow on line 5436885 in the linux kernel, no biggie.

What most people don't know is that there are extremely rigid requirements for producing any software for use in commercial aircraft. The DO-178B document details criteria that should (or must) be considered for any software used in airborne systems. Few of us, myself included, have ever labored under the level of scrutiny it imposes.

But as Bob Jones points out, there are reasons for these design criteria. Hard experience, purchased with human lives, has determined a software development model that not only assures accountability, but also provides a consistent analysis process that permits precise fault analysis.

How often have you heard of a airplane crash traced to software? The answer is, none that I can think of.

That said, NASA, the real rocket scientists and progenitors of these types of development processes, managed to crash the Mars lander into the planet because they got their measurement units mixed up.

Anyone else notice the plane in the wire-frame diagram of this article has blades rotating in the same direction. Is this the first bug report?

Why start with aeroplanes - seems like the endpoint (or near endpoing - star trek being the endpoint) rather than the startpoint.

I have been toying with the idea of the open source car - there are already initiatives out there but getting that going would be a first step. Establish the processes and thinking around open source design (think Arduino) that any manufacturer can pick up. Design it on a lego type system so you can mix and match to your requirements (parts and connections are universally compatible) and make it electric / hydrogen based. That is an achievable goal - and it will lay the ground work for more ambitious projects so that one day - open source aircraft might be a viable option

The rise of 3D printings, particular those that use materials appropriate for load bearing structures, mean an open source car may be closer to reality than an airplane. In this case, assuming certain critical safety systems are assured (brakes, steering, crash protection), a user designed car may be in our future.
One of the major auto manufacturers had a "skateboard" concept where they used a common chassis and powertrain that could be mated to a variety of bodies. That concept would provide the public with the opportunity to design a body that met their practical and aesthetic requirements, while reserving the truly capital and engineering intensive aspects of the vehicle were produced to strict, tested standards.

Riversimple is developing an open source urban car powered by hydrogen. The development is principally by Riversimple because of the complexities of dar design and the difficulties in enabling distributed working on such difficult items (no realistic open source CAD systems or affordable collaborative proprietary systems). It is open source to encourage others to make using the same components thereby reducing costs to everyone and increasing efficiency. Well worth taking a look. Legals are certainly entertaining.

I get the feeling we are getting bogged down by complexity. If we look at the cars on the road today and try and opensource that - no chance. But that is not how open source works.
Didn't Ferrari start in someone's garage?
Start with a basic design using available parts where possible - use existing engines => V .01
Then let opensource methodology take over.
If Torvalds had aimed at current linux at the start unlikely it would have gone anywhere.
Ultimate goal: a car that can be built from standard non-proprietary parts sourced from preferred supplier. Car either assembled by specialist outfit or DIY.
Will it compete with BMW, Merc, Porsche etc - probably not - but then that is not the point.
Disclaimer: I have no automotive experience at all - couldn't tell you the difference between a diff and a cam belt - so could be talking rubbish.

Riversimple are not looking at the cars on the road today. That is exactly the issue. They have taken a long look at who an environmentally friendly urban car should be and how it should be financed etc and have come up with something quite different. You won't be buying a Riversimple vehicle but leasing it. Although the design is open source, you won't be tinkering with a Riversimple car but there will be nothing to prevent you looking at the designs or building your own as a hobby project (if you can!) or even setting up your own plant and entering manufacturing.

Current automotive manufacturers have minimal interest in changing their world. It's too complex an area for someone to break into the traditional automotive industry without huge huge backing. Open source makes an alternate viable.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.