The trends toward product line development and toward adopting more 3 rd -party software are hard to combine. The reason is that product lines demand fine control over the software (e.g., for diversity management), while 3 rd -party software (almost by definition) provides only little or no control. A growing use of 3 rd -party software may therefore lead to less control over the product development process or, vice-versa, requiring large control over the software may limit the ability to use 3

more »

... rd -party components. Since both are means to reduce costs and to shorten time to market, the question is whether they can be combined effectively. In this paper, we describe our solution to this problem which combines the Koala component model developed within Philips with the concept of build-level components. We show that by lifting component granularity of Koala components from individual C files to build-level components, both trends can be united. The Koala architectural description language is used to orchestrate product composition and to manage diversity, while build-level components form the unit of 3 rd -party component composition. iv Conclusions: A potential risk exists that a growing use of 3 rd party software goes in hand with less control over the product development process, or, the other way around, that requiring large control over the software limits the ability to use 3 rd party software. We observed this trend within Philips, where 3 rd -party (open source) software did not integrate seamlessly with the successful Koala component model. In this paper, we describe our solution to this problem by combining the Koala component model and the concept of build-level components. We have shown that by lifting component granularity of Koala components from individual C files to build-level components, both demands can be united. The Koala ADL can be used to orchestrate product composition and to manage diversity, build-level components can form the unit of 3 rd -party component composition.