Sylvain Wallez
email: wallez@anyware-tech.com

Open Source Software: Risk or Opportunity?

Keywords: Risk or Opportunity? open source, business model, tools, software vendors

under the GPL at will, provided you do not inhibit others from doing the same. The GPL also requires works derived from work licensed under the GPL to be licensed under the GPL as well, thus forbidding commercial proprietary use (and abuse) of free software.

The word "free" has two meanings in English: "liberty" and "at no cost", which is often explained as "free as free speech" vs. "free as free beer". Stallman was referring to the free speech. This political message combined with the constraints of the GPL led many software companies to reject free software outright, as their primary goal is to make money, and not the philanthropic action of adding to the common knowledge.

Open source software: in 1997 a group of leaders in the free software community tried to find a way to promote the ideas surrounding free software to people who had formerly shunned the concept. They were concerned that the Free Software Foundation's (GNU's umbrella organization) anti-business message was keeping the world at large from really be involved in free software.

One of the outcomes of the discussions was that some marketing was needed to win mind share and move away from the political meaning of "free" used by the FSF. This is where the term "open source" comes from (also written as OSS -Open Source Software). A series of guidelines were crafted to describe software that qualified as open source.

The Open Source Definition [START_REF] Perens | The Open Source Definition[END_REF] allows greater liberties with licensing than the GPL does. In particular, the Open Source Definition allows greater promiscuity when mixing proprietary and opensource software.

Consequently, an open source license could conceivably allow the use and redistribution of open source software without compensation or even credit. This allows companies to use open source software in their proprietary products, but also allows them to release some of their software as open source.

But why would a companies release their source code for free to the world, including their competitors? For a number of reasons, but the most compelling is that it gets greater market share for their code. In this way, giving away source code is a very good way to build a platform. We will largely expand on this subject in the paper.

Nowadays, along with "Free Software" and "Open Source Software", the "FLOSS" acronym (Free/Libre and Open Source Software) is used to refer to both types of software whose source code is available publicly.

Achievements of open source software

FLOSS is something that cannot be ignored, as everybody that uses a computer nowadays uses open source software directly or indirectly.

The internet infrastructure: the GNU project's original goal was to build a free version of Unix at a time where the Internet was growing, and the first major achievements are in the server infrastructure: the Internet's domain name server infrastructure is powered by BIND, and most email messages are routed either by Sendmail or QMail Separate from the GNU project, and leader of the OSS movement, the Apache server powers more than 2/3 of the web servers worldwide, and most of these servers are running a FLOSS variant of Unix, such as Linux, FreeBSD or OpenBSD.

Development tools: next to infrastructure servers came development tools. It started with Emacs, a versatile text editor that is so extensible that fullfledged IDEs were built on top of it.

A very important project is GCC, the GNU C Compiler that over the years has become a generic purpose compiler for many languages and many target hardware platforms, and is the base of GNAT, a well-known Ada compiler.

More recently, the IDE market has seen the emergence of serious open source contenders. This started with NetBeans, a Java development environment. Then in 2001, IBM decided to opensource a large part of their commercial IDE, and created the Eclipse project. This project is now developed by an impressive number of companies that contribute resources for free, and which led Eclipse to now be the platform used by most of the large-scale IDEs on the market. Desktop software: this is a domain where FLOSS started rather recently, but where it is quickly growing. This includes tools such as the Mozilla web browser and email clients, the OpenOffice suite that is more and more chosen in public sectors and administrations. Also, the Linux graphical environments, Gnome and KDE have now reached a quality that allow the use of Linux as the desktop operating system in many enterprises, along with being the operating system of choice of many hobbyists and students. This last category is worth considering seriously as they are tomorrow's engineers and managers.

Open source licences

One of the first things to consider when it comes to open source software is the licence. There is a wide variety of licences that are approved by the Open Source Initiative [START_REF]Approved open source licences[END_REF] that specify what you can do with the software and the associated requirements you must comply with.

These licences can be classified by the constraints they impose to commercial users.

The GPL (General Public Licence): the original "free software" licence. This is the most constraining, as it states that GPL-licensed software must be redistributed in source form, and that any work derived (i.e. built with) GPL'ed code must also be licensed under the GPL. This is why this licence is said to be "viral". Practically, this means that no closed proprietary products can be built with GPLlicensed software.

There are some ways to build commercial value with the GPL though:

• By using GPL-licensed code but not redistributing it. This includes in-house use and also selling services with the software. A number of large e-commerce websites heavily use GPL'ed software.

• By using "dual-licensing": a company that owns the copyright of a product can distribute it under the GPL for those people that accept its constraints, and using a traditional commercial licence for commercial users. This is a way for companies to win market and mind share with the free version while still making revenue with the commercial version.

This dual-licensing model is used for example by MySQL with the namesake database engine or AdaCore with GNAT, the GNU Ada Translator.

The LGPL (Lesser General Public Licence): this is a relaxed version of the GPL, which restricts its viral nature to "extensions" of the software. LGPLlicensed code can be used in proprietary software.

However, this license has a clause that states that users should be able to upgrade LGPL-licensed part of the software on their own, and that it may include the ability to reverse-engineer the product.

The MPL (Mozilla Public License) and the EPL (Eclipse Public Licence): these licences were written by two companies, Netscape and IBM respectively, to cover the large code bases they open-sourced.

These licences put no constraints on derived works, which can choose any license they like, including closed-source commercial ones. It does require though, that any modification of the original source code be republished to the originating project.

The Apache and BSD licenses: these licenses allow unlimited use and modification or the open source code base, but require crediting the original author in derived works.

These licenses are very commercial-friendly and projects using this license often receive some corporate investments.

Intellectual property and patent issues

An important point to consider when using open source software is the patent issue. Many licences have some clauses protecting users from being sued for patent infringement because of their use of software covered by that licence.

The Apache Licence, for example, states that each contributor to the licensed software grants it users a perpetual, worldwide and royalty free patent license to use the software.

To allow this clause to be effective, most open source groups and organizations require that, prior to contributing code, contributors do sign a "contributor licence agreement". Basically, this agreement states that the contributor has the authority to decide what should be contributed as open source, and accepts the contribution to be redistributed under the open source license. And when the contributions are developed on paid time, the employer also has to sign a "corporate contributor license agreement".

It is to be noted that contributing code to an open source organization doesn't mean giving away authorship and copyright, but just a license to use the code. The original authors keep the copyright on their work (in some countries such as France, giving its copyright is actually legally not possible) and thus the right to do whatever they want with it.

Open Source ecosystems

An open source product cannot exist without a community around it. This community not only takes care of the product itself, but also builds a number of peripheral activities that derive from the open source product and nurture both its development and its developers.

The parties involved and the process described here below is what can be found at the Apache Software Foundation [START_REF]The Apache Software Foundation[END_REF], an organisation that is not only wellknown for the Apache web server, but also for being one of the first and most successful open source development groups.

Open source software: this is the result of the common work of all members of the ecosystem. Good software is not all that is needed to have a successful project. A motto of the Apache Software Foundation is that "the community is more important than the code", meaning that without a surrounding healthy group of people, a software product, as good as it can be, is a dead end. Tim O'Reilly once analysed some distinguishing features of successful open source projects, and came to the conclusion that architecture played an important role in allowing people to contribute. This is the "architecture or participation" [START_REF] Tim | The of participation[END_REF]: the product must allow people to quickly understand pieces of it and start contributing on peripheral parts without having to know the inner details of the whole product. So, a componentized and decoupled architecture, along with being a good technical practice, is also a key community growth factor.

Users: they are obviously needed. Without users, a project is dead. They first download and use the product, then start asking questions on discussion forums. Some will also start contributing either by answering on the forums or by sending code corrections and evolutions.

Users will also often ask for support that goes beyond what the forums can provide, and then will enter a traditional business relation with field experts, most often employed by sponsoring companies. They also will be interested by commercial extensions to the open source software, that allow them to achieve their project's goal and deadlines faster while still benefiting of the advantages of open source foundations for their project.

Mailing-lists and Forums: open source projects are developed in the open by teams that are geographically distributed. The mailing lists and forums are the virtual places where the projects live.

There are often several discussion areas, dedicated to users and developers.

The users forum is where people can ask questions and get answers, which are given both by the developers and other users. Compared to commercial vendors support offerings, users forum are free of charge, and allow people to get in touch directly with the developers.

However, the users forums do have some limits because of their free-of-charge nature. Questions must be concise and precise, otherwise analysing the problem takes too much time for a volunteer effort. What that means is that these forums require people to have the necessary skills to spot their problems, and that questions of a more general nature, such as architectural concerns cannot be answered there. This is where sponsoring and expert companies come in the game.

Developer forums are where actual development of the open source product takes place. Design discussion in public, which allows users to know what happens, voice their concerns and bring their ideas, participate and ultimately, after a number of contributions, become part of the development team.

Development team: also known as "committers" because they have the rights to "commit" modifications to the project's configuration management system, they are those who write the code of the open source product. Most open source projects use a meritocratic process. The more people participate, the more they earn merit and thus rights. Developers are grown-up users that have contributed on a regular basis and were therefore invited to join the developer group.

Supporting companies: licences have an influence on the nature of the development group: commercial-friendly licenses allow companies to have some of their employees working on open source products. This is not a philanthropic act, but a business strategy, as we'll see later, since it allows companies both to have an influence on the product's roadmap and be in a privileged position to sell derived products and services.

In this regard, developers are for the company much more than technicians: they are also strong marketing assets and the link between users of the open source product and the company's associated offerings.

Open source organizations: last but not least, the organization that hosts the project. Users too often see this important actor in the system as a simple web site. A successful project cannot exist without some kind of structure, and over time some large organizations have emerged, each specializing in its own domain.

Open source organizations have several roles with regard to the other elements of the ecosystem:

• Infrastructure: a project needs a website, a configuration management system, some mailing lists and forums. The hosting organization provides hardware resources and network bandwidth to the project. This is the bare minimum that can be offered by the organization.

• Legal framework: contributing and using some open source code inevitably leads to the question of patent issues. What if I accidentally violate a patent with the code I contribute? What about users that use that code? The role of the organization is also to protect users and contributors from legal issues by taking responsibility of them.

• Oversight and guidance: as in all collective human activities, personal problems and conflicts can arise in a project. And since the various contributors often have no authority on each other, the role of the organisation is to take appropriate actions when mediation has failed.

In some rare occasions, this can go up to evicting some people from the development team.

• Incubation: working on an open source project doesn't follow the same rules are traditional inhouse development. Large organisations such as the Apache Software Foundation or the Eclipse Foundation have set up incubators [START_REF]The Apache Software Foundation[END_REF] where newborn or open-sourced projects start their life and learn "the open source way".

Why industrials use open source software

About six years ago, the author's company started an offering related to web application development in the information systems (IS) area. This offering was built using a number of open source products, but we avoided mentioning "open source" when showcasing our products to customers. At that time, it conveyed a negative image of low-quality code, written by insomniac students or academic researchers. Today things have dramatically changed, and stating that our offering is based on well-known open source products, the development of which we're actively involved in, is considered as a real bonus by our customers.

This isn't a temporary fashion effect, but a real longterm trend. Today, most of the infrastructure and middleware software needed to build a project in the IS domain are available for free. This is a side effect of the standardization of protocols and service interfaces that has happened over the last years in this domain.

The growing complexity of IS systems had a number of consequences. Rewriting everything from scratch for each project wasn't economically viable, and components had to be reused to speed up development. Also, projects had to be an assembly of products from various origins because no company, except huge ones, were able to provide all-in-one-product solutions.

4.1 The "commons" and the standardization process

Out of this came new needs and concerns:

• The need for "commons": these are the common components that reused again and again to avoid reinventing the wheel for each project.

• The need for interoperability. The various parts of the project need to be interoperable, and more importantly, interchangeable. This because customers want to avoid being "locked-in" with a given vendor.

The need for commons led some low-level open source products to appear: these aren't finished products that can be used out of the box, but building blocks that allow to develop faster.

These commons have no strategic value in terms of trade secrets or intellectual property for their users. For example, an XML parser, a web server or even a workflow engine are just "enablers" that allow to implement the actual business logic.

So some people started to work on these commons within open source projects, to share development resources on these basic building blocks.

The need for interoperability led software vendors to work together to define standard interfaces between software layers, so that products from various origins could easily be assembled together.

Some standardizing organisations have put open source at the very centre of their process. For example, the World Wide Web Consortium (W3C), that defines the web standards, only makes a specification final once at least two implementations exist for it, so that the ability to actually implement it is proven, and requires one of these implementations to be open source. This ensures that the specification won't stay in the hands of a single vendor, and will be available for free to everybody to evaluate it.

The same applies to the Java platform: the Java Community Process (JCP), that gathers companies and users involved in Java-related products, has to provide a reference implementation of each new specification. Most of these reference implementations are developed as open source products. A key point also is that users are involved in the standardization process along with vendors, thus ensuring that the specification meets their actual needs.

So more and more in the IS domain, there is an offering of open source products that allow new specifications to quickly spread in the industry.

As we'll see later in this paper, this doesn't prevent commercial business and even encourages it. The open source product becomes a commodity available for all, and vendors can provide valueadded complements to this commodity.

Choosing an open source product

Choosing an open source product must be done with care, especially if this product is to have a central role in a company's information system.

The evaluation criteria are both technical and nontechnical:

• Consistency with the existing environment: the product must use the technologies that have been chosen or already exist, and should be easily connected, if needed, to the existing environment.

• Maturity: how old is the product? How many stable releases has there been already?

• Project health: what is the release frequency? How many people are in the development team?

• Community health: what is the traffic on the user and developer forums? How fast are user questions answered?

• Commercial support: are there some companies that employ developers or sponsor the project? Do they provide support, services, training or additional products?

These criteria aren't always easy to evaluate, and there's no central directory where to find this information. This likely to change soon with the recent "Business Readiness Initiative" [START_REF]BRR -The Open Readiness Rating for Open Source[END_REF] which aims at defining a standard model for rating open source software.

Why software publishers move to open source

Commoditization and complements

When a specification exists for some software layer, a lot of people rely on it, and can therefore join forces to build a common open source implementation of that layer. This implementation then becomes commodity and allows companies to build products of higher value and technological interest on top of it. That's why a lot of software publishers have based their offerings on open source foundations, and participate to the development of these foundations rather than maintaining their own parallel branches. And their participation strengthens the open source group in a virtuous cycle.

A great example of this is IBM, whose Websphere product uses a lot of open source products from the Apache Software Foundation, while still providing some distinctive features that justify its price. We also see some vendors that invented a "nonstandard" technology deciding to open source it, or at least its foundations. A good example is BEA with the Beehive project [START_REF] Schmidt | Beehive, A case study for new open source business models[END_REF], which they donated to Apache. This allows them to avoid vendor-lock in fears expressed by their customers, while still allowing a sustainable business of tools, extensions and services.

Joel Spolsky expands [START_REF] Spolsky | Strategy Letter V[END_REF] on the effects of commoditization on business strategies: demand for a product increases when the prices of its complements decreases. By collaborating to open source projects, publishers actually reduce the price of their product's complement to zero.

Dealing with obsolescence

Another phenomenon that drives software publishers towards open source is the technological obsolescence.

A software product is composed of several layers. The bottom layer is the platform: the operating system, the programming language and its standard libraries. Then comes a set of reused components that provide additional features to the platform.

The actual product is built on top of these lower-level blocks, and each layer clearly brings different features.

Now as time goes by, each of these layers evolves and grows, which leads to some functional overlap. These overlapping parts become obsolete, as the lower-level blocks provide the same to a wider range of users and at a lower cost. So how should this overlap be dealt with?

The platform/OSS components overlap is easy to manage: the OSS components that have been obsoleted disappear after a transition period, since there is no more community interest for them. It is to be noted that this overlap is sometime caused by the platform integrating some open source components, such as what happens in Linux distributions or the Java platform.

The OSS/proprietary components overlap is less easy to manage, as it affects the intellectual property and commercial assets of the company. And this is actually one of the driving forces that lead publishers to contribute to the open source software movement.

There are 3 types of answers to this overlap:

• Ignore it. This is probably the worst choice, as the overlap will continue to grow, and at some point in time, the open source solution will destroy the market for the whole commercial product.

• Replace the overlapped part by its open source equivalent. This solution is to be adopted when the open source solution is already mature and well established.

• Embrace the open source solution by contributing to it.

In the IS domain, more and more publishers are going for this 3 rd answer. Although it can at first look like giving away some resources and intellectual property, this is actually creating some beneficial conditions for the proprietary product that then becomes a complement to some commodity. Also, it gives the company some influence in the evolution of the open source components, so that they can better fit the needs for the upper level proprietary components.

Finally, and this is not to be neglected, it also gives the company an enhanced visibility, and some additional channels to market its offering.

Developing commons

Embracing open source foundations for a commercial product is also a way to develop commons that are shared between various companies working or even competing in the same domain.

The best example of this is the Eclipse Foundation [9]: in 2001, IBM decided to open source a large part of their commercial IDE, Websphere Studio Application Developer and created the Eclipse project. The reasoning being this move was that modern IDEs were more about providing very sophisticated tools such as project management, requirement traceability, modelling and simulation tools, etc, rather than about managing files in a project and launching a compilation process.

In a few years, an impressive list of companies has joined the Eclipse Foundation (which is now an independent non-profit organization). Many of them are editors of commercial IDEs that work together on a common platform, each keeping its own added value and commercial products on top of this common platform. This has been explained very well by Patrick Kerpan from Borland in "the IDE is dead, long live the IDE" [START_REF] Kerpan | The IDE is dead, long live the IDE[END_REF]: for more than 20 years, Borland has been writing IDEs, and each of them needed file management, standard menus such as file/open, file/save, etc. And each new generation of the IDE requires rewriting these low-level features. So when seeing the success of the Eclipse platform, Borland made the strategic decision to collaborate with its competitors on a common platform. This allows them to concentrate on the higher-level distinguishing features that are their real expertise and that customers are interested in.

Open source trends in the embedded software world

Open source software is now a key element in the information systems world. Now what about the embedded software world? It's coming. It even has been already there for some years with the gcc compiler, which is used in many cross-development tools, and is the basis of the GNAT Ada compiler.

But the embedded software domain is also very different from the information systems, as embedded systems both need to be carefully optimised, and often need to be certified.

That is why, contrarily to the IS domain, open source is coming first through tools rather than runtime components.

Tools as complements to realtime operating systems

Realtime operating systems vendors mainly sell runtime licenses of their operating systems. Tools are there to help selling runtimes by making development easier, but aren't their primary differentiating feature on the market.

A few years ago, QNX decided to join the Eclipse Foundation and build there the C/C++ development environment. By doing this, just as Borland, they benefited from a huge set of features brought by the platform, and shared resources with other actors interested in seeing support in Eclipse for these programming languages. They of course kept their commercial IDE offering, which is now a thin layer dedicated to their particular operating system.

About one year ago, Windriver, a major player in the realtime operating system arena, also joined the Eclipse Foundation. And we now see QNX and Windriver, competitors, working together on a common platform, just as Borland did in the IS domain.

Long lasting development environments

Embedded software often has a lifetime far more longer than IS software, and maintenance has to be possible for many years or even decades. So industrials must ensure of the continuous availability of the tools used to build the software, which can't be guaranteed by proprietary tools sold by often-small companies.

To We see however some newcomers in the realtime operating system landscape, that provide certified versions of Linux for the embedded world. So although the software isn't available for free, its cost is dramatically reduced by its open source origins. This cost covers not only the certification process, but also the liability that the vendor endorses.

Standardizing interfaces

The complexity of embedded software is constantly growing. Today's cars contain dozens of calculators, smart DSL modems containing multimedia applications are spreading in many houses, and mobile phones are as powerful and featured as 10year old personal computers.

The result of this growing complexity is that not a single company is able to provide the entire software of a system, and also that final product manufacturers no more want or can rely on a single solution vendor.

That's what triggers standardization processes. Two of them are worth mentioning: OSGi [START_REF]OSGi -Open Systems Gateway Initiative[END_REF] and AUTOSAR [START_REF]AUTOSAR -AUTomotive Open System ARchitecture[END_REF].

Started in 1999, OSGi is a specification for a runtime platform based on the Java technology that can host software services. It defines software contracts that allow application and services developed independently to coexist and cooperate on a single device. OSGi is a consortium of companies from the automotive and set-top-boxes domains, and only members of the consortium were authorized to produce a certified implementation of the specification.

Then, some open source implementations of OSGi emerged. They could not claim strict compliance with the specification, but the fact was they were actually full featured and robust. And this led more people to using OSGi, for use cases that where not initially foreseen. The effect is that although the open source offering competes with commercial implementations, it actually widens the OSGi market. The OSGi group has taken this trend into account, and the latest release of the specification is available under an open source licence, allowing anybody to implement it.

AUTOSAR is a recent initiative in the automotive world that aims at defining an open standard architecture for electronic and software modules. Its purpose is to allow car manufacturers to easily integrate parts from various vendors, to answer the problem of the growing complexity of automotive systems and allow interchangeability of equipments.

The automotive world is not as open as the information systems world, and full open source solutions are not likely to happen in the near future in mission-critical software. However, it is very likely that some strong influence from the open source world will emerge.

A hardware device manufacturer my decide to "share the source" of the associated software with its users and integrators, to allow for faster roundtrips in the software design and be more reactive at integrating new needs coming from users.

Finally, there are a lot of software modules in a car that aren't critical. These are for example all the onboard entertainment features. In these areas, standardized interfaces such as OSGi and AUTOSAR will allow the emergence of open source applications such as multimedia players, enhanced GPS navigation software integrated with the driver's address book, mail readers, etc.

Conclusion

In a few years time, open source software has changed the industry landscape in the information systems world. Open source projects are now studied by researchers and management schools [14] to understand how these self-organizing projects achieve their goals and what lessons can be learned from this.

The conclusion that can be drawn from the experience of the information systems world and the current trends in the embedded systems world is that open source cannot be ignored.

Now is it a risk or an opportunity?

For industrials, it is clearly an opportunity, as it allows the development of shared solid foundations and fulfils the need for long-term maintainability.

For vendors, it is a risk if ignored, as it will likely cut down sales. But it is an opportunity for those vendors that will use open source foundations to provide value-added offerings on top of them. But they also have to be aware that business will have to include more service and less runtime licenses.

This will change the embedded software industry landscape. And it already has begun.

Glossary

ASF

  And the answer is similar to the one from Borland in the previous chapter: the competition is not on the modelling tools, but on what is done with them. Also, only standard models are open source. Airbus-specific ones are kept proprietary.

	Again we see the value of open source commons
	that help go further in the upper levels where the
	actual commercial competition is.
	6.2 Embedded runtimes: the certification issue
	Compared to other domains, embedded software
	systems must be carefully certified before being
	deployed, both because such software often has
	some critical mission regarding human lives and
	because it is not easily upgraded once distributed in
	the wild at a large scale.
	Certification is a very costly process that somehow
	goes against the lightweight development model
	used by open source organizations.
	solve this problem, we see the emergence of
	projects such as Topcased [11], led by Airbus and
	gathering companies working on a common and
	open source toolset for the development of avionics
	software.
	Topcased is a generic modelling toolset based on
	the Eclipse platform. It is actually a meta-modeller as
	it allows to define the "model of a model" to quickly
	build a graphical editor for a particular model. The
	goal is to provide editors for all models that
	participate in the design of an aircraft's software.
	Without the open source commons provided by
	Eclipse, this project would never have been started.

When presenting the project, people from Airbus are often asked: "since it is open source, what if Boeing decides to use Topcased too?"


F Gasperoni
email: gasperoni@adacore.com

FLOSS, COTS, and Safety: A Business Perspective

Keywords: COTS, Free Software, Open Source, FLOSS, safety-critical software, certification

This paper discusses the relationship between COTS software (Commercial-off-the-shelf) and FLOSS (Freely Licensed Open Source Software) from a purely business perspective. The emphasis of this work is on safety-centric industries such as aerospace, automotive, and railways.

Introduction

After explaining the nuance between Free Software and Open Source Software, this paper shows that, contrary to popular belief, COTS software and FLOSS are two orthogonal and non-conflicting attributes of a software product since the first deals with commercial off-the-shelf availability while the second deals with licensing terms. COTS vendors have a continuum of choices between providing only restrictively licensed COTS, a mixture of restrictively licensed and FLOSS licensed COTS, or entirely FLOSS licensed COTS.

Furthermore, this paper demonstrates that the notion of software quality is a third orthogonal dimension to COTS and FLOSS. We also dispel the myth that all FLOSS is developed in bazaar-style.

This work shows that the availability of source code in FLOSS-licensed software is not its key advantage when it comes to safety-focused industries. Rather, it is the set of freedoms guaranteed by FLOSS that makes it an interesting alternative over restrictively licensed COTS.

More specifically, copyright grants a temporary monopoly on a software product. This monopoly may result in vendor lock-in for software changes, support, and certification material. This drawback has usually been overshadowed by COTS advantages. Our work shows that COTS software sold with a FLOSS license (COTS FLOSS) has all the advantages of restrictively licensed COTS without the vendor lock-in disadvantages. This paper does not claim that COTS FLOSS is systematically superior to restrictively licensed COTS since the choice between two COTS products involves commercial and technical aspects in addition to legal ones. Our objective is to show that all other things being equal FLOSS-licensed COTS is always better than restrictively licensed COTS because the absence of lock-in aligns the COTS vendor interests with the customer's. This paper draws on over 10 years of working experience at AdaCore the commercial company behind GNAT Pro, the Free Software Ada 83, Ada 95, and now Ada 2005 technology used by the primary actors in safety focused industries such as aeronautics, military, railways, and space.

FLOSS

FLOSS (Freely Licensed Open Source Software) [1]

is a recent term used to denote Free Software [2] and Open Source Software [3]. In Europe FLOSS is also used as the acronym of Free/Libre Open Source Software. The French and Spanish word "Libre" means free (as in freedom) and emphasizes the notion of liberty that is at the root of the FLOSS movement. For most people FLOSS means:

• Access to the sources;

• Existence of a community dedicated to the evolution of the software;

• Free-of-charge software availability.

While these attributes are sometimes true, this is not what FLOSS is all about. FLOSS is all about the terms and conditions of the software license.

Software License

Software, like literature, music, and cinematography, is protected by copyright and governed by the Berne convention [START_REF]Berne Convention for the Protection of Literary and Artistic Works[END_REF]. Copyright controls the right to use, copy, distribute, modify, and make derived works of the software (whether in source or binary form). To undertake anyone of these activities, one must obtain a license from the copyright holder. Broadly speaking a software license is the legal document listing the things the software recipient is and is not allowed to do with the software.

Unless explicitly placed in the public domain, the use, copy, distribution, modification, etc. of all software whether FLOSS or otherwise, is governed by the laws of copyright. From this standpoint there is absolutely no difference between Microsoft Windows and GNU Linux. These are both copyrighted works. To be able to use them one must obtain a license from its copyright holders. This software license grants users certain rights and may impose certain restrictions in the use, modification, and/or redistribution of the software.

Copyright holders can, at their discretion, charge a fee in exchange for a copy of the software work and its attached license. In this case what the recipient is buying is not the software work per se but a copy of it along with its license. Because this paper focuses on the business aspects of FLOSS as applied to safety-related industries, we concentrate on the key freedoms promoted by Free Software and embodied in the vast majority of FLOSS licenses. These freedoms are:

Free

• The freedom to run the software for any purpose;

• The freedom to redistribute the software;

• The freedom to create and distribute derived works;

• The freedom to market the original or derived versions of the software.

Access to the source code and build procedures is a consequence of the freedom to create derived works since without these FLOSS recipients are not free to create and market derived works.

The ability to create and redistribute derived works allows the creation of an open community of developers collaborating in the evolution of the software. This is a possible side-effect of FLOSS licenses, not a requirement and not a guarantee.

FLOSS licenses put no restrictions on distribution or redistribution fees. The recipient of FLOSS can sell/resell copies of the software at any price.

COTS and FLOSS

What is COTS?

COTS (Commercial Off-The-Shelf) [START_REF]COTS[END_REF], is the term used for systems which are manufactured commercially and then tailored for specific uses. A COTS product is sold to the general public in the course of normal business operations at prices based on list or market prices. COTS are in contrast to bespoke or custom-made systems that are produced solely for a specific customer.

In the software area the significance of COTS varies greatly. In office automation, for instance, tools such as word processors and spreadsheets require no customization prior to their use. In embedded devices, on the other hand, COTS operating systems or kernels require a great degree of customization: from creating or adapting the BSP (board support package) for the target hardware, to configuring certain OS modules such as the scheduler.

Advantages of COTS

Advantages of COTS include:

• Existence of a commercial organization that can be held liable for all the IPR (Intellectual Property Rights) issues regarding the software such as copyright, patents, etc.;

• Existence of a commercial support organization responsible for answering questions and fixing problems encountered in the use of the software;

• Availability of complete, easy-to-install software package;

• Sharing of the cost for the creation, industrialization, maintenance, fixing of, and evolution of the software among users having similar needs.

Evolution of COTS Software Licenses

As we explained in section 2.1 software falls under the laws of copyright. Copyright grants copyright holders a temporary monopoly on their work. The duration of this temporary monopoly varies from life plus 70 years for individuals to 70 year after the first publication in the case of corporations (95 years in the USA). After this duration the software work falls in the public domain.

Coming back to COTS, up until recently COTS software was marketed under very restrictive licenses which severely limited the user's ability to use and copy COTS software let alone make modifications or redistribute the software. These restrictive licenses created vendor lock-in, making the temporary monopoly on a software work very apparent.

Because waiting 70 or 95 years for the software work to fall in the public domain was not a viable alternative and in any case the potential lack of source code would have made this event irrelevant, Richard Stallman launched the notion of Free Software in the mid 80s. This started as an ideological movement with the creation in 1985 of the Free Software Foundation. Thus, initially, COTS software was opposed to Free Software in people's minds since the first had to be purchased and had a restrictive license while the latter was available freeof-charge and came with a freer license.

This changed with the creation of corporations such as Red Hat in 1993 [13] and AdaCore in 1994 [14]. Whether it's GNU Linux or the GNAT Pro Ada 2005 development environment these companies market COTS software licensed under a FLOSS license. Thus, when looking for software two orthogonal aspects must be distinguished:

(a) Whether the software is COTS, i.e. commercially available off-the-shelf;

(b) The terms and conditions of the software license (restrictive or FLOSS).

A Remark on COTS and Licenses

It is important to understand that a COTS vendor owning the copyright of its software is under no obligation to:

• Give the same software license to all its customers: higher paying customers may obtain more favorable terms (e.g. a FLOSS license) while lower paying ones may receive a more restrictive license.

• A COTS vendor can provide certain of its products under a restrictive license, while marketing other products under a FLOSS license. This is the case, for instance of Wind River [15], which markets various versions of VxWorks (restrictive license) and GNU Linux (FLOSS).

• The COTS vendor is under no obligation to make the sources/binaries available to all (e.g. by internet download) when the software is licensed as FLOSS. The source code must be provided only to recipients of the COTS software licensed as FLOSS.

• It is perfectly possible for a company to market patches for FLOSS packages that are not themselves under a FLOSS license. For example, a company may distribute GNU Linux and separately sell a patch adding industryspecific functionalities for the GNU Linux kernel under a restrictive software license. The entity that receives the restrictively licensed patch can insert it into GNU Linux. This entity can use the resulting program internally but cannot, however, redistribute it.

The point of the above remarks is to show that COTS vendors have a continuum of choices between providing only restrictively licensed COTS, a mixture of restrictively licensed and FLOSS licensed COTS, or entirely FLOSS licensed COTS.

COTS FLOSS and Safety

We come to the core question of this paper: what are the advantages, if any, of COTS software licensed under a FLOSS license in the area of safety-related industries such as the aeronautics, automotive, military, railway, or space industries. The statements made below, except for issues dealing with certification, apply to other industries as well.

4.1 Software Quality and Software Licenses Software tools, libraries, and components used in safety-related systems benefit from careful planning and quality assurance procedures. They often must be part of an auditable and repeatable process with stringent quality requirements and a clear set of software development artifacts. In the avionics industry, for instance, the DO-178B certification protocol [START_REF]DO-178B, Software Considerations in Airborne Systems and Equipment Certification[END_REF] stipulates that the contribution of software to potential failure conditions is used to define 5 software levels. Each software level imposes specific requirements on software planning, development, verification, configuration management and quality assurance. The stringency of these requirements increases with higher safety levels.

What are the quality guarantees of FLOSS-licensed COTS and restrictively licensed COTS? Answer: absolutely none (unless explicit evidence, such as certification material, is produced to the contrary).

With restrictively licensed COTS customers may not even have access to the sources. Even when customers have access to source code and build procedures no license (FLOSS or otherwise) requires the availability or redistribution of design documents, development plans, quality assurance procedures, test suites, or other software development artifacts.

The quality and quality-oriented procedures vary greatly from one COTS to another and the software license gives no guarantees in this matter. Some FLOSS proponents claim that because FLOSS is developed by a community of dedicated developers this yields better software. There is no systematic evidence of this. This really depends on the project. Furthermore, not every FLOSS is developed in a bazaar style. GNAT Pro [14], for instance, is developed mainly following a cathedral model, and although the sources of all of its components are available to all, AdaCore is very careful from both an IPR and software quality standpoint when accepting contributions from customers or other users.

There is nothing that prevents FLOSS-licensed COTS from achieving high-quality and being used in safety-critical systems. For the GNAT Pro Ada compiler alone, for instance, AdaCore has accumulated more than 10,000 tests in 12 million lines of Ada code. Furthermore, GNAT Pro in its High-Integrity Edition is used in several safety-critical projects in the avionics and railway industries (Airbus A380, 767 Tanker, C130AMP, Boeing 787 …). Finally, GNAT Pro comes with an Ada runtime certifiable to DO-178B Level A.

Drawbacks of Restrictively Licensed COTS

COTS software that comes with a restrictive license has a number of drawbacks. Up until recently, because the industry's only choices were between do-it-yourself and restrictively licensed COTS, COTS downsides were considered as inevitable.

These downsides stemmed from the fact that the customer did not own the copyright of the COTS software and had to abide by the restrictive rules set by the COTS owner. Once a restrictively licensed COTS was chosen and deployed the monopoly conferred by copyright to its owner was used to create:

• Vendor lock-in for software changes and evolution;

• Vendor lock in for support;

• Vendor lock-in for certification material (in safety-related industries).

The above drawbacks do not include absence of source code. In fact, thanks to the pressure exerted by the appearance of FLOSS, it is now possible to obtain the sources of certain restrictively licensed COTS against a modest fee. The difference of this source code with that of COTS FLOSS resides in the restrictions attached to the former. In particular, and unlike COTS FLOSS, customers of restrictively licensed COTS cannot use its sources to free themselves of vendor lock-in.

COTS FLOSS: No Vendor Lock-in for Software Evolution

Because COTS software is designed to meet the needs of a majority of disparate users there is a possible compromise on features, performance, and usability. In safety-related industries, for instance, a customer may have the choice between a vendor offering a POSIX-only API from one embedded operating system vendor and another offering only an ARINC 653 one [START_REF]Avionics Application Software Standard Interface[END_REF].

Restrictively licensed COTS forces customers to go to their original COTS vendor for software evolution.

Because the COTS vendor has a monopoly over changes to its software this can be arbitrarily expensive. This is not much of an issue in office automation and similar software, it is, however, an issue in safety related industries where the COTS software is used in very disparate hardware environments and the features required can vary greatly between integrated modular avionics and railway systems.

With FLOSS the customer is not hostage of its COTS vendor. Because FLOSS licenses guarantee a free market, FLOSS customers can solicit competitive bids when software modifications, additional tools, or extra libraries are needed. This is attractive for business and particularly so in safetyfocused industries where the vendor lock-in is significantly more pronounced because of the heavy engineering investments required.

Taking GNU Linux as an example there are today several reliable COTS vendors for it, some making available specialized versions for the embedded market. Because of the lack of vendor lock-in, a customer that has committed significant resources to the use of the GNU Linux kernel in its embedded software infrastructure can switch COTS vendors or can occasionally use additional vendors to add industry-specific features. In the avionics industry a customer could obtain GNU Linux from one COTS vendor and have a separate company produce an ARINC 653 conformant API layer on top of it.

In the case of GNAT Pro, one of AdaCore customers (EUROCONTROL) needed an additional tool. To be economical this tool had to leverage on the guts of the GNAT Pro compiler to avoid redoing a parser and a semantic analyzer for Ada. To show upper management that COTS FLOSS has no vendor lock-in the customer did an open bid for the additional tool which was won by a small and very capable French firm.

As another example, there was a segment in our industry that we (AdaCore) were not serving. An independent company used the GNAT Ada technology to build and market a COTS product for that market segment. We have since entered that market segment and are now competing with our own technology.

COTS FLOSS: No Vendor Lock-in for Support

The source code, scripts, and build procedures of restrictively licensed COTS software cannot be given by a customer to third-party service providers to obtain higher levels of support whether in the form of training, consulting, or professional services.

Conventional wisdom tells us the COTS vendor knows best because it has developed the technology. More often than not, however, the development team of the COTS vendor is segregated from its services organization and is often shielded from the final customer.

The possibility to have support organizations separate from the original COTS vendor allows the creation of a cottage industry which may be in a better position to provide localized services to medium and smaller size customers.

Note that for strategic reasons a number of COTS vendors selling restrictively licensed software have decided to unbundled or outsource part of the service business inherently linked with their products. Some (e.g. Microsoft) have done this to create and foster an ecosystem of partners around their products.

Again, the difference with COTS software licensed as FLOSS, is market freedom. With restrictively licensed COTS it is the COTS vendor that solely decides its support strategy. With COTS FLOSS it is the market.

They key point here is not that production of software and its support should be systematically unbundled, rather it is the customer that should have the freedom to decide so when a business case exists.

COTS FLOSS: No Vendor Lock-in for Certification Material

COTS software is designed to meet the needs of a majority of disparate users. In safety-related industries, certification material may be available only for certain certification protocols such as DO-178B [START_REF]DO-178B, Software Considerations in Airborne Systems and Equipment Certification[END_REF] or not available at all. Without special arrangements with the original COTS vendor this certification material may not be shared with partners or subcontractors.

With COTS licensed as FLOSS, the customer can contract with an independent provider for certification materials and audit trails. Incidentally, in this case the customer may decide to own the copyright for the certification material which he may provide to its partners, subcontractors or perhaps resell. Alternatively, an industry segment may decide to pool its resources to create certification evidence for kernels such as GNU Linux.

The key point here is that quality, when present, can be reversed engineered. Indeed, Verocel [20], the certification company AdaCore has partnered with to certify its Ada runtime for VxWorks 653 [21], starts from the final code to produce audit trails and certification evidence.

Once more the difference between restrictively licensed COTS and COTS licensed as FLOSS is market freedom. With the former the COTS vendor is the only one deciding who can produce certification evidence for its software. With COTS FLOSS it is the market.

Conclusion

In the previous sections we have shown how COTS FLOSS is unaffected by the downsides (for customers) of restrictively licensed COTS. COTS vendors have a continuum of choices between providing only restrictively licensed COTS, a mixture of restrictively licensed and FLOSS licensed COTS, or entirely FLOSS licensed COTS.

Our objective is not to show that COTS FLOSS is systematically superior to restrictively licensed COTS since this choice involves commercial and technical aspects in addition to legal ones.

Our objective has been to show that all other things being equal a FLOSS-licensed COTS is always better than a restrictively licensed one because the lack of vendor lock-in aligns the COTS vendor interests with the customer's. Put it another way, to the question: should an industry segment lobby with its favorite vendor(s) so that, when it is of value, they


E Noulard
email: eric.noulard@bt.com

Y Dufrenne
email: yves.dufrenne@astrium.eads.net

TS2P an open source testbed & simulation software platform

Keywords: open source, real-time, simulation, sampling protocol, TSP

Integration of open source software in industrial environment and process may be something critical. We present hereafter the practical experience of an industrial open source project in the domain of real-time testbed and simulation. A proposition is made to build such a particular project experience and to develop an open source software platform for testbed and simulation.

Introduction

Ten years ago we were still informed of the arrival of the envisioned open source software wave, with software such as the web centric software like Apache [START_REF]Apache HTTP Server[END_REF], general purpose operating systems like Linux, and new development model [START_REF] Raymond | The Cathedral and the Bazaar[END_REF]. At that point industrials were considering open source software like toys or at most like prototyping tools but it was clear for them that they could not be used within industrial application.

Nowadays the worldwide internet connectivity and the dramatic broadband accessibility growth [START_REF] Revillard | Livre Blanc, Organisations et Logiciels Libres[END_REF] made it possible to change the open source software (OSS) status: the OSS are now present in industrial projects, and it seems they are here to stay. Nevertheless, there are many ways for industrials to integrate the OSS in their daily business; ranging from simple use as a particular case of OTS (Off The Shelves) Software to full Open Source supporter such as OSS project founder or driver. IBM with the Eclipse Framework [4], Open Cascade with the Open Cascade Software [START_REF] Cascade | [END_REF], and the LEON Open Spatial processor from ESA [START_REF]LEON2 Processor[END_REF], to name just a few of them.

Exhaustive presentation of Open Source software, hardware [START_REF]LEON2 Processor[END_REF], philosophy or even business model is out of the scope of this paper. We focus on the practical example of an industrial open source software and project with its business model companion. The interested reader may find broader information starting point on OSS in [START_REF] Revillard | Livre Blanc, Organisations et Logiciels Libres[END_REF] or [START_REF]Open Source Initiative[END_REF]. We present hereafter the industrial experience of a niche market OSS project and software [START_REF]Open Source Initiative[END_REF] that lead us to a proposition for a wider industrial open source platform for testbed & simulation associated with a new industrial service-oriented open source business model.

An industrial open source project

Genesis

BT C&SI and EADS Astrium have been working together for several years in the domain of the validation testbed for satellite assembly, integration and test. Both companies do have firm technical experience in the domain of real-time test beds. One of the recurrent features of those testbeds was the need to observe or "sample" evolving data (simulated physical element or spied hardware). Some solutions already exist (internals, COTS, …), but were too specific, heavy, or complex.

And so appeared the idea of a versatile real-time sampling protocol. The protocol and its implementation should be reusable between different projects in order to lower the cost. This protocol could become a mighty silver bullet only if it makes easier the separation of concern (e.g. monitoring GUI versus real-time simulation, whoever is in charge of it). This implies that the usage of the protocol must be free. Then every company developing a solution which needs such protocol may simply use it. The open source project is submitted on Savannah on December 2002 and accepted some weeks later: http://savannah.nongnu.org/projects/tsp is born.

Datab ase

T Ta ar rg ge et t

Bench

TSP at a glance

The TSP may be used to efficiently sample and observe data in either real-time or not simulators and testbeds. The TSP architecture follows the publish/subscribe paradigm [START_REF] Noulard | The TSP whitepaper[END_REF] in which a data producer is called a TSP provider and a data consumer is called a TSP consumer. Even if the TSP shares the publish subscribe concept of DDS [START_REF]OMG adopted specification ptc/03-07-0, Data Distribution Service for Real-Time Systems Specification[END_REF], the TSP is much simpler than DDS. Moreover the TSP focus on the observability and the on-thewire portability of the data link, which is not the case for DDS. DDS is a data-oriented middleware service, including high level constraints (real-time, QoS, Ownership).

The TSP protocol is networked and multiconsumer/multi-provider offering a wealth of data collection possibility. The TSP consists in an open source development toolkit available in portable C

and Java which make TSP readily available on several platforms.

Provider Consumer Asynchronous Requests

N o time quality Time garanties

Synchronous flow

TSP: industrial experiences

The Open Source TSP has since been used on three real-life projects for three different industrial partners for either EADS-Astrium or BT C&SI.

Each time a project using TSP needs a new feature, it has to fund the improvement, to design it and to implement it. Afterwards, the useful generic part is contributed back into the open source project. Other projects using TSP may get those evolutions smoothly when needed.

TSP is now a small but useful open industrial project used directly or indirectly (through subcontracting) by at least four big companies in space or telecom industry in five different projects.

Industrial Open Source

BT C&SI would like to generalize the TSP process thanks to the technical and business success of the TSP project. We propose a new open source business model with an open source platform for testbeds and simulation.

B

This is true for satellite, telecom systems, aircraft and probably many other industrial technical products. During steps B, C and D one needs to build some kind of software and/or hardware simulation testbeds specialized for the concerned business domain.

A sample industrial process

Let's focus on a satellite production example.

Step B consists in the satellite system design which implies the use of a functional simulation testbed. This kind of testbed is used by AOCS experts to validate and tune the on-board and ground system. The testbed may be software only or may include some characterization features used to evaluate particular satellite hardware equipment (GPS receiver, star tracker, gyroscope...). It usually includes simulated hardware processor components used to co-design the system, such as a FPGA simulated Leon processor [START_REF]LEON2 Processor[END_REF] or a software processor emulator. This kind of simulation testbed are generally not real-time but as-fast-as possible in order to efficiently run many test cases.

Step C consists in the validation of the designed system. This step usually involves more hardware and much more software whose purpose is to achieve full closed-loop simulation. The main objective is to validate on-board software/hardware and their expected performances. The hardware missing in the (closed-)loop should be simulated sometimes at bus of electrical level. The included hardware should be stimulated in order to fake the missing part of the real world. Those real parts must be stress-tested in order to verify their functional range is the one assumed during design. Those simulation testbed usually are hard real-time ones. A satellite validation testbed may be very complex since it may be used for global systems simulation as rehearsal means for the to be launched system which includes operational ground segment.

Step D consists in the satellite system assembly, integration and test (AIT). Ideally the previous step C validation testbed is reused, sometimes in open-loop mode, in order to incorporate and test final hardware (and embedded software) in the system currently being assembled.

Step E is when satellite systems has or will entered soon operational state. Satellite is now in space, either fully operational or in orbital transfer phase.

The previously built testbed are used to:

Train operator Operator cannot exercise on a real satellite system. Classically a real ground-segment is connected to a simulated space segment (a simulation testbed).

Solve problem occurring on the real system When problem occurs in space, the validation (and/or integration) testbed is used to reproduce the problem (if it's possible) on the ground. When reproduced, a new on-board software is created and validated using the simulation testbed before uploading the new software in space. In this situation the simulation testbed may need further development if a non anticipated test case shows up.

This satellite system example should share common properties with other industrial systems (telecom systems, aircraft, car...), so the previously described steps, including the issues should be similar.

Some common industrial issues

If you consider the software development part of such technical projects, some technical choices should be made in order to cope with following recurrent issues:

Costly start-up time on specific proprietary environment

When a new person comes in a specific simulation testbed development team, start-up time is on average 1,5 man/month. This start-up delay is mostly due to the complexity of simulation testbed and their proprietary nature.

Software knowledge management problem

Even a software standard based simulation testbed contains a lots of in-house software mostly developed by subcontractors. When the product is out and/or going into maintenance phase the industrial may come up against difficulty to maintain the sufficient knowledge. Since the simulation testbed may/will be used in maintenance over a long period (20+ years maintenance for telecom satellite system), this may become a real industrial issue.

Software reuse problem

Large industrial companies usually built several simulation testbeds a year in different (unrelated) projects or department. Internal cross-project reuse is not as easy as it seems and revalidation cost may be paid by several projects, even if they potentially could have shared those costs.

Control software vendor license policy

When using technical niche market COTS, industrial is sometimes bound to a couple of software providers which may be bought by competitors. This situation sometimes induce unpredictable software licenses cost raise during maintenance phase.

Note that those issues are not the same as general purpose software product (widespread langage compiler, word processor, web servers) where normalized standard and multiple vendors solutions may tackle those problem right away.

Inside the specific testbed & simulation market there is no such ready-to-use solution and it won't probably be one any soon, because of the specific nature of each project.

There exists tools, but they usually are not the big part of the testbed. As an example, today the simulation testbeds are getting more and more distributed. In this area you have tools (CORBA, HLA, DDS,...) but even if they provide necessary building blocks they are not "solution". Moreover, if you did bought a commercial DDS product for a large project it may be out of budget for a smallest one, due to the licence cost.

Open source software answers

Open source software (OSS) may tackle some of those issues, more easily than proprietary do.

We should clearly and early point out that OSS does not mean free of charge and that OSS may come with full commercial support solutions which are necessary in industrial environment. A simple web search with "professional open source support" should convince the reader. You may look at open source initiative [START_REF]Open Source Initiative[END_REF] in the section "O.S. for Customers, Business, and Programmers" in order to find more information on the subject. Nevertheless, we will come back to those "professional" aspects when introducing the TS 2 P business model.

The OSS industrial use may tackle some of the previous industrial issues and derive the following benefit from OSS:

A) Accelerate software development Though, the efficient industrial use of OSS in the domain of simulation testbed may need little more formalized recommendation in order to guarantee success.

TS 2 P: Open Source platform project

In March 2005, BT C&SI proposed to its main customers to get involved in the TS 2 P project: the Testbed & Simulation Software Platform.

TS

P: the content

The platform will contain independent software modules with TSP as the first one. The stakeholders will put in, software modules which are generic enough to be useful and do not entail their competitiveness. Everybody can reuse the software building blocks of the platform, but development of one module is leaded autonomously by the people in charge of it (preferably most contributing people). Software modules may be development toolkit, standalone applications, GUI, etc... Modules may be linked with each other or not.

Every module should adopt an open source licence such as GNU GPL, GNU LGPL, Apache or BSD. The license must, at least, enable the use of the module in industrial and commercial context. Licences for documentation could be open too just like GNU FDL or Creative Commons Sharealike.

The TS 2 P steering committee will vote the new module introduction. A software module may not endanger the specific business of a stakeholder, so only general test and simulation modules should enter the platform. A software module not used by any project (including maintenance) for more than 2 years shall not stay in the platform.

TS 2

P: the stakeholders and their role Each software module manager handles its module autonomously. Each module manager has a place in the steering committee of the platform. The steering committee only deals with "platform-wide" decision like module addition or deletion.

Every stakeholder should clearly promote the use of the platform in its own projects for which a simulation testbed is used or built. It does not mean that one is forced to use it but it should appear as a valuable choice in the invite bids when appropriate.

This promotion is not a marketing one but the only concrete means for the stakeholders to ensure the life of the platform.

TS 2 P: support cost

The stakeholders do not support the cost of the platform but instead all cost should be taken from project using the platform. This does not preclude pure sponsoring, but this is not the preferred way to support the platform.

The TS 2 P must be project driven.

TS 2 P: an open source business model

The business model is totally service oriented: NO software product would be sold from the platform. The platform will be, as TSP, essentially project driven. Evolution of TS 2 P is led by project. Instead of buying custom software the users will order service to include, enhance and maintain TS 2 P modules. The great difference with typical custom software service buying is that the open platform will leverage the cost between unconnected testbeds and/or simulation projects.

Note that the proposed TS 2 P business model is different of other existing business models: TS 2 P is not a product like JBoss [START_REF] Fleury | Why I love Professional Open Source[END_REF][START_REF][END_REF] or MySQL [START_REF] Mysql | [END_REF] and their associated service around OSS product business model TS 2 P stakeholder will not package existing OSS like linux distributors do (RedHat, Mandrake, SuSE/Novell) TS 2 P will not support and/or develop OSS for marketing argument as some software companies do. TS 2 P stakeholder will use the platform for practical and industrial reasons. When inviting for tenders one indicates clearly that TS 2 P should be used when appropriate When examining bidders' proposal, one chooses the best one as usual, but TS 2 P objectives are incorporated in the other classical criterion choice (price, technical validity etc...)

If a project will use TS 2 P, during project kick-off one identifies (re)usable TS 2 P modules and potential new modules that could comes in during the project At project ending ensure that evolution of TS2P modules and/or new modules will be contributed back to the platform. 4.6 TS 2 P: a concept to build together Fifteen people of 6 companies attended the first TS 2 P workshop and declared to be both surprised and interested in such a process. The TS 2 P project is in its infancy but building on the TSP experience it should be successful.

Conclusion

  : first step in the Open Source World In august 2002, BT C&SI and EADS-Astrium decide co-specify the future Transport Sampling Protocol (TSP) and to implement the C library version. At this point the project is a classical customer (EADS Astrium) -software provider (BT C&SI) contract. The two parties then discover the benefits to open source the specifications and the code, in order to try external re-use and improvement through an open source project. The main goal is to provide better reuse and sub-contracting through an open "standard" way to observe evolving data in real-time testbeds. After managing several problems and human factors, the two companies set the seal on an opensource project specifying how they will proceed.

3. 1

 1 Industrial needsIndustrial companies (telecom, satellite, transport, military) developing products want to reduce the cost of software development and manage to deliver the right working solution on time.Those industrial products usually follow the life cycle steps:

1 .B) Reduce cost 1 .

 11 Internal and external software reuse: anyone is free to use it and to give contribution back 2. More efficient training since subcontractor of different industrial projects may train their team efficiently at lower cost since software may be used for free training. Concentrate on core business and open source non business critical software 2. Stimulate competitiveness because anyone wanting to acquire the knowledge may do it (at its own cost). C) Ensure long term stability 1. Interoperable [de-facto] standard 2. Open industrial work group Those benefits may be shared by almost every open source software, including general purpose ones.

We have drawn experience from a niche market open source project and propose collaborative open source software platform for testbed and simulation. We think both the TS 2 P project and the associated business model will prove itself useful for industrial interested in the domain of simulation testbed.

Acknowledgement

The authors acknowledge people at BT C&SI and EADS Astrium who decided at the beginning that such an industrial open source project was possible and in particular José Dekneudt and Jean-Paul Chaumier. Special thanks go to the worldwide TSP development team for its valuable contribution for the past 4 years and the forthcoming ones.