|BlueSky Business Aviation News|
The open source, open architecture airplane (this grows increasingly awkward, I shall call it the open airplane as a shorthand reference to open source, open architecture) as a platform for innovation is a powerful means for reducing the operating costs of business aviation, allowing us to profitably serve the next layer of customers down the marketing pyramid.
This is crucial to generate more cash flowing through our industry so that we can hire more of the best quality people who can innovate and further reduce costs, bootstrapping a renaissance in aviation.
An open airplane can reduce costs, but an open engine has just as much power (no pun intended, really). I personally know people who are quite enthused about projects as esoteric as open source FADECs (I know; I need to get out more). Admittedly, an open engine may be more challenging than an open airplane in some respects, but it seems obvious to me that it is something that will have to be done sooner or later.
No doubt many of my readers understand that engine manufacturers have long since adopted the paradigm of selling engines cheap and making their money back on expensive repair parts. Obviously, an open architecture engine where parts can be made by any qualified vendor isn't going to be particularly profitable for the existing engine manufacturers under that paradigm. Not that the engine OEMs and their top tier suppliers can't make those same parts for a healthy profit, after all, they have decades of experience doing exactly that. But, it seems clear that for this engine, the correct pricing model is cost plus for the delivered engine. The distant rumblings that I hear from the engine community indicate that this may well be the paradigm they would like to adopt, and the open engine may be a terrific reason to adopt it.
The real challenge behind the open airplane
The real challenge behind an open airplane or open engine isnít really the idea of an open airplane or open engine, as wonderful as those ideas are. Those ideas just give us a point of departure, a conversation starter, if you will, something around which we may be able to create an industry consensus. There is still an enormous amount of work that has to be done and a lot of questions about how that would work exactly. Professionals hired to do the work? Design students at university? Frustrated airplane designers working in their evenings and weekends? Unemployed engineers looking to add something useful to their resume? Some of the above, no doubt, maybe a mixture, possibly primarily one group with a leavening of help from others. I havenít a clue, really. Iím open to all that and more (including the open airplane as a national program to provide a platform for innovation in the industry--perhaps the EU would be interested; Iím certain it would be a great deal less expensive than other current programs and infinitely more useful).
And itís not just the labor. In my opinion, even with the people available, there is still the huge question of the tools necessary to create a design. For open source software, each programmer has an example of his intended hardware target, a computer, with which he can work. There is nothing like that for aircraft or engines. We are only now getting to the point where there are open source CAD programs available, and I don't know if they have developed to the point where a serious project can make use of them. The ubiquity of the tools is what has made the revolution in software possible. Perhaps this is the next step in the open software revolution: open source engineering tools designed for collaboration.
The proper question, in my view, is not whether an open airplane project can be done with currently available open source software. It likely can, if only just. On the other hand, I think the cost of decent CAD software is within the reach of just about anyone interested in participating, and qualified to do so. But let us recall that aircraft have been designed, built, tested, and certified with nothing but pencils and paper for most of a century. The secret, if there is one, is in organization and design discipline. Good software simply makes it easier and faster.
The Proper Question
No, I think the proper question is how much more innovative could we be if we had open source engineering tools for computational fluid dynamics, vibration analysis, finite element modeling, and fatigue analysis. That is, if each engineer had the tools freely available to test his design in several different ways without the requirement (and expense) of going directly to hardware and to wind tunnels (I had a little thrill, what if all of those tools could be interactively integrated into one suite?). This would allow us to rapidly run through many more iterations of a design, refining it extensively before ever having to cut metal to verify. Yes, there will have to be a lot of academic collaboration to provide calibration points for various kinds of analysis, but academic people need projects, too. This is a win-win, really.
I want an open source, freely available, fully integrated suite of interactive engineering tools that spits out a STEP file at the end of the day that can be digitally pre-assembled into larger and larger assemblies and installations up to and including the entire airplane for analysis in flight. Also, I want to be able to send the STEP file to a manufacturer anywhere in the world and have it downloaded directly onto an NC machine for post-processing and part fabrication.
The Other Real Challenge
The other real challenge? The actual business of operating a profitable air taxi business targeted at the next layer of customers on the marketing pyramid. How is that possible? DayJet failed, and they had oodles of cash. What can beat mad cash?
Well, what if we separate the operations side of the business from the passenger aggregation side? That is, suppose we structure the business such that the people who own and operate the airplane (and it could be any kind of airplane; this is not specific to the open airplane) decides where they want to be based, and where they are willing to fly. They become an independent contractor, setting their own rates. The other side of the business becomes a separate business, one that aggregates the passenger demand. Think of them as a sort of dispatcher, and the operator as a sort of independent cab. This part of the business, the dispatcher side, doesn't even have to be for-profit. It, too, can be a sort of open source, open architecture business.
What does open source, open architecture business mean?
What does that mean, open source, open architecture business? I argue that it means that so long as the operator conforms to the published rule set (must be a commercially rated pilot, probably instrument rated, airworthy aircraft with current maintenance logs, properly insured, etc) they can participate as much or as little as they like. Keep in mind that this is air taxi, not scheduled service, and not a charter operation.
Part of the business process is a feedback rating on each operator, much as there is on eBay. In fact, the dispatcher side would operate a bit like eBay, facilitating the purchase of services by various customers.
Two levels of service
There should be at least two levels of service. The first is where people who do not know one another can make a deal for a flight between two airports. Perhaps ground transportation is added, or is a separate deal also facilitated by the dispatcher business in the same way that one can now book airfare, car rentals, and hotel rooms at the same time on the big commercial sites. This is a solved problem. We know how to aggregate these services in software; which is not to say that it cannot be done better in open source, just that we know effective solutions already exist.
One possibility is for a customer to put their flight up for bid. This would only work where there are multiple operators and sufficient time for the bidding process to work, but this has some real possibilities for those who will be making regular trips, or corporate travel offices which need to regularly schedule travel of this sort.
Otherwise, I think we get a pretty standard rate, so many dollars per air mile or Euros per air kilometer. The rate may be be different for different kinds of aircraft, or the operator may be able to state their basic rate, or use a more or less sophisticated algorithm to manage the yield.
The other service
The other main level of service is between two entities that have done business before. Think of it as a preferred provider and preferred customer relationship. Perhaps the customer's corporation has a relationship with a particular operator. Perhaps the customer had a really great experience with that operator and wants to fly with them again (maybe the operator is their nephew, who knows?). At which point, really all they need is the billing and scheduling part.
Benefits of one dispatching company
The operator gets a lot of benefits from the dispatcher company, the organization and scheduling of trips, the additional scheduling of ground transportation (and possibly even hotel rooms). Perhaps some quarterly tax help in the form of data on trips and payments. If the operator is one of the larger FBOs, they can offer additional services, more aircraft types, or something we haven't even thought of yet, and have those on offer through the dispatching company. These benefits would cost a lot if each operator had to develop them all themselves. Being able to essentially plug straight in to an existing, fully functional business that provides all of those services without the enormous inefficiencies from duplication of effort allows the operator to function with a minimal business structure, i.e., with the lowest possible overhead. This gives our operator a fair chance at making a good profit at a much lower price than current air taxi operators can; even lower, I think, than DayJet could, even in theory.
One dominant company, but room for specialists
One issue that I think we can all see is that it makes sense to have one dispatching company. Perhaps one per country or per region, or per continent. It would make the most sense to have one company globally, but that makes it a monopoly, and pretty much by definition takes it into the realm of government. OK, maybe not. Or, perhaps it could be run as a software service all around the world, a sort of global utility. Obviously, such a company would have a number of design challenges. Whether designed as such, the economics of it will drive the market to one dominant solution, the eBay of the air taxi world. There will probably be room for specialist operations, maybe seaplanes, island services, ski planes, helicopters or something very specific. For most people, it will be the one player. This is good as it allows the dispatching company to rapidly gain mass, which is crucial to success.
Pay for it, how?
Among the many challenges is how does it get paid for. OK, lets assume we get the basic software for free (maybe not, but lets assume that for the moment). That still leaves the cost of servers, bandwidth, maybe even a customer service call center, and some marketing, advertising, and public relations, to say nothing of salaries and benefits. The obvious solution is a surcharge on the fare. Perhaps a fix fee. Perhaps a percentage like (yet another) tax. So long as that fee remains reasonable, and the company policies remain without favoritism, I think it will be successful. This is a lot cheaper than trying to do it all yourself as the operator.
The single most important feature of the dispatcher company, in my view, is that we have separated demand aggregation from the operator, which, as I recall, was the big regulatory hurdle for DayJet, one that they solved in software. Why not solve it organizationally? Why not go fully open architecture? Surely, if such a thing can be made to work for a ground taxi, it can be made to work for an air taxi.
Terry Drinkard is a Contract Structural Engineer based in Jacksonville, Florida whose interests and desire are being involved in cool developments around airplanes and in the aviation industry. He has held senior positions with Boeing and Gulfstream Aerospace and has years of experience at MROs designing structural repairs. Terryís areas of specialty are aircraft design, development, manufacturing, maintenance, and modification; lean manufacturing; Six-sigma; worker-directed teams; project management; organization development and start-ups.
Terry welcomes your comments, questions or feedback. You may contact him via firstname.lastname@example.org
Other articles by Terry Drinkard: