March 7, 2003
Open Source software sites are the first organized, centralized, multi-vendor, reuse organizations. Earlier reuse organizations have been single vendors that have provided software functionality mainly as operating systems and applications for many customers, even though they may have not have considered themselves a reuse organization.
Multi-vendor collaboration finally makes reuse feasible for some types of software functionality because the cost per function is shared by more customers. Open Source would succeed even more if the common functionality was component based that could be used by many applications, which would mean that the cost is distributed between applications and customers.
Open Source has generally succeeded where there are enough customers to pay (often with labor) for the common product. Eventually it seems that there could be websites devoted to the whole range of prices for software, and payment for developers. Some software may be free, and the developers do not get paid while for other software, the developers are paid. Clients could request software products and select between interested developers. The developer output could be judged by the client, or possibly by a third quality assurance group so that clients can choose between developers in the future. Perhaps payment models could be micro payments or have some base pay plus some pay based on some measure of quality. Improvements in communication mean that developers can be any place and work at much lower cost. Some software will inevitably be developed in this manner.
Some commodity software is expensive to develop, but if created for a generic platform, can last virtually forever. This is the reason that some software producers must go to a services model of payment. This is also an opportunity for the Open Source software movement.
If requirements are Open, then sharing of requirements would also increase efficiency. Platform or architecture requirements could be standardized in a similar manner to how the different licenses have become standardized.
The main problem for Open Source software is that components are generally not reusable by other software. The main reasons are that it doesn't have a standard component communication protocol, and reuse isn't generally a high priority. If this could be improved, the entire software industry would be more efficient. Tools could also be built up around these protocols.
To increase reuse, the dependencies, functionality and interfaces must all be considered. Run-time and compile-time dependencies should be documented. These dependencies will limit the reuse. The entire functionality of the component should be studied. Graphical components are very difficult to reuse because of different customer desires. Functionality in this case also means appearance. Some software such as something like XUL may help in this case. The interface also includes the pre and post conditions (state management) and exception handling.
A component communication protocol should have the following requirements:
multi-platform
multiple coding languages
simple
efficient
functionally layered
bi-directional
independent of memory, process, or thread
factory pattern or ability to find and start other components
In addition, the interface definition of the protocol could be separated from the implementation. This would allow the protocol to be used on top of many types of communication architectures.
Efficiency and simplicity can be conflicting goals. For example, the data respresentation of XML is not the most efficient, but may make the protocol simpler because it can be used to handle versions, and can be a form of "black box" communication. For most applications, it seems that XML (or a subset of XML) may be efficient enough.
A component communication protocol needs to be functionally layered so that simple applications do not get burdened with excess baggage. As example, the lowest layer would handle components within a single non-graphical application. Higher layers can handle multiple processes, threads, machines, synchronicity and networks. Higher layers can also be defined for window interactions of graphical components.
Examples of some existing component communication protocols are shown below.
| Protocol | Comments |
| XPCOM | Too simple, but could have layers added (Used by Mozilla, Netscape) |
| XPLC | Unknown |
| UNO | Not layered, (Used by OpenOffice and StarOffice) |
| ArgoUML | Mainly for one computer language |
| EJB, J2EE, RMI, JINI, JXTA |
Only for Java |
| SOAP, Easysoap++ | Not a full definition. Requires HTTP, and specific libraries |
| Web Services, WSIF | Non-standardized libraries for different languages. |
| XmlRpc, XmlRpc++, | Not a full definition. Requires specific libraries |
| CORBA | Too complex (not layered) |
| Codea | Only for C++ and Apache |
| ACDK | Only for C++ |
| Delphi | Only one vendor |
| COM,
NET,
Next Protocol |
Mainly one vendor, not open source, too complex (not layered) |
A few middleware comparisons are shown below.
| Title | Middleware | |
| Performance Comparison of Middleware Architectures for Generating Dynamic Web Content | PHP, Java servlets, EJB | |
| Comparison of Client-Server Middleware | ONC/RPC, RMI, CORBA, Web services (SOAP/WSDL/UDDI), Jini | |
| Comparison of Middleware Technologies - CORBA, RMI & COM/DCOM | CORBA, RMI, COM/DCOM |
It is very important that the Open Source software industry standardizes on some common protocol. Programmers do not want to write the same software over and over again.