This blog post explains why the Orchex Enterprise Orchestration Engine (EOE) is open-source.
Update 15.Dec.2025: After years of frustration with WordPress, I am finally abandoning this blog. The content will likely stay here for some time, but new content will appear here:
This post is part of a collection of posts that introduce EOE concepts and Orchex specifically:
Orchex believes in honesty, transparency, and sharing human knowledge globally at no cost. We believe that *all* software should be open-source. We think that this is in the best interests of individuals and organizations using any software, but especially for developers. We think that having many eyes and contributors on a codebase will lead to better security, enhanced capability, greater flexibility, and in general, the best possible solutions.
We think that the right way to make money in the technology industry is to provide implementation, hosting, and other services so that deliver more value at lower cost, allowing organizations to focus on product development and strategy and rather than technology, vendor selection, and software costing. It is also important to limit costs, especially in composable solutions that may involve tens of interacting applications, each of which presents some cost to the organization.
One goal of composable architecture is to reduce vendor lock-in by avoiding usage of native proprietary APIs such as one would use in Java or C#. When a solution accesses a vendor’s APIs directly or uses the native JSON formats of such an application, it defeats this fundamental objective of composable architecture, tightly coupling the solution to the underlying service-oriented applications.
Truth be told, it is impossible to avoid tightly coupling a solution to its underlying components. The key questions are where and how that coupling occurs. We want to provide a range of deployment options for Orchex, from SaaS to on-prem, with the ability to migrate as needed.
In a traditional (“monolithic”) application, the coupling occurs between the solution and the vendor’s concrete APIs (as opposed to webservice APIs). In a typical composable solution, the coupling occurs between the client, which may be a browser or a point application or a solution, and the service, which often means a SaaS system. With an orchestration engine, the customer solution is tightly coupled to the EOE rather than specific underlying applications. We feel that it is critical that the customer completely own and understand the EOE.
Especially considering the high failure rate for software and SaaS companies, because an EOE becomes a fundamental component of all composable enterprise solutions, it is critical that it not depend on any vendor that could fail, drop support, force upgrades, change pricing terms, or otherwise risk business cost and continuity. A black box EOE presents significant organizational risk in this context.
We want developers to have control of the systems for which they are responsible. This is not possible with SaaS or closed-source software, which make developers accountable for systems over which they have no control.
deliverystack.net 
One thought on “-Why Is Orchex Open-Source?”