In this workshop session, the participants examined the issues surrounding the development of an economy of component software.
Market Issues
The fundamental issues surrounding a component software market were effectively reduced to one question: what will people pay for? This question established a framework for our discussion of market issues:
The issue of granularity sparked discussion as to which granularity would become predominant in a software component market. The point was made that there is already a market for small granularity components such as ActiveX controls, JavaBeans, and widgets. Others theorized that the component market would probably have to begin with small, easily controlled components, but that as the market matured, the component size would grow. The point that 'ease-of-use' tends to lead to broader initial adoption was raised to support the point that the preferred granularity would be small at the beginning.
There was discussion over where (in which domain) the component marketplace would develop first. Suggestions included software utility objects or financial services.
The issue of payment models was brought up. Discussion centered on whether payment would tend to be made for design-time use of the component (payment up front before the software is deployed), run-time usage (payment made depending on how often the component is used, or a percentage of sales made with that component), or some mixture of both models. We also discussed pay-per-use services versus subscription services. There was no real consensus on what sort of model might be adopted, and some pointed out that there might not be a dominant payment model.
This led to a further broadening of the topic and we then discussed whether the first widely marketed components would tend to be static software or software services or some combination of both. The point was raised again that there is already a market for static software components, albeit small ones.
This topic was touched upon during the discussion of market issues and then again during the talks. Ideas for possible third-party services included licensing services, verification and security services, wrapper services, software maintenence services, and intellectual property protection services.
Conceptual Issues & Barriers
After the discussion about the market issues, we then turned to broader issues in the development of a component market that are not purely marketing issues. (Some of the marketing issues were subsumed under these conceptual issues.) We had originally intended to talk about barriers to the component market as a seperate discussion, but that discussion ended up merging with conceptual issues, so they are listed together here.
We spent some time discussing the potential dynamics of a component market. In particular, we looked at how the preferred granularity of a software component might affect the market dynamics as a whole. The point was raised that there may be room for both millions of microvendors and a oligopoly of a few dominant vendors. The large vendors have to ability to support complex and sophisticated software components that require a lot of up-front effort and continued maintenence, while the microvendors can more easily provide small, single product components. There would be scales of economies in between.
One participant mentioned that the size of the market may actually tip the market towards the microvendors as the market may not be big enough to support many large vendors. Those vendors that could be supported would be highly specialized. An example might be travolocity.com.
Other participants observed that the size and character of vendors in the market would probably be dependant on where in the software hierarchy the component existed. This is an extension of how the market is structured now. (i.e., a few number of OS vendors but many application vendors and even more web designers).
Participants largely agreed that one of the biggest conceptual issues to tackle (and one of the largest barriers) are the attitudes of both consumers and vendors towards a component marketplace. For example, one participant observed that while many online services market themselves as a place to comparison shop, many of the services or goods that they advertise (i.e., airline tickets or car purchases) are produced by vendors who do not want consumers to be able to easily comparison shop. These vendors will be reluctant to support a technology that commoditizes their goods or services. In response to that point, another participant pointed out that while that reluctance certainly exists, it might be seen as a catalyst to the component marketplace rather than an impediment as small startups will take advantage of the reluctance of the big companies to enter the component market.
Another existing barrier is the lack of consumer confidence in the web or other online technologies. This was touched upon during the talk by Anup Ghosh (Reliable Software Technologies). Before a consumer marketplace becomes large, consumers must feel confident and secure in their purchases, so there is a great need for both consumer education as well as more reliable and secure technology.
One of the biggest conceptual (and marketing) issues to address is the question of which architecture(s) will dominate. Participants debated over whether a consistent architecture was, in fact, needed at all. Most participants agreed that competing architectures created more market competition and therefore more choice in components. One participant observed that a strong component market was dependent on differing architectures to ensure that the best components were developed. Another questioned whether the architectures themselves could be considered components and therefore mixed and matched just as component software products were expected to mix. An observation was made, however, that differing architectures would eventually lead to problems in scalability as the more complex a component became the harder it would be to interface that component to competing architectures.
It was observed that one of the barriers to the component marketplace is the lack of intellectual property protections for the component designers. Several issues, such as rights to derivative work, rights to source code, protection from modifications, and other related issues have not yet been adressed by law.
Talks
Robert Seacord's work on the Duke ORB Walker is based on a model of the component software economy that was widely accepted by session participants; namely, a marketplace which will house many hetergeneous components, some publicly available, and some behind corporate firewalls. The Duke ORB Walker is an automated Internet search engine that walks through this marketplace to collect information about software components that are ORB compliant. It is analogous to how current Internet search engines collect information about web pages and web content. Questions to answer regarding the Duke ORB Walker revolve around mechanisms for searching for other component technologies such as COM, JavaBeans, etc. as well as whether the ORB walker will need to rely on an implementation repository to find ORB compliant components.
This talk led to further discussion regarding the essential infrastructure of a software component market. Session participants considered a simple method of finding usable components as a necessary part of the infrastructure of a component based software market.
Anup Ghosh's work examines a method of providing software certification for software components. The underlying assumption of his work with regards to a software component marketplace is that consumer confidence in the -ilities of a software component is necessary to the widespread adoption of the component marketplace. He examines the use of certification as a viable business model for providing security assurance for software components. Under this model, a potential component is put through a series of pre-planned tests. If the component passes these tests, then it is considered security certified and thus can be considered ready for the component marketplace.
This talk led to a further discussion of what sort of certification services might exist in a component based software market. It was largely agreed that not only would certification of a component's -ilities would be essential, but that further semantic certification would be necessary as well. There was great interest displayed in services that might test a component's semantic correctness.
Martin Bichler discussed the OFFER project, which is a CORBA-based object framework for electronic commerce. One of OFFER's key components is the e-broker, which acts as an intermediary for e-procurement. The OFFER e-broker assists consumers as they peruse heterogeneous e-catalogs and also acts as a price negotiator using auction mechanisms. The OFFER group is also studying what other functionality might be needed in an an e-broker.
This talk led to a discussion about the research question the OFFER group is studying regarding what features might be necessary in an e-broker. Since OFFER is CORBA and Java compliant, there was discussion as to whether the e-broker should be extended to COM, and whether that would be feasible.