title of the paper (times new roman, capital, bold, 14 pt ...

PRAGMATIC AND OPPORTUNISTIC REUSE IN TWO INNOVATIVE STARTUP COMPANIES Slinger Jansen, Sjaak Brinkkemper, Ivo Hunink and Cetin Demir Utrecht University ABSTRACT Reuse of software components and services enables software vendors to quickly develop innovative applications and products. According to current literature and experience reports, integration of functionality cannot be performed successfully without formal component and service selection and integration procedures. This article shows two products that have been developed successfully by two start-up companies, using a pragmatic approach to third-party functionality reuse and integration. We show that developing products and services pragmatically places requirements on the relationship between the software developer and the third-party functionality provider. Furthermore, we discuss the architectural impacts of decisions made during the integration process. The experiences show other software developers how to speed up product development with minimal risk. Keywords: opportunistic reuse, software extension mechanisms, pragmatic reuse, COTS, services, product software PRAGMATIC AND OPPORTUNISTIC REUSE Pragmatic and opportunistic reuse is often frowned upon by both practitioners and academics (van Ommering, 2005). Large organizations report that structured reuse methods (Dunn & Knight, 1991) and software product lines are the way to go when it comes to efficient software reuse (Henry & Faller, 1995). However, opportunistic, i.e. non-structured reuse has proven profitable for small to medium organizations in many cases (Morad & Kuflik, 2005), (McConnell, 1996). In this article we describe two start-ups that have opportunistically and pragmatically developed their products, reusing functionality from others that these start-ups could never have built independently. We demonstrate that opportunistic and pragmatic reuse is necessary for rapid development of innovative software products. When software vendors are developing new innovative products, the success of a new software product or service is largely dependent on the time to market. A statement that is often heard is “it may be buggy, but we were first!” Opportunistic reuse is one way to speed up development of a new product or service. Research has shown that the cost of purchasing a component or service is between 1-19% of the cost of developing such a component or service itself (McConnell, 1996). We define pragmatic reuse as extending software with functionality from a third-party software supplier that was found without a formal search and procurement process that may not have been built with reuse in mind. Our definition differs from Tomer et al. (2004) in that we generalize the term to comprise of both the reuse of services and components. We define opportunistic reuse as extending software with functionality from a third-party software supplier that was not originally intended to be integrated and reused.

1

We continue this article describing different mechanisms that are used to extend a software product or service with functionality from a third-party. Section 3 describes two start-ups and their pragmatic and opportunistic reuse of three components or services each. Section 4 describes the challenges these startups encountered and factors that influenced their selection and integration processes. Section 5 describes the lessons that were learned during the selection and integration of third-party functionality and we end the article with a short discussion of the findings. SOFTWARE FUNCTIONALITY EXTENSION MECHANISMS Several mechanisms exist that extend software functionality with third party functionality: component calls, service calls, source code inclusion, and shared data objects (see Table 1 and Figure 1). Component calls can be direct to a component, or indirect through a component bus or another (glue) component. Components are typical in that they are dormant until invoked, in contrast to services that need to be live to be (re)used. Components can run independently (think of a “hello world” application) or can require a component framework or virtual machine to be instantiated. Data object sharing, though popular, has the drawback that the database is required to be „smart‟ (locking and transactions are at least required) and that software objects cannot independently evolve the data model. Services run locally (think of MySql running on the same server as a PHP program) or remotely (think of a currency conversion service) when called upon. Services can be called directly through for instance a SOAP call, or indirectly through a service bus. We cannot avoid the difference in trend here between services and components, in that services are said to be less tied to a location than components are. Furthermore, it is easier to facilitate dynamic composition and updating of service configurations than it is for component configurations (Ajmani, Liskov, & Shrira, 2006). Contrary to Tomer et al. (2004), we explicitly rule out source code inclusion from the list of software functionality extension mechanisms because it has serious drawbacks. One can simply copy a method, class, or full package into a component configuration. By doing this, tight coupling is established, with all its downsides, such as the fact that an update of the third-party source requires another copy-paste action. Table 1 - Software Functionality Extension Mechanisms Unit of Inclusion

Call Type

Fig. 1

Component

Direct

Indirect

Service

Direct

Interaction Method

Example

(a)

Pipe and filter

Call runnable component and feed it data

(b)

Component library reuse

Method calls & class use, DLL, libraries, jars, etc

(c)

Glue code

Glue code is written between the application and the extending component

(d)

Shared data object

Call runnable component on data source, report when finished

(e)

Component bus

Component invocation bus, that is active like a service, CORBA call

(f)

Plug-in architecture

Java Plug-in architecture, Eclipse Plug-ins

(g)

Service framework

Specific integration, forward form submits, web page inclusion, SOAP call, MySql database service, online currency converter, etc

2

Indirect

(h)

Service call that is evaluated and directed to three different services, of which one is found most suitable to handle the request, e.g. OWL-S

Enterprise service bus

There are two reasons for classifying the different mechanisms for third-party functionality inclusion. First, the classification can be used to see whether organizations drive business differently when they use different types of inclusion. Secondly, when studying opportunistic Components Off The Shelf (COTS) reuse, we can establish whether the products being integrated with these COTS require a specific type of software architecture. The presented mechanisms have been inspired by comprehensive overviews of reuse mechanisms such as Krueger‟s work on software reuse (Krueger, 1992), Szyperski‟s (1997) work on components, and the work of Shaw et al. (1996) on architectural connections. (a)

(e)

System Data Objects

Product A

(b)

Product A

(f)

System Product A: Plugin Architecture

Component B

Component B System X

System Product A

Glue Code

Component B

Product A

(g)

Component B

Component C

Network

(c)

Component Bus Component B

System Product A

System

System Y Service B

System X

(d)

System

Service Bus Product A

(h)

Component B

Network System Y

DB

System Z Product A

Service B

Figure 1: Graphical Representation of Software Extension Mechanisms

TWO START-UP CASES OF OPPORTUNISTIC REUSE Two cases of opportunistic reuse are described in detail. Both cases are examples of newly developed solutions (ideas developed in 2006 and 2007, first releases planned in 2008). Both cases still need to prove themselves in the field. The cases were selected from a selection of ten start-up software businesses from the Netherlands (see sidebar Netherware). The main criteria for selection were the number of integrated components and services, viability of the business, and the dedication of the team. The names of the start-ups have been changed to FirstStartUp and SecondStartUp for uniformity and to protect the business ideas. The empirical data was gathered in two case study databases, and was collected by interviewing four developers, reviewing development and design artefacts, testing prototypes, and inspection of software code. Netherware Netherware is a software incubator founded by Utrecht University that provides young student entrepreneurs with cheap office space, courses, development tools, and advice from experienced entrepreneurs and venture capitalists. Students develop product prototypes with a business plan, next to performing staff roles like marketing, bookkeeping, HRM or management in the incubator. Since its start in 2002 Netherware has already delivered upwards of 20 successful start-ups in the Netherlands. Please see www.netherware.nl and (ten Berge et al. (in press)) for more information.

3

For both case studies a description is provided of each integrated functionality, including the used extension mechanism(s), the cost of the functionality, integration effort, architectural impact, feature criticality, and coupling (see Table 2 for a description of each characteristic). Integration effort refers to the amount of hours that was spent on integrating functionality. Architectural impact refers to the scale on which the software architecture and interaction model of the software had to be adjusted to accommodate new functionality. Feature criticality refers to how important the feature is for the key selling point of the solution. Coupling refers to how easily a component could be replaced by a substitute, independent of the availability of such a substitute. Table 2 - Integration Impact Characteristics Integration Effort ℗OO ℗℗O ℗℗℗ Architectural Impact ℗OO ℗℗O ℗℗℗ Feature Criticality ℗OO ℗℗O ℗℗℗ Coupling ℗OO ℗℗O ℗℗℗

The amount of time spent on integrating functionality Under a week Between one and two weeks At least two weeks of development effort The impact on the host architecture No adjustments required to the software architecture Some adjustments required (such as glue code) Complete restructuring of interaction model and product architecture The importance of the feature to the key selling point of the software The feature is a nice-to-have The feature is essential but can be substituted The feature is critical to the software The effort required to replace a functionality by a substitute Loose – Easy to replace with a substitute. Medium – Possible to replace, but with considerable difficulty. Tight – Intertwined with the software, almost impossible to replace.

Solution 1: Online Workshop Planning Application by FirstStartUp In 2007 the idea was born to develop a workshop scheduling application for large groups of people. Similar applications already exist, but this application is directed at a specific customer target group. The planning application facilitates to plan series of workshops, where participants need to provide their preference on the workshop they wish to take part in. Normally, development of such an application requires a lot of development time and specific knowledge on timetabling. In this case however, FirstStartUp decided to reuse common components to solve this problem. Three components were integrated into Solution 1: Spreadsheet Service - To plan a series of workshops, a workshop list and a list of participants are required. The main reason why this application can be successful on-line is because it reduces overhead in regards to paperwork for the organizer. This requires a smart method to enter data for the organizer, which the developers wanted to be simple, especially because workshop organizers will already have a list or even a spreadsheet of participants and sessions. To enable copying and pasting such a list to the application, the developers decided they needed a spreadsheet application that could be integrated. Zoho Sheet (http://sheet.zoho.com) provides this functionality as an online service. It can be reused by third parties in their own applications. Zoho Sheet interacts with Solution 1 by including a Zoho Spreadsheet page on the solution web page and by making SOAP calls to the Zoho server to read locally stored data.

4

Interaction method: Web page inclusion, SOAP calls. Cost: Free. Integration effort: ℗OO. Architectural impact: ℗℗℗. Feature criticality: ℗℗O. Coupling: ℗℗℗. Payment Service – To enable payment in the Netherlands, where the application will first be launched, the iDeal (http://www.ideal.nl/) module is used. This component is provided by most banks in the Netherlands to enable online vendors to receive quick electronic payments. iDeal is especially popular because the money is transferred from bank account to bank account immediately, reducing credit problems and the like. The iDeal module can be accessed remotely by supplying a button on a website (that posts the payment data to the iDeal site). After the user has finished entering its credentials and the payment is completed, the iDeal module forwards the user back to the website. Interaction method: Forward form submit. Cost: Service charge of 0,75-1,50 euro per transaction. Integration effort: ℗℗℗. Architectural impact: ℗OO. Feature criticality: ℗℗O. Coupling: ℗OO. Timetabling Component – Once all data has been provided by the organizer and all preferences have been entered by the participants of the workshops, a schedule needs to be created and published. Schedule creation is a complex problem that has been studied since the earliest days of computer science. To avoid having to reinvent the wheel the developers looked for planning applications that provided the features required. Tablix (http://www.tablix.org) is a timetabling application using genetic algorithms. It is available under the terms of GNU General Public License and includes, amongst other features, a graphical user interface. Tablix proved to be well-fit for the problem at hand, because it has a command line interface and can import and export data in a myriad of formats (XML, etc). Tablix is integrated with a pipe and filter, such that when a schedule needs to be created, Tablix is started and provided with the data. A solution is created by Tablix and stored locally for reading by Solution 1 in XML. Interaction method: Shared data source, pipe and filter. Cost: Free. Integration effort: ℗℗℗. Architectural impact: ℗OO. Feature criticality: ℗℗℗. Coupling: ℗℗℗. Solution 2: Online Direct Marketing via a Third Party Social Network by SecondStartUp In 2006 development was started on an automatic marketing service via an existing social network. The marketing service allows customer companies to communicate with their clients in an automated way with a humanlike feel to it. Simultaneously, the service gathers valuable client specific information, like preferences and characteristics relevant for marketing. Solution 2 has the possibility to directly sell products. Normally, automated human-computer communication requires linguistic-algorithms and extensive knowledge in the field of linguistics, which are expensive to develop and gain. Furthermore, using a third party network to communicate requires a network specific implementation to approach users of the social network. As in Solution 1, SecondStartUp decided to reuse common functionality to solve these problems. Third-party social network library component – SecondStartUp chose a specific implementation and social network. SecondStartUp chose a library that supports full interaction with the network. To make the application as extendable as possible, SecondStartUp is using a layer of abstraction. Interaction method: Direct component call / Component library reuse. Cost: Free. Integration effort: ℗OO. Architectural impact: ℗℗℗. Feature criticality: ℗℗℗. Coupling: ℗℗O. Advanced language interpreter component - To automatically communicate with customers, an advanced language interpreter was needed. It had to recognize language structure (grammar) and 5

meaning (semantics). Developing such a component requires extensive knowledge in the field of linguistics and artificial intelligence. Basically, the solution requires a component that allows customers to chat with the service using natural language. Artificial Intelligence Markup Language (AIML) is an XML dialect for creating natural language software agents. The AIMLbot2 (http://aimlbot.sourceforge.net/) component uses linguistic-algorithms, which can interpret user input and automatically respond with relevant, predefined information. This predefined information is stored in AIML scripts. To save time SecondStartUp decided to use configurable scripts that were freely available. An example of an event is when the service receives a message from a customer. When this event is invoked, the AIMLbot2 module is executed. It interprets the message and responds with appropriate information to the client. Interaction method: Direct component call / Component library reuse. Cost: Free. Integration effort: ℗OO. Architectural impact: ℗℗O. Feature criticality: ℗℗℗. Coupling: ℗℗℗. Micropayment Service – To enable easy payment of small fees, a text message service is used. This service enables online and offline vendors to quickly charge fees between € 0,00 and € 10,00 (micro payment) through a client‟s mobile telephone account or from a prepaid balance. Interaction method: Direct service call through form submission. Cost: Service charge per transaction. Integration effort: ℗℗℗. Architectural impact: ℗OO. Feature criticality: ℗℗O. Coupling: ℗OO. COMPONENT AND SERVICE INTEGRATION In this section the difficulties that were encountered during the integration of the components and services are discussed. The empirical evidence is used to show what challenges still lay ahead for component providers and component integrators, and how all this relates to current research. Component and Service Selection Both presented products have been created by a small team of entrepreneurs (two in both cases) that are not engaged in the projects full time. This has enabled the developers to take certain risks in the selection process. For Solution 1 the spreadsheet selection process was challenging. They needed to at least provide a spreadsheet interface to end-users. The two services that were shortlisted are Google Docs spreadsheet service and Zoho Spreadsheet service. Furthermore, the data that was created by end-users needed to be accessible by Solution 1. During the first evaluation it became clear that Google Docs did not allow anonymous login to the service. This presented another problem, because now end-users needed to explicitly share sheets with Solution 1. Zoho thus became the most well fit component, even though many integration problems needed to be overcome. For Solution 2, the third party networking component was most critical. There are several free and commercial products available, which support the chosen network. Similar to Solution 1, SecondStartUp was looking for components that were freely available, to keep costs low. These products were available in a wide variety of environments like PHP, .NET and J2EE. SecondStartUp preferred the .NET component because they have experience in .NET. Moreover, SecondStartUp had personal contact with the developers of the library and therefore it was selected, even though it is no longer formally supported.

6

The component and service selection process for both start-ups was largely driven by information and knowledge available on specific API and integration websites. Both the payment service and the spreadsheet service have sites that provide comprehensive integration examples of services into applications. The timetabling component has extensive manual pages that describe exactly how the component works and how it can be reused and integrated with other applications. Component and Service Integration and Interaction The method used to integrate and interact with components and services determines what the software architecture of a product or service looks like. When opportunistically reusing functionality, severe changes to the architecture and complex glue code might be necessary to achieve correct interaction and integration. For Solution 1 the timetabling component was relatively simple to integrate. Since the component runs each time a schedule needs to be created, the timetabling component was fairly loosely coupled to Solution 1. The timetabling component was integrated using simple steps: first the workflow of the component was determined (table data in, schedule data out). Secondly, the data types are implemented in Solution 1, so that Solution 1 can readily supply the correct data in the correct XML format for the timetabling component. Solution 1 now checks regularly (every minute) to see whether the timetabling component has finished. Once the timetabling component finishes, the schedule (output in XML) is imported into Solution 1, and an e-mail is sent to the customer. The component is still considered to be tightly coupled, mostly because no abstract data layer is implemented in Solution 1; switching to another component introduces a lot of work. One problem with the timetabling component is that when a scheduling problem is provided to it that has no solution, it runs eternally. A time-out is used to check whether the component can find a solution or not. With regard to the spreadsheet service, integration was painful. Different features are required from the service: the spreadsheet functionality was required to provide a user interface and the storage functionality was required to enable storage of the sheet on the FirstStartUp web server. The spreadsheet functionality is designed for integration with a sheet that is stored on the third-party spreadsheet server. When the spreadsheet service is opened it comes from the same location as all the spreadsheet service HTML/Ajax/JavaScript code. Solution 1, however, requires that the file is never opened from the third-party server, but from the Solution 1 server, leading browsers to believe that a “cross site scripting hack” had occurred. This was solved using a hidden form post, which made it seem as though the user uploaded the spreadsheet sheet to the spreadsheet service. Secondly, Solution 1 requires users to click from sheet to sheet. In between steps the sheets must be stored. To save a sheet the user must click the „save‟ button in the spreadsheet service, meaning that changes to the sheet are lost when a user clicks „next‟ to go to the next sheet. This problem was solved pragmatically by graying out the „next‟ button until the user has clicked save using JavaScript. Finally, to get data from a stored sheet, SOAP calls are used. SecondStartUp choose to make the application as flexible as possible by using a layer of abstraction for third-party functionality. There are several downsides to this approach. First, errors are difficult to handle in a standardized way. Second, implementing an abstraction layer that handles the essential features requires a lot of effort. The advantage is that this approach creates loose coupling between the Solution and the third-party functionality. Consequently, the abstraction layer provides the possibility to easily switch to another component, or update the same component. This abstraction layer is developed using the Bridge design pattern. The Bridge design pattern decouples an abstraction from its 7

implementation so that the two can vary independently. This pattern enables easily switching between different implementations of the third-party functionality, like the third-party social network client. Dealing with Upgrades When a system depends on third-party functionality, upgrades can affect the offered functionality a great deal. For one, if the interaction with a component or service is changed, the system will end up breaking or behaving unpredictably. On the other hand, if new features are offered by the upgrade, third-parties want to make use of these features as soon as possible. Problems can be avoided and opportunities can be discovered earlier when the network of developers that integrates third-party functionality is frequently informed about changes. Solution 1 is independent when it comes to the timetabling component. It is only updated when the developers wish to upgrade it, since it is installed locally. With regard to the spreadsheet service and the payment service the developers are members of mailing lists, so that they stay up-to-date when problems arise and potentially profitable changes are made. Furthermore, developers see the advantage of web services when changes are made to the two services that do not directly affect the interface or the key features, but still improve service quality. The developers of Solution 1 trust the service suppliers to not change the service radically without announcement. Practical Considerations Even though the integration of third-party functionality can be painless, one should take into account some practical considerations. The developers for Solution 1 were well on their way with the integration of the spreadsheet service, when they realized that the product was being integrated in English, and that they had not thought about localization. To their luck, the spreadsheet services are available in many different languages, amongst which the Netherlands language. The developers of SecondStartUp were less fortunate. The advanced language interpreter component uses linguisticalgorithms and predefined information which is stored in AIML scripts. The free scripts used, were solely available in English, while their customer companies and their clients prefer the Netherlands language. Therefore, to support the Netherlands language, they need to translate over 50,000 sentences. To overcome this problem, SecondStartUp is planning a distributed translation approach, where they ask friends, family and colleagues to translate a few sentences using a simple (and easy to develop) web application. LESSONS LEARNED From the interviews with the two start-ups we derive the following lessons: Components and Services are Selected based on Critical Functionality – Both presented solutions integrate third-party functionality. Interestingly, the fact that functionality was offered as a component or a service only remotely influenced both the selection processes, showing that pragmatism trumps the architectural consideration in the decision between components and services. According to the development teams there are significant differences in impact, however. An advantage of services over components is that users and integrators of the services are encouraged to use new functionality when it is released. According to the development teams a more continuous release cycle speeds up implementation of new innovations in products. Developers prefer reusing components over services when these components provide a critical functionality. The main reasons provided are that the component‟s functionality remains stable, that the component does not have to run remotely, and that performance is guaranteed and independent of network capacity. Another factor that influences the 8

choice for a component or a service is the location of the most valuable data. The planning application, which hopes to acquire customer data through a spreadsheet interface, sees its core value in the customer data. To outsource storage of this data at Google Docs, for instance, was considered too risky. Documentation Availability is critical to Component and Service Reusability - The selection process for both solutions was influenced by the knowledge network surrounding the third-party functionality. For Solution 1 the developers relied heavily on the forums, websites, source code repositories, API documentation, etc. Solution 2, to a lesser extent, decided to use one specific library because they know the developer of the library. Both cases show that, should a third-party functionality supplier wish to have its product adopted more frequently, a knowledge infrastructure is required to support the integrating party. Some sources of knowledge were deemed essential to the integration by the developers, such as API documentation, an integration example, a demo version in case of a commercial product, and an active development community in the shape of a mailing list or forum. A formal standard for knowledge infrastructures concerning COTS and services could greatly assist both suppliers and integrators. COTS Selection Methods are hard to apply in Practice - Both FirstStartUp and SecondStartUp place a critical note with regards to formal behavioral models, COTS selection methods, and formal development procedures. Both teams prefer pragmatism and agility above formality and rigidity. The teams do wonder, however, how long they can stick to these software engineering morals. COTS and Services do not Interact Sufficiently – For all six reused components and services was established that interaction with Solution 1 and Solution 2 was of a very crude level. Both the timetabling component and the spreadsheet service hardly make use of exit codes, return codes, etc., making testing and debugging intensive processes. We identify this as one of the main disadvantages of opportunistically reusing third-party functionality that was not originally intended for intensive reuse. Reusing COTS and Services enforces Abstraction – Opportunistically reusing components forced both FirstStartUp and SecondStartUp to invest extra time in modularizing and abstracting parts of the software, because it was known beforehand that integration might be troublesome and that components might evolve in the future. Both teams suspect that their solutions are more stable due to the modularization and abstraction. Opportunistic Reuse Enables Rapid Development – The two start-ups demonstrate that innovative products can be developed quicker by reusing in an opportunistic and pragmatic fashion. The first releases might not be of the highest quality possible with extensive formal COTS selection and reuse methods, but at least the products are released sooner. These lessons show that software reuse is not just a technical problem, agreeing with Will Tracz (1994) who aptly chose “Software Reuse is a Technical Problem” as the first myth of software reuse. DISCUSSION AND CONCLUSIONS This article describes the challenges developers experienced while creating new value by combining open source components, commercial components, and services into new innovative products. FirstStartUp and SecondStartUp still need to prove themselves in the field and we do not know whether results from this research will hold in the long run. In its defense, we encountered similar functionality extension mechanisms in earlier case studies of product software vendors in the 9

Netherlands (Jansen, Ballintijn, Brinkkemper, & van Nieuwland, 2006). Furthermore, the members of FirstStartUp and SecondStartUp all have industrial experience in regards to software engineering, software architecture, and COTS reuse. Opportunistic reuse is often frowned upon by both academic and industrial software developers. We suspect, however, that this pragmatic approach to reuse is day to day practice in innovative industries. The two presented cases show that pragmatic reuse can be highly profitable and cost-effective for rapid development. We show that if third-party functionality providers wish for their products to be reused, they must surround those products with a sufficing knowledge infrastructure. Furthermore, we show that the crucial factors to the choice for services or components are business requirements, much more than technical requirements. Finally, the point is raised that standards are required for knowledge infrastructures and for service and component interactions to promote reuse.

ACKNOWLEDGEMENTS We would like to thank fellow entrepreneurs Peter Duijnstee and Wilco van Duinkerken for their inspiring ideas that contributed to this work. Furthermore, this research could not have been performed without the software incubator Netherware.

Bibliography Ajmani, S., Liskov, B., & Shrira, L. (2006). Modular Software Upgrades for Distributed Systems. European Conference on Object-Oriented Programming (ECOOP). Dunn, M. F., & Knight, J. C. (1991). Software reuse in an industrial setting: a case study. Proceedings of the 13th international conference on Software engineering (pp. 329-338). Austin, Texas, US: IEEE. Henry, E., & Faller, B. (1995). Large-Scale Industrial Reuse to Reduce Cost and Cycle Time. IEEE Software , 47-53. Jansen, S., Ballintijn, G., Brinkkemper, S., & van Nieuwland, A. (2006). Integrated development and maintenance for the release, delivery, deployment, and customization of product software: a case study in mass-market ERP software. Journal of Software Mainrenance , 133-151. Krueger, C. W. (1992). Software Reuse. ACM Computing Surveys (CSUR), Volume 24, Issue 2 , 131181. McConnell, S. (1996). Rapid Development: Taming Wild Software Schedules. pp. 449-463. ISBN 155615-900-5: Microsoft Press. Morad, S., & Kuflik, T. (2005). Conventional and Open Source Software Reuse at Orbotech - An Industrial Experience. International Conference on Software - Science, Technology and Engineering (SwSTE 2005) (pp. 110-117). Herzelia, Israel: IEEE . Shaw, M., DeLine, R., & Zelesnik, G. (1996). Abstractions and Implementations for Architectural Connections. Third International Conference on Configurable Distributed Systems, (pp. 2-10). Annapolis, Maryland. 10

Szyperski, C. (1997). Component Software: Beyond Object-Oriented Programming. 411 pages: Addison-Wesley Professional . ten Berge, J., Ramaekers, S., Brinkkemper, S., Pilot, A., & Nab, J. (2008). Teaching Entrepreneurship in the Software Branch: The Design of an Authentic Task in Higher Education. Education and Information Technologies. , (in press). Tomer, A., Goldin, L., Kuflik, T., Kimchi, E., & Schach, S. R. (2004). Evaluation Software Reuse Alternatives: A Model and its Application to an Insdustrial Case Study. IEEE Transactions on Software Engineering , 601-612. Tracz, W. (1994). Software Reuse Myths Revisited. Proceedings of the 16th international conference on Software engineering (pp. 271-272). Sorrento, Italy : IEEE. van Ommering, R. (2005). Software Reuse in Product Populations. IEEE Transactions on Software Engineering 31, 7 , 537-550.

BIOS Slinger Jansen – Slinger Jansen is currently an Assistant Professor at the Department for Information and Computer Science at Utrecht University, the Netherlands, where he recently finished his PhD entitled "Customer Configuration Updating in a Software Supply Network". His research focus is on software product management and software supply networks, with a strong entrepreneurial component. Contact him at Utrecht University, Department of Information and Computing Sciences, PO Box 80.089, 3508TB, Utrecht, The Netherlands; [email protected]. Sjaak Brinkkemper – Sjaak Brinkkemper is full professor of Organization and Information at the Department of Information and Computing Sciences of Utrecht University, the Netherlands. He leads a group of about thirty researchers specialized in product software entrepreneurship. The main research themes of the group are methodology of product software development, implementation and adoption, and entrepreneurship in the product software industry. Contact him at Utrecht University, Department of Information and Computing Sciences, PO Box 80.089, 3508TB, Utrecht, The Netherlands; [email protected]. Cetin Demir – Cetin Demir is a master student in the subject of Game and Media Technology at Utrecht University, the Netherlands. He has completed his bachelor degree in Computer Science, including a minor Entrepreneurship. Contact him at Utrecht University, Department of Information and Computing Sciences, PO Box 80.089, 3508TB, Utrecht, The Netherlands; [email protected]. Ivo Hunink – Ivo Hunink is a master student in Information Science on the subject of Business at Utrecht University, the Netherlands. Contact him at Utrecht University, Department of Information and Computing Sciences, PO Box 80.089, 3508TB, Utrecht, The Netherlands; ihunink@ cs.uu.nl.

11