How are user contributions managed so that the software integrity is not affected?

All software is categorised into "core" or "user application" software, and they are managed in two completely different ways. Each end user application platform is made up of core software and application software, the core providing common functionality and the application providing business specific functionality. In effect, the core acts as a rich telecommunications transaction engine and operating environment, into which a mixture of core and user functions are loaded, divided into a series of "modules". It is important to understand that modules are generally completely independent one from the other, with cohesion being provided by the framework engine.

Core software is tightly controlled, and follows a strict release plan. Contributions to the core software are usually only ever made by our people, and we use a version control system to track and manage each and every change to the core. During the release process, we perform regression tests with known inputs and expected results, and manually analyse the changes in system output. Each change in system behaviour must have a rational explanation.

It is important to bear in mind that core software changes may affect all running applications. Therefore we release changes on a slow cycle, which miminises the pain in upgrading. Also it is important to note that we are running a fairly stable platform now, and heavy core changes happen rarely.

We call this process "architectural governance and stewardship", and in our opinion it is the difference between a successful open source project and a failed one. We feel very strongly about our product, and it is our chief business asset, which we defend religiously.

User Application software is different - it is the code which personalises the core to provide the functionality that you require. It is usually a thin layer of application specific functionality over the top of the core. Occasionally, complete new modules are created, and these can pass (after appropriate review, and with appropriate intellectual property negotiations) into the core. We call this process "promotion". At the point it passes into the core, it effectively becomes rigid and falls under the core controls.

User application software is also managed in a version control system, but does not have the same level of transversal checking which core modules have. This means that changes to the user application software undergo specific tests, but not transversal regression tests. Because the amount of user application code is usually small, this means that testing and certification is a quick and painless process.

User application software develops on a different rhythm to the core code - it can have much faster release cycles (hours or even minutes) if required.

Hotfixing and patching. During the operation of the system, it may become necessary to correct a defect within short time scales. We need to understand if the problem is a core problem or a user application problem, and handle the defect accordingly. For a large majority of cases, the defect will be an application one, meaning that the resolution can be made according to the User Application Software release rhythm. Core changes take longer, as the transversal checks need to be performed.

However, OpenRate has a very useful trick up it's sleeve. In the case that a hot fix needs to be provided (neither the core nor the user application software development process can provide a solution in the necessary time scales, a "hot-fix module" will be provided. This either overwrites or replaces the defect code, and with a single change to the configuration file, we load the hot-fix module instead of the standard module containing the defect. OpenRate runs in a fully object oriented environment, and we are able to replace a single method by applying an extension of the core module (patching), or by substituting the module completely (hot-fixing). Recall that modules are independent: this means that the patch or hotfix can be guaranteed to touch a very small element of the functionality, meaning that we have a high certainty of fixing the defect without causing any side effects.
We believe that OpenRate can offer something that no other system can with this.