How we choose open-source components for Affectli

Where it started

Mi-C3, the company behind Affectli, began building its platform in the early 2000s. The first generation was one suite with several tightly integrated modules. It covered a lot of ground at a fair price, but no single module led its field, and a small team was stretched between building features and supporting the people using them.

Those early versions ran on a niche, proprietary technology stack. Engineers who knew it were scarce and expensive, which made the team hard to grow.

The rebuild started from a clear split. Mi-C3 would build the core itself: the semantic ontology and the engines that tie data, rules and work together. For everything else, it would use the best open-source component available. Three principles stayed fixed: the organisation owns its data, it chooses where the platform runs, and the platform does not depend on any one device or system.

Two choices that lasted

The database. PostgreSQL was chosen over the other options of the time, and its later releases have kept adding what the platform needs. Percona provides support and consulting for the PostgreSQL databases behind Affectli, under an agreement announced in April 2021.
The workflow standard. Mi-C3 had written its own workflow engine before. It moved to BPMN 2.0, the industry standard for modelling business processes, and Affectli Designer builds apps, workflows and forms on it today.

Two mistakes worth sharing

Writing our own middleware. The first version passed each request from the browser to a simple service that looked up a stored query and returned the result. It got the product to market quickly. It became a burden as soon as users wanted filtering, sorting, counting and grouping. The fix was a standard query layer built from open-source modules.

Forking a demo application. The workflow engine came with sample interfaces. Taking them, changing them and running them in production was the fastest route at the time. It also left no upgrade path: keeping the fork in step with the public project was so painful that it was done once, to fix a critical bug. The fix was to start again, stop forking, and follow the community’s releases.

Our checklist for any open-source project

Read the licence. Permissive licences such as MIT and Apache pass quickly. Copyleft licences such as the GPL and LGPL raise two questions: will the code be included in ours, and will we need to change it? Product-specific licences with unusual terms are a warning sign.
Look past the open core. Some projects publish a small core and keep everything useful in a paid edition, with little documentation for the free part. Find out where the line sits before you commit.
Check that the project is alive. Look at recent commits, open issues and how maintainers respond. Check that the demos work and the documentation is current.
Count the hidden costs. Free to download still costs time to run. Engineers and operations staff pay in hours, or the organisation pays for support, perhaps under a service-level agreement.
Compare like with like. Can your team deploy and maintain it? Do you have engineers who read the language it is written in? Is it widely used, with a reputable steward? Are maintained container images available?
Try it. Install it, build a small proof of concept, and note how quickly you get stuck and how quickly you get unstuck.

Why it matters to Affectli users

Choosing components this way keeps the platform maintainable over the long term, which matters for software that runs control rooms. It keeps technical debt down, so improvements reach users sooner. And it supports the principle the platform started with: no lock-in to one vendor’s technology. Affectli’s AI follows the same rule, working with different engines and models on live and historical data, without lock-in to one AI vendor.