7th December 2005, EUROCONTROL-EEC, Bretigny-Sur-Orge, France
Preliminary DEBRIEFING: lessons learned
by Marc Bourgois, EUROCONTROL, 15th Dec 2005
The challenging and at times very animated debate has lead us to formulate the following five insights:
- OSS is a reality for every business
- Licenses are not the barrier
- Communities which are successful
- Creating value with OSS
- No OSS experience in safety-critical domains
OSS is a reality for every business
The first and probably most fundamental insight came when asking the question “why bother?”. Why should EUROCONTROL bother about OSS? The answer is very simple and very generic, i.e. it applies to all organizations which are heavily engaged in software development: any organization or business is confronted with OSS, whether it set out to do so voluntarily or not. Any software being procured runs a high risk of including some OSS.
Any software being released runs the risk of being included in some OSS further down the line. And if it were not for one’s own suppliers or customers, one’s own software developers (a notoriously independent and free-thinking breed) are likely to rely on some OSS.
Depending on the specific licenses that go with the OSS, as we will see next, the risks can entail important commercial consequences. In one case, PHILIPS had to distribute tens of thousands of CDs. In another case had no realistic option but to release its software as OSS because of the inadvertent inclusion of OSS.
What can be done to contain the risks associated with inadvertent inclusion of OSS? Three measures are possible: (i) scan the software with specialized tools for OSS detection and subsequently eliminate its reliance on OSS; (ii) strategically decide on which software is commercially interesting and subsequently engineer an architecture that allows the separation of proprietary software and OSS; (iii) define an in-house policy (which should include the previous two measures) to increase awareness.
It became very apparent during the discussions at the roundtable that there is a lot of confusion in the ATM domain (and we would suspect in any domain only recently confronted with the open source paradigm) about what exactly qualifies as OSS. We had already identified the problem during our fieldwork preceding the roundtable. Most importantly, the concept of freeware is often mistaken to be identical to OSS; not in the least because both are often accompanied by very active user and development communities. One cannot quote enough the famous analogy of Richard Stallman, one of the gurus of the open source paradigm, that “free as in freedom, not as in free beer”. Terminology confusion has been plaguing the OSS community itself for as long as it existed as well. No wonder that, given the plethoric number of expressions – OSS, Libre Software, Free Software, FLOSS – the legal experts starting out their exposes at the roundtable with a set of definitions, which takes us to the second lesson learned:
Licenses are not the barrier
A facilitated brainstorming session at a recent CALIBRE conference let to the prioritisation of issues that have to be dealt with in order for OSS to become a mainstream paradigm. Legal issues ended at the sixth and last place; clearly licensing and related issues are not expected to be the showstopper. Our roundtable discussion strongly confirmed this appreciation.
There exist a bewildering number of open source licenses (200 by one count). The large number of such licenses is both a curse and a blessing. A curse because it leads to confusion and scares away non-legal people. A blessing because the license which would fit the requirements of your project probably already exists and merely needs to be adopted.
While admitting that the IPR issues surrounding OSS are complicated (even legal experts do not necessarily agree on all the details, as we could witness at our roundtable), the multitude of licenses can be reduced to three broad categories: (i) Free-for-All open source, (ii) Keep-Open open source and (iii) the viral Share-Alike open source. The categories are based on two basic obligations for the user of the licence: the need to credit the origin and/or the obligation to share modifications and possibly extensions.
In fact, the EUROCONTROL agency has already released one piece of software under an OSS of the second category. It concerned an ADA utility, which was re-integrated in the core OSS release on request of external users. Admittedly this piece of software cannot be considered an ATM application; nevertheless it offered a first opportunity for the legal service to get acquainted to the issues and to management to take a stance.
So the solution to the license issue consists in dealing with the issue proactively by formulating the exact strategic / commercial requirements of the project. This requires an early involvement of legal experts in order to reduce the risks and identify the appropriate solution.
Communities that are successful
Probably the most quoted strength of OSS projects is their (supposedly) large and responsive developer community. Proponents of the OSS paradigm attribute the quality and long-lived successes of OSS software projects to the abundant and free contributions of large distributed teams of volunteer developers.
As has been shown, many of these claims only hold for a very small subset of OSS projects; neither is the verdict on OSS quality easy or uniformly positive. The research on OSS has only just begun to investigate more in depth the relationship between characteristics of the OSS community and the resulting software quality. Indications are that the set of tools being used in the development process, the motivation of the developers are all factors which may positively correlate with quality.
Currently a trend can be observed of ever more developers contributing to OSS during their normal working time and with the full endorsement of their employers. This is a reflection of the maturity OSS is reaching in certain areas of software development; mainly infrastructure-related or so-called horizontal areas such as. The original assertion that large numbers of developers contributing for free are essential to successful OSS is clearly being countered by this evolution. The current assertion is more subtle and considers the quality of contributions (which by definition is relatively high amongst professionals) to be more significant than the amount of contributors. This holds promise for a small vertical domain such as ATM which would always have difficulty in attracting the larger base of “hobby” developers working from their homes in their free-time. Nevertheless the roundtable did go into a small excursion to explore how even an arcane domain such as ATM could tap into and motivate the larger community of OSS developers. One of the more promising ideas mentioned concerned creating a ATM simulator (much like flight simulators).
As mentioned before, several ATM experts presented early OSS experiences during our roundtable. Interestingly, two of these were described as “failed” OSS projects. One was a portal / forum created by EUROCONTROL in conjunction with another major ATM research centre. The portal was to host free software put at the disposal of the larger ATM research community for use, discussion and evolution. Surprisingly, although several research tools were uploaded, little or no activity took place on the forum. This remained unexplained until the OSS experts enlightened us on two “soft” issues determining the success of an OSS community: motivation and championship.
On the one hand it seems to be essential to involve the community early in order to avoid a “not-invented-here” reaction when they are confronted with a “fait accompli”. Rather than submitting finished contributions, the relationship between the contributing organization and the OSS community should be based on the golden rule of “release early, release often”. On the other hand, all new initiatives require an energetic champion, or “benevolent dictator”, to guide the often chaotic evolution of a self-motivated development community. Both lessons should be taken serious when selecting pilot projects for OSS adoption.
Creating value with OSS
Let us come back to the second OSS example from the ATM domain which was presented as a “failure”. It concerns an application called AudioLan. AudioLan, which implements Voice-over-IP for ground-ground communications between controllers [to be checked whether the claim of air-ground can be substantiated], replacing the analogue telephone switches, was originally developed on behalf of EUROCONTROL . The early version was quickly adopted by over 10 European sites, with 500+ positions.
For the second time, the OSS experts at the roundtable came up with a plausible explanation. Based on their wider experience, allowing them to draw parallels, they strongly argued that this effect is being witnessed whenever the piece of OSS is crucial to differentiate between the products of the industrial players. For an OSS effort to be successfully adopted by established industrial competitors, the application should not be central to the competitive advantage of their respective products.
In such situation fierce competitors may behave, quite counterintuitively, in an altruistic manner, contributing substantially to the standardization of the OSS functionality. A good example from a horizontal domain is the X-Windows implementation, which flourished under the sponsorship of an industry consortium because the application was not seen as providing any valuable product differentiation, but it was seen as a necessary enabler for user-required interoperability. X-Windows may be the best known such example of a reference implementation which has become the unique implementation, but it is by now means the only example. We believe that this insight holds promises for successful adoption of OSS in the ATM domain.
As pointed out in a CALIBRE interview before the roundtable, the question came up whether the ATM supplier industry is not already a service industry, and it would be fooling itself when behaving as if its major income stems from basic ATM applications and not from system integration, maintenance and other service activities.
No OSS experience in safety-critical domains
Finally, and here we can be very short, we noted the lack of OSS penetration for safety-critical applications. No examples could be found in the literature; neither could any be recalled by the OSS expert panel at the roundtable. It is worth noting however that there is ample anecdotical evidence of OSS communities which are very responsive to critical bug reports, much more responsive then what would usually be specified in contracts with proprietary software providers of safety-critical applications.
Does this mean that the ATM domains cannot benefit from the potential of OSS? No, it merely means that the safety-critical applications in ATM should not be the first to be explored. But then again, there are very many non safety-critical components in the overall ATM system, so plenty of opportunities to build experience with OSS exist. In fact, one ATM expert at the roundtable ably, but provokingly argued that ATM applications are not safety-critical at all, because the traffic is constantly kept conflict free by definition, offering several minutes of reaction time for the humans in the system to deal with outages of automated components. The argument continues to identify the avionics components as the truly safety-critical parts. With the unavoidable increased air-ground integration of future evolutions of the ATM system the borders of what is a safety-critical application and what is not are definitely going to blur further.
