Open Source Benefits

• Choose your compiler: It improves your ability to write highly portable code if you can create a development environment with a compiler that spans many platforms. Many proprietary products lock you into a single compiler, often linked to the hardware platform. Open source products often support multiple compilers from which you can choose.
• If for some reason you do not want to upgrade the platform O/S, in lockstep with everyone else, you don't have to. You can stay at previous versions and add patches or enhancements selectively.
• If you have a special platform you want the software to run on. Do the port yourself and create an affinity group within the community to help you spread your maintenance activities. Don't let someone else dictate platform policy for your organization. You don't have to follow the crowd.
• If you are a platform vendor and you find your platform is no longer supported, or you think it is poorly supported. Support it yourself! Give your customer base insight into how to tune the software to maximize performance. No longer do you have to worry about a vendor having platform architectural biases, (suspected or real!)
• In general open source slows the pressure to support only a single or very narrow set of platforms. Open source is an inclusionary style for platforms versus the more usual exclusionary style (i.e. support for only popular platforms), traditionally adopted by vendors. The result is open source supports choice. Proprietary systems limit choice.

• You don't need to negotiate putting code in escrow as insurance for critical projects. You have the source code now and forever.
• You can monitor the development activities and measure progress for yourself. No more blind acceptance of a vendor's optimistic delivery dates that are unlikely to be met.
• Everyone can beta test the next release. It is an open process, not restricted to a privileged few. You can verify its stability and features, then plan accordingly.
• It is released when the group feels it is ready, not just to meet revenue targets for management.

• You don't have to wait for the vendor to add features you need. If it is urgent, you can do it yourself.
• When you add features and submit back to the community, a lot of people you don't know, and don't have to pay, but are very smart, will help you improve it. They can't make bad ideas become good ideas, but they can turn good ideas into great ideas.
• If it is really important to you, you too can participate in the overall development process. You can influence schedules and priorities by contributing.
• If it is not that important, you can still enjoy the benefits. Nobody makes you contribute.
• You can patch the code yourself if you need it right away, and post it with the newsgroups to get really quick feedback.
• You don't have to upgrade if you don't want to. You have the source to support yourself at any release level that you choose.
• You do not pay for enhancements you do not necessarily want. You do not pay, period.

• With source available you can use a debugger to navigate as your own code interacts with that of the product. In this way you can isolate bugs, both in your code and the product code, faster. (Developers consider this a huge benefit. The improved productivity is dramatic and substantial enough in itself to warrant consideration for open source as major element of the risk reduction strategy on any major project.)
• While stepping through the product code using a debugger, greater understanding can be gained in how the product works. Your code can cooperate with the middleware more effectively when you understand its behavior.

• With access to the source code, people using a wide variety of platform, operating systems, and compiler combinations can compile, link, and run your code on their system to test for portability. This sort of scale, and parallel debug, cannot be easily duplicated within the confines of a single vendor's testing labs.

• People outside of the core development group are more likely to contribute additional user documentation

• If you need deeper insight into the behavior of the software, it is easier to see with source code, than it is guessing or trying to use reverse engineering techniques.
• Interested users are more likely to exercise the code during beta activities as opposed to only working with the product after it's been released. This means there are more opportunities for user's ideas to be incorporated into the code.

• Users are now stakeholders.
• Everyone must succeed or no-one succeeds.
• There is no adversarial relationship between vendor and client.

• By having access to the source code, developers are better able to provide additional tools and add-on products that can enhance the code functionality. Without access to the source code developers must frequently reverse engineer file formats and API's.

• No hassle evaluation. No time limit pressures.
• No limited use rules restricting the number of evaluators. Everyone who cares can get involved.
• No messy legal paperwork to process, or permission to seek. Only the evaluation consumes your time.

• Many proprietary vendors make you sign agreements that prevent you from publishing benchmarks on their products. No such requirement from open source vendors! We have no interest in suing our stakeholders and partners. They can help us in improving the code. We do not want to hide our results or inhibit evaluation.
• Get those benchmarks out there and let the community assist you in building the right kind of benchmark. Share or improve what is already out there. Open source providers usually will package suggested benchmarks. Build on what is available, this will save you time. Add your benchmark code to the mix. Someone else will likely improve on it for you. The community will also help you interpret them. You must measure what matters. You cannot improve what you cannot measure. The more measuring going on, the more improvement will occur.
• Porting someone else's benchmark to your platform and comparing results helps us all understand implementation differences across platforms. This is an important insight for the evaluation process. Does a product mask or magnify the variation that occurs between platforms?
• Benchmarking when done right can cost a lot of resources. Open source approaches can provide you more leverage. Open approaches can help avoid errors in the selection process.
• Proprietary vendor benchmarks are often very selective. They portray the products in their best light. Open source benchmarks play to the market of free ideas.

• Open source means what you see is what you get. You can inspect the code line by line to ensure that no disgruntled programmer has buried logic bombs, trapdoors, Trojan horses, viruses or any other nasty surprises in the code.
• You do not have to worry that being late with that license fee might result in a locked up system. No worries, as with proprietary systems, that the code may contain the means to disable the software, and effectively your business. Open source is not UCITA!
• No worry that the weak link in a security strategy might be some proprietary application with poor defensive measures. You can add security features to open source if you wish and ensure a consistent level of protection across all applications in the system.

• There are no licensing fees! Neither development nor run-time.
• You can put open source software where you want it, when you want it. Performance and other considerations drive those decisions, not the licensing model constraints.
• No arguing with management about money for license upgrade funding just to stay current. Upgrading is now mostly a technical decision, not just a financial one.
• Your cost model for your products is more predictable, no more sweating about vendor licensing model changes, which might break your pricing strategy.
• There is no vendor to use a combination of licensing and proprietary extensions to keep you locked into an implementation.
• No worries that your vendor might disappear without trace leaving you with node locked software, a roll-out coming up, and no way to implement more licenses. In other words, no way to go into production with your application.
• Switching costs are not inhibited, or influenced, because of their magnification due to the sheer volume of systems involved.
• You can recommend the software to others on its merits, without worrying about cost implications.
• You can build it into, or ship it with your products, as a way to help your customers, and to improve your product's utility, without affecting your pricing edge.
• Your own product's functionality can continue to be improved and take advantage of the open source product's improvements without worrying about the repercussions of your customers having to pay upgrade fees. They can stay current with minimal financial impact. Or you can ship the new version with your product.
• It levels the playing field for those smaller companies who cannot negotiate site licenses and other large discount programs that give larger companies an additional pricing edge.

Object middleware is a special kind of software. Its utility stems from its ability to ensure consistency and interoperability. The value middleware offers includes:

• The ability to provide a standard, stable, consistent interface to a wide variety of applications, on a broad set of platforms and enable their inter-operability.
• It decouples service providers from service requesters.
• It enables parallel development of service and client.
• It hides implementation details behind standard interfaces. This allows the implementation to change without disrupting or breaking existing clients.
• It allows multiple clients to access the same services, often simultaneously.
• It frees the developers of distributed systems from the burden of developing networking software, allowing them to focus on their application’s particular needs.
• It enables the migration of services to new platforms, increasingly diverse and specialized communications technologies, operating systems, and implementation languages.
• It allows legacy systems to be "wrapped" in standard interfaces, giving them the ability to become distributed components as well.
• It allows co-existence of solutions employing multiple languages.
• It protects the existing legacy systems, and yet future proofs what you develop today against language, platform and communications obsolescence tomorrow.

Vendors of proprietary products are typically under pressure to differentiate their product with extensions. These value-added features can often lead to incompatibility and confusion. Vendors must balance standards compliance with maintaining an edge. It is not an easy task. A product that is fully standards compliant can be more easily replaced. To protect market share, middleware vendors must selectively add proprietary new features along with standard ones to maintain a lock on their client-base.

Open source software has no such pressures. Often, as second-generation products, their value proposition is that they support the standard very closely. This is their way to differentiate themselves from the other products already present in the market place. They hope to use the consensus achieved in that standard and experiences from multiple product implementations, as a way to stabilize the technology domain, create a commodity item from that technology and thus create another stable building block in the technology layers that make up distributed systems. Users can then move on to other areas, higher up the ladder of abstraction, to advance technology and create new value.

Applications are the true value added software. Middleware should be "low impedance" software for enabling application interoperability and systems diversity. Software historically has moved towards a monopoly, as a way to achieve easy interoperability via uniformity. Within the middleware market there should be enough diversity to foster innovation and yet with sufficient uniformity to enable cooperation. Open source software can act as a break on the natural progression towards a single dominant vendor. A progression, some would say, towards a monopoly.

In open source the users contribute extensions that they want to see in the product. This might include extensions beyond the standard but they are created by a user's need to inter-operate, not a vendor's motivation to lock in. These activities can become the basis for a standards submission as they can prove the viability of an approach and enable many users to validate their utility, in real life situations.