viewpoints of component developers, buyers, sellers, and brokers. .... marketplace is characterised as a means for âOpen Market ... any platform from multiple component authors, and ... component makes either the source code or some.
Original Software Component Manufacturing: Survey of the State-of-the-Practice Veikko Seppanen, Nina Helander University of Oulu Department of Information Processing Science P . 0. Box 3000, FIN-90014 Oulun yliopisto, Finland E-mail: Veikko.Seppanen @ oidu.fi, Ninahelander @ koti. tvo.fi
Eila Niemela, Seija Komi-Sirvio VTT Electronics P.O. Box 1100, FIN-90571 Oulu, Finland E-mail: Eila.Niemela @ vtt.fi, Seiia. Komi-Sirvio @ vtt.f i
Abstract This paper m d y s e s the state-of-the-prcictice of sojtware cotnporients produced in strategic partnerships. We call this kind of business original software coniponent manufacturing (OCM), referring to the concept of origirial equipment niani$zctiiring (OEM) that is well known in other industries. The analysis is mostly based on irlforniatioti acquired from Internet in Fall 2000, dealing with OCM supplier-. brokering and buyer coinpanies. Based on the nnaljsis, the context of OCM is oirtlinrd and a suggestion ninde for fiirther K&D activities.
1. Introduction This paper discusses the results of a pre-study carried out recently on software components developed for the electronics, automation and telecommunication industries. The focus of the study, which in part carries further the work reported in [ I ] , is on tailorable software components that can be modified either by suppliers or buyers before their actual reuse. This type of business is called original software component rnnnufacturing (OCM), referring to the analogy of original equipment manufacturing (OEM) that is well-known in other industries. Another phrase that could be used is partnership softwrire coniponent production. However, we wish to point out there is a continuum from reusable software parts developed by the product manufacturer itself to fully commercial off-theshelf software components and products (COTS).
1089-6503/01$10.000 2001 IEEE
Therefore, our survey and thereby this paper includes certain aspects along the entire continuum. An important issue related to the continuum is. if an OCM supplier would develop towards a COTS seller company. A related question at the buyer's side is the change of an independent product manufacturer to a system inte,Orator. One of the main tasks of the study was to try to structure the domain of OCM businesses and processes. The information that was gathered includes, however, both business-related and technical subjects, from the viewpoints of component developers, buyers, sellers, and brokers. The latter is emerging as an intermediary role to help managing software component distribution channels. In an OCM type situation the role of the broker can be played by a first-tier supplier, i.e. a company that manages portions of the supplier network for the buyer company. As a part of the study, a plan for continuing R&D activities was outlined. The key items of the plan will be discussed at the end of the paper, based on a framework of OCM derived from the surveyed information. The information discussed in this paper is mostly based on the analysis of Internet sites. The information was gathered from the Internet during Fall 2000. Many different types of search words and phrases were attempted, but mainly th phrase "software component" and detailed checking of hundreds of links produced, after all, some useful results. This indicates that there is no markets and well-organised information on OCM businesses around yet. To compare, the acronym "OEM" produced plenty of relevant links about physical parts and product manufacturing around the world.
138
2. Analysis of the Surveyed Information
2.2. Component Selling
A simple structuring of the acquired information was used in the survey: business related and technical pieces of information were handled separately. Business-related information was divided into software component selling, buying and brokering viewpoints. Technical information was divided into component development, acquisition, utilisation and general viewpoints. In the following we will address only the main pieces of the information, focusing almost entirely on the business side.
Http://www.wrldcomp.com/, ”World Computers Ltd” is a British company located in London and Brussels. It represents the development of an embedded systems software subcontracting company to a COTS component seller - to be an OCM supplier would most likely be part of this kind of strategic evolution. For the company in case the change took five years ( 1995 - 2000). The company provides one key component, a user interface engine. The Web pages of the company indicate that the company is prepared to tailor the component. The user interface component is described as ”a services layer module and as such ... designed to occupy a services slot within the Application. The concept is to move all the common software out of the application layer, to generalise this software, and to move it into the services layer”. In other words, the component would separate the presentation layer from the application layer in an embedded systems software architecture. The user interface component with its associated components can be bought for a single or unlimited number of execution platforms used by the purchaser, and also for the particular software development platform of the purchaser. This distinction is important, as it makes a difference between component-based product developers and end-users. The components can also be embedded into the customer’s own software or hardware solutions, or into some specific operating system. The annual maintenance fee of the component is 760 US dollars. Details of the license agreements for the component can be found from the Web pages of the company. To compare, http:Nwww.flashline.com/ is apparently one of the biggest software component market places available in the Internet. The basic functions provided by the site are the following: “Extend Your Component Development Expertise, Developer Links, See How It Works, Register as a developer, Search through Requests, View your Developer info” and “Need a license agreement”. A component design manager is provided for software suppliers. A procedure to become a software component supplier or buyer is provided, too. Flashline also offers software component certification services, by ”verifying the availability of critical documentation and by disclosing test results”.
2.1. Overview In general, information on software industry is scattered around the Internet. Examples of the pieces of information found from the Internet and discussed in the following are illustrated in Table 1. As is shown by the table, two rather big software component marketplaces exist, flashline.com and componentsource.com. Other component selling sites that were found are very small - some of them apparently more a hobby than any serious business. The two big sites illustrate, however, well the kinds of services that will be needed when selling, distributing and buying software components, especially generic COTS components. Yet, compared to the information on software selling, there is not much information available on the purchasing of software components. The buyers’ side of the software component market would thus obviously deserve more attention. Surprisingly much information - including a few good scientific papers - was found on software component brokering. This includes one company specialising in OEM software licensing consultant work and studies of automated software brokering agents, among others. It is likely that brokering will not end up in any of these ends of the continuum though, but somewhere in the middle. Therefore, it would be interesting to investigate further the strategies, processes, services and support tools of professional brokering firms, for the needs of COTS and OCM software component businesses. Licensing is clearly a special topic that should also be addressed further. A specific issue that became visible regarding software component brokering is application service provisioning (ASP), i.e. renting of software products as opposed to selling software usage licenses. Although ASP may at first sound somewhat irrelevant from the viewpoint of software components, there may very well be cases, where a component is needed only occasionally and its renting - use over the Internet for some specific period of time - becomes an interesting option.
139
Table 1. Examples of the acquired information.
http://www.wrldcomp.com/
Seller of embedded COTS user interface software component(s): user interface engine and application Software component marketplace (small - hobby?) Software component marketplace (big) Software (business) component marketplace (big) Software component marketplace (small) Finnish OEM software company selling components, Droducts and Dlatforms I Software component licensing principles
, http://www.gsia.cmu.edu/bb26/45941market/cmarket.html http://www.flashline.com/
http://www.componentsource.com/ http://www.itseeds.com/softwarecomponents/index.htm http://www.votek.ti/, http://www.votek.Si/te sw co2.htm Chavez et al. 1998 [ 2 ]
~
http://~~~.sei.cmu.edu/publications/documents/98.reports/98tr003 Description of a computer-assisted method for /98tr003abstract.htmI improving the software acquisition process (e.g., for COTS software components) http://interactive.sei.cmu.edu/Columns/COTS S~ot/l999/Decembe View to process and product changes required by r/COTS.decBB.htm commercial software products http://www.esi.es/ GURU software reuse economics method and tool http://www.roguewave.com/corp/press/articles/sdtimes.cSm Poll of industrial views to software components and component-based software development Coniuonent hrokerinp
Http://www.componentsource.com/ is another software component marketplace, but with a focus on businessrelated artefacts. The site markets the opportunity to encapsulate ”existing knowledge” into components that can be sold in the marketplace. The component marketplace is characterised as a means for ”Open Market Component Based Development” that offers buying companies the ability to choose software components for any platform from multiple component authors, and combine them with their own in-house components, in order to build applications. However, there are also other aspects related to building open market components that are necessary regardless the platform, such as utilising
security certificates, providing adequate documentation, and installing the components. For example, security certificates allow developers to digitally sign their components, ensuring their authenticity and preventing them from being altered. This service is provided for componentsource.com by its partner company Verisign (http://www.verisign.com/). [2], a paper by Chavez, ‘Tornabene and Wiederhold, was the only piece of information found to focus on licensing of software components, not only of software products. The main differences that the authors consider between the licensing of software components and products include the following.
140
First of all, components are not stand-alone applications, but form considerable portions of some other application; components should be of high quality, ready to be integrated into the product of the licensee; and most licensees assume that the components can be adapted and modified somehow. From the viewpoint of this paper, the last item is most important, because it means the OCM case, as opposed to the COTS case. According to the authors, this would result in that the licensor of a component makes either the source code or some application programming interfaces available to the licensees. To keep some control over the modifications, the authors suggest that component developers should limit by naming them in the contract - the products into which the component can be integrated, as well as the parts of the code that can be modified. Before making any modifications, the licensee should get a permission from the licensor. The same may hold in more general terms, i.e. access to the component should be limited, especially if the source code or some proprietary application programming interface is available.
Carney indeed concludes that ”the attempt to pin down whether a product fits the perfect definition of COTS is the wrong question: Even if you can determine absolutely that a given package is or isn’t COTS, that won’t tell you what you really need to know”. Some more useful characterisations of commercial software would be needed that ”could aid us both in making choices between competing alternatives, as well as in making the more basic build vs. buy decision”. This holds very well for OCM type software components, indeed, because the build-or-buy decision is apparently even more problematic: the OCM supplier both builds and sells components for the OCM company, which may need to specify what is to be built. ESI The European Software Institute (http://www.esi.es/) has dealt with COTS software components in several different projects. From the viewpoint of component buying, the Guide To Reuse Economics (GURU) is interesting, since it ”at helping organisations to estimate the economic benefits of reuse’’. It provides a framework to quantify return of investments by evaluating reuse-associated costs and savings. Although GURU focuses on in-house reuse, its ideas can be accommodated to the reuse of OCM type external 2.3. Component Purchasing components. For example, GURU helps people in different roles to consider the make-or-reuse (buy) Only a few and rather general pieces of information decisions: software engineers can evaluate whether it is could be found in our survey on the buyer’s viewpoint, i.e. convenient to reuse a component or develop i t from on purchasing of software components. Selected examples scratch; component producers can evaluate the benefits fol Io w. http://www.sei.cmu.edu/~ublications/do~uments/98.re~ from developing a reusable component; and project managers can plan which components are being reused orts/98tr003/98tr003abstract.html is an overview of- the and which are being created within a project. Software Acquisition Improvement Framework (SAIF) of The results of GURU include a reuse economic model the Software Engineering Institute (SEI), based on SEI’S framework to help organisations estimate reuse benefits, a reference model Software Acquisition Capability Maturity tool to support the estimation of the benefits of software Model for buying commercial software products and reuse, and guidelines for using the reuse economic model componcnts. SAIF is a computer-assisted organiser to help framework and the supporting tool. improving the acquisition process. The referred document discusses “rationale behind the need for the SAIF, the elements constituting the SAIF, and the intended 2.4. Component Brokering operational usage of the SAIF”. T o compare, the article on htt~://www.microsoft.com/oem/main.htm provides for “The Elusive Search for Categories” by David Carney (http://interactive.sei.cniu.edu/Columns/COTS Spot/1999 a very good example of the kinds of procedures available /December/COTS.dec99.htm), deals with the question ”Is for OEM hardware vendors, ”new complete or bare-bones PCs or distributing hard disks or motherboards”. It is this product really COTS’?” - i.e., when can a piece of taken here as an example of elaborated brokering services. software regarded as commercially available off-the-shelf The overall set of procedures is called the Microsoft OEM product on which the buyer’s own products can be based. Although the question is after all not the right one, the System Builder program. Information and tools are provided by Microsoft to ”successfully build, sell, and article illustrates well what should be considered by component buyers regarding the supplier’s ability as a support new systems with genuine Microsoft OEM System professional software sales organisation, especially with Builder products”, including promotions, technical regard to the need of the component buyers to go ”from support, system compatibility tools, software downloads, simple installation through more complex and online training. The service is delivered through Authorised Microsoft OEM Products Distributors. parameterisation, through tailoring, through cus tomisation”.
141
What can be ordered by OEM vendors are, for example, Microsoft operating systems, pointing devices, keyboards, selected applications, and system components. Credit, systematic order processing, and fixed delivery times are being offered by the Microsoft distributors. http://www.stromian.com/guide.htm is titled to ”OEM Software Licensing Site: Stromian’s OEM Software Licensing Guide” by Donald K. Rosenberg of the company Stromian Technologies. As Rosenberg characterises, ”OEM sales are widely known in the hardware world, but many companies, including software companies, are still unclear about software OEM licensing”. According to Rosenberg the OEM software business model is similar to that of hardware OEM, ”but is driven by the special pressures of the software industry”. One of the basic concerns is how to ensure that the customers will adopt software by a licensee to increase functionality that ”will add more than enough customers to pay for the license fees”. Stromian Technologies has experience in OEM licensing at Q+E Software and INTERSOLV, as well as ”third-party work licensing software to many vendors of databases, development tools, and applications”. For OEM software vendors Stromian Technologies offers market analysis for the product, partner identification and contact, and negotiations. Rosenberg claims that the OEM software vendor company and its buyer may end up in fighting for gaining the same end-users as ”full customers”. Regarding the pricing of OEM software, ”a complicated, modular product will likely require a correspondingly complicated royalty arrangement”. The ideal may be a flat price or a percentage, and based on boxes sold or users, but on the other hand there may be several other ways of counting and calculating, including seats, servers, sites, and onetime or annual fees. As the licensee’s business changes over time, it is necessary to make changes in the OEM agreement, too. Rosenberg points out that one of the most important things in maintaining the OEM relationship is to ”support the engineering efforts of your licensee as he integrates your product. You will need to specify clearly the standards of support and time limits, as well as the cost for support beyond those limits”. According to Rosenberg, ”the best way generally to handle requests for source code is to agree to an escrow arrangement, and then charge the licensee suitable initiation and annual fees for the service”. The escrow arrangement will ensure the buyer that he will not risk his own business by the use of the present OEM software deal. It is important that the conditions specify that royalties will still be paid even if the licensee obtains the source code from escrow.
The article by Aoyama and Yamashita [ 3 ] , “Software commerce broker over the internet”, describes an approach to a system that would collect information about software components available world wide, and make use of digital catalogues of the components described using a specific language. This language would make explicit both technical and business related aspects of the components. In a related article by Robinson [4] on “Electronic brokering for assisted contracting of software applets”, the kinds of services that a component brokering organisation could offer, are discussed: market-based services (possessing detailed knowledge of the markets, including cumulative information on the development of the markets); requirements-based services (assisting software sellers to match their offerings with the needs of certain markets and customers); and negotiation-based services (matching of sellers and buyers, creating packaged deals as opposed to isolated single transactions - possibly becoming a system integrator helping to put together larger offerings, and helping to organise associated legal, financial etc. services). Robinson’s idea of electronically assisted contracting is in his opinion useful especially i f the market is volatile and the contract to negotiate is complex. Simple contracts in stable markets can be managed by electronic data interchange systems.
-
2.5. Footnote Does OCM Exist Yet? Overall, very little information was found from the Internet on OCM. One might even ask, if the idea of partnership software components - as opposed to COTS software components - even exists yet as a practice. The likely answer is yes, but not as a business model that would have been made explicit, studied and developed as part of component-based software engineering. This can be illustrated by referring to information that is already available on software components in general. For example, http://www.componentsoftware.org/home.html, http://www.cbdhq.com/links.asp,http:Ncetus-links.org/ are link collections to software component related sites. Cetus claims to include structured access to ” 1 8,875 Links on Objects & Components”. Its is ”non-commercial, free of charge, free of advertising, quickly accessible, mirrored all over the world, independent of any organisation, developed and maintained by private people and protected by copyright”. Another way to put this would be that Cetus is a well-developed software component engineering expert community. From the viewpoint of component development and utilisation these kinds of communities are not only useful as structured information sources, but they may at least partially provide an alternative to such commercial software component warehouses as flashline.com discussed above.
142
3. Discussion Referring to above, there seems to exist neither expert communities nor many commercial sites yet that would focus on OCM, as a possible step in the evolution from inhouse software component development and reuse to fully COTS-based software product integration. One of the main conclusions that can thus be drawn from the survey is that OCM components have this far not resulted in considerable business endeavours. Even the two big COTS component marketplaces, Flashline and Component Source, are after all very small compared the total volume of software businesses. As another - domestic - example, in Finland only one small company was found to actively market software components.
3.1. Components vs. Services The services that are provided in this phase by software component sellers focus on quality assurance, testing and component certification - which are obviously the most important technical services. The few existing component marketplaces are not organised according to any application domains or target industries, but based on the technological foundations of the components to be sold (for example, Java, COM, Visual Basic, Corba). In addition to the two big sites, only a few small component selling companies were found. No companies that would sell only OCM components could be find. As discussed above, there exist, however, rather many interest group type, non-commercial sites to leverage information related to components, and even components themselves. General interest in software components is thus quite high. Although this interest in not geared towards business, it may affect the markets, if there is enough convergence in sites managed by the largest communities. The interest groups that were found in this survey do not indicate such convergence, though. The same holds for the commercial COTS marketplaces. The idea that is most visible is more like a software component supermarket than a speciality store. Tone of the basic differences between firms selling COTS and OCM software components, in addition to their size, is thus in the business idea. The component purchasing problem includes the main questions of choosing what components to buy, how to find candidate suppliers, how to evaluate and select components, and how to change the software process for the needs of the externally acquired commercial pieces of software. What is most likely also very important, is how to design and maintain the buyer’s product architecture not only the process - to support the incorporation of soft ware compo ne n ts ,
Moreover, it might be worthwhile to buy some portions of the architecture, too, not only components. If the buyer’s product is a large system, it may include several sub-domains with different software development and purchasing strategies. One conclusion is that when the buyers’ products become “big” enough, there is no more room for any uniform view in software platform and component development and purchasing. Different subsystems of the same large systemic product may be based on quite different strategies and solutions, and involve thereby many different types of software suppliers. Regarding OCM, the Microsoft services to OEM companies, i.e. firms that use authentic Microsoft products and components in their own products, illustrate well the kinds of arrangement that would be needed between companies that develop software products based on externally provided software components and platforms. Especially the idea of an OEM program provided only through authorised distributors - in this case authorised component brokers - would be highly relevant. This kind of program ought to be established at least when selling a family of interrelated components, and could become one of the basic differences between COTS and OCM component suppliers. In the former the services are those of a marketplace, searching, trying, choosing and buying of components. In the latter the choices are usually more limited, and the services would focus on supplying prefabricated subassemblies to the buyers. Rosenberg, an OEM software consultant, proposes that OEM software selling would be of the type prodiict feurure business, the buyer would sell full products of its own? based in part on features provided by the suppliers’ products. This is important from the viewpoint of the expected growth of OCM software sales. Aoyama and Yamashita [3] suggest that the software industry will become divided into component vendors and component integrators. and that the software commerce broker industry will serve as a middleman. This would be comparable to parts manufacturers, system integrators and intermediate wholesale type distributors in other industries. This is an interesting scenario, Flashline and Component Source are clearly good examples of the emerging COTS software component brokers. However, the need and role of a software commerce broker would depend much on the granularity of the purchased components. The bigger the purchased software items are, the less obvious would the role of the broker become, because the relationship would reduce to the ”ordinary” software product selling and buying problem. In this kind of situation, an ASP type broker could have a role, but in the operational use of the OCM components by the end-user, not necessarily during the integration of the product by the component buyer.
143
ASP brokers could also help the end-users in the use of branded third-party components included in the larger assembly put together by the OCM buyer company. The system integrator or component providers could even themselves become ASP type brokers, i.e. system integration could be done in part during the usage time. This indicates that the roles suggested by Aoyama and Yamashita are not clear cut, and may change quite radically due to each party’s business strategies. According to Robinson [4], especially optimisation of software transaction costs would make room for the brokering business, in the first place: brokers must be able to improve the deals, to make it cost-effective for the buyers and sellers to use their services. We believe that this is a valid remark: the brokering businesses must indeed bring some added value. Referring to [2], in the case of OCM type software components this question is even more important. The seller (component developer) and the buyer (product integrator) are likely to have close relationships, and both parties need to be rather much technically oriented. In COTS component developer - product integrator type of cases the relationship is likely to be more distant. Moreover, the buyer may not need to be technically as competent with regard to software development as the component seller is.
3.2. OCM Context To summarise, the OCM context can be divided into three business areas: buyers, intermediaries and sellers: The buyers can be considered either as system integrators or OEM companies, depending on the visibility and modifiability of the purchased components or software products. The sellers are either vertical (including OEM software providers among others) or horizontal (including e.g. COTS component sellers). The intermediaries are relationship brokers that serve mainly vertical sellers or market place providers that focus on horizontal sellers - as well as buyers, of course. The buyers’ needs can be viewed through a three-tier product needs structure, consisting of application, middleware and basic system solutions. Moreover, such support systems as software development and testing environments are needed to build and integrate products. The “small” or “large” number of software products or components to be exchanged has a key effect on all the three types of businesses. In the buyer’s side the corresponding effect could be emphasised by using the concepts of a production company (small number of purchased components) and an assembly company (large number of purchased components).
Referring to above, the concept of OCM is still in its immature developing state, compared to component-based software engineering in general and even to COTS software component businesses. More importantly, our survey indicates that OCM may pay off, if the components to be exchanged are “big” enough, i.e. they come close to software products. Such products may be platforms, by which the buyer integrates its own value-added software. In the case of COTS components the situation is different, due to the generality of the components and the emergence of digital market places with associated services to all parties.
3.3. Further R&D Topics Based on what has been said above, at least three different types of foci can be taken to the further research and development of original software component manufacturing: (1) development of component market places and partner relationships, (2) OCM process creation and improvement, and (3) software productoriented research and development. The first area ( 1 ) would include active development of especially market place management services. One starting point could be identification of a few large buyers and a new or newly established market place management firm. An alternative would simply be to help companies to make use of existing global software component market places. Especially software component developers should be helped to exploit global market places, be they domestic or global. If domestic market places were established, one of the most obvious opportunities would be to focus it on a certain domain of applications, e.g. wireless mobile applications. There are good examples of domainspecificity among software subcontracting service firms, and such companies could serve as partners in this kind of R&D activities. However, strong participation of the future buyers of OCM components would also be needed. One possibility could be to establish software component buyers’ circles in certain domains of applications. Such a circle could both test use the existing market places and help to establish new ones. An important topic for further research would also be (2) making explicit the interplay of the processes of various types of OCM business parties. There exist at least the following problems to study with regard to the processes: Definition and optimisation of marketplace-driven processes: offering, evaluating, and delivering of software components, products and platforms, investigating and analysing markets for the needs of different parties, helping vendors and buyers to
144
make use of the market place processes, building and management of software delivery and maintenance channels (cf. ASP), definition and optimisation of system integration and OEM production processes, and definition and optimisation of software acquisition processes. Improvement of relationship-based processes: productisation of subcontracted software, building of product lines and system family platforms, screening and evaluation of relationship partners, building of contract-based software supplier networks, establishing system integration and OEM environments, and mixing of COTS and customised software components and products. Component-based software development has already changed and will continue changing the internal processes of the most advanced software developer organisations. What has not been achieved, though, is the definition and effective use of processes meant to help using external products, components and platforms. Therefore, process improvement R&D efforts could be directed to make this to happen - similarly to how many software companies have already established and utilised software process assessment and improvement practices during the nineties. The strategic change of the biggest buyer companies towards product lines, software platforms and componentbased software development could be used as a driving force behind the “externalisation” of component-based software production. We consider this more important than, for example, narrowly focused research of specific process measurement techniques. What could be done regarding the latter is to make use of the existing expertise in the acquisition of external pieces of software that is integrated into the buyer’s products through an acquisition process in which the buyer and the seller participate. One of the most obvious directions of iurthcr research and development of OCM, taking into account what is already known about component-based software engineering, is (3) to follow the product-oriented view. In other words, to continue developing software architectures - including both generic reference models and domainspecific or product-specific platforms, component principles, and middleware type integration techniques. The architecture research will, for sure, result in better possibilities for the biggest buyers to make use of external components, products and platforms. Reference architectures for certain application domains could be used as a backbone for the exchange of components, products and platforms. However, not only different types of techniques to evaluate exchanged software should be studied, but also environments by which buyers and sellers can rapidly test new ideas and existing solutions (e.g., OCM software
products). Various types of simulation environments are available and could be instrumented for the needs of “ultra-rapid system integration”. Traditional vertically integrated systems will become more distributed and flexible than what they used to be, and the “lowest” (enabling technologies) and “highest” (service and network access) platforms will become standardised - consider Java and Symbian as examples of the former and WAP of the latter in the domain of mobile telecommunication systems. What will be needed “in between” is an interesting question. Big buyers will make use of product lines to structure the intermediate level, but suppliers may have hard times to segment their offerings. They should be helped to develop software that can be used in similar product lines by buyers representing different market segments. Ultimately, this will lead to sellers’ own product lines. A specific area related to this evolution from the viewpoint of buyers, sellers, and intermcdiaries, is opensource software. One direction would therefore be to carry out research on the use of open-source software in the context of both OCM and COTS components.
References [ I ] Niernelii, E., Kuikka, S . , Vilkuna. K., Lampola. M.. Ahonen, M., Forsell, M., Korhoncn, R.. Seppiinen, V., and Vent& 0. 2000. Teolliser koi~i~~otiei~~riolijelr~iisrot. Kehiiiririiistarlleet jci iaitiieti~~i~e-rh~l~tiiksei.
Teknologiakatsaus 89/2000. Technology Development Center of Finland Tekes (www.tekcs.fi). 129 p. (in Finnish, Abstract in English) [ 2 ] Chavez, A.. Tornabene, C., and Wiederhold, G. 1998. “Software component licensing: A primer”. IEEE Sqfrwire. Septcmbcr/October, pp. 47-53. [3] Aoyama, M., and Yamashita. T. 1998. “Software commerce broker over the internet”. Pmc. of tlze 22nd A t z t ~ ~ t a l Itiieriiritroticil Coinpitier Software citid Applicaiions C~tfire17ce (COMPSAC ‘98),pp. 430-435.
[4] Robinson, W.N. 1997. “Electronic brokering for assisted contracting of software applets”. Proc. of h e 30ili Hawuii Itiierii~iiiot~cil Cutzference 011 Swtetil Sciences, vol. 4. pp. 449-458.
